Telecommuting is also becoming popular. In the East and West Coast urban corridors, ISDN is an enabling technology making telecommuting more attractive. In some cases, Internet Service Providers may be another form of access. All those dial-up connections mean we're now managing more access servers. ("Terminal server" evolved into "communications server", now "network access server", or "NAS", reflecting new capabilities.)
Where this becomes challenging is if we want to control access on a per-user basis. With remote access or telecommuting, we need central administration of users and passwords. We might want to do this for routers so that when someone terminates employment, we don't have to reconfigure 30, 100, or more routers. We might want records of who did what, when. We might want specific control allowing some users to do things other users are not allowed to do, even by time of day.
Login control requirements motivated the original Cisco TACACS and XTACACS capabilities. Vikas Aggrawal has done an admirable and voluntary job of adding capabilities to XTACACS. But the underlying protocol has limitations. To meet growing customer needs, Cisco specified a new protocol that deals with the sorts of information communicated between routers or access servers and a "login server". This is the TACACS+ protocol. Preliminary, unsupported server code has been available on ftp.cisco.com, and the necessary client commands have been implemented.
In this article we'll look into the capabilities of TACACS+ in more depth, and we'll look at what's involved in configuring a router to use TACACS+. Let's start by reviewing some terminology.
Authorization determines what the user is allowed to do. It allows network managers to limit which network services are available to different users. It can also be used to limit the commands a new network administrator may issue on corporate NAS's or routers.
Accounting tracks what the user did and when they did it. It can be used for an audit trail or for billing for connection time or resources used (bytes transferred).
Collectively, authentication, authorization, and accounting are sometimes referred to as AAA. Central management of AAA means the information is in a single, centralized, secure database. This is much easier to administer than information distributed across numerous devices.
The TACACS+ protocol was designed to allow effective communication of AAA information between NAS's and a central server. It uses TCP for reliable connections between clients and servers. The NAS sends authentication and authorization requests to the TACACS+ server. It also sends accounting information to the server. This shifts the necessary logic and policy to the database and server software, decoupling it from the Cisco IOS in the NAS.
The only alternative is Radius, also a client-server system. It too provides AAA. Like the current TACACS and XTACACS systems, the server is typically free source code with no vendor support. Recent trade magazine articles have been critical of the increasing number of vendor-specific extensions to Radius.
The first step is to enable it. Use the command
aaa new-modelThis isn't going to do much good unless you tell the NAS where to contact the server:
tacacs-server host ip-addressThe NAS software searches for the hosts in the order specified, so you can set up a list of preferred servers. This provides redundancy in case of failure.
tacacs-server host ip-address2
For authentication and secure communication between NAS and server, an encryption key is typically used (known to both parties). Tell the router about it with the configuration command:
tacacs-server key key
aaa authentication login default tacacs+ line noneThis creates three login authentication lists named "default", "admin_only", and "old_way". The general syntax is
aaa authentication login admin_only tacacs+ enable none
aaa authentication login old_way line none
aaa authentication login list_name method1 method2 ...Each such list can contain up to four methods.
Methods that you can put in these lists:
Method Meaning
enable Use the enable password.
line Use the line password.
local Use the local username database.
none Use no authentication.
tacacs+ Use TACACS+ authentication.
To use these, you might configure something like
line console 0This sets things up so that on the console, tacacs+ is used. If that results in an error, for example the server is unreachable, then the enable password (not the console line password) is used. If that method results in an error (there is no enable password set) then no authentication is required. On the virtual terminals, the fallback is the line password. Note that an error is not the same as a failure: an error means the authentication method failed to respond (or apply), whereas failure means the method said that the user failed authentication.
login authentication admin_only
line aux 0
login authentication admin_only
line vty 0 4
login authentication old_way
line 1 16
login authentication default
We'll leave it up to you figure out how authentication works on the other lines in our example.
Now we've set up to use TACACS+ for ordinary logins. What about privileged access to the router? It works similarly. Specify a default list of methods:
aaa authentication enable default tacacs+ enable noneThis will first try to use TACACS+ to authorize privileged access. If that results in an error (e.g. the TACACS+ servers can't be reached), an enable password is used (the one configured into the router). If that isn't set, privileged access is allowed.
There are also ARA (AppleTalk Remote Access), PPP (Point-to-Point Protocol), and local-override (locally configured user and password) capabilities that can be used in conjunction with this. As they function similarly to the above, we'll move on.
aaa authorization {network | connection | exec | commands level} methods
Choose the keyword (network, connection, etc.) to use based on the following
table.
Keyword What Gets Checked for Authorization
network Check authorization for all network activities,
including SLIP, PPP, PPP NCP's (Network Control
Protocols), and ARA.
connection Check authorization for outbound telnet and rlogin.
exec Determine if the user is allowed to run an EXEC
shell, as in log into the NAS. This keyword may
cause TACACS+ to return user profile information,
such as autocommand information.
commands Check authorization for all commands at the
level specified privilege level level. Valid levels are 0
through 15. Level 1 is normal user EXEC commands.
Level 15 is normal privileged level.
If you don't specify authorization for some of the above functions, the default is none, meaning the command is allowed. There is a slightly different set of methods that are used with these commands. They are:
Method Meaning
tacacs+ Requests authorization information from the TACACS+
server.
if-authenticat Allows the user to access the requested function if
ed the user is authenticated. Note that you're either
authenticated or not, so there should be no methods
after this in the list (success or failure are
possible, but no errors).
none No authorization is performed.
local Uses the local database for authorization.
Here's what that all looks like in practice:
aaa authorization network tacacs+ noneThese commands cause a request to the TACACS+ server whenever a user issues a command requiring an authorization check.
aaa authorization connection tacacs+ if-authenticated
aaa authorization exec tacacs+ if-authenticated
aaa authorization command 1 tacacs+ if-authenticated
aaa authorization command 15 tacacs+ if-authenticated
Caution: the last command above has a side-effect. One you issue it, you will not be able to further configure the router until you either have TACACS+ authorization or can become authenticated. On my test router, I configured a fictitious TACACS+ server. I then had to log out and log back in to become authenticated. At that point I was also authorized to further configure the router.
Thus, if you configure your routers from a file, this ought to be the very last command in the file you feed the router.
accept the request as is
make changes to the request
refuse the request, thereby refusing authorization
Here are the attribute-value pairs used with aaa authorization. They give you some idea of what information is being sent to or returned by the TACACS+ server. This plays a role in understanding how to configure the server, how to tell it what people are authorized to do. It also indicates the degree of control TACACS+ offers: command-specific control, protocol-specific control, and access list control are available, all on a per-user basis.
Attribute Value Description
service=arap AppleTalk Remote Access authorization check.
service=shell EXEC startup and EXEC command authorization
checks.
service=ppp PPP authorization check.
service=slip SLIP authorization check.
protocol=lcp LCP (lower layer of PPP) authorization request.
protocol=ip Modifier used with service=slip or service=ppp to
indicate protocol layer for authorization check.
protocol=ipx Modifier used with service=ppp to indicate
protocol layer for authorization check.
protocol=atalk Modifier used with service=ppp or service=arap to
indicate protocol layer for authorization check.
protocol=vines Modifier used with service=ppp for VINES over
PPP.
protocol=unknown Used with undefined or unsupported conditions.
cmd=x Modifier used with service=shell.
If cmd=NULL, this is an authorization request to
start an EXEC process.
If cmd is not NULL, this is a command
authorization request containing the name of the
command being authorized. For example, cmd=telnet
cmd-arg=x Modifier used with service=shell. When performing
command authorization, the name of
the command is given by a cmd-arg=x pair for each
argument listed. For example,
cmd-arg=www.ccci.com
acl=x Modifier used with service=shell and
service=arap. For ARA, this pair contains an
access list number. For service=shell, this pair
contains an access class number. For example,
acl=1
inacl=x Modifier used with service=ppp and protocol=ip.
Contains an inbound IP access list for SLIP or
PPP/IP. For example, inacl=3
outacl=x Modifier used with service=ppp and protocol=ip.
Contains an outbound IP access list for SLIP or
PPP/IP. For example, outacl=5
addr=x Modifier used with service=slip, service=ppp, and
protocol=ip. Indicates the IP address that the
remote host should use when connecting via SLIP
or PPP/IP. For example, addr=144.100.123.123
routing=x Modifier used with service=slip, service=ppp, and
protocol=ip. Equivalent in
function to the /routing flag in SLIP and PPP
commands. Can either be true or false. For
example, routing=true.
timeout=x Modifier used with service=arap. The number of
minutes before an idle ARA session disconnects.
For example, timeout=120.
autocmd=x Modifier used with service=shell and cmd=NULL.
Specifies an autocommand to be executed at EXEC
startup. For example, autocmd=telnet server.com.
noescape=x Modifier used with service=shell and cmd=NULL.
Specifies noescape (user cannot use the escape
character), equivalent to the noescape option on
the username configuration command. Can be either
true or false. For example, noescape=true.
nohangup=x Modifier used with service=shell and cmd=NULL.
Specifies a nohangup option, equivalent to the
option for the username configuration command.
Can be either true or false. For example
nohangup=false.
priv-lvl=x Modifier used with service=shell and cmd=NULL.
Specifies the privilege level for command
authorization, a number from 0 to 15. For
example, priv-lvl=15.
zonelist=x Modifier used with service=arap. Specifies an
AppleTalk zonelist for ARA. For example,
zonelist=8.
addr-pool=x Modifier used with service=ppp and protocol=ip.
Specifies the name of a local address pool from
which to get the address of the remote host.
There's one command with options for the various types of things that can be logged for accounting purposes. The default is to have no accounting ("there's no accounting for taste.")
aaa accounting {system | network | connection | exec | command level} {start-stop | wait-start | stop- only} tacacs+
This command allows you to activate accounting of several types of events.
Event Type Meaning
system Enables accounting for all system-level events not
associated with users, such as reloads.
network Enables accounting for all network-related requests,
including SLIP, PPP, PPP NCPs, and ARAP.
connection Enables accounting for outbound telnet and rlogin.
exec Enables accounting for EXEC processes (user shells).
command level Enables accounting for all commands at the specified
privilege level, 0-15.
The other keywords indicate when TACACS+ accounting is to take place. We list them in order of increasing amounts of accounting information.
Keyword Meaning
stop-only The NAS sends a stop record accounting notice at the
end of the specified activity or event (command,
EXEC shell, etc.).
start-stop The NAS sends a start record accounting notice at
the beginning of a process and a stop record at the
end of the process. The start accounting record is
sent in the background. The requested user process
begins regardless of whether or not the start
accounting record was acknowledged by the
accounting server.
wait-start Causes both a start and a stop accounting record to
be sent to the accounting server. However, the
requested user service does not begin until the
start accounting record is acknowledged. A stop
accounting record is also sent. In other words, you
can't do it until you're on the record!
Here's what that might look like in a real configuration:
aaa accounting system start-stop tacacs+The intent here is to get start and stop times on system activities, network and outbound connections. If we don't get an accounting record, it's not a big deal. Ditto EXEC level. I'm assuming we might want start and stop records for time of connection calculations. The "command 1" line says that user EXEC (level 1) commands should be logged after they happen.
aaa accounting network start-stop tacacs+
aaa accounting connection start-stop tacacs+
aaa accounting exec start-stop tacacs+
aaa accounting command 1 stop-only tacacs+
aaa accounting command 15 start-stop tacacs+
The last line says to send start-stop accounting records for each privileged command. Do you want to know that it took 0.1 seconds to run your "write terminal" command? The following command will definitely be less verbose:
aaa accounting command 15 stop-only tacacs+One question that comes to mind: does a reload command trigger a stop accounting record? How could it do so after the reload takes place? You can catch reloads with syslog logging instead, but maybe you want to know who issued the reload command.
Caution: Suppose that last line instead was:
aaa accounting command 15 wait-start tacacs+This would mean that privileged level (level 15) commands must be logged before they can take place. This is what you might do if you want an audit trail of who has configured what on your routers. On the other hand, it means that if the TACACS+ server is unavailable, you can't reconfigure your routers. You might want to use the command with "start-stop" in it, unless you're really sure you want an audit trail!
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .