You want to configure a TACACS+ server to accept AAA requests from your network devices.
Here is an example of a TACACS+ server configuration file that accepts AAA requests from network devices to authenticate users. You can use this example as a template to help you build your own configuration files:
freebsd% cat tac.conf
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
}
In this recipe, we 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. Please note that other TACACS+ servers use different configuration syntax; however, the basic concepts are the same.
The first thing you 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, 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, you need to define a special enable user called $enabl15$. The following example creates this enable account 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 using a series of grep-style regular expressions. For more information on regular expressions, see the egrep manpage, or Mastering Regular Expressions (O'Reilly).
By default, TACACS+ implicitly denies all commands. So, unless you explicitly allow a user to issue a command, it will be denied. Also note that the router will fully expand all commands before sending them to the TACACS+ server. This means that if a user types in sh ip rou, as a short form for show ip route, the TACACS+ server is 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 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 failsafe 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 that TACACS+ will permit any commands that you don't explicitly deny. When you include this command in a user's configuration, they 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 that, by default, he is permitted to access all commands. We then specifically denied access to the debug commands using the cmd statement. You can include several such cmd statements, if required. This illustrates one of TACACS+'s greatest strengths: 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 the 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, all other members of the staff group, including user kdooley, are allowed to use any command except the debug commands.
Finally, if you wish to enable AAA accounting, you need to define the log file in which TACACS+ will store these accounting messages:
accounting file = /var/log/tacacs
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.
Recipe 4.1; Recipe 4.2; Recipe 4.5; Recipe 18.11; Mastering Regular Expressions, Second Edition, by Jeffrey E.F. Friedl (O'Reilly)
 |
|
|
| Top |