The TACACS+ System

Home

Resources

Archived Articles

The TACACS+ System

Friday, 01 December 1995 21:09

TACACS+

What Is TACACS+ For?

Network managers are finding that they are managing more and more network devices. Frame Relay and ISDN, not to mention automated dialup, have opened the door to networking even the smallest offices in cost-effective fashion. In more and more cases, all of a company is now being networked, not just the main offices.

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.

Introducing AAA

Authentication determines who the user is and whether he or she should be allowed access to the network. It allows us to bar intruders from our networks. It may use a simple database of users and passwords. It can also use one-time passwords.

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.

Configuring AAA

Let's take a look at how to configure a router or NAS for AAA. Curiously enough, the TACACS+ router commands begin with aaa (what could those programmers have been thinking of).

The first step is to enable it. Use the command

aaa new-model

This 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-address2

The 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

Authentication

That gets the NAS configured to do TACACS+. Now we have to tell it which TACACS+ features to use. The first thing we want is login authentication. We need to create one or more lists of authentication methods to use at login time. These correspond to different ways of authenticating users, for use on different access lines. The following sets up three lists of methods. We'll see how they're used in a moment.

aaa authentication login default tacacs+ line none
aaa authentication login admin_only tacacs+ enable none
aaa authentication login old_way line none

This 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 default

This 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 none

This 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.

Authorization

There's one command governing authorization. It does it all! It uses methods just like the authentication commands above do. The command is

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-authenticated

These 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.

Attribute-Value Pairs

The request packet contains a series of attribute value pairs, sent to the TACACS+ daemon. The daemon can either

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.

Accounting

Finally, you might want to enable accounting. Note that accounting information is sent only to the TACACS+ server, not the console nor to any other device(s).

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 (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 eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has 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/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

Chesapeake NetCraftsmen