Access control is a critical aspect of your network security. When we talk about access control in regards to our network infrastructure, we want to control not only the access to the devices themselves , but potentially access to the network itself. Authentication is the process of providing access control by ensuring that the user is who he or she claims to be by examining username and/or password credentials.
Authentication as a component of an AAA architecture relies on the use of external servers running RADIUS or TACACS+ to validate the user s credentials, not local user accounts or shared passwords. In turn , these RADIUS and TACACS+ servers are typically configured to use additional account databases such as Microsoft Active Directory, Novell NDS, or LDAP for user account validation, although they can also use their own local user databases. The benefit of this type of system is the ability to use a centralized authentication authority throughout your enterprise that can not only authenticate management sessions but user network access sessions as well.
Access control on IOS “based equipment is used to control who has management access to the device. Four basic steps are involved in configuring AAA authentication on IOS-based equipment:
Enable AAA. This configures the device to use AAA.
Configure the authentication server network parameters. This defines the AAA server or server group to use for authentication.
Define one or more method lists for AAA authentication. This defines the AAA authentication methods that will be used.
Apply the method lists to a particular interface or line (this is an optional step). This allows you to use unique method lists for each line or interfaces.
Method lists simply define the authentication methods that will be used for AAA and the order in which they will be attempted. When you define a method list, you must apply that method list to a line or interface before it will be used. The sole exception to this is the default method list, which is used for all lines and interfaces. You want to implement method lists so that you have a backup authentication method in the event that the initial authentication method fails.
Server groups are used in conjunction with method lists to define a group of TACACS+ or RADIUS to use for AAA authentication. The primary benefit of server groups is in providing redundancy and failover. For example, if authentication server 1 fails, the other authentication servers in the group will be queried before undertaking the other authentication methods defined in the method list.
Configuring login authentication using Microsoft IAS as the RADIUS server has two main tasks . First you must configure the appropriate IAS settings. Then you must configure the appropriate AAA settings on the IOS-based device. I recommend that you use windows global security groups to identify the users that you want to grant login access. By specifying a group of users, as you will see in the configuration steps, you can restrict who can connect to the equipment.
IAS is not installed by default in a Microsoft server installation. For more information about the installation prerequisites and procedures for IAS, see http://support.microsoft.com/default.aspx?scid=kb;en-us;317588.
Configure the IAS Server The first step is to configure the appropriate user groups and IAS with the RADIUS settings that you need in your environment.
Ensure that you have created the appropriate users and groups in the Microsoft Windows domain. You can do this by running the Active Directory Users and Computers MMC administrative tool.
Run the Internet Authentication Service MMC administrative tool. Right-click the Clients container and select New and then Client. This will start the New Client Wizard.
At the Add Client screen, enter the host name of the RADIUS client and select RADIUS as the protocol. When you are finished, click Next .
At the Add RADIUS Client screen, enter the IP address of the RADIUS client. This is the IP address of the network device on which you want to configure AAA, for example the Cisco router. Select RADIUS Standard as the client-vendor and specify a shared secret. The shared secret can be up to 255 characters in length and is case sensitive. The longer the shared secret value the better the security it will provide and the less susceptible it will be to brute force hacks. As a result, I recommend that at least 22 random alphanumeric /special characters be used. The shared secret will be used later on when we configure the router to use this RADIUS server. Uncheck the box Client Must Always Send The Signature Attribute In The Request. When you are finished, click Finish.
The next step is to configure the remote access policy that will determine which clients will be authenticated. Select the Remote Access Policies container and remove any existing remote access policies. This is very important, because by default Microsoft IAS grants access for any clients that have dial-in permissions enabled in their user account properties. You should start with a blank slate of remote access policies, because IAS will apply the remote access policies in order. As soon as a match is made, the IAS server stops processing the remaining rules. As a result, if you are going to configure multiple rules (for example, if you want to grant a certain privilege level to some users and a different privilege level to others) you need to make sure that they are listed in the order that you want them processed .
Right-click the Remote Access Policies container and select New Remote Access Policies. This will start the New Remote Access Policy Wizard. Enter a name for the access policy. In this example, we will create a policy for users that should have privilege level 15 access, so we will name it CiscoPriv15Policy. When you are finished, click Next.
At the Conditions screen, click Add to add a new condition. At the Select Attribute screen, select Windows-Groups, as shown here, and click Add.
At the Groups screen, click Add to select the user group from Active Directory that you want to use for authentication. Select the group from the Select Groups screen and click Add. When you are finished selecting groups, click OK to return to the Groups screen, and then click OK again to return to the policy wizard. When you have finished adding all of the conditions, click Next.
At the Permissions screen, select whether to grant or deny access based on the policy. In this case, we want to select to grant access. When finished, click Next.
At the User Profile screen, click Edit Profile. This will present you with the Edit Dial-in Profile screen. Click the Authentication tab and select only Unencrypted Authentication (PAP, SPAP) as shown next. Cisco does not support any of the encryption methods, but it will use the shared secret to encrypt the password, so make sure that you use a long and difficult shared secret to provide a stronger level of encryption. As previously mentioned, you should use a shared secret of at least 22 alphanumeric/special characters in length.
Click the Advanced tab and remove any existing attributes. Once you have done that, click Add to add the vendor specific attributes that will be used by the remote access policy. Scroll down and select Cisco-AV-Pair and click Add.
At the Attribute Information screen, click Add and enter shell:priv-lvl=15 in the Attribute Value box, as shown next. When you are finished, click OK two times to return to the Add Attribute screen.
Repeat steps 11 to 12, this time selecting Service-Type as the attribute with an attribute value of Login, as shown next. When you are finished, click OK and then Close to return to the Edit Dial-in Profile screen. Click OK to return to the access policy wizard. You may be prompted to decide whether you want to review the corresponding help file. Select Yes or No, as appropriate.
At the User Profile screen, click Finish. This will create the remote access policy that allows members of the group you specified to be able to log in to the network device and access the privileged mode of operation. If you wanted to create another remote access policy that granted only user mode access (for example to your help desk or network design team), you could repeat steps 6 to 13, selecting to set the value in step 12 to shell:priv-lvl=1 .
Remember that remote access policies are applied in order. As soon as a match is found, the RADIUS server stops processing. So, for example, if you have a user that is a member of the network admins group (privilege 15) and the help desk group (privilege 1), if the remote access policy for the help desk group is first in the order, the user will never be able to gain privilege level 15 access.
Configure AAA on the Network Device Once the IAS server has been configured correctly, the next step is to enter the AAA commands on the IOS-based device to configure it to use RADIUS for authentication. The following steps detail this process:
Use the AAA command to configure the AAA authentication on the device. At the global configuration mode, enter the following:
local-rtr(config)#aaa new-model local-rtr(config)#aaa authentication login default group radius local
This will configure the device with a default method list that uses RADIUS as the primary authentication and the local user database as the backup.
Configure at least one local user as a backup user in the event that the RADIUS server is unavailable. This can be done by entering the following command at the global configuration mode:
local-rtr(config)#username backupadmin privilege 15 password difficultpass
Now configure the device with the RADIUS server settings by running the following commands at the global configuration mode. Make sure that you specify the exact RADIUS key that you used when you added the client to the RADIUS server in step 4 in the previous section.
local-rtr(config)#radius-server host <radiusserverIP> auth-port 1812 acct-port 1813 local-rtr(config)#radius-server key <theradiuskeyfromabove>
At this point, you should be able to connect to the device using RADIUS authentication. However, this is only part of AAA. While the user will be authenticated, you will still need to use the enable password to enter the privileges mode of execution until you complete the authorization steps detailed in the section Hardening Your Network with Authorization. The final step is to save your configuration when you are finished by running copy running-config startup-config at the command-line interface (CLI).
Like configuring login authentication using RADIUS, TACACS+ requires two steps. The first step is to configure the Cisco Secure ACS server properly. The second step is to configure the IOS-based device properly.
Configure the Cisco Secure ACS Server Configuring the Cisco Secure ACS server includes first configuring the server to authenticate using a Microsoft Windows user database. The benefit of this system is that your administrators can connect to and manage the network equipment using the same username and password that they use to log in to the Microsoft workstations. The steps to configure Cisco Secure ACS are as follows :
Connect to the Cisco Secure ACS server and click External User Database in the navigation bar. This will bring up the External User Database screen.
Click Database Configuration, and at the next screen click Windows Database. The Database Configuration Creation table will appear:
Click Create New Configuration. Enter the name for the new configuration for windows and click Submit.
In the External User Database Configuration table, click Configure.
This will present you with the Windows User Database Configuration page. By default, Verify Grant Dialin Permission To User Has Been Enabled is checked. Check or uncheck this as appropriate in your environment. If you are not sure, leave it checked and make sure that the users that you want to authenticate with TACACS+ have that setting checked in the user properties in Windows 2000.
Scroll down to the Configure Domain List table and select the domains that you want Cisco Secure ACS to try in the event that the username is not qualified by a domain (for example, if it is not in the domain\username format).
Scroll down to the MS-CHAP Settings and Windows EAP Settings tables and enter the appropriate values for your environment. If you are unsure of what to use, leave them at their default values.
When you are finished with the configurations, scroll down and click Submit.
The next step is to configure an unknown user policy. This tells the Cisco Secure ACS server what to do in the event that it can not authenticate the user using the local database. For example, you can use this to tell the Cisco Secure ACS server to attempt to validate the user against the domain that you just added.
In the navigation bar, click External User Databases, and then click Unknown User Policy.
In the Configure Unknown User Policy table, select Check The Following External User Databases and move the appropriate external database to the selected databases field, as shown next. When you are finished, click Submit.
Next, configure the database group mappings that will define what access will be permitted by the user.
You can do this by clicking External User Databases in the navigation bar, and then clicking Database Group Mappings.
In the Unknown User Group Mappings table, click the name of the external user database that you want to configure.
In the Domain Configurations table, click New Configuration.
This will take you to the Define New Domain Configuration table. Select the domain that you want to configure and click Submit.
You will be returned to the Domain Configurations screen, where two entries should appear. The \DEFAULT entry is used to define what to do with any users not explicitly matched to a group. By default, they are made members of the Default Group. The other entry is the domain that you just added. Click it.
In the Group Mappings for Domain <YOUR DOMAIN> table, click Add Mapping to add a new NT group to CiscoSecure group mapping.
This will take you to the Create New Group Mapping for Domain <YOUR DOMAIN> table. Select the NT group that you want to map to the CiscoSecure group and click Add To Selected. Once you have added all of the NT groups, select the CiscoSecure group that you want to map from the drop-down list, as shown next. When you are finished, click Submit.
The next process is to configure the CiscoSecure groups with the appropriate permissions. You want to configure at least two groups. The first group is the default group. By default, all users that are not mapped to another group are members of the default group. Because this group could potentially grant anyone access to your resources, I strongly recommend that you configure the group with access restrictions that do not allow connections at any time. This will ensure that no one can accidentally connect to your equipment. You can do this by performing the following steps:
Click Group Setup in the navigation bar. Select 0: Default Group in the Group drop-down box and click Edit Settings.
In the access restrictions table, check Set As Default Access Times and click Clear All, as shown next. This will prevent any user who is a member of the Default Group from being authenticated. When you are finished, click Submit.
You will be returned to the Group Setup screen. Select the group that you configured for the group mapping and click Edit Settings.
Scroll down to the TACACS+ table to configure the TACACS+ settings. Check the values for Shell( exec ) and Privilege level. For the privilege level, specify 15, which will grant the users of this group full access to the network device. While this is not required for authentication, it will be used for authorization when we discuss that. When you are finished, click Submit + Restart.
The next step is to configure the Cisco Secure ACS server to allow the network device to authenticate against it. This is similar in function to adding the client to the RADIUS server, which you did previously.
Click Network Configuration in the navigation bar.
In the AAA Clients tables, click Add Entry.
In the Add AAA Client table, enter the hostname, IP address, and preshared key that should be used, and select Authenticate Using TACACS+. When you are finished, click Submit + Restart.
Because Cisco does not hide the key value, make sure that people are not watching over your shoulder when you configure the key value.
Configure AAA on the Network Device Once you have configured the Cisco Secure ACS server properly, the next step is to enter the AAA commands on the IOS-based device, configuring it to use TACACS+ for authentication. The following steps detail the process:
Use the AAA command to configure the AAA authentication on the device. At the global configuration mode, enter the following commands:
local-rtr(config)#aaa new-model local-rtr(config)#aaa authentication login default tacacs+ local
This will configure the device with a default method list that uses TACACS+ as the primary authentication and the local user database as the backup.
Configure at least one local user as a backup user in the event that the TACACS+ server is unavailable. This can be done by entering the following command at the global configuration mode:
local-rtr(config)#username backupadmin privilege 15 password difficultpass
Now you want to configure the device with the TACACS+ server settings by running the following commands at the global configuration mode. Make sure that you specify the exact TACACS key that you did when you added the client to the TACACS server in step 4 in the "Configure the Cisco Secure ACS Server" section.
local-rtr(config)#tacacs-server host 192.168.173.100 local-rtr(config)#tacacs-server key tacacskey
At this point, you should be able to connect to the device using TACACS+ authentication. This is only part of AAA, however. While the user will be authenticated, you will still need to use the enable password to enter the privileges mode of execution until you complete the authorization steps detailed in the section Hardening Your Network with Authorization. The final step is to save your configuration when you are finished by running copy running-config startup-config at the CLI.
Configuring access control using AAA on a PIX firewall is similar to configuring your IOS-based devices. The first step is to configure the TACACS+ or RADIUS server as follows:
Configure the appropriate users/groups.
Add the PIX firewall as a new client.
Define the remote access policy (RADIUS).
These steps are the same as those for configuring your IOS-based devices. What is unique are the commands that must be run on the PIX to configure it to use RADIUS or TACACS+. Those are the final steps required to configure the PIX to use AAA authentication.
The first step in configuring the PIX to use RADIUS authentication is to run the following commands:
firewall(config)# aaa-server RADIUS protocol radius firewall(config)# aaa-server RADIUS (inside) host 192.168.173.100 radiuskey timeout 10
These commands configure the PIX to use the AAA server that you have specified.
The next step is to configure the PIX to use RADIUS for all of the connection methods as follows:
firewall(config)# aaa authentication serial console RADIUS firewall(config)# aaa authentication telnet console RADIUS firewall(config)# aaa authentication ssh console RADIUS firewall(config)# aaa authentication http console RADIUS
The steps to configure the PIX to use TACACS+ are almost identical to the RADIUS configuration. First you configure the PIX to use the appropriate AAA server, and then you configure authentication on the various connection methods.
firewall(config)# aaa-server TACACS+ protocol tacacs+ firewall(config)# aaa-server TACACS+ (inside) host 192.168.173.115 tacacskey timeout 10 firewall(config)# aaa authentication serial console TACACS+ firewall(config)# aaa authentication telnet console TACACS+ firewall(config)# aaa authentication ssh console TACACS+ firewall(config)# aaa authentication http console TACACS+
In addition to being able to authenticate users for administrative sessions on the PIX, you can also use AAA to authenticate users through PIX. This is an excellent method of controlling who can and cannot access Internet resources if you cannot afford a content filtering solution.
The PIX does not grant access to the privileged mode to users, as do your IOS-based devices. Instead, you will still need to use a local username and password, the AAA user password, or the enable secret password, to enter privileged mode. The command aaa authentication enable console < server_tag > can be used to provide an extra level of security by requiring the user to be authenticated to enter the enable secret password.
To configure PIX enable authentication, perform the following steps:
At the Cisco Secure ACS server, go to the Interface Configuration TACACS+ (Cisco IOS) screen.
Scroll down to the Advanced Configuration Options table, and check Advanced TACACS+ Features. When you are finished, click Submit. This will enable the Advanced TACACS+ Settings table in the User Setup.
Go to the User Setup screen and enter the name of the user you want to manage. Click Add/Edit.
Scroll down to the Advanced TACACS+ Settings table and set the Max Privilege for any AAA Client to Level 15. Next, select To Use External Database Password and select the appropriate user domain. This will allow the user to enter privileged mode by entering his password (not the enable secret password). When you are finished, click Submit.
The last step is to configure enable authentication by running the following command:
firewall(config)# aaa authentication enable console TACACS+
Once you have taken care of the previously mentioned pre-configuration tasks on your AAA server and configured the PIX to use AAA, the next step is to run the appropriate commands to configure the authentication. Two methods can be used, though you should never mix their use.
Authenticating Using AAA Authentication Include The first method is to run the command aaa authentication include < svc > < if_name > < l_ip > < l_mask > [ < f_ip > < f_mask > ] < server_tag >for each service that you want to authenticate. For example, if you wanted to authenticate all HTTP traffic at the inside interface using TACACS+, you would run the following:
firewall(config)# aaa authentication include HTTP inside 0 0 0 0 TACACS+
Any user that attempts make an HTTP connection from the inside will be prompted for a username and password. If the user is authenticated, the HTTP traffic is permitted. If not, the HTTP traffic is denied . While the example provided here covers all traffic, you could also specify certain internal or external addresses that must be authenticated to access, while allowing others to pass without authentication.
Authenticating Using AAA Authentication Match The second method allows you to leverage any investment that you have made in access control lists (ACLs) by configuring the PIX to authenticate traffic that matches an existing ACL. For example, if an existing ACL defined the traffic that could pass through the interface, and the ACL was named 101, you could run the following command:
firewall(config)# aaa authentication match 101 inside TACACS+
The benefit of this method is that since the ACL has already been created, it takes a single command to apply authentication to it.