Cisco IOS Cookbook, 2nd Edition

Authenticating Login IDs from a Central System

Problem

You want to administer login ID and password information centrally for all routers.

Solution

Cisco changed the AAA syntax slightly in Version 12.0(5)T. The following set of commands allows you to configure TACACS+ authentication in the older (pre-12.0(5)T) IOS versions:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default tacacs+ 
Router1(config)#aaa authentication enable default tacacs+
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK    
Router1(config)#end
Router1#

Newer IOS versions require the group keyword, which defines server groups. Therefore, you would now configure the same functionality as follows:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default group tacacs+
Router1(config)#aaa authentication enable default group tacacs+
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK
Router1(config)#end
Router1#

Discussion

When you configure AAA authentication on a router, it starts to ignore the locally configured passwords in favor of those provided by the TACACS+ server. In this example, we have configured the router to consult TACACS+ for both the login and enable passwords. This is a great labor saver because it means that you don’t have to reconfigure all of your routers just because you want to change passwords. Instead, because the passwords are stored on a central server, you can change them once, and the new passwords instantly propagate to all of your routers. If the router can’t reach the TACACS+ server due to a failure of either the network or the server, then it will resort to using the locally configured passwords.

For audit and control reasons, most organizations that implement AAA supply a unique username and password for each individual user. While it is possible to store all of this information locally on the router, if you have a large number of routers, it is extremely time consuming to reconfigure all of the routers to reflect a password change, or simply to add a new user. One of the main advantages to using TACACS+ for AAA authentication is that none of the information is stored on the router. Instead, when a user tries to log in, the router automatically sends a query to the TACACS+ server to verify the login credentials. This minimizes the configuration on each router. And, because this query is done each time, the information is always up to date.

When TACACS+ is working correctly, the router will prompt for a login ID and password instead of the usual line password only:

freebsd% telnet toronto
Trying 172.25.1.5...
Connected to toronto.
Escape character is '^]'.


User Access Verification

Username: ijbrown
Password: xxxxxxxx
 
Router1>

The most obvious drawback to using a central server for authentication is that it represents a single point of failure. Therefore, TACACS+ allows you to configure several servers:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#tacacs-server host 172.25.1.1 key COOKBOOK
Router1(config)#tacacs-server host 10.12.1.33 key OREILLY
Router1(config)#end
Router1#

Note that we have defined different encryption keys for each server. This is the key that TACACS+ will use to encrypt the session between the router and the central server. It is important to protect this encryption key. The ability to configure different keys for the different servers helps to improve your overall security by making sure that you can always switch quickly to the backup server if you suspect that the primary’s encryption key has been compromised.

The order of these server commands is important because it reflects the order that the router will consult the servers. If the first server is unreachable, the router will resort to the next one, and so on. If no server responds, then the router will use locally configured passwords. This also allows you to easily set up a simple load sharing among multiple servers by making one group of routers use the first server as their primary, and making the second group of routers use the second server. Then you can configure both groups of routers to use the other server as a backup. In this way, you can have all of the benefits of fault tolerance as well as load balancing.

The examples in this recipe and many others throughout this chapter show two sets of syntaxes because Cisco changed the AAA commands in IOS Version 12.0(5)T. The big change is the addition of AAA server groups. In the recipe example, we have opted to use the default TACACS+ group, which consists of all of the servers defined using tacacs-server host commands:

Router1(config)#aaa authentication login default group tacacs+
Router1(config)#aaa authentication enable default group tacacs+
Router1(config)#tacacs-server host 172.25.1.1

However, some organizations are so large that they have to deploy many TACACS servers. In this case, it is convenient to create groups of servers, by either geography or some other logical grouping:

Router1(config)#aaa group server tacacs+ SERVERGROUP-A
Router1(config-sg-tacacs+)#server 172.25.1.1
Router1(config-sg-tacacs+)#server 10.12.1.33
Router1(config-sg-tacacs+)#exit
Router1(config)#aaa authentication login default group SERVERGROUP-A

You can also create groups of RADIUS servers, if required.

By default, the router will allow three login attempts before dropping a session. You can modify this limit using the TACACS+ command tacacs-server attempts. In the following example, we have configured the router to allow only failed one login attempt before dropping the session:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#tacacs-server attempts 1
Router1(config)#end
Router1#

Once you implement this command, the router’s login behavior will change:

freebsd% telnet toronto
Trying 172.25.1.5...
Connected to toronto.
Escape character is '^]'.

User Access Verification

Username: ijbrown
Password: <wrong password>
Connection closed by foreign host.
freebsd%

You can configure the maximum number of failed login attempts to be any number between 1 and 1,000. However, having a high number makes it considerably easier to launch a brute-force password-guessing attack. So in general it is better to keep the maximum number small.

Most large organizations have a security policy that dictates the maximum number of failed logins, with typical values being three or four attempts. Check with your local security department to see what policies you should be following.

See Also

Recipe 3.1; Recipe 4.3; Recipe 4.8