Sample Server Configuration Files

Problem

You want to configure a TACACS+ server to accept AAA requests from your network devices.

Solution

Here is an example of a TACACS+ server configuration file that accepts AAA requests from network devices to authenticate users. Use Example 4-1 as a template to help you build your own configuration files.

Example 4-1. tac.conf sample TACACS server configuration file

key = "COOKBOOK"

accounting file = /var/log/tacacs

user = ijbrown {
 default service = permit
 member = staff
 login = cleartext cisco
}

user = kdooley {
 default service = permit
 member = staff
 login = des l5c2fHiF21uZ6
}

user = $enab15$ {
 login = cleartext happy
}


group = staff {
 # Default Group
}

Discussion

In this recipe, we will look at how to configure Cisco's free TACACS+ server software because we want to show how the TACACS+ server works. Most of the configuration is done at the central server, so understanding a basic configuration helps with understanding AAA services in general. You can obtain a copy of this software via FTP from ftp-eng.cisco.com in the directory /pub/tacacs. Please note that other TACACS+ servers use different configuration syntax; however, the basic concepts are the same.

The first thing you first need to configure is the TACACS+ encryption key. This key must be identical to the one configured on your router configuration with the tacacs-server key command. If the keys are not identical, none of the TACACS+ services will work. In the following example, we use the same encryption key as in Recipe 4.1, COOKBOOK:

key = "COOKBOOK"

To configure authentication for a single user, you need to define a username and password combination as follows:

user = ijbrown {
 login = cleartext cisco
}

In this example, we configured the username ijbrown and assigned it a password, cisco. If you prefer, you can encrypt the password using DES encryption and store only this encrypted form in the configuration file. However, for this example we chose to use a clear text password. The TACACS+ server is now ready to accept authentication requests for this user.

If you choose to use TACACS+ to authenticate your enable password as well, then you will need to define a special enable user called $enabl15$ . The following example creates this enable account by using the password happy. After you define this username, the TACACS+ server will be able to handle authentication requests for the enable password:

user = $enab15$ {
 login = cleartext happy
}

To enable AAA authorization, you need to define command authorization by using a series of grep-style regular expressions. For more information on regular expressions, please see your egrep man page, or Mastering Regular Expressions by Jeffrey Friedl (O'Reilly).

By default, TACACS+ will implicitly deny all commands. So unless you explicitly allow a user to issue a command, it will be denied. Note also that the router will fully expand all commands before sending them to TACACS+ server. This means that if a user types in sh ip rou, as a short form for show ip route, the TACACS+ server will be asked to authorize the long form version of the command, show ip route. This is important to remember when you build your regular expression command statements.

The following example shows how to enable command authorization by using the cmd statement. This configuration example permits the user sarnott to issue all show commands, with the exception of show running-config:

user = sarnott {
 member = staff
 login = cleartext nssor
 cmd = show {
 deny running-config
 permit .*
 }
}

Notice that we have included two instructions in the cmd = show section. The first command, deny running-config, denies the user access to the show running-config command, while the permit .* line enables access to all other show commands. This works because the regular expression .* matches everything.

We mentioned earlier that, by default, the TACACS+ server implicitly denies all commands. This is a fail-safe approach, but it does make things more difficult when you want to allow a large number of commands. Fortunately, you can use the default service = permit command to change this default behavior so TACACS+ will permit any commands that you don't explicitly deny. When you include this command in a user's configuration, users can issue any command they like. If there are certain commands that you don't want them to use, you can use a deny statement to prevent the specific commands, as follows:

user = ijbrown {
 default service = permit
 login = cleartext cisco
 cmd = debug {
 deny .*
 }
}

Here we have configured user ijbrown so he is permitted to access all commands by default. Then we have then specifically denied access to the debug commands by using the cmd statement. You can include several such cmd statements, if required. This illustrates one of TACACS+'s greatest strengths, which is the fine granularity of its command authorization.

TACACS+ also allows you to put users into TACACS+ groups for easier administration. You can define several different profile groups and assign users to them as required. For example, you might create a group for users who are only allowed to look at show commands, another group for users who can do everything except debugging, and an administration group with full access to everything. You simply define a group, build its attributes, and assign users to the group. These users will inherit the group attributes, which will keep administration to a minimum.

Our next example creates a group and assigns a user to the new group:

user = kdooley {
 default service = permit
 member = staff
 login = des l5c2fHiF21uZ6
}

group = staff {
 # Default Group
 cmd = debug {
 deny .*
 }
}

In this example, we have assigned the user kdooley to the group called staff using the member command. This new user will now inherit the group's attributes. In this example, like all other members of the staff group, user kdooley is allowed to use any command except the debug commands.

Finally, if you wish to enable AAA accounting, then you need to define the log file for TACACS+ to store these accounting messages. Interestingly enough, this is the only configuration command required to enable accounting on the server. As soon as you define this accounting file, the TACACS+ server is able to begin capturing these messages from any routers that are configured to send them.

AAA accounting logs can grow rather unruly, especially if you are using command logging. So we highly recommend cycling your accounting log on a daily basis, keeping at least a week's worth of logs in case of emergencies. Recipe 18.11 shows a script that will rotate your accounting log files:

accounting file = /var/log/tacacs