03_9781587132483_ch03.

qxp 7/13/09 1:08 PM Page 63

CHAPTER 3

Authentication, Authorization, and Accounting

Chapter Introduction
A network must be designed to control who is allowed to connect to it and what they are allowed
to do when they are connected. These design specifications are identified in the network security
policy. The policy specifies how network administrators, corporate users, remote users, business
partners, and clients access network resources. The network security policy can also mandate the
implementation of an accounting system that tracks who logged in and when and what they did
while logged in.
Managing network access using only the user mode or privilege mode password commands is lim-
ited and does not scale well. Instead, using the Authentication, Authorization, and Accounting
(AAA) protocol provides the necessary framework to enable scalable access security.
Cisco IOS routers can be configured to use AAA to access a local username and password data-
base. Using a local username and password database provides greater security than a simple pass-
word and is a cost effective and easily implemented security solution. Cisco IOS routers can also
be configured to use AAA to access a Cisco Secure Access Control Server (ACS). Using Cisco
ACS is very scalable because all infrastructure devices access a central server. The Cisco Secure
ACS solution is also fault tolerant because multiple servers can be configured. The Cisco Secure
ACS solution is often implemented by large organizations.
A hands-on lab for the chapter, Securing Administrative Access Using AAA and RADIUS, allows
learners to use CLI and SDM to configure and test local authentication with and without AAA.
Centralized authentication using AAA and RADIUS is also explored. The lab is found in the lab
manual on Academy Connection at cisco.netacad.net.
A Packet Tracer activity, Configure AAA Authentication on Cisco Routers, provides learners addi-
tional practice implementing the technologies introduced in this chapter. Learners configure local
authentication with and without AAA. Server-based AAA authentication is configured with
TACACS+ and RADIUS. Packet Tracer activities for CCNA Security are found on Academy Con-
nection at cisco.netacad.net.

3.1 Purpose of AAA

3.1.1 AAA Overview
Network intruders can potentially gain access to sensitive network equipment and services. To
help prevent unwanted access, access control is necessary. Access control limits who or what can
use specific resources as well as the services or options available once access is granted. Many
types of authentication methods can be performed on a Cisco device, and each method offers vary-
ing levels of security.
The simplest form of authentication is passwords. This method is configured using a login and
password combination on console, and vty lines and aux ports. This method is the easiest to imple-
ment, but it is also the weakest and least secure. Password-only logins are very vulnerable to brute-
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 64

64 CCNA Security Course Booklet, Version 1.0

force attacks. Additionally, this method provides no accountability. Anyone with the password can
gain entry to the device and alter the configuration.
To help provide accountability, local database authentication can be implemented using one of the
following commands:
username username password password
username username secret password
This method creates individual user accounts on each device with a specific password assigned to
each user. The local database method provides additional security, because an attacker is required
to know a username and a password. It also provides more accountability, because the username is
recorded when a user logs in. Keep in mind that the username password command combination
displays the password in plaintext in the configuration file if the service password-encryption
command is not configured. The username secret combination is highly recommended because it
provides MD5-style encryption.
The local database method has some limitations. The user accounts must be configured locally on
each device. In a large enterprise environment that has multiple routers and switches to manage, it
can take time to implement and change local databases on each device. Additionally, the local
database configuration provides no fallback authentication method. For example, what if the ad-
ministrator forgets the username and password for that device? With no backup method available
for authentication, password recovery becomes the only option.
A better solution is to have all devices refer to the same database of usernames and passwords
from a central server. This chapter explores the various methods of securing network access using
Authentication, Authorization, and Accounting (AAA) to secure Cisco routers.
AAA network security services provide the primary framework to set up access control on a net-
work device. AAA is a way to control who is permitted to access a network (authenticate), what
they can do while they are there (authorize), and to audit what actions they performed while ac-
cessing the network (accounting). It provides a higher degree of scalability than the con, aux, vty
and privileged EXEC authentication commands alone.
Network and administrative AAA security in the Cisco environment has several functional compo-
nents:

■ Authentication - Users and administrators must prove that they are who they say they are.
Authentication can be established using username and password combinations, challenge and
response questions, token cards, and other methods. For example: “I am user ‘student’. I know
the password to prove that I am user student.”
■ Authorization - After the user is authenticated, authorization services determine which
resources the user can access and which operations the user is allowed to perform. An
example is “User ‘student’ can access host serverXYZ using Telnet only.”
■ Accounting and auditing - Accounting records what the user does, including what is
accessed, the amount of time the resource is accessed, and any changes that were made.
Accounting keeps track of how network resources are used. An example is “User ‘student’
accessed host serverXYZ using Telnet for 15 minutes.”

This concept is similar to the use of a credit card. The credit card identifies who can use it, how
much that user can spend, and keeps account of what items the user spent money on.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 65

Chapter 3: Authentication, Authorization, and Accounting 65

3.1.2 AAA Characteristics

AAA Authentication
AAA can be used to authenticate users for administrative access or it can be used to authenticate
users for remote network access. These two access methods use different modes to request AAA
services:

■ Character mode - A user sends a request to establish an EXEC mode process with the router
for administrative purposes.
■ Packet mode - A user sends a request to establish a connection through the router with a
device on the network.

With the exception of accounting commands, all AAA commands apply to both character mode
and packet mode. This topic focuses on securing character mode access. For a truly secure net-
work, it is important to also configure the router for secure administrative access and remote LAN
network access using AAA services as well.
Cisco provides two common methods of implementing AAA services.
Local AAA Authentication
Local AAA uses a local database for authentication. This method stores usernames and passwords
locally in the Cisco router, and users authenticate against the local database. This database is the
same one required for establishing role-based CLI. Local AAA is ideal for small networks.
Server-Based AAA Authentication
The server-based method uses an external database server resource that leverages RADIUS or
TACACS+ protocols. Examples include Cisco Secure Access Control Server (ACS) for Windows
Server, Cisco Secure ACS Solution Engine, or Cisco Secure ACS Express. If there are multiple
routers, server-based AAA is more appropriate.
AAA Authorization
After users are successfully authenticated against the selected AAA data source (local or server-
based), they are then authorized for specific network resources. Authorization is basically what a
user can and cannot do on the network after that user is authenticated, similar to how privilege lev-
els and role-based CLI give users specific rights and privileges to certain commands on the router.
Authorization is typically implemented using an AAA server-based solution. Authorization uses a
created set of attributes that describes the user’s access to the network. These attributes are com-
pared to the information contained within the AAA database, and a determination of restrictions
for that user is made and delivered to the local router where the user is connected.
Authorization is automatic and does not require users to perform additional steps after authentica-
tion. Authorization is implemented immediately after the user is authenticated.
AAA Accounting
Accounting collects and reports usage data so that it can be employed for purposes such as audit-
ing or billing. The collected data might include the start and stop connection times, executed com-
mands, number of packets, and number of bytes.
Accounting is implemented using an AAA server-based solution. This service reports usage statis-
tics back to the ACS server. These statistics can be extracted to create detailed reports about the
configuration of the network.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 66

66 CCNA Security Course Booklet, Version 1.0

One widely deployed use of accounting is combining it with AAA authentication for managing ac-
cess to internetworking devices by network administrative staff. Accounting provides extra ac-
countability above and beyond authentication. The AAA servers keep a detailed log of exactly
what the authenticated user does on the device. This includes all EXEC and configuration com-
mands issued by the user. The log contains numerous data fields, including the username, the date
and time, and the actual command that was entered by the user. This information is useful when
troubleshooting devices. It also provides leverage against individuals who perform malicious ac-
tions.

3.2 Local AAA Authentication

3.2.1 Configuring Local AAA Authentication with CLI
Local AAA Authentication, also referred to as self-contained authentication, should be configured
for smaller networks, such as those with one or two routers providing access to a limited number
of users. This method uses the local usernames and passwords stored on a router. The system ad-
ministrator must populate the local security database by specifying username and password pro-
files for each user that might log in.
The Local AAA Authentication method is similar to using the login local command with one
exception. AAA also provides a way to configure backup methods of authentication.
Configuring local AAA services to authenticate administrator access (character mode access) re-
quires a few basic steps.
Step 1. Add usernames and passwords to the local router database for users that need administra-
tive access to the router.
Step 2. Enable AAA globally on the router.
Step 3. Configure AAA parameters on the router.
Step 4. Confirm and troubleshoot the AAA configuration.
To enable AAA, use the aaa new-model global configuration command. To disable AAA, use the
no form of this command.

After AAA is enabled, to configure authentication on vty ports, asynchronous lines (tty), the auxil-
iary port, or the console port, define a named list of authentication methods and then apply that list
to the various interfaces.
To define a named list of authentication methods, use the aaa authentication login command.
This command requires a list name and the authentication methods. The list name identifies the list
of authentication methods activated when a user logs in. The method list is a sequential list de-
scribing the authentication methods to be queried for authenticating a user. Method lists enable an
administrator to designate one or more security protocols for authentication. Using more than one
protocol provides a backup system for authentication in case the initial method fails.
Several keywords can be used to indicate the method. To enable local authentication using a pre-
configured local database, use the keyword local or local-case. The difference between the two
options is that local accepts a username regardless of case, and local-case is case-sensitive. To
specify that a user can authenticate using the enable password, use the enable keyword. To ensure
that the authentication succeeds even if all methods return an error, specify none as the final
method. For security purposes, use the none keyword only when testing the AAA configuration. It
should never be applied on a live network.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 67

Chapter 3: Authentication, Authorization, and Accounting 67

For example, the enable method could be configured as a fallback mechanism in case the user-
name and password is forgotten.
aaa authentication login TELNET-ACCESS local enable

In this example, an AAA authentication list named TELNET-ACCESS is created that requires
users to attempt to authenticate to the router’s local user database first. If that attempt returns an
error, such as a local user database is not configured, the user can attempt to authenticate by know-
ing the enable password.
A minimum of one method and a maximum of four methods can be specified for a single method
list. When a user attempts to log in, the first method listed is used. Cisco IOS software attempts
authentication with the next listed authentication method only when there is no response or an
error from the previous method occurs. If the authentication method denies the user access, the au-
thentication process stops and no other authentication methods are allowed.
The defined list of authentication methods must be applied to specific interfaces or lines. For flexi-
bility, different method lists can be applied to different interfaces and lines. For example, an ad-
ministrator could apply a special login for Telnet and then have a different login method for the
line console. To enable a specific list name, use the aaa login authentication list-name com-
mand in line configuration mode.
The option also exists to configure a default list name. When AAA is first enabled, the default
method list named “default” is automatically applied to all interfaces and lines, but it has no au-
thentication methods defined. To assign multiple authentication methods to the default list, use the
command aaa authentication login default method1... [method4].
The authentication methods in the default list are used by default on all lines, unless a custom au-
thentication method list is created. If an interface or line has a nondefault method list applied to it,
that method overrides the default method list for that interface. If the default list is not set and
there is no other list, only the local user database is checked. This has the same effect as the com-
mand aaa authentication login default local. On the console, login succeeds without any
authentication checks if default is not set.
Once a custom authentication method-list is applied to an interface, it is possible to return to the
default method list by using the no aaa authentication login list-name command. If the de-
fault list has not been defined, then AAA authentication does not occur.
Additional security can be implemented on the line using the aaa local authentication at-
tempts max-fail number-of-unsuccessful-attempts command in global configuration mode.
This command secures AAA user accounts by locking out accounts that have excessive failed at-
tempts. To remove the number of unsuccessful attempts that was set, use the no form of this com-
mand.
To display a list of all locked-out users, use the show aaa local user lockout command in priv-
ileged EXEC mode. Use the clear aaa local user lockout {username username | all} com-
mand in privileged EXEC mode to unlock a specific user or to unlock all locked users.
The aaa local authentication attempts max-fail command differs from the login delay
command in how it handles failed attempts. The aaa local authentication attempts max-
fail command locks the user account if the authentication fails. This account stays locked until it
is cleared by an administrator. The login delay command introduces a delay between failed login
attempts without locking the account.
When a user logs into a Cisco router and uses AAA, a unique ID is assigned to the session.
Throughout the life of the session, various attributes that are related to the session are collected
and stored internally within the AAA database. These attributes can include the IP address of the
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 68

68 CCNA Security Course Booklet, Version 1.0

user, the protocol that is used to access the router, such as PPP or Serial Line Internet Protocol
(SLIP), the speed of the connection, and the number of packets or bytes that are received or trans-
mitted.
To display the attributes that are collected for an AAA session, use the show aaa user {all |
unique id} command in privileged EXEC mode. This command does not provide information for
all users who are logged into a device, but only for those who have been authenticated or author-
ized using AAA or whose sessions are being accounted for by the AAA module.
The show aaa sessions command can be used to show the unique ID of a session.

3.2.2 Configuring Local AAA Authentication with SDM

AAA is enabled by default in Cisco SDM, but it is a good idea to confirm that is currently enabled.
To verify the AAA configuration and to enable or disable AAA, choose Configure > Additional
Tasks > AAA.
If the Disable AAA button is clicked, Cisco SDM displays an informational message stating that it
will make configuration changes to ensure that the router can be accessed after AAA is disabled.
The first task when using SDM to configure AAA services for local authentication is to create
users:
Step 1. Choose Configure > Additional Tasks > Router Access > User Accounts/View.
Step 2. Click Add to add a new user.
Step 3. In the Add an Account window, enter the username and password in the appropriate fields
to define the user account.
Step 4. From the Privilege Level drop-down list, choose 15, unless there are lesser privilege levels
defined.
Step 5. If views have been defined, check the Associate a View with the User check box and
choose a view from the View Name list that is associated with a user.
Step 6. Click OK.
The CLI command that Cisco SDM generates is username AAAadmin privilege 15 secret 5
$1$f16u$uKOO6J/UnojZ0bCEzgnQi1 view root.

To configure AAA authentication, an administrator must first either define a list of authentication
methods for the default method or configure a named method list and apply it. Different method
lists can be created and applied to different interfaces or lines.
Configure the default method list for login authentication using the local database:
Step 1. Choose Configure > Additional Tasks > AAA > Authentication Policies > Login and
click Add.
Step 2. In the Add a Method List for Authentication Login window, verify that Default is selected
in the Name drop-down list.
Step 3. Click Add.
Step 4. From the Select Method List(s) for Authentication Login window, choose local from the
method list.
Step 5. Click OK.
The CLI command that Cisco SDM generates is aaa authentication login default local.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 69

Chapter 3: Authentication, Authorization, and Accounting 69

3.2.3 Troubleshooting Local AAA Authentication

The Cisco router has debug commands that are useful for troubleshooting authentication issues.
The debug aaa command contains several keywords that can be used for this purpose. Of special
interest is the debug aaa authentication command.
The best time to understand debug output is when everything is working properly. Knowing how
debug output displays when all is well helps identify problems when things are not working prop-
erly. Exercise caution when using the debug command in a production environment because these
commands place a significant load on router resources and can affect network performance.
The debug aaa authentication command is instrumental when troubleshooting AAA problems.
To disable this command, use the no form of the command or the all-encompassing undebug all
statement.
Look specifically for GETUSER and GETPASS status messages. The Method message is also
helpful when identifying which method list is being referenced.

3.3 Server-Based AAA

3.3.1 Server-Based AAA Characteristics
Local implementations of AAA do not scale well. Most corporate environments have multiple
Cisco routers with multiple router administrators and hundreds or thousands of users needing ac-
cess to the corporate LAN. Maintaining local databases for each Cisco router for this size of net-
work is not feasible.
To solve this challenge, one or more AAA servers, such as Cisco Secure ACS, can be used to man-
age the user and administrative access needs for an entire corporate network. Cisco Secure ACS
can create a central user and administrative access database that all devices in the network can ac-
cess. It can also work with many external databases, including Active Directory and Lightweight
Directory Access Protocol (LDAP). These databases store user account information and pass-
words, allowing for central administration of user accounts.
The Cisco Secure ACS family of products supports both Terminal Access Control Access Control
Server Plus (TACACS+) and Remote Dial-in User Services (RADIUS) protocols, which are the
two predominant protocols used by Cisco security appliances, routers, and switches for imple-
menting AAA.
While both protocols can be used to communicate between client and AAA servers, TACACS+ is
considered the more secure protocol. This is because all TACACS + protocol exchanges are en-
crypted; Radius only encrypts the user password. It does not encrypt user names, accounting infor-
mation, or any other information carried in the radius message.

3.3.2 Server-Based AAA Communication Protocols

TACACS+ and RADIUS are both authentication protocols. Each supports different capabilities
and functionality. Whether TACACS+ or RADIUS is selected depends on the needs of the organi-
zation. For example, a large ISP might select RADIUS because it supports detailed accounting re-
quired for billing users. An organization with various user groups might select TACACS+ because
it requires select authorization policies to be applied on a per-user or per-group basis.
It is important to understand the many differences between the TACACS+ and RADIUS protocols.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 70

70 CCNA Security Course Booklet, Version 1.0

Critical factors for TACACS+ include:

■ Is incompatible with TACACS and XTACACS

■ Separates authentication and authorization
■ Encrypts all communication
■ Utilizes TCP port 49

Critical factors for Radius include:

■ Uses RADIUS proxy servers for scalability

■ Combines RADIUS authentication and authorization as one process.
■ Encrypts only the password
■ Utilizes UDP
■ Supports remote-access technologies, 802.1X, and SIP

TACACS+ is a Cisco enhancement to the original TACACS protocol. Despite its name, TACACS+
is an entirely new protocol that is incompatible with any previous version of TACACS. TACACS+
is supported by the Cisco family of routers and access servers as part of maintenance Cisco IOS
Release 10.3. Cisco is currently presenting TACACS+ to the IETF working groups and is con-
tributing to and adopting the emerging protocol standards.
TACACS+ provides separate AAA services. Separating the AAA services provides flexibility in
implementation, because it is possible to use TACACS+ for authorization and accounting while
using another method of authentication.
The extensions to the TACACS+ protocol provide more types of authentication requests and re-
sponse codes than were in the original TACACS specification. TACACS+ offers multiprotocol
support, such as IP and AppleTalk. Normal TACACS+ operation encrypts the entire body of the
packet for more secure communications and utilizes TCP port 49.
RADIUS, developed by Livingston Enterprises, is an open IETF standard AAA protocol for appli-
cations such as network access or IP mobility. RADIUS works in both local and roaming situa-
tions and is commonly used for accounting purposes. RADIUS is currently defined by RFCs 2865,
2866, 2867, and 2868.
The RADIUS protocol hides passwords during transmission, even with the Password Authentica-
tion Protocol (PAP), using a rather complex operation that involves Message Digest 5 (MD5)
hashing and a shared secret. However, the rest of the packet is sent in plaintext.
RADIUS combines authentication and authorization as one process. When a user is authenticated,
that user is also authorized. RADIUS uses UDP port 1645 or 1812 for authentication and UDP
port 1646 or 1813 for accounting.
RADIUS is widely used by VoIP service providers. It passes login credentials of a session initia-
tion protocol (SIP) endpoint, such as a broadband phone, to a SIP Registrar using digest authenti-
cation, and then to a RADIUS server using RADIUS. RADIUS is also a common authentication
protocol that is utilized by the 802.1X security standard.
The DIAMETER protocol is the planned replacement for RADIUS. DIAMETER uses a new
transport protocol called Stream Control Transmission Protocol (SCTP) and TCP instead of UDP.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 71

