The debug aaa authentication CLI command helps you verify that AAA authentication is functioning. Note that in the following example, the terminal monitorcommand was necessary because this capture was made during a telnet session with the router. The output represents a successful login using the
“default” AAA method:
CiscoISR#debug aaa authentication AAA Authentication debugging is on CiscoISR#terminal monitor
Apr 21 14:24:56.511: AAA/BIND(00000032): Bind i/f
Apr 21 14:24:56.511: AAA/AUTHEN/LOGIN (00000032): Pick method list
‘default’
Additional Local Database AAA CLI Commands
Let’s examine some additional CLI commands that help secure and verify an AAA configuration that uses the local database for authentication.
If you want to lock out any user after 10 failed login attempts for local AAA, you can issue this command:
aaa local authentication attempts max-fail 10
To identify local AAA users whose accounts have been locked out, you type in this command:
show aaa local user lockout
Here’s an example. It appears that the ISP user has been locked out. What were they doing working on the weekend anyway?
CiscoISR#show aaa local user lockout Local-user Lock time
ispuser 14:28:49 UTC Sun Apr 20 2008
To clear (re-instate) all local AAA users who have been locked out, type in this command:
clear aaa local user lockout
If you want to clear a single local AAA user, you can use this form of the com- mand, where ispuseris the locked-out user:
clear aaa local user lockout ispuser
To display detailed statistics of all logged-in users, you type in this command:
show aaa user all
The following command displays current sessions of users who have been authenticated, authorized, or accounted by the AAA module. It shows AAA ses- sions with their unique IDs:
show aaa sessions
Here’s an example of its output:
CiscoISR#show aaa sessions
Total sessions since last reload: 48 Session Id: 45
Unique Id: 50 User Name: admin
IP Address: 192.168.0.114 Idle Time: 0
CT Call Handle: 0 CiscoISR#
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 self- contained 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 strate- gic 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.
NOTE
There is a complete module on configuring AAA, including authentication authorization and accounting configuration in Cisco’s “Securing Networks with Routers and Switches”
course. Because we focus on authentication and (later) authorization and accounting in this book, there is a danger that you may equate AAA with authentication. Remember that authentication is only the first A of three A’s in AAA!
There are two important differences or “deltas” in configuring external authen- tication 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 exter- nal 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 communi- cate 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 num- ber 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.
FIGURE 3.14 Cisco Secure ACS home page.
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 800x600 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 pre- installed on a 1U, rack-mountable server form factor with a security-hardened Windows Server pre-installed. Table 3.3 compares the specifications and capa- bilities of these devices.
TABLE 3.3 Rack-Mount ACS Solutions Comparison Matrix
Cisco Secure ACS Solution Engine Cisco Secure ACS Express Processor Intel Pentium 4, 800MHz FSB, 2MB cache Intel 352 Celeron D
RAM 1GB 1GB
Optical Drive CD/DVD combo CD/DVD combo
Ports 1 x RS-232, 3 x USB 2.0 1 x RS-232, 3 x USB 2.0
Hard Drive 80GB SATA 250GB, non-SATA
Number of Users over 350 up to 350
NICs 2 x 10/100/1000 Ethernet 2 x 10/100/1000 Ethernet
TACACS+ or RADIUS?
Whether you use Terminal Access Control Access Control Server Plus (TACACS+) or Remote Dial-in User Services (RADIUS) in your AAA implemen- tation depends very much on what you need to accomplish. For example, the busi- ness 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 summa- ry of some of the important differences between the two protocols.
TABLE 3.4 TACACS+ vs. RADIUS Comparison
TACACS+ RADIUS
Authentication and Separates authentication Combines authentication Authorization Processing and authorization. and authorization.
Transport TCP port 49. Authentication: UDP ports 1645 or
1812.
Accounting: UDP ports 1646 or 1813 (see note).
(continues)
Encryption Encrypts all communication. Password encrypted.
Origin / Future Developed from (but not Developed by Livingston.
compatible with) TACACS DIAMETER is the planned
and XTACACS. replacement.
Where Used Everywhere except when Remote access (dial-up, detailed accounting is DSL, VPNs).
required, especially for
command authorization. IEEE 802.1X EAP.
SIP.
Anywhere that detailed accounting is required (for example: ISP).
Closed or Open Source Mostly Cisco. Open Source / RFC.
CHAP Bidirectional. Unidirectional.
Customization Yes. For example, No. No option for command authorization command authorization can be configured at on a per-user or per- user or group level. group level.
Protocol Support Yes, multi-protocol. Yes, but no ARA or NetBEUI.
Per-user IP ACLs No. Yes.
TABLE 3.4 TACACS+ vs. RADIUS Comparison Continued
TACACS+ RADIUS
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 num- ber. 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 communi- cation 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 co- located on the same IP subnet. Many security policies dictate that the AAA serv- er be in a separate DMZ or other protected zone that implies that there may well be a firewall on the communication 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:2002in 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 num- ber 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 loop- back 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 fig- ure match up with the task list. These general tasks would be followed regard- less 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.
FIGURE 3.15 The navigation bar in Cisco Secure ACS.
FIGURE 3.16 Three main tasks for setting up external AAA.