AAA is an architectural framework for configuring a set of three independent security functions in a consistent manner. AAA provides a modular way of performing the following services:

• Authentication—Provides the method of identifying users, including login and password dialog, challenge and response, messaging support, and, depending on the security protocol you select, encryption. Authentication is the way a user is identified prior to being allowed access to the network and network services. You configure AAA authentication by defining a named list of authentication methods, and then applying that list to various interfaces. The method list defines the types of authentication to be performed and the sequence in which they are performed; it must be applied to a specific interface before any of the defined authentication methods are performed. The only exception is the default method list (which is named “default”). The default method list is automatically applied to all interfaces if no other method list is defined. A defined method list overrides the default method list. All authentication methods, except for line password and enable authentication, must be defined through AAA. For information about configuring all authentication methods, including those implemented outside of the AAA security services, see Configuring Authentication.
• Authorization—Provides the method for remote access control, including one-time authorization or authorization for each service, per-user account list and profile, user group support, and support of IP and Telnet. AAA authorization works by assembling a set of attributes that describe what the user is authorized to perform. These attributes are compared to the information contained in a database for a given user and the result is returned to AAA to determine the user’s actual capabilities and restrictions. The database can be located locally on the device or access server or it can be hosted remotely on a RADIUS or TACACS+ security server. Remote security servers, such as RADIUS and TACACS+, authorize users for specific rights by associating attribute-value (AV) pairs, which define those rights with the appropriate user. All authorization methods must be defined through AAA. As with authentication, you configure AAA authorization by defining a named list of authorization methods, and then applying that list to various interfaces. For information about configuring authorization using AAA, see Configuring Authorization.
• Accounting—Provides the method for collecting and sending security server information used for billing, auditing, and reporting, such as user identities, start and stop times. Accounting enables you to track the services users are accessing as well as the amount of network resources they are consuming. When AAA accounting is activated, the network access server reports user activity to the RADIUS or TACACS+ security server (depending on which security method you have implemented) in the form of accounting records. Each accounting record is comprised of accounting AV pairs and is stored on the access control server. This data can then be analyzed for network management, client billing, and/or auditing. All accounting methods must be defined through AAA. As with authentication and authorization, you configure AAA accounting by defining a named list of accounting methods, and then applying that list to various interfaces. For information about configuring accounting using AAA, see Configuring Accounting.

In many circumstances, AAA uses protocols such as RADIUS or TACACS+ to administer its security functions. If your device or access server is acting as a network access server, AAA is the means through which you establish communication between your network access server and your RADIUS or TACACS+ security server.

Although AAA is the primary (and recommended) method for access control, Cisco IOS software provides additional features for simple access control that are outside the scope of AAA, such as line password authentication and enable password authentication. However, these features do not provide the same degree of access control that is possible by using AAA.

You must first decide what kind of security solution you want to implement. You need to assess the security risks in your particular network and decide on the appropriate means to prevent unauthorized entry and attack. Cisco recommends that you use AAA, no matter how minor your security needs might be.

To configure AAA authentication, you must first define a named list of authentication methods, and then apply that list to various interfaces. The method list defines the types of authentication to be performed and the sequence in which they are performed; it must be applied to a specific interface before any of the defined authentication methods are performed. The only exception is the default method list (which is named “default”). The default method list is automatically applied to all interfaces except those that have a named method list explicitly defined. A defined method list overrides the default method list.

A method list is a sequential list describing the authentication methods to be queried in order to authenticate a user. Method lists enable you to designate one or more security protocols to be used for authentication, thus ensuring a backup system for authentication in case the initial method fails. Cisco IOS software uses the first listed method to authenticate users. If that method fails to respond, the Cisco IOS software selects the next authentication method listed in the method list. This process continues until there is successful communication with a listed authentication method, or all methods defined in the method list are exhausted.

It is important to note that the Cisco IOS software attempts authentication with the next listed authentication method only when there is no response from the previous method. If authentication fails at any point in this cycle—meaning that the security server or local username database responds by denying the user access—the authentication process stops and no other authentication methods are attempted.

1.    enable


2.    configure terminal


3.    aaa new-model


4.    aaa authentication login {default | list-name} method1 [method2...]

5.    line [aux | console | tty | vty] line-number [ending-line-number]

6.    login authentication {default | list-name}

7.    end

