Configuring AAA Using Cisco Secure ACS

Cisco Secure ACS provides administrators with a centralized identity networking solution and simplified user management experience, whether they are working with Cisco devices or security management applications.

Through Cisco Secure ACS, administrators can ensure the enforcement of assigned policies by controlling who can log into the network, the privileges a user may have on the network, and securing access to the administrative web interface for each configuration administrator. Cisco Secure ACS also can provide documentation of security audits and account billing information. This section examines the role of Cisco Secure ACS in configuring AAA and explores working with RADIUS and TACACS+.

Overview of Cisco Secure ACS for Windows

Cisco Secure ACS for Windows allows you to manage and administer user access for Cisco IOS routers, virtual private networks (VPN), firewalls, dialup and DSL connections, cable access solutions, storage, content, VoIP, Cisco wireless solutions, and Cisco Catalyst switches using IEEE 802.1x access control. Cisco NAC is an industry initiative sponsored by Cisco Systems. It uses the network infrastructure to enforce security policy compliance on all devices seeking to access network computing resources. It relies on Cisco Secure ACS as an important component. In NAC deployments, Cisco Secure ACS 4.0 for Windows acts as a policy decision point by allowing the evaluation of credentials, determining the state of the host, and providing per-user authorization to the network access devices.

Cisco Secure ACS 4.0 for Windows provides a number of advanced features:

■ Lightweight Directory Access Protocol (LDAP) and Open Database Connectivity

(ODBC) user authentication support I Topic

■ 802.1x authentication type support, including Extensible Authentication Protocol Transport Layer Security (EAP-TLS), Protected EAP (PEAP), Cisco Lightweight EAP (LEAP), EAP-Flexible Authentication via Secure Tunneling (EAP-FAST), and EAP Message Digest 5 (EAP-MD5)

■ Access control lists (ACL) that may be downloaded for any Layer 3 device, including Cisco routers, Cisco PIX Firewalls, and Cisco VPNs

■ Automatic service monitoring, database synchronization, and importing of tools for large-scale deployments

■ Device command set authorization

■ Dynamic quota generation

■ User and device group profiles

■ User and administrative access reporting

■ Network access restrictions

■ Restrictions such as time of day and day of week

Cisco Secure ACS 4.0 for Windows provides a scalable, high-performance RADIUS and TACACS+ security server. Cisco Secure ACS provides a comprehensive identity-based NAC solution for Cisco intelligent information networks by acting as the centralized control point for managing enterprise network users, network administrators, and network infrastructure resources. Cisco Secure ACS combines traditional authentication, authorization, and accounting (AAA) with policy control to effectively extend network access security. Through implementing Cisco Secure ACS, you can enforce a uniform network access security policy for network administrators and other network users.

Cisco Secure ACS supports a wide range of Cisco and other network access devices (NAD), sometimes called AAA clients:

■ Wired and wireless LAN switches and access points

■ Edge and core routers

■ Dialup and broadband terminators

■ Content and storage devices

Additional Features of Cisco Secure ACS 4.0 for Windows

Cisco Secure ACS 4.0 for Windows provides a number of additional features that you might want to use:

,-— ■ Cisco NAC support: In NAC deployments, Cisco Secure ACS 4.0 for Windows acts

Topic as a policy decision point. Cisco Secure ACS 4.0 provides configurable policies that it uses to evaluate and validate the credentials received from the Cisco Trust Agent (posture). With these it also determines the state of the host and sends a per-user authorization to the NAD: ACLs, a policy-based ACL, or a private VLAN assignment. This evaluation of the host credentials can enforce many specific policies, such as OS patch level and antivirus digital audio tape (DAT) file version. Cisco Secure ACS also records the results of this policy evaluation for use with monitoring systems. For hosts without the appropriate agent technology, Cisco Secure ACS 4.0 for Windows makes it possible for these hosts to be audited by third-party vendors before granting network access. External policy servers also make it possible to extend Cisco Secure ACS policies.

■ Improvements to scalability: The 4.0 version of Cisco Secure ACS for Windows supports an industry-standard relational database management system (RDBMS), increasing the number of devices (AAA clients) ten times while increasing the number of users by three times the previous number. Improvements have also been made in performance, including significant performance increases in the number of transactions per second across the full protocol portfolio supported by Cisco Secure ACS.

■ Network Access Profiles (NAP): One new feature provided by Cisco Secure ACS 4.0 for Windows is Network Access Profiles. Using these, administrators may classify access requests based on network location, membership in a network device group (NDG), protocol type, or other RADIUS attribute values sent by the NAD used by the user to connect. AAA policies may be mapped to specific profiles. Using this feature allows you as an administrator to apply a different access policy based on, for instance, wireless access.

■ Extended replication components: Through the improved replication provided by Cisco Secure ACS 4.0 for Windows, administrators may now replicate NAPs and all related configurations, including

— Posture validation settings

— AAA clients and hosts

— External database configuration

— Global authentication configuration

— Dictionaries

— Shared-profile components

— Additional logging attributes

■ EAP-FAST enhanced support: Cisco has developed EAP-FAST as a publicly accessible IEEE 802.1x EAP type to support customers who cannot enforce a strong password policy. EAP-FAST is also for those who want to deploy an 802.1x EAP type that has the following characteristics:

— No digital certificate is required

— Versatile supports for user and password database types

— Support for password expiration and change

— Flexible and easy to deploy and manage

■ Machine access restrictions (MARs): MARs is offered as an enhancement of Microsoft Windows machine authentication. Administrators can use MARs to control authorization of EAP-TLS, EAP-FASTv1a, and Microsoft PEAP users who authenticate with a Microsoft Windows external user database when Microsoft Windows machine authentication is enabled. With this feature, users who access the network with a computer that has not passed machine authentication within a configurable length of time are given the authorizations of a user group that you specify. You can configure this to limit authorization as needed, or you may choose to deny network access.

■ NAFs: Network access filters (NAF), a new type of shared profile component, give administrators a flexible way to apply network access restrictions and downloadable ACLs on network device names, NDGs, or their IP address. When NAFs are applied by IP addresses, you may use IP address ranges and wildcards. This new feature allows for granular application of network access restrictions (NAR) and downloadable ACLs. Previously, these supported only the use of the same access restrictions or ACLs to all devices.

■ Downloadable IP ACLs: Per-user ACL support is extended to any Layer 3 network device that supports downloadable IP ACLS, such as Cisco ASA, Cisco PIX Firewalls, Cisco VPN solutions, and Cisco IOS routers. Sets of ACLs may be defined that can be applied per user or per group. This works hand in hand with NAC by enforcing the correct ACL policy. Further, these may be used along with NAFs to apply downloadable ACLs differently on a per-device basis, tailoring ACLs uniquely per user, per access device.

■ Certificate revocation list (CRL) comparison: An X.509 CRL profile is used to support certificate revocation in this version of Cisco Secure ACS for Windows.

Cisco Secure ACS 4.0 for Windows Installation

You may install Cisco Secure ACS 4.0 on either Microsoft Windows 2000 Server or Microsoft Windows Server 2003. Before you undertake this installation on either operating system, however, you need to do a few things to prepare.

You need to be sure that the minimum hardware, OS, and third-party software requirements have been met before the installation. What follows is a general overview of these requirements; we will review each in greater detail later:

■ Hardware configuration of the server

■ Software currently on the server

■ Compatible browser types used to administer Cisco Secure ACS

■ Network requirements

■ Ports used to communicate with Cisco Secure ACS

■ Answers to installation questions, including the administrator and database passwords

The server on which Cisco Secure ACS will be installed must meet the following minimum hardware requirements:

■ IBM PC-compatible with a minimum of a 1.8 GHz or faster Pentium 4 processor

■ Minimum of 1 GB of free disk space (if you are running the database on the same computer, more disk space is required)

■ Minimum graphics resolution of 256 colors at 800x600 pixels

■ 100BASE-T or faster connection

Cisco Secure ACS 4.0 supports the following operating systems. Note the service pack levels and other necessary services beyond the base OS. Also note that the OS and the service pack must be English-language versions.

■ Microsoft Windows 2000 Server (Service Pack 4 [SP4])

■ Microsoft Windows 2000 Advanced Server, with the following conditions:

— Microsoft Windows 2000 Cluster Service must not be installed.

— Other features specific to Microsoft Windows 2000 Advanced Server, such as Microsoft Windows 2000 Terminal Services, should not be installed.

■ Microsoft Windows Server 2003 Enterprise Edition with Service Pack 1

