Tuesday, 23 October 2012

User Account Configuration Example - RADIUS Attributes

This blog post will be a continuation of the previous post "User Account Configuration Example - RADIUS Basic" please feel free to reference the material in the previous post. In the exercises below I will take a step further and utilize RADIUS attributes. The lab topology will be the same as the previous post. I utilized VMware Workstation to create an instance of Windows Server 2008 R2 (for the radius configuration), and used an SRX100 for the device configuration.
RADIUS Attributes
RADIUS attributes are used to carry specific data between the client and server. There are a number of attribute types listed in the standard and more than one attribute can be in a single RADIUS message. Specifically we will focus on attribute type 26 which is defined as Vendor-Specific. Attributes can be used to pass information from the RADIUS server to the client (SRX device). Here is a link of the RADIUS Attributes supported in Junos 11.1 for user authentication.

Example#1 - Using RADIUS Attributes to Specify a different User Template
In the previous exercise we set up a RADIUS server to authenticate our test user 'Fred'. The default user template of 'remote' is used to provide read-only access. In this exercise we will to use a different (non-default) user template to provide a different level of access.

To demonstrate this a new user 'Barney' will be created. On the SRX a new user template called 'remote-template-2' will be created with super-user permissions. The RADIUS server will be configured to pass the user template to Junos when 'Barney' logs in. Many templates can be used to provide a wide variety of access policies using RADIUS.

Configuration - Windows Server 2008 R2
1. Create a new user 'barney' (refer to the previous blog post for screenshot examples). Similar to the previous post we will use simple users and user groups within Windows Server 2008.

2. Create a new group 'superusers' (refer to the previous blog post for screenshot examples).

3. Create a new Network Policy on the NPS Server control panel.

4. In this section name the policy, I have used the name 'Junos Superusers' for this policy name. Leave the type as 'Unspecified'.

5. Set the conditions to grant access based on user groups. In this case the user group 'superusers' is used as Barney (our test user) is a member of this group.

6. Make sure to enable PAP under constraints, all other settings can be left at default. Remember PAP passes user information in clear-text so considerations should be made before deploying PAP in a production network.

7. Ensure the only standard attribute is 'Service Type = Login' as outlined below.

8. In this step we configure the vendor specific RADIUS attribute. Essentially we are going to use the 'Juniper-Local-User-Name' attribute to apply a user template to users authenticated with this policy. The screenshots below outlines the configuration.

Configuration - SRX100
The configuration below outlines the command to create a new user template. In this example the name 'remote-template-2' is used and a class of 'super-user' is applied to this template.

Here is what the config looks like.

Now that configuration is complete we can test the login. As you can see below the login is successful. We also confirmed that this user can access the configuration menu.

Below is a packet capture screenshot of the RADIUS traffic that took place to authenticate Barney. In the access-request you can see the username is identified. In the reply the radius code is 'access-accept' showing the user was authenticated Additionally the 'Juniper-Local-User-Name' attribute is passed in the access-accept reply assigning Barney to the class configured under remote-template-2 which is super-user.

Example#2 - Using RADIUS Attributes to Apply Allow/Deny Commands to Users 
In this exercise we will demonstrate how allow/deny commands and configuration can be passed to the Junos device using RADIUS attributes. Currently the user 'Barney' has super-user access, once logged in he could run the command 'request system reboot' to reset the Junos device. We could use the deny-commands RADIUS attribute to limit this command so Barney could not reboot the device while still having access to all other commands. Keep in mind no configuration is needed on the SRX100 for the example.

1. Edit the 'Junos Superusers' Network Policy and select Vendor Specific in the left hand column. Then select the existing Vendor-Specific RADIUS attribute that was configured in the previous example and select 'edit'.

2. A window will open outlining the attribute information. Select 'add' to insert an additional attribute. The goal is to stop the user "Barney' from executing the command 'request system reboot'. Vendor attribute 'Juniper-Deny-Commands' can be used to deny this command. See the screenshots below for detailed configuration.

Now that configuration is complete we can test to see if Barney can run the command 'request system reboot'. As you can see below Barney cannot access the command however he can still access the configuration menu.

Below is a packet capture screenshot of the RADIUS traffic that took place to authenticate Barney. In the access-request you can see the newly configured attribute of "Juniper-Deny-Commands' is in the access-reply packet which prevents Barney from running this command.

Remember to take a look at the RADIUS Attributes supported in Junos 11.1 for user authentication page to see all of the attributes that the Juniper SRX supports. I do not plan to setup TACACS+ in the lab but I am curious to hear from anyone who has.

No comments:

Post a Comment