Chapter 3: Authentication, Authorization, and Accounting 71

3.3.3 Cisco Secure ACS

Many enterprise-level authentication servers are on the market today. Funk’s Steel-Belted RA-
DIUS server, Livingston Enterprises’ RADIUS Authentication Billing Manager, and Merit Net-
works’ RADIUS servers are well known. While these are reputable companies with popular
products, they lack the ability to combine both the TACACS+ and RADIUS protocols into a single
solution. Fortunately, the Cisco Secure ACS for Windows Server (ACS) is a single solution that of-
fers AAA for both TACACS+ and RADIUS.
Cisco Secure ACS is a highly scalable, high-performance access control server that can be lever-
aged to control administrator access and configuration for all network devices in a network sup-
porting RADIUS or TACACS+ or both. Cisco Secure ACS offers several benefits:

■ Extends access security by combining authentication, user access, and administrator access
with policy control within a centralized identity networking solution.
■ Allows greater flexibility and mobility, increased security, and user-productivity gains.
■ Enforces a uniform security policy for all users, regardless of how they access the network.
■ Reduces the administrative and management burden when scaling user and network
administrator access to the network.
Cisco Secure ACS uses a central database. It centralizes the control of all user privileges and dis-
tributes them to access points throughout the network. Cisco Secure ACS provides detailed report-
ing and monitoring capabilities of user behavior, access connections, and device configuration
changes. This feature is extremely important for organizations trying to comply with various gov-
ernment regulations. Cisco Secure ACS supports a broad variety of access connections, including
wired and wireless LAN, dialup, broadband, content, storage, VoIP, firewalls, and virtual private
networks (VPNs).
Cisco Secure ACS provides a variety of advanced features:

■ Automatic service monitoring

■ Database synchronization and importing of tools for large-scale deployments
■ LDAP user authentication support
■ User and administrative access reporting
■ Restrictions to network access based on criteria such as the time of day and the day of week
■ User and device group profiles
Cisco Secure ACS is an important component of the Cisco Identity Based Networking Services
(IBNS) architecture. Cisco IBNS is based on port-security standards such as IEEE 802.1X and Ex-
tensible Authentication Protocol (EAP), and extends security from the perimeter of the network to
every connection point inside the LAN. New policy control, such as per-user quotas, VLAN as-
signments, and access control lists (ACLs) can be deployed within this new architecture. This is
due to the extended capabilities of Cisco switches and wireless access points to query Cisco Se-
cure ACS over the RADIUS protocol.
Cisco Secure ACS is also an important component of Cisco Network Admission Control (NAC).
Cisco NAC is an industry initiative sponsored by Cisco. Cisco NAC uses the network infrastruc-
ture to enforce security-policy compliance on all devices seeking to access network computing re-
sources. This limits damage from viruses and worms. With Cisco NAC, customers can choose to
allow network access only to compliant and trusted endpoint devices and restrict the access of
noncompliant devices. NAC is part of the Cisco Self-Defending Network initiative and is the foun-
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 72

72 CCNA Security Course Booklet, Version 1.0

dation for enabling NAC on Layer 2 and Layer 3 networks. Future phases extend endpoint and net-
work security interoperation to include dynamic incident-containment capabilities. This innovation
enables compliant system elements to report misuse emanating from rogue or infected systems
during an attack. Infected systems can be dynamically quarantined from the rest of the network to
significantly reduce virus, worm, and blended threat propagation.
Cisco Secure ACS has many high-performance and scalability features:

■ Ease of use - A web-based user interface simplifies and distributes the configuration for user
profiles, group profiles, and Cisco Secure ACS configuration.
■ Scalability - Cisco Secure ACS is built to provide large networked environments with support
for redundant servers, remote databases, and database replication and backup services.
■ Extensibility - LDAP authentication forwarding supports the authentication of user profiles
that are stored in directories from leading directory vendors, including Sun, Novell, and
Microsoft.
■ Management - Microsoft Windows Active Directory support consolidates Windows
username and password management and uses the Windows Performance Monitor for real-
time statistics viewing.
■ Administration - Different access levels for each Cisco Secure ACS administrator and the
ability to group network devices together make it easier and more flexible to control the
enforcement and changes of security policy administration for all devices in a network.
■ Product flexibility - Because Cisco IOS software has embedded support for AAA, Cisco
Secure ACS can be used across virtually any network access server that Cisco sells (the Cisco
IOS software release must support RADIUS or TACACS+). Cisco Secure ACS is available in
three options: Cisco Secure ACS Solution Engine, Cisco Secure ACS Express, and Cisco
Secure ACS for Windows.
■ Integration - Tight coupling with Cisco IOS routers and VPN solutions provides features
such as multichassis multilink PPP and Cisco IOS software command authorization.
■ Third-party support - Cisco Secure ACS offers token server support for any one-time
password (OTP) vendor that provides an RFC-compliant RADIUS interface, such as RSA,
PassGo, Secure Computing, ActiveCard, Vasco, or CryptoCard.
■ Control - Cisco Secure ACS provides dynamic quotas to restrict access based on the time of
day, network use, number of logged sessions, and the day of the week.
Cisco Secure ACS is available as software installed on a Windows Server or on a 1U, rack-mount-
able, security-hardened server, such as ACS Solution Engine or ACS Express. All are server-based
examples of providing AAA services using a remote security database.
The Cisco Secure ACS for Windows option enables the AAA services on a router to contact an ex-
ternal Cisco Secure ACS installed on a Windows server system for user and administrator authenti-
cation.
Cisco Secure ACS Solution Engine is a 1U rack-mountable unit, security-hardened appliance with
a pre-installed Cisco Secure ACS license. It should be used in large organizations where more than
350 users need to be supported. Compared to the Cisco Secure ACS for Windows product, Cisco
Secure ACS Solution Engine reduces the total cost of ownership by eliminating the need to install
and maintain a Microsoft Windows server machine.
Cisco Secure ACS Express is also a 1U rack-mountable unit, security-hardened appliance with a
pre-installed Cisco Secure ACS Express license. The difference is that the ACS Express option is
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 73

