AAA Overview

AAA provides a cohesive framework to control who can access a router, what services they can use on a router, and what they can do on a router. The following sections cover the functions of AAA, as well as how to enable it.

AAA Functions

AAA has three main components:

  • Authentication

  • Authorization

  • Accounting

The authentication component of AAA is responsible for providing a method to identify (authenticate) users. This can include login access, as well as other types of access, such as PPP network access. With AAA authentication, you define one or more authentication methods that the router should use when authenticating a user. For example, you could specify two authentication methods: use an external security server, and, if this is not available, use the local username database on the router. As you will see later in the chapter, you can use many methods to perform authentication on your router.

When authentication for a user successfully has completed, AAA's authorization is used to restrict what actions a user can perform or what services a user can access. For example, you might want a network administrator to have privileged EXEC access, but want him to use only the debug command. With AAA authorization, you can enforce this restriction.

AAA's accounting component is responsible for keeping a record of events of authentication and authorization actions. This can be as simple as keeping track of who logs into a router and any status changes on the router (such as an interface going down or the router being reloaded), or something as complex as keeping track of each command that a user executes on a router. The accounting of AAA keeps a log of these events. One restriction of the accounting component is that it requires an external AAA security server to store the actual accounting records.


AAA is the recommended Cisco solution for implementing access control. Note that other solutions exist, such as those that I discussed in Chapter 3, but AAA is the preferred one.

Enabling AAA

You need to configure many things to implement AAA. This book focuses on only the router configuration (configuring an AAA security server is beyond the scope of this book). To configure AAA, you need to perform the following steps:

Step 1. Enable AAA.

Step 2. Configure the parameters for an external AAA server, if used.

Step 3. Define the method or methods you will use to perform authentication.

Step 4. Optionally, configure authorization to restrict what the user can do on the router.

Step 5. Optionally, configure accounting to keep track of what and when events occur on the router.

By default, AAA is disabled on your Cisco router. To enable it, use the following command:

Router(config)# aaa new-model

As you can see, enabling AAA is a very simple process; however, this is only the first step in configuring AAA on your router.

Security Protocols

If you want to centralize your AAA implementation, you use one or more AAA security servers. Many products are available on the market, including the Cisco Secure Access Control Server (ACS). Centralizing AAA provides these benefits:

  • Scalability

  • Redundancy through multiple AAA servers

  • Flexibility

If you decide to use an AAA server to centralize your AAA security policies, you need to use a security protocol between your router and the AAA server. This protocol is used to exchange AAA messages. In most situations, three security protocols are used:

  • Terminal Access Controller Access Control System Plus (TACACS+)

  • Remote Authentication Dial-In User Service (RADIUS)

  • Kerberos

Of these three, TACACS+ and RADIUS are the more common. The following sections discuss and compare TACACS+ and RADIUS; Kerberos is not discussed in this book.

Scalability Example

I once dealt with a client that had 1,300 routers in its network. When I walked through the company's door, authentication/authorization was not centralized; it was localized on each router. The problem with this situation was that the company hired many contractors, who came and went on a weekly basis. Because authentication was localized, contractors were given only the user EXEC password, greatly limiting their usefulness as systems administrators and putting a very large workload on the full-time employees. We designed a centralized solution using Cisco's Cisco Secure ACS security server product.


TACACS+ is a third-generation security protocol, with roots in XTACACS and, before that, TACACS. TACACS+ is a Cisco-proprietary protocol that facilities the use of AAA. Basically, it defines how a router and an external AAA server communicate. TACACS+ supports all three components of AAA. It enables you to modularize the AAA components for security purposes: One or more AAA servers can be used to handle these components. For example, you could have one AAA server handle authentication and another handle authorization for a router using TACACS+.

TACACS+ provides an additional layer of security by authenticating access to the security server, as well as encrypting messages between the router and the server, protecting your AAA transactions from prying eyes.

To use TACACS+, you need a router that supports it (Cisco IOS 10.3 and later) and an AAA server with the TACACS+ daemon software. Even though TACACS+ is Cisco proprietary, Cisco has pushed its acceptance in the network marketplace by placing it in an RFC draft state with IETF. This allows other vendors to implement TACACS+ in their AAA security server solution. Cisco provides two commercial products that support TACACS+ (Cisco Secure ACS for Windows and UNIX), as well as a freeware version of TACACS+ that runs on Linux.