■ Microsoft Windows Server 2003 Standard Edition (SP1)

Specific to Windows 2000 Advanced Server, Cisco has not yet tested the multiprocessor feature of this OS; therefore, it cannot be considered to be supported. Further, Microsoft Windows 2000 Data Center Server is not a supported OS.

You may use the following browsers with Cisco Secure ACS:

■ Microsoft Internet Explorer 6 SP1 and Microsoft Internet Explorer 5.5 for Microsoft Windows (English and Japanese version)

■ Netscape 7.0, 7.1, and 7.2 for Microsoft Windows (English and Japanese version)

Key Topic

A number of known issues are related to using Netscape Communicator with Cisco Secure ACS. If this is your preferred browser, see the "Release Notes for Cisco Secure ACS for Windows" on

You also need either the Sun Java Runtime Environment (JRE) 1.4.2_04 or Microsoft Java Virtual Machine (JVM) installed.

Before you deploy Cisco Secure ACS 4.0 for Windows, your network should meet the following requirements:

■ The Cisco Secure ACS computer should be able to ping all AAA clients.

■ All dial-in, VPN, or wireless clients must be able to connect to the applicable AAA clients.

■ Gateway devices between the Cisco Secure ACS and AAA clients must permit communication over the ports needed to support the necessary feature or protocol.

■ All network cards must be enabled in the computer that is running Cisco Secure ACS.

■ AAA clients must run Cisco IOS Release 11.1 or later to have full TACACS+ and RADIUS support on Cisco IOS devices.

■ Other vendors' AAA clients must be configured with TACACS+, RADIUS, or both.

■ For Cisco Secure ACS to use the Grant Dial-in Permission to User feature in Microsoft Windows when authorizing network users, this option must be selected in the Windows User Manager or Active Directory Users and Computers for the required user accounts.

■ One of the supported web browsers must be installed on the computer that is running Cisco Secure ACS.

Table 4-7 lists the ports used by Cisco Secure ACS for communicating with AAA clients, other Cisco Secure ACS machines and applications, and web browsers. Additionally, other ports are used to communicate with external user databases, but Cisco Secure ACS initiates those communications rather than listening to specific ports. For instance, if Cisco Secure ACS initiates communications with LDAP or RADIUS token server databases, these destination ports may be configured in Cisco Secure ACS.