Chapter 3: Authentication, Authorization, and Accounting 73

intended for commercial (less than 350 users), retail, and enterprise branch office deployments.
ACS Express offers a comprehensive yet simplified feature set, a user-friendly GUI, and a lower
price point that allows administrators to deploy this product in situations where Cisco Secure ACS
for Windows Server or Cisco Secure ACS Solution Engine might not be suitable.
While this chapter focuses on deploying Cisco Secure ACS for Windows Server, the concepts and
features discussed are also available on the ACS Solution Engine and ACS Express.

3.3.4 Configuring Cisco Secure ACS

Before installing Cisco Secure ACS, it is important to prepare the server. Third-party software re-
quirements and the network and port requirements of the server and AAA devices must be consid-
ered.
Third-Party Software Requirements
Software products that are mentioned in the release notes are supported for interoperability by
Cisco. Support for interoperability issues with software products that are not mentioned in the re-
lease notes might be difficult to attain. The most recent version of the Cisco Secure ACS release
notes are posted on Cisco.com.
Keep in mind that in the Cisco Secure ACS application, a client is a router, switch, firewall, or
VPN concentrator that uses the services of the server.
Network and Port Prerequisites
The network should meet specified requirements before administrators begin deploying Cisco Se-
cure ACS:

■ For full TACACS+ and RADIUS support on Cisco IOS devices, AAA clients must run Cisco
IOS Release 11.2 or later.
■ Cisco devices that are not Cisco IOS AAA clients must be configured with TACACS+,
RADIUS, or both.
■ Dial-in, VPN, or wireless clients must be able to connect to the applicable AAA clients.
■ The computer running Cisco Secure ACS must be able to reach all AAA clients using ping.
■ Gateway devices between the Cisco Secure ACS and other network devices must permit
communication over the ports that are needed to support the applicable feature or protocol.
■ A supported web browser must be installed on the computer running Cisco Secure ACS. For
the most recent information about tested browsers, see the release notes for the Cisco Secure
ACS product on Cisco.com.
■ All NICs in the computer running Cisco Secure ACS must be enabled. If there is a disabled
network card on the computer running Cisco Secure ACS, installing Cisco Secure ACS might
proceed slowly because of delays caused by the Microsoft CryptoAPI.
After successfully installing Cisco Secure ACS, some initial configuration must be performed. The
only way to configure a Cisco Secure ACS server is through an HTML interface.
To access the Cisco Secure ACS HTML interface from the computer that is running Cisco Secure
ACS, use the Cisco Secure icon labeled ACS Admin that appears on the desktop or enter the fol-
lowing URL into a supported web browser: http://127.0.0.1:2002.
The Cisco Secure ACS can also be accessed remotely after an administrator user account is config-
ured. To remotely access the Cisco Secure ACS, enter http://ip_address[hostname]:2002.
After the initial connection, a different port is dynamically negotiated.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 74

74 CCNA Security Course Booklet, Version 1.0

The home page of Cisco Secure ACS is divided into frames. The buttons on the navigation bar rep-
resent particular areas or functions that can be configured:

■ User Setup
■ Group Setup
■ Shared Profile Components
■ Network Configuration
■ System Configuration
■ Interface Configuration
■ Administration Control
■ External User Databases
■ Posture Validation
■ Network Access Profiles
■ Reports and Activity
■ Online Documentation
If the RADIUS options are not displayed, the AAA client that uses the RADIUS protocol must be
added. Additionally, the interface configuration is directly affected by the settings in the network
configuration.
Before configuring a router, switch, or firewall as a TACACS+ or RADIUS client, the AAA client
to the server must be added and the IP address and encryption key specified. The Network Config-
uration page is where the AAA clients are added, deleted, or modified.
To create an AAA client, use the Network Configuration page:
Step 1. Click Network Configuration on the navigation bar. The Network Configuration page ap-
pears.
Step 2. In the AAA Clients section, click Add Entry.
Step 3. Enter the client host name in the AAA Client Hostname field. For example, enter the name
of the router that will be a AAA client to the server. In the Cisco Secure ACS application, a client
is a router, switch, firewall, or VPN concentrator that uses the services of the server.
Step 4. Enter the IP address in the AAA Client IP Address field.
Step 5. Enter the secret key that the client uses for encryption in the Shared Secret field.
Step 6. Choose the appropriate AAA protocol from the Authenticate Using drop-down list.
Step 7. Complete other parameters as required.
Step 8. Click Submit and Apply.
The options that are available from the Interface Configuration navigation button allow the admin-
istrator to control the display of options in the user interface. The specific options displayed de-
pend on whether TACACS+ or RADIUS clients have been added to the server:

■ User Data Configuration

■ TACACS+ (Cisco IOS)
■ RADIUS (Microsoft)
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 75

Chapter 3: Authentication, Authorization, and Accounting 75

■ RADIUS (Ascend)
■ RADIUS (IETF)
■ RADIUS (IOS/PIX)
■ Advanced Options

The User Data Configuration link enables administrators to customize the fields that appear in the
user setup and configuration windows. Administrators can add fields such as phone number, work
location, supervisor name, or any other pertinent information.
The TACACS+ (Cisco IOS) link enables the administrator to configure TACACS+ settings as well
as add new TACACS+ services. Administrators can also configure advanced options that affect
what is displayed in the user interface.
Cisco Secure ACS can be configured to forward authentication of users to one or more external
user databases. Support for external user databases means that Cisco Secure ACS does not require
duplicate user entries to be created in the Cisco Secure user database. In organizations in which a
substantial user database already exists, such as an Active Directory environment, Cisco Secure
ACS can leverage the work already invested in building the database without any additional input.
For most database configurations, except for Windows databases, Cisco Secure ACS supports only
one instance of a username and password. If Cisco Secure ACS is configured to use multiple user
databases with common usernames stored in each, be careful with the database configurations. The
first database to match the authentication credentials of the user is the only one that Cisco Secure
ACS uses for that user. It is for this reason that it is recommended that there be only one instance
of a username in all the external databases.
Use the External User Databases button to configure Cisco Secure ACS to access external data-
bases:
Step 1. Click the External User Databases button from the navigation bar. The External User
Databases window appears with the following links:

■ Unknown User Policy - Configures the authentication procedure for users that are not located
in the Cisco Secure ACS database.
■ Database Group Mappings - Configures what group privileges external database users
inherit when Cisco Secure ACS authenticates them. In most cases, when a user is
authenticated by an external user database, the actual privileges are drawn from Cisco Secure
ACS and not the external database.
■ Database Configuration - Defines the external servers that Cisco Secure ACS works with.

Step 2. Click Database Configuration. The External User Database Configuration pane appears,
displaying the following options:

■ RSA SecurID Token Server

■ RADIUS Token Server
■ External ODBC Database
■ Windows Database
■ LEAP Proxy RADIUS Server
■ Generic LDAP
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 76

76 CCNA Security Course Booklet, Version 1.0

Step 3. To use the Windows database as an external database, click Windows Database. The Win-
dows External User Database Configuration pane appears.
The Windows external database configuration has more options than other external database con-
figurations. Because Cisco Secure ACS is native to the Windows operating system, administrators
can configure additional functionality on the Windows External User Database Configuration
pane.
Step 4. To configure the additional Windows database functionality, click Configure from the Ex-
ternal User Database Configuration pane. The Windows User Database Configuration window ap-
pears.
Step 5. If more control over who is able to authenticate to the network is required, the Dialin per-
mission option can also be configured. In the Dialin Permission section, check the Verify that
“Grant dialin permission to user” setting has been enabled from within the Windows User
Manager for users configured for Windows User Database authentication check box. Also
make sure that the Grant dialin permission check box is checked in the Windows profile within
Windows Users Manager.
The Dialin Permissions option of Cisco Secure ACS applies to more than just the dialup connec-
tions. If a user has this option enabled, it applies to any access that user tries to make.
Another option that can be configured using the Windows external database is mapping databases
to domains. Mapping allows an administrator to have the same username across different domains,
all with different passwords.

3.3.5 Configuring Cisco Secure ACS Users and Groups

After Cisco Secure ACS is configured to communicate with an external user database, it can be
configured to authenticate users with the external user database in one of two ways:

■ By specific user assignment - Authenticate specific users with an external user database.
■ By unknown user policy - Use an external database to authenticate users not found in the
Cisco Secure user database. This method does not require administrators to define users in the
Cisco Secure user database.
Use the External User Databases link to configure the unknown user policy:
Step 1. In the navigation bar, click External User Databases.
Step 2. Click Unknown User Policy.
Step 3. Enable the Unknown User Policy by checking the box in the Unknown User Policy sec-
tion.
Step 4. For each database that administrators want Cisco Secure ACS to use when attempting to
authenticate unknown users, choose the database in the External Databases list and click the right
arrow button to move it to the Selected Databases list. To remove a database from the Selected
Databases list, choose the database, and then click the left arrow button to move it back to the Ex-
ternal Databases list.
Step 5. To assign the order in which Cisco Secure ACS checks the selected external databases
when attempting to authenticate an unknown user, click a database name in the Selected Databases
list and click Up or Down to move it into the desired position. Place the databases that are most
likely to authenticate unknown users at the top of the list.
Step 6. Click Submit.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 77

Chapter 3: Authentication, Authorization, and Accounting 77

After a user is authenticated to an external database, the authorization that takes place is deter-
mined by Cisco Secure ACS. This can complicate things because users that are authenticated by a
Windows server might require different authorization than users that are authenticated by the
LDAP server.
Because of this potential need for different authorizations, place users that are authenticated by the
Windows server in one group and users that are authenticated by the LDAP server in another
group. To do this, use database group mappings.
Database group mappings enable an administrator to map an authentication server, such as LDAP,
Windows, ODBC, and so on, to a group that has been configured in Cisco Secure ACS. For some
databases, a user can belong to only one group. For other databases, such as LDAP and Windows,
support for group mapping by external database group membership is possible.
One of the things that can be configured in a group setup is per group command authorization,
which uses Cisco Secure ACS to authorize which router commands the users that belong to a
group can execute. For example, a group can be permitted to execute any router commands except
show running-config.

Step 1. Click Group Setup in the navigation bar.

Step 2. Choose the group to edit, the Default Group for example, and click Edit Settings.
Step 3. Click Permit in the Unmatched Cisco IOS commands option.
Step 4. Check the Command check box and enter show in the text box. In the Arguments text
box, enter deny running-config.
Step 5. For the Unlisted Arguments option, click Permit.
Adding a user account and configuring user access is a critical task for Cisco Secure ACS:
Step 1. Click User Setup in the navigation bar.
Step 2. Enter a username in the User field and click Add/Edit.
Step 3. In the Edit pane, enter data in the fields to define the user account. Some of the likely
needed fields are the user password fields, TACACS+ enable control, TACACS+ enable password,
and TACACS+ shell authorized commands.
Step 4. Click Submit.
If there are necessary user properties that you do not see, verify the interface configuration. To
modify the user interface, choose Interface Configuration > User Data Configuration.

3.4 Server-Based AAA Authentication

3.4.1 Configuring Server-Based AAA Authentication with
CLI
Unlike Local AAA Authentication, server-based AAA must identify various TACACS+ and RA-
DIUS servers that the AAA service should consult when authenticating and authorizing users.
There are a few basic steps to configure server-based authentication:
Step 1. Globally enable AAA to allow the use of all AAA elements. This step is a prerequisite for
all other AAA commands.
Step 2. Specify the Cisco Secure ACS that will provide AAA services for the router. This can be a
TACACS+ or RADIUS server.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 78

78 CCNA Security Course Booklet, Version 1.0