Switch> enable

Switch# configure terminal

Switch(config)# aaa new-model

Switch(config)# aaa authentication login test local

Switch(config)# line vty 0

Switch(config-line)# login authentication test

Switch(config-line)# end

The list-name is a character string used to name the list you are creating. The method argument refers to the actual method the authentication algorithm tries. The additional methods of authentication are used only if the previous method returns an error, not if it fails. To specify that the authentication should succeed even if all methods return an error, specify none as the final method in the command line.

For example, to specify that authentication should succeed even if (in this example) the TACACS+ server returns an error, use the following command:

aaa authentication login default group tacacs+ none

Note	Because the none keyword enables any user logging in to successfully authenticate, it should be used only as a backup method of authentication.

The table below lists the supported login authentication methods.

The login command only changes username and privilege level but does not execute a shell; therefore autocommands will not be executed. To execute autocommands under this circumstance, you need to establish a Telnet session back into the device (loop-back). Make sure that the device has been configured for secure Telnet sessions if you choose to implement autocommands this way.

1.    enable


2.    configure terminal


3.    aaa authentication enable default method1 [method2...]

4.    end

Switch> enable

Switch# configure terminal

Switch(config)# aaa authentication enable default group radius group tacacs+ local

Switch(config)# end

The method argument refers to the actual list of methods the authentication algorithm tries, in the sequence entered. Table 8 lists the supported enable authentication methods.

Password:

1.    enable


2.    configure terminal


3.    aaa authentication password-prompt text-string


4.    end

Switch> enable

Switch# configure terminal

Switch(config)# aaa authentication password-prompt "Enter your password now:"

Switch(config)# end

AAA supports the use of configurable, personalized login and failed-login banners. You can configure message banners that are displayed when a user logs in to the system to be authenticated using AAA and when, for whatever reason, authentication fails.

This section includes the following sections:

• Configuring a Login Banner
• Configuring a Failed-Login Banner

1.    enable


2.    configure terminal


3.    line [aux | console | tty | vty] line-number [ending-line-number]

4.    password password


5.    login


6.    no login


7.    end

Switch> enable

Switch# configure terminal

Switch(config)# line vty 0

Switch(config-line)# password 1234abcd

Switch(config-line)# login

Switch(config-line)# no login

Switch(config-line)# end

If you configure line password protection and then configure TACACS or extended TACACS, the TACACS username and password take precedence over line passwords. If you have not yet implemented a security policy, we recommend that you use AAA.

Note

The login command only changes username and privilege level but it does not execute a shell; therefore autocommands will not be executed. To execute autocommands under this circumstance, you need to establish a Telnet session back into the device (loop-back). Make sure that the device has been configured for secure Telnet sessions if you choose to implement autocommands this way.

1.    enable


2.    configure terminal


3.    username name [nopassword | password password | password encryption-type encrypted password] or username name [access-class number]


4.    username name [privilege level]


5.    exit

Switch> enable

Switch# configure terminal

Switch(config)# username user password 1234abcd

Switch(config)# username user privilege 15

Switch(config)# exit

1.    enable


2.    configure terminal


3.    aaa authorization {network | exec | commands level | reverse-access | configuration} {default | list-name} [method1 [method2...]]

4.    line [aux | console | tty | vty] line-number [ending-line-number] or interfacetype slot/port

5.    authorization commands{arap | commands level | connection | exec} {default | list-name}

6.    exit

Switch> enable

Switch# configure terminal

Switch(config)# aaa authorization commands 7 tacauth group tacacs+

Switch(config)# line vty 0

Switch(config-line)# authorization commands 7 tacauth

Switch(config-line)# exit

1.    enable


2.    configure terminal


3.    no aaa authorization config-commands


4.    end

Switch> enable

Switch# configure terminal

Switch(config)# no aaa authorization config-commands

Switch(config)# end

A server group is a way to group existing RADIUS or TACACS+ server hosts for use in method lists. The figure below shows a typical AAA network configuration that includes four security servers: R1 and R2 are RADIUS servers and T1 and T2 are TACACS+ servers. R1 and R2 make up the group of RADIUS server. T1 and T2 make up the group of TACACS+ servers.

Figure 4. Typical AAA Network Configuration