,■•— Table 4-7 Ports Used by Cisco Secure ACS for Client Communication (Key '

Table 4-7 lists the ports used by Cisco Secure ACS for communicating with AAA clients, other Cisco Secure ACS machines and applications, and web browsers. Additionally, other ports are used to communicate with external user databases, but Cisco Secure ACS initiates those communications rather than listening to specific ports. For instance, if Cisco Secure ACS initiates communications with LDAP or RADIUS token server databases, these destination ports may be configured in Cisco Secure ACS.

,■•— Table 4-7 Ports Used by Cisco Secure ACS for Client Communication (Key '




RADIUS authentication authorization


1645, 1812

RADIUS accounting


1646, 1813




Table 4-7 Ports Used by Cisco Secure ACS for Client Communication (Continued)

Table 4-7 Ports Used by Cisco Secure ACS for Client Communication (Continued)




Cisco Secure ACS database replication



RDBMS synchronization



User-changeable password web application






Administrative HTTP port for new sessions



Administrative HTTP port range



As you begin the installation, you are asked a series of questions. For instance, you are asked to check the following:

■ Confirm that end-user clients can successfully connect to AAA clients.

■ Confirm that the Microsoft Windows server can ping the AAA clients.

■ Confirm that Cisco IOS Release 11.1 or later is running on the Cisco IOS clients.

■ Confirm that Microsoft Internet Explorer 6 SP1 or Netscape 7.02 is installed.

An administration password and database password also need to be created for the installation. The following is a detailed list of the steps necessary to install Cisco Secure

ACS 4.0 for Windows for the first time:

Step 1 Log on to the computer using a local administrator account.

Step 2 Click setup.exe in the root directory of the CD-ROM.

Step 3 Read the software license agreement, and accept it by clicking Accept.

Step 4 After reading the Welcome screen, click Next. The Before You Begin dialog box appears.

Step 5 After you have completed all items in the Before You Begin dialog box and checked the corresponding check box for each item, click Next. The Choose Destination Location dialog box appears.

Step 6 If you do not want to change the destination folder, click Next. The Authentication Database Configuration dialog box appears.

Step 7 You have two options:

1. If you want to authenticate users with the Cisco Secure ACS internal database only, click Check the Cisco Secure ACS Database Only.

2. If you want to authenticate users with a Windows Security Access Manager (SAM) user database or Active Directory user database in addition to the Cisco Secure ACS internal database, you can do the following:

• Click Also Check the Windows User Database. The Grant Dial-in

Permission to User setting check box becomes available.

• Click Yes for the Grant Dial-in Permission to User setting if you want to allow access by users who are authenticated by a Microsoft Windows domain user database only when they have dial-in permission in their Microsoft Windows account.

NOTE The Yes, Grant Dial-in Permission to User setting check box applies to all forms of access that Cisco Secure ACS controls, not just dial-in access.

Step 8 Click Next. The setup program installs Cisco Secure ACS and updates its configuration.

Step 9 The Advanced Options dialog box has several features of Cisco Secure ACS displayed that are not enabled by default. Select each feature you want to enable by checking the corresponding check box for each feature, and click Next. The Active Service Monitoring dialog box appears.

Step 10 Click Next. The Database Encryption Password dialog box appears.

Step 11 Enter a password to be used for database encryption, and click Next. The setup program ends. The Cisco Secure ACS Service Initiation dialog box appears.

Step 12 Check the corresponding check box for each option you require, and then click Next. Select from the following options:

• Yes, I Want to Start the Cisco Secure ACS Service Now

• Yes, I Want Setup to Launch the Cisco Secure ACS Administrator from My Browser Following Installation

Step 13 Click Finish. The setup program exits. You can access the Cisco Secure ACS HTML interface, on the computer running Cisco Secure ACS, by using the Cisco Secure ACS Admin desktop icon, or you can use one of the following URLs:


If you will be administering the Cisco Secure ACS from the network, you need to create and enable an administrator first, because an administrative account is not created by default.

To create an administrative account, follow these steps:

Step 1 Click Administration Control. Step 2 Click Add Administrator.

Step 3 Complete the boxes in the Administrator Details table:

• Enter the login name (up to 32 characters) in the Administrator Name box.

• Enter the password (up to 32 characters) in the Password box.

• Enter the password a second time in the Confirm Password box.

Step 4 Click Grant All to choose all privileges, including user group editing privileges for all user groups.

If all privilege options are selected, all user groups move to the Editable groups list. To clear all privileges, including user group editing privileges for all user groups, click Revoke All.

Overview of TACACS+ and RADIUS

TACACS+ and RADIUS are the two most widely used AAA protocols. Although TACACS+ and RADIUS are quite popular, each has different features that make them suitable for different situations.

The Internet Engineering Task Force (IETF) created and maintains the RADIUS standard. TACACS+ is a proprietary Cisco Systems technology that encrypts data and replaces older versions such as TACACS and XTACACS. These protocols also differ in the protocols that they run on. TACACS+ runs in TCP, and RADIUS operates in User Datagram Protocol (UDP). Furthermore, TACACS+ can control the authorization level of users, but RADIUS cannot. Unlike RADIUS, TACACS+ also separates authentication and authorization. This feature allows administrators to use TACACS+ for authorization and accounting while giving them the flexibility to implement a different method for authentication, such as Kerberos, if they want to.

TACACS+ Authentication

The TACACS+ protocol is more flexible than RADIUS communication. TACACS+ allows an arbitrary conversation to be held between the daemon and the user. It continues until the daemon receives enough information to authenticate the user. Typically this is accomplished by prompting for a username and password combination, but this may include additional methods as well. For instance, the user might be prompted for something like her mother's maiden name. This is all done under the control of the TACACS+ daemon.

The following is a detailed list of the steps involved in the authentication process used with TACACS+, as shown in Figure 4-3:

1. The user requests access.

2. The NAC requests a username from the TACACS+ server.

3. The TACACS+ server provides a username prompt.

4. NAC prompts the user.

5. The user provides a username.

6. NAC forwards the username to the TACACS+ server.

7. NAC requests the password prompt from the TACACS+ server.

8. The TACACS+ server provides a password prompt.

9. NAC prompts the user for the password.

10. The user submits the password.

11. NAC forwards the password to the TACACS+ server.

12. The TACACS+ server accepts or rejects the user.

Figure 4-3 TACACS+ Authentication Process

0 Connect__(2 What is the username prompt?

4 Username? © Use "username:"

Client ACS

0 Connect__(2 What is the username prompt?

4 Username? © Use "username:"

Client ACS










What is the password prompt?




Use "password:"





The TACACS+ daemon provides the NAS with one of the following responses:

■ ACCEPT: The user is authenticated, and authorization begins at this point if the NAS

has been configured to require it. ! Topic

■ REJECT: Authentication has failed for the user. The user either is prompted to retry the login sequence or is denied further access, depending on the TACACS+ daemon.

■ ERROR: At some point during the authentication process, an error occurred. This may have occurred at either the daemon or in the network connection between the daemon and the NAS. If an ERROR response is received, the NAS usually attempts to use an alternative method to authenticate the user.

■ CONTINUE: The user is prompted for further authentication information before acceptance or rejection.

As soon as authentication has occurred, the user must complete an authorization phase if authorization has been enabled on the NAS. Successful TACACS+ authentication is required of the user before he goes on to TACACS+ authorization.

The TACACS+ daemon is contacted again if TACACS+ authorization is required, and it returns an ACCEPT or REJECT authorization response. If it returns an ACCEPT response, it contains attributes that are used to direct the EXEC or NETWORK session for that user. This determines which services the user can access.

The services that may be available include

■ PPP, Telnet, rlogin, SLIP, or EXEC services

■ Connection parameters, such as the host or client IP address, ACL, and user timeouts

Figure 4-4 shows the authorization process with TACACS+ after the user has successfully authenticated.

Figure 4-4 TACACS+ Authorization Process

User "bob" Connected © Network Authorization for User "bob"

And Authentication ACCEPT

; TOpiC

Client (Use ACL 192, ip route ACS

TACACS+ can be used to upload a per-user ACL and static route to the NAS, as well as for a variety of other parameters. The steps involved in this process are as follows:

1. NAC submits an authorization request for network access to the TACACS+ server.

2. The request is either accepted or denied by TACACS+. Authorization parameters are sent to the NAC if the access is permitted and are applied to the user connection.

Command Authorization with TACACS+

Access control over services available to a user is an important aspect of authorization. By controlling access to configuration commands, infrastructure security in large enterprise networks is simplified considerably. The ACS allows per-user permissions to be easily configured, and this simplifies the configuration on network devices.

Figure 4-5 shows the authorization process involved when a network administrator issues the configure terminal command on the router. In this example, the router queries the ACS for permission to execute the command on behalf of the user. During this process, TACACS+ establishes a new TCP session. By default, a new TCP session is established for each authorization request; this may lead to delays when users enter commands. To improve performance, Cisco Secure ACS supports persistent TCP sessions. To realize this benefit, both the Cisco Secure ACS and the router have to be configured for this functionality.

,•— Figure 4-5 TACACS+ Command Authorization Process f Key

\ Topic Administrator bob Command Authorization (Level 15) for _Logged in via Telnet_ —Vr^""— User "bob", Command "configure terminal"

"configure terminal" ACCEPT


TACACS+ Attributes

TACACS+ frequently uses a number of attributes for authentication and authorization:

Key \ Topic

■ ACL (EXEC authorization): Lists an access class number that will be applied to a line.

■ ADDR (SLIP, PPP/IP authorization): When using a SLIP or PPP/IP connection, this is used to specify the IP address of the remote host that should be assigned.

■ CMD (EXEC): The attribute-value (AV) pair is used to start an authorization request for an EXEC command.

■ Priv-lvl (EXEC authorization): This may be an integer between 0 and 15. It is used to specify the current privilege level for command authorization.

■ Route (PPP/IP, SLIP authorization): Used to specify a route to be applied to an interface.

■ InACL (PPP/IP, SLIP authorization): Used with SLIP or PPP/IP connections to list an inbound IP ACL.

■ OutACL: Used with SLIP or PPP/IP connections to list an outbound IP ACL.

■ Addr-pool: Used to specify the name of a local address pool from which to obtain the address of the remote host.

■ Autocmd: Used to specify a command to be automatically executed at EXEC startup.

In addition to these attributes, a number of other attributes exist for most network applications.

TACACS+ is a Cisco-proprietary protocol that uses TCP port 49 as the default transport layer. TACACS+ is supported on IOS routers, switches, and the Cisco PIX Firewall. It is the primary protocol used with Cisco AAA implementations.

When TACACS+ is used with AAA, typically each AAA transaction uses a dedicated TCP connection. By using a single session, there should be less server load and better detection of a break in communication. This single session persists as long as the server or network device is operational.

Authentication and Authorization with RADIUS

Like TACACS+, RADIUS may be used as a AAA protocol. Unlike TACACS+, it operates using UDP/IP rather than TCP/IP and provides only password encryption. However, unlike TACACS+, a Cisco-proprietary protocol, RADIUS was created by the Internet Engineering Task Force (IETF). The following list describes the steps involved in the authentication process with RADIUS (see Figure 4-6):

1. The NAS prompts the client for a username.

2. The client provides a username to the NAS.

3. The NAS prompts the client for a password.

4. The client provides the password.

5. An Access-Request datagram containing all the necessary AV pairs is used to send the information about the username and the password to the RADIUS server.

6. If the information provided by the user is correct, the server responds with an Access-Accept datagram. This Access-Accept message also contains authorization parameters in the form of AV pairs. For instance, this might be the IP address to be assigned, and so on. On the other hand, if the information that the user has provided is incorrect, an Access-Reject message is returned, and NAS terminates the connection.

Figure 4-6 Authentication Process Using RADIUS











Access-Request (bob, "sEcReT")



RADIUS Message Types

The four RADIUS message types are as follows:

■ Access-Request: Contains AV pairs for the username and password that are encrypted by RADIUS, as well as additional information such as the NAS port.

■ Access-Challenge: Used for authentication methods that employ a challenge-based approach such as Challenge Handshake Authentication Protocol (CHAP), Microsoft CHAP (MS-CHAP), and Extensible Authentication Protocol-Message Digest 5 (EAP-MD5).

■ Access-Accept: Indicates that the user-provided information is correct.

■ Access-Reject: Indicates that the user-provided information is incorrect. RADIUS Attributes

All RADIUS messages can contain a number of AV pairs. Some of the pairs are used for authentication, and others are used for authorization purposes.

Here are some of the most commonly used RADIUS AV pairs:

■ User-Password (encrypted)

■ CHAP-Password

■ Framed-IP-Address

Roughly 50 AV pairs are defined in IETF standards. To these, Cisco has added several vendor-specific attributes on the server side. Cisco AV pairs are always used by default by Cisco IOS devices, but you may configure these devices to use only IETF attributes for standard compatibility if you like.

Features of RADIUS

You can augment the standard attributes we discussed with either proprietary attributes or extensions to RFC 2865. When we think in terms of RADIUS (Cisco), it is actually RADIUS (IETF) support plus IETF attribute 26, the vendor-specific attribute (VSA) for Cisco. It is via this VSA that any authorization request specified in the TACACS+ specification can be sent to an access device through RADIUS.

However, limitations exist, even with this extension of RADIUS. The most notable are the following:

■ Limited security features

■ The combination of authentication and authorization in one function Table 4-8 describes the primary differences between RADIUS and TACACS+.

Table 4-8 Comparison of RADIUS and TACACS+




Packet delivery



Packet encryption

Encrypts the entire body of the packet but leaves a standard TCP header.

Encrypts only the password in the Access-Request packet from the client to the server.

AAA support

Uses the AAA architecture, separating authentication, authorization, and accounting.

Combines authentication and authorization.

Multiprotocol support

Supports other protocols, such as AppleTalk, NetBIOS, and IPX.


Router management

Enables network administrators to control which commands can be executed on a router.

Can pass a privilege level down to the router, which can then be used locally for command authorization.


Uses multiple-challenge response for each of the AAA processes. Uses the AAA architecture and separates each process.

Uses single-challenge response. Combines authentication and authorization.

Configuring TACACS+

This section explores how to configure an IOS router to use TACACS+ as a AAA protocol using both the CLI and Cisco SDM. Let's begin by looking at the steps involved in this configuration using the CLI.

Here are the first steps of configuring the network access server:

Step 1 Enable AAA globally to allow the use of all AAA elements. This is a prerequisite for all other AAA commands.

Step 2 Specify which Cisco Secure ACS will provide AAA services for the network access server.

Step 3 Configure an encryption key to be used to encrypt the data transfer between the network access server (NAS) and the Cisco Secure ACS.

Example 4-3 shows these steps being used with TACACS+.

Example 4-3 Configuring the Network Access Server with TACACS+ router(config)# aaa new-model router(config)# tacacs-server host single connection router(config)# tacacs-server key sharedl

Table 4-9 lists commonly used AAA configuration commands and their functions.

Table 4-9 Commonly Used AAA Configuration Commands



aaa new-model

Used to enable AAA on the router. This is a prerequisite for all other AAA commands.

tacacs-server host ip-address single-connection

Used to indicate the address of the Cisco Secure ACS server and to specify the use of the TCP single-connection feature of Cisco Secure ACS. Performance is improved by maintaining a single TCP connection for the life of the session between the network access server and the Cisco Secure ACS server, rather than opening and closing TCP connections for each session, which is the default.

tacacs-server key key

Used to establish a shared secret encryption key between the network access server and the Cisco Secure ACS server.

Using the CLI to Configure AAA Login Authentication on Cisco Routers

To enable the AAA authentication process, the aaa authentication login command is issued in global configuration mode. Here is an example of the syntax that is used:

/'Key \ Topic aaa authentication login {default I list-name} group

{group-name I radius I tacacs+}

[method2 [method3 [method4]]]

Table 4-10 lists the aaa authentication login parameters, along with the details of their usage.

Table 4-10 aaa authentication login Parameters


Default list-name group group-name group radius group tacacs+

method2 method3 method4


Used to create a default that is automatically applied to all lines and interfaces to specify the method or sequence of methods used for authentication.

Used to create a list (you may choose the name) that is applied explicitly to a line or interface using the method or methods specified. This list overrides the default when applied to a specific line or interface.

Used to specify the use of a AAA server. The group radius and group tacacs+ methods refer to previously defined RADIUS or TACACS+ servers. The group-name string is used to specify a predefined group of RADIUS or TACACS+ servers for authentication (created with the aaa group server radius or aaa group server tacacs+ command).

Used to execute authentication methods in the order listed. If an error is returned by the authentication method, such as a timeout error, the Cisco IOS software attempts to execute the next method. Access is denied if the authentication fails. Up to four methods may be configured for each operation. The method must be supported by the authentication operation specified.

A general list of methods includes the following:

enable: The enable password for authentication group: Uses server-group krb5: Kerberos version 5 is used for authentication line: The line password is used for authentication local: The local username and password database is used for authentication local-case: Specifies the use of case-sensitive local username authentication none: No authentication is used

Configuring Cisco Routers to Use TACACS+ Using the Cisco SDM

In addition to using the CLI to configure your routers to use TACACS+ as a AAA protocol, you may use the graphical user interface of the Cisco Security Device Manager (SDM). The first task when configuring AAA using the Cisco Security Device Manager is to enable AAA.

To enable AAA through the SDM, choose Configure > Additional Tasks > AAA. Figure 4-7 shows this process in the interface.

Figure 4-7 Enabling AAA in the Cisco SDM

Figure 4-7 Enabling AAA in the Cisco SDM

Click the Enable AAA button in the upper-right corner to enable AAA on the router. The SDM performs a series of precautionary tasks to prevent locking the router or disconnecting the SDM session. Figure 4-8 shows the Enable AAA dialog box.

Figure 4-8 Enable AAA Dialog Box

Figure 4-8 Enable AAA Dialog Box

Defining the AAA Servers

After you have enabled AAA on the router, you can define the AAA servers to be used. To do this, choose Configure > Additional Tasks > AAA > AAA Servers and Groups. Click the Add button in the upper-right corner to create a new AAA server entry.

Figure 4-9 shows how to define a TACACS+ server. After you have clicked the Add button in the AAA Servers configuration section, the Add AAA Server window appears. You may select either RADIUS or TACACS+ from the Server Type drop-down box. When you choose TACACS+, you have the option of configuring the key to be used, as shown in the figure.

Figure 4-9 Defining the TACACS+ Server in the SDM

Figure 4-9 Defining the TACACS+ Server in the SDM

0 0

Post a comment