Step 3. Configure the encryption key needed to encrypt the data transfer between the network ac-
cess server and Cisco Secure ACS.
Step 4. Configure the AAA authentication method list to refer to the TACACS+ or RADIUS
server. For redundancy, it is possible to configure more than one server.
Configure a TACACS+ Server and Encryption Key
To configure a TACACS+ server, use the tacacs-server host ip-address single-connection
command.
The single-connection keyword enhances TCP performance by maintaining a single TCP con-
nection for the life of the session. Otherwise, by default, a TCP connection is opened and closed
for each session. If required, multiple TACACS+ servers can be identified by entering their respec-
tive IP address using the tacacs-server host command.
Next, use the tacacs-server key key command to configure the shared secret key to encrypt the
data transfer between the TACACS+ server and AAA-enabled router. This key must be configured
exactly the same on the router and the TACACS+ server.
Configure a RADIUS Server and Encryption Key
To configure a RADIUS server, use the radius-server host ip-address command. Because
RADIUS uses UDP, there is no equivalent single-connection keyword. If required, multiple RA-
DIUS servers can be identified by entering a radius-server host command for each server.
To configure the shared secret key for encrypting the password, use the radius-server key key
command. This key must be configured exactly the same on the router and the RADIUS server.
Configure Authentication to Use the AAA Server
When the AAA security servers have been identified, the servers must be included in the method
list of the aaa authentication login command. AAA servers are identified using the group
tacacs+ or group radius keywords. For example, to configure a method list for the default login
to authenticate using a RADIUS server, a TACACS+ server, or a local username database, use the
command aaa authentication login default group radius group tacacs+ local-case.

3.4.2 Configuring Server-Based AAA Authentication with

SDM
If using SDM for TACACS+ support, it is necessary to specify a list of available Cisco Secure
ACS servers that provide TACACS+ services for the router:
Step 1. From the Cisco SDM home page, choose Configure > Additional Tasks > AAA > AAA
Servers and Groups > AAA Servers.
Step 2. From the AAA Servers pane, click Add. The Add AAA Server window appears. Choose
TACACS+ from the Server Type list box.
Step 3. Enter the IP address or host name of the AAA server in the Server IP or Host field. If the
router has not been configured to use a DNS server, enter a DNS server IP address.
Step 4. The router can be configured to maintain a single open connection to the TACACS+ server
rather than opening and closing a TCP connection each time it communicates with the server. To
do so, check the Single Connection to Server check box.
Step 5. To override AAA server global settings and specify a server-specific timeout value in the
Server-Specific Setup section, enter a value in the Timeout (seconds) field. This field determines
how long the router waits for a response from this server before going on to the next server in the
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 79

Chapter 3: Authentication, Authorization, and Accounting 79

group list. If a value is not entered, the router uses the value that is configured in the AAA Servers
Global Settings window. The default setting is five seconds.
Step 6. To configure a server-specific key, check the Configure Key check box and enter the key
that is used to encrypt traffic between the router and this server in the New Key field. Re-enter the
key in the Confirm Key field for confirmation. If this option is not checked and a value is not en-
tered, the router uses the value that was configured in the AAA Servers Global Settings window.
Step 7. Click OK.
An example CLI command that Cisco SDM would generate based on a TACACS+ server at IP ad-
dress 10.0.1.1 and key TACACS+Pa55w0rd is tacacs-server host 10.0.1.1 key
TACACS+Pa55w0rd.

After AAA is enabled and the TACACS+ servers are configured, the router can be configured to
use the Cisco Secure ACS server to authenticate user access to the router. To configure the router
to use the Cisco Secure ACS server for login authentication, a user-defined authentication login
method list must be created, or the default method list must be edited. Keep in mind, the default
method list is automatically applied to all interfaces and lines, except those that have a user-de-
fined method list explicitly applied.
The administrator can use Cisco SDM to configure a user-defined authentication login method list:
Step 1. From the Cisco SDM home page, choose Configure > Additional Tasks > AAA > Au-
thentication Policies > Login.
Step 2. From the Authentication Login pane, click Add.
Step 3. To create a new authentication login method, choose User Defined from the Name drop-
down list.
Step 4. Enter the authentication login method list name in the Specify field, for example
TACACS_SERVER.
Step 5. Click Add to define the methods that this policy uses. The Select Method List(s) for Au-
thentication Login window appears.
Step 6. Choose group tacacs+ from the method list.
Step 7. Click OK to add group tacacs+ to the method list and return to the Add a Method List for
Authentication Login window.
Step 8. Click Add to add a backup method to this policy. The Select Method List(s) for Authenti-
cation Login window appears.
Step 9. Choose enable from the method list to use the enable password as the backup login au-
thentication method.
Step 10. Click OK to add enable to the method list and return to the Add a Method List for Au-
thentication Login window.
Step 11. Click OK to add the authentication login method list and return to the Authentication
Login screen.
The resulting CLI command that Cisco SDM generates is aaa authentication login
TACACS_SERVER group tacacs+ enable.

After the authentication login method lists are created, apply the lists to lines and interfaces on the
router.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 80

80 CCNA Security Course Booklet, Version 1.0

SDM can be used to apply an authentication policy to a router line:

Step 1. Choose Configure > Additional Tasks > Router Access > VTY.
Step 2. From the VTY Lines window, click the Edit button to make changes to the vty lines. The
Edit VTY Lines window appears.
Step 3. From the Authentication Policy list box, choose the authentication policy to apply to the
vty lines. For example, applying the authentication policy named TACACS_SERVER to vty lines
0 through 4 results in the login authentication TACACS_SERVER CLI command.
The CLI can also be used to apply an authentication policy to lines or interfaces with the login
authentication {default | list-name} command in line configuration mode or interface con-
figuration mode.

3.4.3 Troubleshooting Server-Based AAA Authentication

When AAA is enabled, it is often necessary to monitor authentication traffic and troubleshoot con-
figurations.
The debug aaa authentication command is a useful AAA troubleshooting command because it
provides a high-level view of login activity.
The command indicates a status message of PASS when a TACACS+ login attempt is successful.
If the status message returned is FAIL, verify the secret key.
Two other very useful server-based AAA troubleshooting commands include the debug tacacs
and debug radius commands. These commands can be used to provide more detailed AAA de-
bugging information. To disable debugging output, use the no form of these commands.
Similar to the debug aaa authentication command, the debug tacacs also indicates status mes-
sages of PASS or FAIL.
To see all TACACS+ messages use the debug tacacs command. To narrow the results and display
information from the TACACS+ helper process, use the debug tacacs events command in privi-
leged EXEC mode. The debug tacacs events command displays the opening and closing of a
TCP connection to a TACACS+ server, the bytes read and written over the connection, and the
TCP status of the connection. Use the debug tacacs events command with caution, because it
can generate a substantial amount of output. To disable debugging output, use the no form of this
command.

