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 }
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
Recipe 4.1; Recipe 4.2; Recipe 4.5; Recipe 18.11; Mastering Regular Expressions by Jeffrey Friedl (O’Reilly)
Get Cisco IOS Cookbook, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.