Using server groups, you can specify a subset of the configured server hosts and use them for a particular service. For example, server groups allow you to define R1 and R2 as a server group, and define T1 and T2 as a separate server group. For example, you can specify R1 and T1 in the method list for authentication login, while specifying R2 and T2 in the method list for login authentication.

Server groups also can include multiple host entries for the same server, as long as each entry has a unique identifier. The combination of an IP address and a UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. In other words, this unique identifier enables RADIUS requests to be sent to different UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, authentication—the second host entry configured acts as failover backup to the first one. Using this example, if the first host entry fails to provide accounting services, the network access server will try the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order in which they are configured.)

For more information about configuring server groups and about configuring server groups based on Dialed Number Identification Service (DNIS) numbers, see Configuring Cisco ME 2600X to RADIUS Server Communication or TACACS+ Configuration Task List.

Cisco IOS supports the following two methods for accounting:

• TACACS+—The network access server reports user activity to the TACACS+ security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server.
• RADIUS—The network access server reports user activity to the RADIUS security server in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the security server.

EXEC accounting provides information about user EXEC terminal sessions (user shells) on the network access server, including username, date, start and stop times, the access server IP address, and (for dial-in users) the telephone number the call originated from.

The following example shows the information contained in a RADIUS EXEC accounting record for a dial-in user:

Wed Jun 27 04:26:23 2001
NAS-IP-Address = “172.16.25.15”
NAS-Port = 1
User-Name = “fgeorge”
Client-Port-DNIS = “4327528”
Caller-ID = “5622329483”
Acct-Status-Type = Start
Acct-Authentic = RADIUS
Service-Type = Exec-User
Acct-Session-Id = “00000006”
Acct-Delay-Time = 0
User-Id = “fgeorge”
NAS-Identifier = “172.16.25.15”

Wed Jun 27 04:27:25 2001
NAS-IP-Address = “172.16.25.15”
NAS-Port = 1
User-Name = “fgeorge”
Client-Port-DNIS = “4327528”
Caller-ID = “5622329483”
Acct-Status-Type = Stop
Acct-Authentic = RADIUS
Service-Type = Exec-User
Acct-Session-Id = “00000006”
Acct-Session-Time = 62
Acct-Delay-Time = 0
User-Id = “fgeorge”
NAS-Identifier = “172.16.25.15”

The following example shows the information contained in a TACACS+ EXEC accounting record for a dial-in user:

Wed Jun 27 03:46:21 2001 172.16.25.15 fgeorge tty3 5622329430/4327528
start task_id=2 service=shell
Wed Jun 27 04:08:55 2001 172.16.25.15 fgeorge tty3 5622329430/4327528 stop
task_id=2 service=shell elapsed_time=1354

The following example shows the information contained in a RADIUS EXEC accounting record for a Telnet user:

Wed Jun 27 04:48:32 2001
NAS-IP-Address = “172.16.25.15”
NAS-Port = 26
User-Name = “fgeorge”
Caller-ID = “171.68.202.158”
Acct-Status-Type = Start
Acct-Authentic = RADIUS
Service-Type = Exec-User
Acct-Session-Id = “00000010”
Acct-Delay-Time = 0
User-Id = “fgeorge”
NAS-Identifier = “172.16.25.15”

Wed Jun 27 04:48:46 2001
NAS-IP-Address = “172.16.25.15”
NAS-Port = 26
User-Name = “fgeorge”
Caller-ID = “171.68.202.158”
Acct-Status-Type = Stop
Acct-Authentic = RADIUS
Service-Type = Exec-User
Acct-Session-Id = “00000010”
Acct-Session-Time = 14
Acct-Delay-Time = 0
User-Id = “fgeorge”
NAS-Identifier = “172.16.25.15”

The following example shows the information contained in a TACACS+ EXEC accounting record for a Telnet user:

Wed Jun 27 04:06:53 2001 172.16.25.15 fgeorge tty26 171.68.202.158
starttask_id=41 service=shell
Wed Jun 27 04:07:02 2001 172.16.25.15 fgeorge tty26 171.68.202.158
stoptask_id=41 service=shell elapsed_time=9

1.    enable


2.    configure terminal


3.    aaa accounting {system | network | exec | connection | commands level} {default | list-name} {start-stop | stop-only | none} [method1 [method2...]]

4.    line [aux | console | tty | vty] line-number [ending-line-number] or interface interface-type interface-number