3.5 Server-Based AAA Authorization and

Accounting
3.5.1 Configuring Server-Based AAA Authorization
While authentication is concerned with ensuring that the device or end user is as claimed, authori-
zation is concerned with allowing and disallowing authenticated users access to certain areas and
programs on the network.
The TACACS+ protocol allows the separation of authentication from authorization. A router can
be configured to restrict the user to performing only certain functions after successful authentica-
tion. Authorization can be configured for both character mode (exec authorization) and packet
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 81

Chapter 3: Authentication, Authorization, and Accounting 81

mode (network authorization). Keep in mind that RADIUS does not separate the authentication
from the authorization process.
Another important aspect of authorization is the ability to control user access to specific services.
Controlling access to configuration commands greatly simplifies the infrastructure security in
large enterprise networks. Per-user permissions on the Cisco Secure ACS simplify network device
configuration.
For example, an authorized user can be permitted to access the show version command but not
the configure terminal command. The router queries the ACS for permission to execute the
commands on behalf of the user. When the user issues the show version command, the ACS
sends an ACCEPT response. If the user issues a configure terminal command, the ACS sends a
REJECT response.
TACACS+ by default establishes a new TCP session for every authorization request, which can
lead to delays when users enter commands. Cisco Secure ACS supports persistent TCP sessions to
improve performance.
To configure command authorization, use the aaa authorization {network | exec | commands
level} {default | list-name} method1...[method4] command. The service type can specify
the types of commands or services:
commands level for exec (shell) commands
exec for starting an exec (shell)
network for network services (PPP, SLIP, ARAP)
When AAA authorization is not enabled, all users are allowed full access. After authentication is
started, the default changes to allow no access. This means that the administrator must create a
user with full access rights before authorization is enabled. Failure to do so immediately locks the
administrator out of the system the moment the aaa authorization command is entered. The
only way to recover from this is to reboot the router. If this is a production router, rebooting might
be unacceptable. Be sure that at least one user always has full rights.
To configure the router to use the Cisco Secure ACS server for authorization, create a user-defined
authorization method list or edit the default authorization method list. The default authorization
method list is automatically applied to all interfaces except those that have a user-defined authori-
zation method list explicitly applied. A user-defined authorization method list overrides the default
authorization method list.
Cisco SDM can be used to configure the default authorization method list for character mode
(exec) access:
Step 1. From the Cisco SDM home page, choose Configure > Additional Tasks > AAA > Autho-
rization Policies > Exec.
Step 2. From the Exec Authorization pane, click Add.
Step 3. From the Add a Method List for Exec Authorization window, choose Default from the
Name drop-down list.
Step 4. Click Add to define the methods that this policy uses.
Step 5. From the Select Method List(s) for Exec Authorization window, choose group tacacs+
from the method list.
Step 6. Click OK to return to the Add a Method List for Exec Authorization window.
Step 7. Click OK to return to the Exec Authorization pane.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 82

82 CCNA Security Course Booklet, Version 1.0

The resulting CLI command that Cisco SDM generates is aaa authorization exec default
group tacacs+.

The SDM can also be used to configure the default authorization method list for packet mode (net-
work):
Step 1. From the Cisco SDM home page, choose Configure > Additional Tasks > AAA > Autho-
rization Policies > Network.
Step 2. From the Network Authorization pane, click Add.
Step 3. From the Add a Method List for Network Authorization window, choose Default from the
Name drop-down list.
Step 4. Click Add to define the methods that this policy uses.
Step 5. From the Select Method List(s) for Network Authorization window, choose group tacacs+
from the method list.
Step 6. Click OK to return to the Add a Method List for Network Authorization window.
Step 7. Click OK to return to the Network Authorization pane.
The resulting CLI command that Cisco SDM generates is aaa authorization network default
group tacacs+.

3.5.2 Configuring Server-Based AAA Accounting

Sometimes a company wants to keep track of which resources individuals or groups use. Examples
of this include when one department charges other departments for access, or one company pro-
vides internal support to another company. AAA accounting provides the ability to track usage,
such as dial-in access, to log the data gathered to a database, and to produce reports on the data
gathered.
Although accounting is generally considered a network management or financial management
issue, it is discussed briefly here because it is so closely linked with security. One security issue
that accounting addresses is creating a list of users and the time of day they dialed into the system.
If, for example, the administrator knows that a worker logs in to the system in the middle of the
night, this information can be used to further investigate the purpose of the login.
Another reason to implement accounting is to create a list of changes occurring on the network,
who made the changes, and the exact nature of the changes. Knowing this information helps the
troubleshooting process if the changes cause unexpected results.
Cisco Secure ACS serves as a central repository for accounting information, essentially tracking
events that occur on the network. Each session that is established through Cisco Secure ACS can
be fully accounted for and stored on the server. This stored information can be very helpful for
management, security audits, capacity planning, and network usage billing.
Like authentication and authorization method lists, method lists for accounting define the way ac-
counting is performed and the sequence in which these methods are performed. After it is enabled,
the default accounting method list is automatically applied to all interfaces, except those that have
a named accounting method list explicitly defined.
To configure AAA accounting, use the aaa accounting { network | exec | connection}
{default | list-name} {start-stop | stop-only | none} [broadcast] method1...[method4]
global configuration mode command. The network, exec, and connection parameters are com-
monly used keywords.
03_9781587132483_ch03.qxp 7/13/09 1:08 PM Page 83

Chapter 3: Authentication, Authorization, and Accounting 83

As with AAA authentication, either the keyword default or a list-name is used.

Next, the record type, or trigger, is configured. The trigger specifies what actions cause accounting
records to be updated. Possible triggers are none, start-stop, stop-only.
For example, to log the use of EXEC sessions and network connections, use the global configura-
tion commands.
R1(config)# aaa accounting exec default start-stop group tacacs+
R1(config)# aaa accounting network default start-stop group tacacs+