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-address tacacs-server host ip-address2The 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.
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 none aaa authentication login admin_only tacacs+ enable none aaa authentication login old_way line noneThis creates three login authentication lists named "default", "admin_only", and "old_way". The general syntax is
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 0 login authentication admin_only line aux 0 login authentication admin_only line vty 0 4 login authentication old_way line 1 16 login authentication defaultThis 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.
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+ none 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-authenticatedThese commands cause a request to the TACACS+ server whenever a user issues a command requiring an authorization check.
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+ 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 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.
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 works for Chesapeake Computer Consultants, a Cisco Training Partner. He teaches the Cisco ICRC, ACRC, ICWC and CID courses and consults on network design and management. He also teaches a course on the Netsys software. CCCI offers training, and does software development and network consulting. Comments, feedback, and suggestions for future articles: pjw@ccci.com.