5.    accounting {arap | commands level | connection | exec} {default | list-name}

6.    exit

Switch> enable

Switch# configure terminal

Switch(config)# aaa accounting commands 7 tacacctcomm start-stop group tacacs+

Switch(config)# line vty 0

Switch(config-line)# accounting commands 7 tacacctcomm

Switch(config-line)# exit

Access control enables you to restrict access to the network server and its services to a specific group of users. The authentication, authorization, and accounting (AAA) network security services provide the primary framework through which you can set up access control on your device or access server.

Authentication is a way of identifying a user before permitting access to the network and network services. The Cisco ME 2600X supports local authentication mechanism to administer its security functions.

1.    enable


2.    configure terminal


3.    aaa new-model


4.    aaa authentication login default methodname


5.    line [aux | console | tty | vty] line-number [ending-line-number]

6.    end

Switch> enable

Switch# configure terminal

Switch(config)# aaa new-model

Switch(config-if)# aaa authentication login default local

Switch(config)# line vty 0 4

Switch(config-line)# end

Switch> enable
Switch# configure terminal
Switch(config)# aaa new-model
Switch(config-if)# aaa authentication login default local
Switch(config)# line vty 0 4
Switch(config-line)# end

Cisco ME 2600X supports multiple privilege levels, which provide access to commands. By default, there two levels of access to commands:

• User EXEC mode (level 1)
• Privileged EXEC mode (level 15)

You can configure additional levels of access to commands, called privilege levels, to meet the needs of users while protecting the system from unauthorized access. Up to 16 privilege levels can be configured from level 0, which is the most restricted level, to level 15, which is the least restricted level.

The access to each privilege level is enabled through separate passwords, which you can specify when configuring the privilege level.

For example, if you want a certain set of users to be able to configure only certain interfaces and configuration options, you could create a separate privilege level only for specific interface configuration commands and distribute the password for that level to those users.

TACACS+ is a security application that provides centralized validation of users attempting to gain access to a device or network access server. TACACS+ services are maintained in a database on a TACACS+ daemon running, typically, on a UNIX or Windows NT workstation. You must have access to and must configure a TACACS+ server before the configured TACACS+ features on your network access server are available.

TACACS+ provides for separate and modular authentication, authorization, and accounting facilities. TACACS+ allows for a single access control server (the TACACS+ daemon) to provide each service—authentication, authorization, and accounting—independently. Each service can be tied into its own database to take advantage of other services available on that server or on the network, depending on the capabilities of the daemon.

The goal of TACACS+ is to provide a methodology for managing multiple network access points from a single management service. The Cisco family of access servers and devices and the Cisco IOS user interface (for both devices and access servers) can be network access servers.

The TACACS+ protocol provides authentication between the network access server and the TACACS+ daemon, and it ensures confidentiality because all protocol exchanges between a network access server and a TACACS+ daemon are encrypted.

You need a system running TACACS+ daemon software to use the TACACS+ functionality on your network access server.

When a user attempts a simple ASCII login by authenticating to a network access server using TACACS+, the following process typically occurs:

1. When the connection is established, the network access server contacts the TACACS+ daemon to obtain a username prompt, which is then displayed to the user. The user enters a username and the network access server then contacts the TACACS+ daemon to obtain a password prompt. The network access server displays the password prompt to the user, the user enters a password, and the password is then sent to the TACACS+ daemon.

   Note

   TACACS+ allows an arbitrary conversation to be held between the daemon and the user until the daemon receives enough information to authenticate the user. This is usually done by prompting for a username and password combination, but may include other items, such as mother’s maiden name, all under the control of the TACACS+ daemon.

2. The network access server eventually receives one of the following responses from the TACACS+ daemon:
   • ACCEPT—The user is authenticated and service may begin. If the network access server is configured to requite authorization, authorization begins at this time.
   • REJECT—The user has failed to authenticate. The user may be denied further access, or is prompted to retry the login sequence depending on the TACACS+ daemon.
   • ERROR—An error occurred at some time during authentication. This can be either at the daemon or in the network connection between the daemon and the network access server. If an ERROR response is received, the network access server typically tries to use an alternative method for authenticating the user.
   • CONTINUE—The user is prompted for additional authentication information.
