Configuring AAA

Configuring AAA

Configuring AAA Using the Local User Database

Unauthorized access to a network creates the potential for network intruders to gain access to sensitive network equipment and services. The Cisco AAA architecture provides a means to address this threat through systematic, scalable access security. Of course, network users and would-be intruders are not the only ones to try to access the network. Network administrators also need access to network equipment, and AAA offers a secure means to provide this.

Authentication, Authorization, and Accounting

Providing network and administrative access in a Cisco environment—regardless of whether it involves campus, dialup, or Internet access—is based on a modular architecture that is composed of three functional components—authentication, authorization, and accounting:

• Authentication: Authentication is the process by which users and administrators prove that they are who they claim to be. The network environment has a variety of mechanisms for providing authentication, including the use of a username and password, token cards, and challenge and response.
• Authorization: After the user or administrator has been authenticated, authorization services are used to decide which resources he is allowed to access, as well as which operations he may perform.
• Accounting and auditing: After being authenticated and authorized, the user or administrator begins to access the network. It is the role of accounting and auditing to record what the user or administrator actually did with this access, what he accessed, and how long he accessed it.

AAA for Cisco Routers

Cisco provides three ways to implement AAA services for Cisco routers:

• Cisco Secure ACS Solution Engine: In this implementation, AAA services on either the router or network access server (NAS), which acts as a gateway to guard access to protected resources, contact an external Cisco Secure ACS Solution Engine for both user and administrator authentication. The Cisco Secure ACS SE is an appliance that contains CSA. This can be an easier approach for some organizations, rather than purchasing hardware, an OS license, CSA license, and ACS license. In this more complex configuration, the administrator would also have to take steps to lock down the server, whereas the ACS SE is already secure.
• Cisco Secure Access Control Server (ACS) for Windows Server: This software package may be used for user and administrator authentication. AAA services on the router or NAS contact an external Cisco Secure ACS for Microsoft Windows systems. You need a separate license for CSA if this is what you want.
• Self-contained AAA: AAA services are self-contained in either a router or NAS. Implemented in this fashion, this form of authentication is also known as local authentication.

One common implementation of AAA is its use in authenticating users accessing the corporate LAN through a remote connection such as dialup or over the Internet via an IPsec VPN. Another is authenticating an administrator’s access to a router console port, auxiliary port, or vty ports.

AAA access control is supported on Cisco networking products using either a local username-password database or through a remote security server database. To provide access to a small group of network users, a local security database can be configured in the router using the username xyz password strongpassword command. The username secret command may also be used to configure a username and an associated MD5-encrypted secret.

A remote security server may also be used. This implementation uses a remote security database on a separate server running an AAA security protocol. This can provide AAA services for multiple network devices and a large number of network users.

Router Access Authentication

Three general steps are required to configure a Cisco router to perform AAA using a local user database for authentication. It is critical that you secure the interfaces of all your routers—most importantly, network access servers and perimeter routers connecting to the Internet. AAA commands are used to configure the router to secure administrative access and remote LAN network access. Table 4-2 compares the router access modes, port types, and AAA command elements.

Six steps are required to configure a Cisco router for local authentication:
Step 1 Secure access to privileged EXEC mode.
Step 2 Use the aaa new-model command to enable AAA globally on the perimeter router.
Step 3 Configure AAA authentication lists.
Step 4 Configure AAA authorization for use after the user has passed authentication.
Step 5 Configure the AAA accounting options.
Step 6 Verify the configuration.

Using AAA to Configure Local User Database Authentication

To configure a router to use the AAA process, you must begin by issuing the aaa newmodel command. This command is a critical first step in establishing a local AAA user authentication account. By establishing the local authentication method, you can reestablish your Telnet or console session and use the locally defined authentication list to access the router should a connection be lost while you’re configuring AAA. Failing to do this causes the administrator to be locked out of the router. If this is the case, you need physical access to the router (console session), and you are required to perform a password recovery sequence. In the most extreme cases, the entire configuration saved in NVRAM may be lost.
At a minimum, these commands should be entered, in this order:

Router(config)# aaa new- model
Router(config)# username username password password
Router(config)# aaa authentication login default local
The following is a complete list of aaa authentication commands for Cisco IOS Release 12.2 and later:
aaa authentication arap
aaa authentication banner
aaa authentication enable default
aaa authentication fail- message
aaa authentication local- override
aaa authentication login
aaa authentication nasi
aaa authentication password- prompt
aaa authentication ppp
aaa authentication username- prompt

For a complete description of each aaa authentication command, refer to Table 4-3.

Although understanding all these commands can be quite useful, it is important that you learn the following three commands and how to implement them in an AAA environment:

• The aaa authentication login command
• The aaa authentication ppp command
• The aaa authentication enable default command

After you have enabled AAA globally on the access server, you need to define the authentication method lists and apply them to lines and interfaces. These are security profiles that indicate the service, PPP, dot1x, or login and authentication method. You may specify up to five authentication methods (local, group TACACS+, group RADIUS, line, or enable authentication) to apply to a line or interface. Although our focus in this section is on the local user database, if you are working with multiple authentication methods, it is a best practice to have either local or enable authentication as the final method to recover
from a severed link to the chosen method server.

Defining a Method List
To define an authentication method list using the aaa authentication command, you need to follow three steps:
Step 1 In global configuration mode, use the aaa authentication command to configure an AAA authentication method list:

• Indicate the service (PPP, dot1x, and so on) or login authentication.
• Either use the default method list name or specify a method list name. Be aware that a defined method list overrides the default method list after it is applied to an interface. If this is not applied, the default method list applies.
• A list name may be any alphanumeric string you want to use. You may configure multiple strings on the router, but each must have a unique name.
• Method lists are sequential lists that describe the authentication methods that should be queried when authenticating a user. These allow an administrator to designate one or more security protocols to be used for authentication, allowing for a backup system for authentication should the initial method have an error or not be reachable.

Step 2 Specify the authentication method (local, group TACACS+, group RADIUS, line, or enable authentication), and how the router should handle requests when a method is not operating. For instance, is a AAA server down?
Up to four methods may be specified.
Step 3 Apply the authentication method lists to each of the following:

1. Lines: TTY, vty, console, auxiliary, and async lines, or the console port for login and asynchronous lines (in most cases) for ARAP
2. Interfaces: Interfaces sync, async, and virtual configured for PPP, Serial Line Interface Protocol (SLIP), NASI, or ARAP

Setting AAA Authentication for Login

The aaa authentication login command is issued in global configuration mode to set AAA authentication for login to a router’s administration port. The following is a list of these commands:

• aaa authentication login default enable is used to specify a default login authentication method list using the enable password.
• aaa authentication login console-in local specifies the login authentication method list named console-in using the local username-password database on the router.
• aaa authentication login tty-in is used to specify a login authentication list named ttyin using the line password configured on the router.

The following is an example of the syntax to be used for the aaa authentication command: aaa authentication login {default | list-name} method1 [ method2…]
Table 4-4 lists the aaa authentication login command elements and details their usage.

Configuring AAA Authentication on Serial Interfaces Running PPP

You may specify one or more AAA authentication methods for use on serial interfaces running PPP. To do this, you use the aaa authentication ppp command from global configuration mode. Here are the choices:

• aaa authentication ppp default local: This command is used to specify a default PPP authentication method list using the local username-password database on the router.
• aaa authentication ppp dial-in local none: This command is used to specify a PPP authentication method list named dial-in. It should be used on the initial login attempt, using the local username-password database on the router. If the local username is not defined, no authentication is used.

Using the aaa authentication enable default Command

To enable AAA authentication to determine if a user can access the privileged command level, you use the aaa authentication enable default command. This command should be issued from global configuration mode. The following is an example of the syntax to be used for this command:
aaa authentication enable default method1 [ method2…]
Authentication commands may be applied to both router lines and interfaces. As a best practice, you should always define a default list for AAA to provide a means of “last resort” authentication on all lines and interfaces protected by AAA. Example 4-1 shows the application of the authentication commands to router lines and interfaces.