Note that Cisco Secure ACS for UNIX is scheduled to be end-of-life shortly and no longer will be available. If you want to deploy Cisco Secure ACS, I recommend that you purchase the Windows version.

If you will be using TACACS+ on your router, you need to perform the following AAA tasks:

Step 1. Enable AAA with the aaa new-model command (required).

Step 2. Specify the location and authentication/encryption key of the TACACS+ server or servers with the tacacs-server host and tacacs-server key commands, respectively (required).

Step 3. For authentication, specify the use of the external security server using TACACS+ with the aaa authentication command (required).

Step 4. For authorization, specify the use of the external security server using TACACS+ with the aaa authorization command (optional).

Step 5. For accounting, specify the use of the external security server using TACACS+ with the aaa accounting command (optional).

When you have enabled AAA with the aaa new-model command, you are ready to set up TACACS+ so that you can communicate, through TACACS+, with your external security server. You can use two commands to set up this communication link:

Router(config)# tacacs-server host IP_address [single-connection]

  [port port_#] [timeout seconds] [key encryption_key]

Router(config)# tacacs-server key encryption_key

Of these two commands, only the first is required. The tacacs-server host command specifies the location of the server. You can specify either an IP address or a host name (that DNS resolves to an IP address or statically resolves with the router's ip host commands) for the location of the server. The single-connection parameter causes the router to set up a dedicated TCP connection that TACACS+ will use between the router and AAA server. This option should be used to limit the number of TCP connections that the router opens to the AAA server. As long as traffic is being passed between the router and the AAA server, the single connection remains up; however, it is brought down when the connection is idle and must be re-established when new traffic needs to be sent. Note that this option does not provide any real performance advantage, but it slightly decreases the amount of time that it takes to handle multiple successive AAA requests to the server.

The default port number that an AAA server uses for TACACS+ is TCP 49. If you change this on the security server, you also need to reflect that change with the port parameter. Optionally, you can change the timeout for the TACACS+ server communication with the timeout parameter. If this value is reached and you have other TACACS+ servers configured, your router will try using one of the other servers.


If you specify more than one AAA server for redundancy, the first server configured is used, by default. If this fails, the second server that was configured is used, and so on. Therefore, the order in which you enter the tacacs-server host commands is important.

Also, if you have an inbound ACL restricting traffic on the interface on which the TACACS+ server is located, you need to permit TCP port 49 in the ACL.

If you have more than one TACACS+ server and each server uses a different encryption key, you need to use the tacacs-server host command, along with the encryption key in the key parameter. However, if all your TACACS+ servers use the same encryption key, you can omit this from all your tacacs-server host commands and specify it once with the tacacs-server key command. If you have both specified, the key configured in the tacacs-server host command takes precedence for the specified host over the key configured in the tacacs-server key command.


The encryption key that you specify on the router must match the one found on the AAA server; otherwise, the two devices will not be capable of decrypting each other's messages.


Like TACACS+, RADIUS is a security protocol used to communicate AAA information between a device and an external AAA security server. Many AAA products support RADIUS: Unlike TACACS+, RADIUS is an open standard, defined primarily in RFCs 2865?2869. The Cisco IOS supports RADIUS as of Cisco IOS 11.1, and Cisco continually enhances the Cisco IOS to add additional RADIUS features and functions.

Unlike TACACS+, RADIUS uses UDP to share information between a device and the security server in a client/server manner. One downside of using UDP is that it requires extra steps to ensure that information that was sent was received by the destination. Cisco networking devices function as a client component, whereas a security server, such as Cisco Secure ACS, functions as a server component. The client is responsible for passing all authentication information to the RADIUS server, and the RADIUS server is responsible for authenticating the user and returning all necessary information to the originating device. RADIUS uses a shared key to protect password information sent between two devices. Basically, the shared key is used to encrypt and decrypt the passwords (such as a user's password for his account); password information never is sent across the network in clear text. This is different from TACACS+, which encrypts the entire AAA message, including the password information.

RADIUS typically is used in the following situations:

  • You have networking devices from multiple vendors and need a single security protocol to communicate with them.

  • You need to implement resource accounting, such as keeping track of how long a user was logged in to a networking device or dialed up to the network.

  • Some smart card authentication systems support only RADIUS.

  • You want to use preauthentication before allowing a user initial access to a device (I discuss this process in Chapter 14, "Authentication Proxy").

RADIUS has its limitations, such as the use of UDP, the encryption of only password information, and additional limitations:

  • It does not support AppleTalk's Remote Access Protocol (ARAP), the NetBIOS Frame Control Protocol (NBFCP), NetWare's Asynchronous Services Interface (NASI), and X.25 PAD connections (these are all dialup services).

  • RADIUS sometimes cannot be modularized. In other words, your networking device sometimes must use RADIUS for all AAA functions, not just some specific ones.

  • It supports only one-way authentication: It does not support two-way authentication, as with PPP's CHAP authentication between two Cisco routers.

  • Unlike TACACS+, RADIUS combines authentication/authorization functions into "authentication," giving you less flexibility in modularizing your AAA processes.

The steps involved in setting up and using TACACS+ are basically the same as those configured to use RADIUS. The main difference is the specification of RADIUS communication instead of TACACS+ when communicating to an AAA security server. Here are the basic commands for specifying your AAA servers using RADIUS:

Router(config)# radius-server host IP_address

  [auth-port port_#] [acct-port port_#] [timeout seconds] [retransmit retries]

  [key key_value] [alias {hostname | IP_address}]

Router(config)# radius-server timeout seconds

Router(config)# radius-server retransmit retries

Router(config)# radius-server key key_value

As you can see from these commands, the configuration is not that much more complex than when setting up TACACS+. The radius-server host command specifies the location to the AAA server running RADIUS, including access parameters. You can specify either the IP address of the AAA server or its host name. The auth-port parameter specifies the UDP port that the server is using to listen for RADIUS authentication messages. This defaults to UDP 1645. RADIUS accounting messages use UDP 1646, but you can change this with the optional acct-port parameter.


Note that you can have more than two RADIUS services running on the same device. If this is the case, at least one of the services must be using different port numbers for authentication and authorization. This sometimes is done for redundancy or separation of AAA policies on the AAA server.

Also, if you have an inbound ACL restricting traffic on the interface where the RADIUS+ server is located, you need to permit UDP ports 1645 (authentication and authorization) and 1646 (accounting) in the ACL.


In RFC 2026, RADIUS also uses UDP ports 1812 and 1813. Therefore, most newer RADIUS server implementations (and some client ones) listen on four UDP ports: 1645, 1646, 1812, and 1813. You need to be aware of this on intermediate routers that have ACL filters, as well as perimeter routers that have internal inbound filters. Be sure to allow the appropriate ports so that RADIUS traffic can travel between the clients and servers.

The default timeout for a RADIUS server connection is 5 seconds; this can be overridden with the timeout parameter (a specific AAA server) or globally with the radius-server timeout command. Typically, this does not need to be changed unless the traffic between the router and the AAA server must travel many hops and has packet manipulations performed on it, such as encryption or address translation.

By default, the router tries to contact the AAA server using RADIUS three times before giving up and trying another method. This can be changed with the retransmit parameter for a specific AAA server or globally with the radius-server retransmit command.

As with TACACS+, you can specify the encryption key (for passwords only) either globally or per server. If you are specifying the key globally, use the radius-server key command. To override the global setting for a specific server, use the optional key parameter in the radius-server host command.

You also can specify an alias or aliases for a RADIUS server?other names or IP addresses configured on it by using the alias parameter.


You actually can use many more commands to set up RADIUS. Some of these are used when connecting to a server running a proprietary implementation of RADIUS; most are used for dialup functions. Because this book covers only basic AAA functions, such as login access control and command restriction, I do not go into the details of these additional commands.

Server Groupings

One of the limitations of using the previously mentioned TACACS+ and RADIUS commands is that the first server that you enter becomes the primary, and the rest are backups. In some situations, you want to divide your AAA servers into groups, with one group handling authentication and authorization functions, and another handling accounting. This can be accomplished through one of two methods:

  • Set up your primary AAA server to redirect AAA requests to the appropriate AAA server.

  • On your router, use server groupings to direct AAA messages to the correct group of servers.

This section focuses on the latter method.

Basically, a server grouping is a list of the AAA servers' host names or IP addresses. You need to configure two things for grouping servers together:

  • Your tacacs-server host and radius-server host commands

  • Your server-grouping commands

To create a grouping of servers (after configuring your tacacs-server host and radius-server host commands), use the following configuration syntax:

Router(config)# aaa group server radius | tacacs+ group_name

Router(config-sg)# server IP_address | hostname

  [auth-port port_#] [acct-port port_#]

The aaa group server command specifies the group of servers. Note that you cannot mix the security protocols within a group: The group contains either TACACS+ or RADIUS servers. Each server grouping must be assigned a unique name, which then is referenced in your AAA authentication, authorization, and accounting configuration. Executing the aaa group server command takes you into a subconfiguration mode, in which you use the server command to list the servers in the group. For your RADIUS configuration, if one AAA server is running multiple instances of RADIUS, with different port numbers, you need to differentiate the services by specifying the auth-port and acct-port parameters with the appropriate port numbers.

Troubleshooting TACACS+ and RADIUS

You can use a handful of commands to troubleshoot TACACS+ and RADIUS AAA problems. The following two subsections cover these commands.

Troubleshooting TACACS+

When troubleshooting TACACS+ connectivity problems, you use three commands:

  • show tacacs

  • debug tacacs

  • debug tacacs events

The show tacacs command displays a summary status of the connections that it has to configured TACACS+ servers, as shown in Example 5-1.

Example 5-1. Using the show tacacs Command

Router# show tacacs

Tacacs+ Server            :

              Socket opens:          3

             Socket closes:          3

             Socket aborts:          0

             Socket errors:          0

           Socket Timeouts:          0

   Failed Connect Attempts:          0

        Total Packets Sent:          42

        Total Packets Recv:          41

          Expected Replies:          0

  No current connection

For more detailed troubleshooting, use the debug tacacs and debug tacacs events commands. The debug tacacs command displays information related to TACACS+ operations. The main difference between this command and the debug tacacs events command is that the latter displays more detailed information, including information about the TACACS+ processes running on the router.


The debug tacacs events command is very CPU intensive. Take care to use it when the CPU utilization is low and during times of inactivity.

Example 5-2 demonstrates the debug tacacs command.

Example 5-2. Using the debug tacacs Command

Router# debug tacacs

15:32:22: TAC+: Opening TCP/IP connection to using      (1)


15:32:22: TAC+: Sending TCP/IP packet number 417383154-1 to       (2)


15:32:22: TAC+: Receiving TCP/IP packet number 417383154-2


15:32:22: TAC+ (417383154): received authen response              (3)

          status = GETUSER

15:32:24: TAC+: send AUTHEN/CONT packet

15:32:24: TAC+: Sending TCP/IP packet number 417383154-3

          to (AUTHEN/CONT)

15:32:24: TAC+: Receiving TCP/IP packet number 417383154-4


15:32:24: TAC+ (417383154): received authen response              (4)

          status = GETPASS

15:32:25: TAC+: send AUTHEN/CONT packet

15:32:25: TAC+: Sending TCP/IP packet number 417383154-5

          to (AUTHEN/CONT)

15:32:25: TAC+: Receiving TCP/IP packet number 417383154-6


15:32:25: TAC+ (417383154): received authen response              (5)

          status = FAIL

15:32:27: TAC+: Closing TCP/IP connection to            (6)

Here is an explanation of the output in Example 5-2. The numbers on the right side of Example 5-2 correspond to the numbers in the following list:

  1. In this statement, the router opens a TACACS+ connection to the AAA server.

  2. In the next two statements, the router sends and receives an authentication START message, telling the AAA server that more authentication information will be sent.

  3. The AAA server responds and requests a username, which the router sends to the AAA server.

  4. Next, the AAA server requests the user's password, which the router sends to the AAA server.

  5. In this instance, the user entered the wrong username/password combination, so the AAA server responds with a FAIL message.

  6. Notice here that the router closes the TACACS+ connection, indicating that no more information needs to be transmitted.

Troubleshooting RADIUS

You can use two commands to troubleshoot RADIUS problems: show radius statistics and debug radius. The first command displays basic statistics about the packets sent and received for accounting and authentication, as displayed in Example 5-3.

Example 5-3. Using the show radius statistics Command

Router# show radius statistics

                                   Auth.      Acct.       Both

          Maximum inQ length:        NA         NA          1

        Maximum waitQ length:        NA         NA          1

        Maximum doneQ length:        NA         NA          1

        Total responses seen:         5          0          5

      Packets with responses:         5          0          5

   Packets without responses:         0          0          0

  Average response delay(ms):      1880          0       1880

  Maximum response delay(ms):      6540          0       6540

   Number of Radius timeouts:         0          0          0

        Duplicate ID detects:         0          0          0

You can see that there are three columns of statistics. Remember that RADIUS combines authentication and authorization functions. In this example, you can see the total number of responses, as well as round-trip delays and timeouts.

For more detailed troubleshooting, use the debug radius [brief] command. The brief parameter creates similar output as the debug tacacs command; omitting this parameter creates output similar to that of the debug tacacs events command.

Server Protocol Example Configuration

Now you will take a look at how to set up the security protocols for AAA. In the example network in Figure 5-1, the TACACS+ servers handle authentication and authorization functions, and the RADIUS servers handle all accounting functions.

Figure 5-1. AAA Server Configuration Example

[View full size image]

This example focuses only on enabling AAA, defining the AAA servers and setting up the server groupings. The later sections "Authentication," "Authorization," and "Accounting" discuss how to associate the server groups with the different AAA processes.

Example 5-4 shows the configuration for Figure 5-1.

Example 5-4. Setting up AAA Security Server Connectivity

Router(config)# aaa new-model

Router(config)# tacacs-server host single-connection

  key secret10

Router(config)# tacacs-server host single-connection

  key secret11

Router(config)# radius-server host key secret12

Router(config)# radius-server host key secret13

Router(config)# aaa group server tacacs aaatacgroup

Router(config-sg)# server

Router(config-sg)# server

Router(config-sg)# exit

Router(config)# aaa group server radius aaaradgroup

Router(config-sg)# server

Router(config-sg)# server

In this example, the aaa new-model command, listed first, enables AAA. The tacacs-server host and radius-server host commands specify the AAA server's location and the encryption key used for communications. With the TACACS+ server configuration, the single TCP connection option is enabled. At the bottom of the configuration, two server groupings are created. In the TACACS+ server group aaatacgroup, is the primary server and is the backup. In the RADIUS server group aaaradgroup, is the primary server and is the backup. As you can see from this example, enabling AAA and setting up your security server connections are straightforward processes.

Comparison of TACACS+ and RADIUS

Now that you have a basic understanding of TACACS+ and RADIUS, as well as their configuration, take a closer look at them by comparing the two security protocols shown in Table 5-1.

Table 5-1. TACACS+ Versus RADIUS








UDP has less overhead; however, with TCP, TACACS+ more quickly can detect a failed server and switch over to a backup. TCP can do this by having the router look for an RST (closed connection) message or by using TCP keepalives.




TACACS+ is more secure because it encrypts the entire payload, which includes all user and AAA message information; RADIUS encrypts only passwords, so everything else, including usernames and other account information, is sent in clear text.

Authentication and authorization



RADIUS combines authentication and authorization functions, which means that you must use the same server or group for these functions. TACACS+ separates them, giving you more control over the server that handles these functions.

WAN protocols



TACACS+ is better suited for remote-access situations that involve multiple dialup protocols, whereas RADIUS supports only PPP and SLIP.

Router command authorization



TACACS+ enables you to control what commands an authenticated user can execute on a router; RADIUS does not.




The one big advantage that RADIUS has over TACACS+ is its robust accounting, which is why many ISPs use it to monitor PPP connections.