3. Following authentication, the user will also be required to undergo an additional authorization phase, if authorization has been enabled on the network access server. Users must first successfully complete TACACS+ authentication before proceeding to TACACS+ authorization.
4. If TACACS+ authorization is required, the TACACS+ daemon is again contacted and it returns an ACCEPT or REJECT authorization response. If an ACCEPT response is returned, the response will contain data in the form of attributes that are used to direct the EXEC session for that user, determining services that the user can access. Services include the following:
   • Telnet, rlogin, or EXEC services
   • Connection parameters, including the host or client IP address, access list, and user timeouts

After you have identified the TACACS+ daemon and defined an associated TACACS+ encryption key, you need to define method lists for TACACS+ authentication. Because TACACS+ authentication is operated via AAA, you need to issue the aaa authentication command, specifying TACACS+ as the authentication method. For more information, see Configuring Authentication.

AAA authorization enables you to set parameters that restrict a user’s network access. Authorization via TACACS+ may be applied to commands, network connections, and EXEC sessions. Because TACACS+ authorization is facilitated through AAA, you need to issue the aaa authorization command, specifying TACACS+ as the authorization method. For more information, see Configuring Authorization.

AAA accounting enables you to track the services users are accessing as well as the amount of network resources they are consuming. Because TACACS+ accounting is facilitated through AAA, you need to issue the aaa accounting command, specifying TACACS+ as the accounting method. For more information, see Configuring Accounting.

RADIUS is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco devices and send authentication requests to a central RADIUS server that contains all user authentication and network service access information.

RADIUS is a fully open protocol, distributed in source code format, that can be modified to work with any security system currently available on the market.

Cisco supports RADIUS under its AAA security paradigm. RADIUS can be used with other AAA security protocols, such as TACACS+ and local username lookup. RADIUS is supported on all Cisco platforms, but some RADIUS-supported features run only on specified platforms.

RADIUS has been implemented in a variety of network environments that require high levels of security while maintaining network access for remote users.

Use RADIUS in networks with multiple-vendor access servers, each supporting RADIUS. For example, access servers from several vendors use a single RADIUS server-based security database.

The RADIUS host is normally a multiuser system running RADIUS server software from Cisco (CiscoSecure ACS), Livingston, Merit, Microsoft, or another software provider. Configuring Cisco ME 2600X to RADIUS server communication can have several components:

• Host name or IP address
• Authentication destination port
• Accounting destination port
• Timeout period
• Retransmission value
• Key string

RADIUS security servers are identified on the basis of their host name or IP address, host name and specific UDP port numbers, or IP address and specific UDP port numbers. The combination of the IP address and UDP port number creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. In other words, this unique identifier enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, accounting—the second host entry configured acts as fail-over backup to the first one. Using this example, if the first host entry fails to provide accounting services, the network access server will try the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order they are configured.)

A RADIUS server and a Cisco ME 2600X use a shared secret text string to encrypt passwords and exchange responses. To configure RADIUS to use the AAA security commands, you must specify the host running the RADIUS server daemon and a secret text (key) string that it shares with the Cisco ME 2600X.

The timeout, retransmission, and encryption key values are configurable globally for all RADIUS servers, on a per-server basis, or in some combination of global and per-server settings. To apply these settings globally to all RADIUS servers communicating with the Cisco ME 2600X, use the three unique global commands: radius-server timeout, and radius-server retransmit. To apply these values on a specific RADIUS server, use the radius-server host command.

Note

You can configure both global and per-server timeout, retransmission, and key value commands simultaneously on the same Cisco network access server. If both global and per-server functions are configured on a Cisco ME 2600X, the per-server timer, retransmission, and key value commands override global timer, retransmission, and key value commands.

To configure per-server RADIUS server communication, complete the following steps:

1.    enable


2.    configure terminal


3.    radius server {hostname}


4.    radius server [address | automate-tester | backoff | exit | key | no | non-standard | pac | retransmit | timeout]

5.    end

Switch> enable

Switch# configure terminal

Switch(config)# radius server cisco_radius

Switch(config-radius-server)# address ipv4 172.26.106.10
 Switch(config-radius-server)# key ciscokey

Switch(config-radius-server)# end

1.    radius-server retransmit retries


2.    radius-server timeout seconds


3.    radius-server deadtime minutes

Switch(config)# radius-server 10

Switch(config)# radius-server 60

Switch(config)# radius-server 2