Example 4-1 Applying Authentication Commands to Router Lines and Interfaces

router(config)# line console 0
router(config-line)# login authentication console- in
router(config)# int s3/0
router(config-if)# ppp authentication chap dial- in

Let’s examine these commands:

• line console 0 is issued to enter line console configuration mode.
• login authentication console-in specifies an authentication list named console-in for login authentication on console port 0.
• int s3/0 is issued to enter interface configuration mode on port 0 of serial interface slot number 3.
• ppp authentication chap dial-in specifies an authentication method list named dialin for use with PPP CHAP authentication on interface s3/0.

Implementing the aaa authorization Command

To set parameters that will restrict administrative EXEC access to the routers or user access to the network, you may use the aaa authorization command from global configuration mode. The following is the syntax:
aaa authorization {network | exec | commands level |
reverse- access | configuration} {default | list-name}
method1 [ method2…]

Additionally, you can name authorization lists after specifying the service. You may list up to four failover methods. Here are some examples of the aaa authorization command:

router(config)# aaa authorization commands 15 default local
router(config)# aaa authorization commands 1 mickey local
router(config)# aaa authorization commands 15 goofy local
router(config)# aaa authorization network pluto local none
router(config)# aaa authorization exec donald if-authenticated

These commands are as follows:

• aaa authorization commands 15 default local: The local user database is used to authorize the use of all level 15 commands for the default method list.
• aaa authorization commands 1 mickey local: The local username database is used to authorize all level 1 commands for the mickey method list.
• aaa authorization commands 15 goofy local: The local user database is used to authorize the use of all level 15 commands for the goofy method list.
• aaa authorization network pluto local none: The local user database is used to
  authorize the use of all network services, such as SLIP, PPP, and ARAP, for the method list named Pluto. If no local username is defined, this command does not perform authorization, and the user can use all network services.
• aaa authorization exec donald if-authenticated: If the user has already been authenticated, this command allows the user to run the EXEC process.

Working with the aaa accounting Command

In addition to authorization and authentication, AAA provides accounting capabilities for either billing or security purposes, or both. To enable AAA accounting of a requested service when you are working with RADIUS or TACACS+, you issue the aaa accounting command from global configuration mode:

aaa accounting {auth- proxy | system | network | exec |
 connection | commands level} {default | list-name} [ vrf vrf-name]
 {start- stop | stop- only | none} [ broadcast] group
 group-name

Table 4-6 explains the options that can be used with the aaa accounting command.

The following are a couple of examples of how this command may be implemented:

router(config)# aaa accounting commands 15 default stop-only group tacacs+
router(config)# aaa accounting auth- proxy default start-stop group tacacs+

The first example defines a default command accounting method list. Accounting services in this case are provided by a TACACS+ security server, and it has been set for privilege level 15 commands. A stop-only restriction is also implemented in this example. The second example defines a default authentication proxy accounting method list in which accounting services are provided by a TACACS+ security server for authentication proxy events with a start-stop restriction. If you are unfamiliar with authentication proxy or the auth-proxy command, it is used to authenticate inbound or outbound users, or both.

Using the CLI to Troubleshoot AAA for Cisco Routers

The primary command used when troubleshooting AAA on Cisco routers is the debug command. Three separate debug commands may be used to troubleshoot the various aspects of AAA:

• debug aaa authentication: Use this command to display debugging messages for the authentication functions of AAA.
• debug aaa authorization: Use this command to display debugging messages for the authorization functions of AAA.
• debug aaa accounting: Use this command to display debugging messages for the accounting functions of AAA.

Each of these commands should be executed from privileged EXEC mode to display the required information. To disable debugging for any of these functions, use the no form of the command, such as no debug aaa authentication. Example 4-2 shows sample output from the debug aaa authentication command.

Example 4-2 Using the debug aaa authentication Command

router# debug aaa authentication
113123: Feb 4 10:11:19.305 CST: AAA/MEMORY: create_user (0x619C4940) user=''
ruser='' port='tty1' rem_addr='async/81560' authen_type=ASCII service=LOGIN
 priv=1
