Configuring External AAA on a Cisco Router Using Cisco Secure ACS
Recall that we have two choices for authentication in AAA:
- Self-contained AAA (local authentication)
- External authentication
This section covers authentication in the contexts of both self-contained AAA and external authentication. Authorization and accounting will not be covered. We modularize the basic tasks required to set up authentication in both selfcontained AAA and external authentication, and along the way examine the strengths and weaknesses of the protocols RADIUS and TACACS+ and see how these protocols might be implemented for external authentication. Cisco strategic product for external AAA is Cisco Secure Access Control Server (ACS). We introduce Cisco Secure ACS, and leverage on its ease of use in describing and implementing an example external AAA solution for external authentication. We will also examine some CLI commands useful in verifying the configuration.
There are two important differences or “deltas” in configuring external authentication as compared to local authentication:
- Delta 1: The username/password database is on the AAA server.
In the section titled “Tasks to Configure Local Database AAA on a Cisco Router,” we configured a local username/password database. With external AAA using Cisco Secure ACS, the database will be on the AAA server instead. (Although we might use the local database as a fallback should the AAA server fail or otherwise be unreachable.) - Delta 2: You must set up communication between the AAA client and the AAA server.
When defining the authentication method (see “Task 3: Configuring AAA on the Router”), we won’t be using local AAA. This implies that we will have to set up a relationship between the AAA client (our router) and the AAA server (Cisco Secure ACS). As we will see, this involves the following AAA policy elements, as well as a way to group them:- Choosing the AAA protocol, TACACS+, or RADIUS, to communicate between the client and server.
- Configuring the IP addresses and pre-shared key of the client and the server.
Clearly Cisco Secure ACS is a deep topic all by itself. In this section, we will just scratch the surface of its features in the context of external AAA. We will also quickly compare RADIUS and TACACS+ protocols.
Why Use Cisco Secure ACS?
Cisco Secure ACS is most often used in networks where there are a large number of devices that need to be configured for AAA, and configuring local AAA on each device is thus made impractical and cumbersome. Here are some main reasons for implementing Cisco Secure ACS:
- Local authentication on a Cisco router does not scale well.
- Cisco Secure ACS can create a central user and administrative access database for an entire network (see the following note).
- Cisco Secure ACS works with many external databases, such as existing Active Directory, LDAP, and others.
NOTE
Perhaps the principle of “Separation of Services” is a guideline that your organization has formulated based on the material in Chapter 2, “Building a Secure Network Using Security Controls.” Also, if your organization already has database repositories such as Active Directory, LDAP, or NDS, for example, Cisco Secure ACS can work with them. Why reinvent the wheel?
Cisco Secure ACS Features
These are the features shared by all versions of Cisco Secure ACS:
- Web-based GUI
- Supports LDAP, Active Directory, Novell Directory Services (NDS), and ODBC databases
- Rich accounting and user reporting features
- Supports TACACS+ and RADIUS
- Tightly integrated with Cisco IOS router and Cisco VPN solutions
- Supports third-party OTPs
- Access restrictions through dynamic quotas
Figure 3.14 illustrates the home page for Cisco Secure ACS.
Cisco Secure ACS for Windows Installation Requirements
Unlike the Cisco Secure ACS Solution Engine and the Cisco Secure ACS Express, which are appliances, Cisco Secure ACS for Windows must be installed as an application on top of an existing Windows server. The Cisco Secure ACS for Windows software requirements are as follows:
- Windows 2000 Server with Service Pack 4
- Windows 2000 Advanced Servers with Service Pack 4
- Windows Server 2003 Standard Edition
- Windows Server 2003 Enterprise Edition
The Cisco Secure ACS for Windows hardware requirements are as follows:
- Pentium IV processor 1.8GHz or faster
- 1GB of RAM
- Minimum 500MB to 1GB free disk space (more required if the database is on the same computer)
- Minimum graphics resolution of 256 colors at 800×600 pixels
Cisco Secure ACS Solution Engine and Cisco Secure ACS Express 5.0 Comparison
One immediate advantage of these devices is that the software comes preinstalled on a 1U, rack-mountable server form factor with a security-hardened Windows Server pre-installed. Table 3.3 compares the specifications and capabilities of these devices.
TACACS+ or RADIUS?
Whether you use Terminal Access Control Access Control Server Plus (TACACS+) or Remote Dial-in User Services (RADIUS) in your AAA implementation depends very much on what you need to accomplish. For example, the business needs of a large ISP might dictate that they choose the RADIUS protocol for their AAA solution because of the detailed accounting that is needed for billing dial-up and DSL users. On the other hand, if yours is an enterprise that has many groups of users accessing your core network devices, a centralized means to deploy granular authorization policies on a per-user or per-group basis may be required. In that case, TACACS+ would be a good solution. Table 3.4 represents a summary of some of the important differences between the two protocols.
NOTE
The Cisco default port numbers for RADIUS are UDP port 1645 for authentication / authorization (remember, these processes are combined in RADIUS; see Table 3.4) and UDP Port 1646 for accounting. This becomes important when working in a mixed-vendor environment where the non-Cisco NAS or AAA server may be using a different port number. This is a very common source of misconfiguration.
Prerequisites for Cisco Secure ACS
One of the main tasks in setting up Cisco Secure ACS is establishing communication between the AAA client(s) and the AAA server, Cisco Secure ACS. You must ensure that all the IP addresses and port numbers that are required to set up the TACACS+ or RADIUS link between the AAA devices are not blocked by other devices. You are not always lucky enough to have the devices physically colocated on the same IP subnet. Many security policies dictate that the AAA server be in a separate DMZ or other protected zone that implies that there may well be a firewall on thecommunication path between the AAA devices. (Firewalls are discussed in Chapter 5, “Using Cisco IOS Firewalls to Implement a Network Security Policy.”) There are some other prerequisites for Cisco Secure ACS of which you should be aware, as follows:
- Cisco IOS Release 11.2 or later must be installed on the Cisco AAA clients.
- Non-IOS Cisco devices (or non-Cisco devices) must be configurable for standards-compliant RADIUS and/or TACACS+.
- A supported web browser must be installed on the Cisco ACS server (see the following note).
NOTE
If you are planning to administer Cisco Secure ACS right on the server where it is installed, you can use a supported web browser to browse to the loopback IP address of the device at http://127.0.0.1:2002. Alternatively, you may administer ACS remotely by browsing to http://IP-address-of-ACS:2002 in a supported web browser. You will then be prompted to login with the username and password of an administrator. After you login on the ACS home page, the browser will be automatically redirected to another port number besides 2002. You will not be prompted for login credentials if you administer ACS right on the server, but you will be prompted for login credentials if you browse to the ACS home page from a remote workstation. The ability to administer ACS remotely would be useful if your security policy dictates that the AAA server can only be administered remotely. You should consider deploying ACS in a separate management VLAN.
Three Main Tasks for Setting Up External AAA
We’re going to take a different approach from most texts to understanding how Cisco Secure ACS works. We start in a very task-oriented fashion. First, we focus on getting a working external AAA set up, and then we look at some of the features of Cisco Secure ACS that have not yet been examined, followed by some verification and debugging commands.
On Cisco Secure ACS, the starting point for setup will always be the navigation bar on the left side of the Cisco Secure ACS browser window. See Figure 3.15 for a screenshot. This screenshot was obtained by browsing to the Cisco Secure ACS home page using a web browser right on the server. Recall that when administering the ACS right on the hosting server, you browse to the local loopback IP address of the server.
The three main tasks for setting up external AAA are the following:
Task 1: Configure the AAA network (client and server).
Task 2: Set up users (server).
Task 3: Identify traffic to which AAA will be applied (client). This has three subtasks:
- Configuring authentication
- Configuring authorization
- Configuring accounting
Figure 3.16 shows where these three tasks occur The numbered labels in the figure match up with the task list. These general tasks would be followed regardless of the external AAA solution. Of course, we will model our solution after Cisco Secure ACS.
This section now goes on to discuss each of these tasks in more detail.
Task 1: Configuring the AAA Network (Client and Server)
Setting up the AAA network essentially consists of setting up a relationship between two peers, the AAA client and the AAA server. The server peers on the client and the client peers on the server. They perform mutual authentication using a pre-shared key and using the same protocol (RADIUS or TACACS+) to exchange AAA information. These main elements must be completed on both the AAA client and the AAA server:
- Set up the protocol (RADIUS or TACACS+).
- Specify the vendor of server (because port numbers used vary).
- Specify the IP address of the peer.
- Specify the pre-shared key (pre-shared because both client and server use the same key).
We perform these tasks first on the Cisco Secure ACS (the AAA server) and then on the IOS router (the AAA client).
Adding an AAA Client in Cisco Secure ACS
Figure 3.17 illustrates the fields that need to be filled out in adding an AAA client in Cisco Secure ACS.
The steps to add a Cisco IOS router as an AAA client in Cisco Secure ACS are as follows:
- Click the Network Configuration button on the navigation bar. The Network Configuration page appears.
- Click Add Entry in the AAA Clients section.
- Enter the client hostname in the AAA Client Hostname field. This is the name of the router that will be the AAA client from Cisco Secure ACS’s perspective.NOTE
Here’s a tip. You should take care when choosing the name for the AAA client in the AAA Client hostname field referenced in Figure 3.17. The hostname is actually a unique connection name and should reflect the hostname of the router and the protocol name so that we can use both TACACS+ and RADIUS between the ACS and the router (that is, “hostnametacacs” and “hostname-radius”). - Enter the router’s IP address in the AAA Client IP Address field.
- Enter the pre-shared secret key in the Shared Secret field (remember this value, as you will need it when you set up the router for AAA).
- Choose the correct AAA protocol in the Authenticate Using dropdown list.
- Complete any other parameters as required.
- Click Submit and Apply.
Adding an AAA Server on the Cisco IOS Router
Now that we have configured the AAA client information on the AAA server, we can perform essentially the same steps, but now on the AAA client. Figure 3.18 illustrates the Add AAA Server dialog in Cisco SDM.
The following shows how to use SDM to add a TACACS+ AAA server to a Cisco IOS router (the CLI appears in a note at the end):
- Open up the SDM, and choose Configure->Additional Tasks->AAA- >AAA Servers and Groups->AAA Servers.
- Click Add in the AAA Servers pane. The Add Server window appears. From the Server Type drop-down list, choose TACACS+.
- Enter the IP address or hostname of the Cisco Secure ACS in the Server IP or Host field.
NOTE
Put in the hostname only if the router has been configured for Domain Name Service (DNS) lookups. - (Optional) You can choose to maintain a persistent connection to the server rather than opening and closing connections with every transaction. If this is what you want, check the Single Connection to Server (for CiscoSecure) check box. This is more efficient but only supported on Cisco Secure ACS version 1.0.1 or higher.
- (Optional) If you want to set a timeout value specific to this server, enter a value in the Timeout (seconds) field in the Server-Specific Setup section. Otherwise, the router will use the value configured in the AAA Servers Global Settings window.
- (Optional) If you want to set a pre-shared key specific to this server, enter a value in the New Key field in the Server-Specific Setup section. Otherwise, the router will use the value configured in the AAA Servers Global Settings window.
- Click OK.
NOTE
The CLI command generated by the SDM will be of the form tacacs-server host 192.168.99.133 key cisco123.
Task 2: Setting Up Users in Cisco Secure ACS (Server)
The users are set up on Cisco Secure ACS, as illustrated in Figure 3.19. Open up Cisco Secure ACS and follow these steps to set up users. The labels on Figure 3.19 correspond with the step numbers:
- In the navigation bar, click User Setup.
- To create a new user, simply enter a username in the User field and click Add/Edit. (If this user already exists, you will be editing that user.)
- Enter data in the fields to define the user account in the Edit pane. You will probably want to set the user’s password, as well as TACACS+ enable control, TACACS+ enable password, and TACACS+ shell authorized command. (Recall that command authorization is one of the features of TACACS+.)
- Click Submit.
NOTE
What you see in the Edit pane in User Setup will depend on the interface configuration. “Interface” is this context means the user’s interface to ACS. The interface is set up when ACS is installed, but if you want to modify it, you may customize what fields are visible by choosing Interface Configuration->User Data Configuration from the navigation bar.
Task 3: Identifying Traffic to Which AAA Will Be Applied (Client)
The identification of which traffic must have AAA service applied to it is done on the AAA client, which is the IOS router in our example. This task has three different elements to it, depending on which of the 3 A’s in AAA we want to apply to the traffic. Recall that we must perform authentication at a minimum because authorization and accounting depend on authentication: To repeat, here are the subtasks that we examine separately and in order in the subsequent sections:
- Configuring authentication
- Configuring authorization
- Configuring accounting
Once the network is set up as in Task 1, this group of AAA server settings is modular and can be used for a number of purposes. For example, once you have set up a TACACS+ server for authentication, it could be used for both remote administrative access and remote network access purposes.
Creating an AAA Login Authentication Policy on the AAA Client
Figure 3.20 illustrates the steps that are required to create an AAA login authentication policy on the AAA client.
Follow these steps to create an AAA login authentication policy using Cisco SDM on the IOS router, our AAA client:
- Open up the Cisco SDM home page and choose Configure- >Additional Tasks->AAA->Authentication Policies->Login.
- Click Add from the Authentication Login pane.
- From the Name drop-down list, choose User Defined to create a new authentication method.
- In the Specify field, enter the authentication login method list name; MY_TACACS, for example.
- To define the methods that this policy uses, click Add. The Select Method List(s) for Authentication Login window appears.
- From the method list, choose group tacacs+.
- To add group tacacs+ to the method list, click OK. This will return you to the Add a Method List for Authentication Login window. The justadded method will now appear in this list.
- To add a backup method for this policy, click Add. The Select Method List(s) for Authentication Login window appears.
- This time, choose enable from the method list. This will cause the enable password to be used as the backup login authentication method.
- To add enable to the method list, click OK. This will return you to the Add a Method List of Authentication Login window. Both group tacacs+ and enable should show up in the window. To make the enable password a back up to the group tacacs+ authentication method, make sure it appears below the group tacacs+ authentication method.
- To add the authentication login method list, click OK.
NOTE
The CLI command that is generated by the Cisco SDM is aaa authentication login MY_TACACS group tacacs+ enable.
Applying the Authentication Method
The authentication login method list, like any policy, has no effect by itself once created. It must be applied to an entity on the device. This is a handy rule of thumb on Cisco devices. You create a policy; then you have to apply it somewhere. Keeping in mind that we have set up a login authentication method (and using your intuition), this authentication method most likely needs to be applied to one of the line interfaces on the router. In this scenario, we apply the authentication method MY_TACACS, to the five default vty lines on the router.
The Cisco SDM dialog to apply the authentication method MY_TACACS to the vtys is illustrated in Figure 3.21.
To apply the authentication method to the vtys using the SDM, follow these steps:
- Choose Configure->Additional Tasks->Router Access->VTY->Edit.
- In the Edit VTY Lines window, choose the MY_TACACS login authentication method from the Authentication Policy drop-down list.
- Click OK to deliver the commands to the router.
The CLI command to apply the authentication policy to the vtys would look like this:
CiscoISR#configure terminal CiscoISR(config) #line vty 0 4 CiscoISR(config-line) #login authentication MY_TACACS
Now when administrators log in to the Cisco IOS router via the vtys, they will be prompted for a username and password. These credentials will be validated using the TACACS+ protocol against the user database on the Cisco Secure ACS. It should be noted that this will not affect SDM login, only access via Telnet or SSH.
Thus, we have completed the tasks to perform the first A in AAA, authentication. Let’s turn our attention to the second A in AAA, authorization. Leveraging on our TACACS+ server, we will:
- First, create and apply an authorization policy for exec (character mode).
- Second, create and apply an authorization policy for network (packet mode).
Creating and Applying an AAA Exec Authorization Policy
The method to create an exec authorization policy is illustrated in Figure 3.22.
NOTE
The following steps assume that we have already configured an authorization policy on the Cisco Secure ACS (we have!). If you create and apply an AAA exec authorization policy before you have configured one on the authorization server, you will lock yourself out of the router. This is very embarrassing.
Using the Cisco SDM and starting at the home page, follow these steps to create and apply the default authorization method list for exec (character mode) access. Figure 3.22 is labeled to correspond to the numbers in the following list of steps:
- Choose Configure->Additional Tasks->AAA->Authorization Polices->Exec.
- Click Add in the Exec Authorization pane.
- Choose Default from the Name drop-down list in the Add a Method List for Exec Authorization window.
- To define the methods that this policy uses, click Add.
- Choose group tacacs+ from the method list in the Select Method List(s) for Exec Authorization window.
- Click OK on the next two windows in succession to return to the Exec Authorization pane.
NOTE
The Cisco SDM will generate this CLI command: aaa authorization exec default group tacacs+
Now, when administrators access the CLI, they will only be allowed to execute the commands they are authorized to use as defined in the user’s authorization policy on the Cisco Secure ACS.
Creating and Applying an AAA Network Authorization Policy
Let’s now turn our attention to defining what a user is authorized to do on the network segment protected by the Cisco IOS router. The method to create a network authorization policy is illustrated in Figure 3.23.
Starting on the Cisco SDM home page, complete the following steps to configure the default authorization method list for network (packet mode) access. Figure 3.23 has labels corresponding to the numbers of the following steps:
- Choose Configure->Additional Tasks->AAA Authorization Policies- >Network.
- Click Add in the Network Authorization pane.
- Choose Default from the Name drop-down list in the Add a Method List for Network Authorization window.
- To define the methods that this policy uses, click Add.
- Choose group tacacs+ from the method list in the Select Method List(s) for Network Authorization window.
- Click OK on the next two windows in succession to return to the Network Authorization pane.
NOTE
The Cisco SDM will generate this CLI command: aaa authorization network default group tacacs+
AAA Accounting Configuration
When properly configured, Cisco Secure ACS acts as a central repository of tracked events as they occur on the network. For example, our comprehensive network security policy might stipulate that all failed login attempts to (and through) the routers are to be tracked, with detailed information about the attempt such as user credentials, time of day, and date. Without keeping track of this information, we might not be able to provide data to aid in a forensic investigation should our network be compromised or otherwise attacked.
As with authentication and authorization, you must first create a method list (the policy), and then apply it to the right entity. As we have seen, method lists can be multi-purpose, so a method list may support all three As in AAA. AAA involves six different types of accounting, as follows:
- Network. Runs accounting for all network-related service requests, including Serial Line Internet Protocol (SLIP), PPP, PPP Network Control Protocols (NCPs), and AppleTalk Remote Access Protocol (ARAP).
- Connection. Provides information about all outbound connections made from the network access server, such as Telnet.
- Exec. Runs accounting for the EXEC shell session.
- System. Performs accounting for all system-level events not associated with users, such as reloads.
- Commands. Runs accounting for all commands at the specified privilege level.
- Resource. Performs accounting for resource use by remote users of the system. (The command syntax for setting resource accounting is different than the other items listed.)
These different types of accounting are reflected in the command syntax of the
aaa accounting command:
aaa accounting { system | network | exec | connection | commands level } {default | list-name} {start-stop | stop-only | none} [ method1 [ method2]]
Use the following form of the command to perform accounting for system resource use by remote users:
aaa accounting resource method-list start-stop [broadcast] group groupname
To set up accounting using the CLI, follow these basic steps (with examples):
- Create an accounting method list and enable accounting. CiscoISR(config) #aaa accounting connection default start-stop group tacacs+
- Enter line configuration mode or interface configuration mode for the lines or interface to which the accounting method list will be applied.
CiscoISR(config) #line vty 0 4 - Apply the account method list to the line(s) or interface(s). CiscoISR(config-line) #accounting connection default
Troubleshooting/Debugging Local AAA, RADIUS, and TACACS+
Here are a handful of useful commands for troubleshooting and debugging local AAA, RADIUS, and TACACS+.
For a high-level view of login activity, use the following CLI command:
debug aaa authentication
Here is an example of the output of the debug aaa authentication command. The highlighted output indicates that someone logged on to this ISR and that the authentication method used was local_auth:
ciscoISR#debug aaa authentication AAA Authentication debugging is on 443521: Aug 7 08:56:19.498 NewYork: AAA/BIND(000032C8): Bind i/f 443522: Aug 7 08:56:20.110 NewYork: AAA/BIND(000032C9): Bind i/f 443523: Aug 7 08:56:22.117 NewYork: AAA/BIND(000032CA): Bind i/f 443524: Aug 7 08:56:24.628 NewYork: AAA/BIND(000032CB): Bind i/f 443525: Aug 7 08:56:24.628 NewYork: AAA/AUTHEN/LOGIN (000032CB): Pick method list ‘local_auth’
For more detailed debugging of TACACS+ in particular, use the following CLI command:
debug tacacs
For even more detailed information about the TACACS+ helper process, you can use the following CLI command. Be careful with its use, because it generates copious amounts of output.
debug tacacs event
For more detailed debugging of RADIUS in particular, use the following CLI command:
debug radius
For even more detailed information about the RADIUS helper process, you can use the following CLI command. Be careful with its use, because it generates copious amounts of output:
debug radius event
AAA Configuration Snapshot
Here is a snapshot of a partial configuration with the commands in Tasks 1, 2, and 3 for setting up external AAA and including the preceding AAA accounting configuration. If the commands don’t make sense, review them in the preceding sections:
aaa new-model ! aaa authentication login MY_TACACS tacacs+ local aaa authorization exec tacacs+ aaa authorization network tacacs+ aaa accounting connection default start-stop group tacacs+ ! tacacs-server host 192.168.99.133 tacacs-server key cisco123 ! line vty 0 4 login authentication MY_TACACS accounting connection default