Centralize your access control method with AAA

Looking for a more standardized method of controlling access to large-scale networks? In this Daily Feature, Robert McIntire introduces you to configuring AAA with TACACS.

If you’re the network admin for a large corporation and you’re authenticating users based on a local database, you're missing out on a much more centralized access control method: Authentication, Authorization, and Accounting (AAA). As I told you in ”Basic access security for Cisco network devices,” user-based login takes device security to a whole new level. By authenticating users, you can set their access levels and track changes to devices based on the actual user—quite an improvement over shared password environments in which users are somewhat anonymous. This is where AAA access features really shine.

AAA also allows the use of external authentication sources like Remote Authentication Dial-In User Service (RADIUS), which is oriented toward remote, dial-in authentication, and Terminal Access Controller Access Control System (TACACS+), which is often used more for actual network device access control. Here, I’ll demonstrate how to implement an AAA setup using an external TACACS+ server. Implementing this scenario requires an actual server running the TACACS+ server software configured for authentication with your network devices.

Implementing AAA
Methods of access
Many options exist for authentication server software, from freeware to high-cost integrated suites running on Windows, UNIX, and other OSs. Although an in-depth treatment of the TACACS+ software is beyond the scope of this article, suffice it to say that I’ll be using Cisco’s Access Control Server (ACS) server software. TACACS+ provides for centralized authentication security, among other things. Because AAA also gives us the ability to provide for different methods of access, let’s start by configuring TACACS+ for login mode authentication.

In the first line, I start the new security model for AAA. I then need to configure authentication server information. Using AAA, I basically specify services (i.e., PPP, login, enable, etc.) whereby users access the router and associate authentication methods. The methods include enable, login, line, local, none, TACACS+, and RADIUS. For instance, I could configure the login to use a local database of names. In this case, the second line configures login mode to use TACACS+ primarily and to use the line password secondarily. This line is known as a method list; it specifies a name for the method list and may designate several different authentication methods. Here, I’ve named the list user-list. It’s not a bad idea to specify at least two methods of authentication. If the first source of authentication is not available, there will be a backup method. In the third and fourth lines, I designate the server address and a TACACS key, which will also be configured on the ACS server. At this point, I need to apply the method lists I’ve defined to an access point, whether it’s an interface or a line, like so:
Router(config)# line vty 0 4
Router(config-line)# login authentication user-list

Another method of configuring authentication is to set it to default to all access lines using the default keyword in the method list. This statement applies to all interfaces or lines that don’t already have another method list applied. That’s the effect of using the default keyword. It’s a good shortcut for standardizing authentication across all network device ports.

When changing access attributes of a network device, I highly recommend opening another session with the device. That way, if one session is unexpectedly disconnected, another access point will be open. Also, if you need to disable AAA security gone awry, simply use the no form of the command, as follows:
Router(config)# no aaa new-model

You can also remove individual method lists with the no form of the AAA authentication command, as follows:
Router(config)# no aaa authentication login user-list

Controlling access to EXEC mode
With AAA, you can control access to user EXEC mode (login) and privileged EXEC mode (enable). You can control access levels differentiated by login and enable mode and set up granular access levels in between, based on the user or group. In doing so, you can restrict different modes under enable mode, like configure mode or interface configuration mode. You can add commands to the router granting access to specific commands or command modes and assign them to different users. Or you can control the authorization information by assigning it to the user on the TACACS+ server itself. I’ll defer the details of authorization to a later feature, as they are beyond the scope of this article.

Here, I’ve configured AAA to work in conjunction with a TACACS+ authentication server in order to centralize access control and standardize it across all network devices. Security between the access server and router is configured using a key shared amongst the systems involved in the process. When everything is functioning as designed, I’ll have granular, centralized control over who has access to the routers and what they can do when connected. For fallback, I can still gain access to the console port via a local router password. This is only one of several ways it could have been implemented. Rather than use the local login or enable passwords, I could have created a local database of usernames on the router itself. This underscores the key point: The great advantage to AAA is not just the choices for access control, but the flexibility in how they can be implemented.

Editor's Picks