113124: Feb 4 10:11:19.305 CST: AAA/AUTHEN/START (2784097690): port='tty1'
 list=''
action=LOGIN service=LOGIN
113125: Feb 4 10:11:19.305 CST: AAA/AUTHEN/START (2784097690): using "default"
 list
113126: Feb 4 10:11:19.305 CST: AAA/AUTHEN/START (2784097690): Method=LOCAL
113127: Feb 4 10:11:19.305 CST: AAA/AUTHEN (2784097690): status = GETUSER
113128: Feb 4 10:11:26.305 CST: AAA/AUTHEN/CONT (2784097690): continue_login
(user='(undef)')
113129: Feb 4 10:11:26.305 CST: AAA/AUTHEN (2784097690): status = GETUSER
113130: Feb 4 10:11:26.305 CST: AAA/AUTHEN/CONT (2784097690): Method=LOCAL
113131: Feb 4 10:11:26.305 CST: AAA/AUTHEN (2784097690): status = GETPASS
113132: Feb 4 10:11:28.145 CST: AAA/AUTHEN/CONT (2784097690): continue_login
(user='diallocal')
113133: Feb 4 10:11:28.145 CST: AAA/AUTHEN (2784097690): status = GETPASS
113134: Feb 4 10:11:28.145 CST: AAA/AUTHEN/CONT (2784097690): Method=LOCAL
113135: Feb 4 10:11:28.145 CST: AAA/AUTHEN (2784097690): status = PASS

In Example 4-2, a user has attempted to log in to the router using the ttyl port. The user tries to access user mode (privilege level 1) using a plain-text authentication method (PAP in this case). The router identifies the default list to be used for authentication. The default list has been configured for authentication against the local user database. Status messages of GETUSER and GETPASS indicate that the router collects the username and password. A check of the local user database, denoted as LOCAL in the debugging output, verifies that the credentials are correct and the user is permitted to access the router. This is indicated in the PASS status in the debugging output.

Using Cisco SDM to Configure AAA

In addition to working with the CLI, you can configure and edit AAA using the Cisco Router and Security Device Manager (SDM). To configure or edit AAA using the Cisco SDM, first you issue the aaa new-model command from the CLI. Then you can configure or edit AAA using Cisco SDM by choosing Additional Tasks > AAA. Next, click the Enable AAA button in the upper-right corner to enable AAA on the router. The SDM takes precautionary steps to prevent locking the router or disconnecting the SDM session.

Figure 4-2 shows the AAA Authentication Login Screen with two login authentication method lists configured on the router. One is the default method list, and the other is the sdm_vpn_xauth_ml_l method list. Each of these method lists uses the local user database to provide login authentication. The screen shown is where you can configure new login authentication method lists, as well as edit or delete existing login authentication method lists on the router.

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
• 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
• VoIP
• Firewalls
• VPNs
  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 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
  • NDGs
  • 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
• 1 GB of RAM
• 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 800×600 pixels
• CD-ROM drive
• 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:
  • SP4 must be installed.
  • 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)

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 Cisco.com. 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.
  
  
  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
• Yes, I Want to View the Readme File

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: http://127.0.0.1:2002
or
http://localhost:2002
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.

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

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.

TACACS+ Attributes

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

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

TACACS+ Attributes

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

• 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. he 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 AccessAccept 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.

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-Name
• User-Password (encrypted)
• CHAP-Password
• NAS-IP-Address
• NAS-Port
• Service-Type
• 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+.

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+.
Table 4-9 lists commonly used AAA configuration commands and their functions. 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:

Example 4-3 Configuring the Network Access Server with TACACS+

router(config)# aaa new- model
router(config)# tacacs- server host 1 92. 1 68. 1 0. 75 single connection
router(config)# tacacs- server key shared1

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

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:

aaa authentication login {default | list-name} group
{group-name | radius | tacacs+}
[ method2 [ method3 [ method4]]]
Table 4-10 lists the aaa authentication login parameters, along with the details of their usage.

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.

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.

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.

• CCNA Security Study Notes