Table Of Contents
Configuring Authentication and Accounting Services
Local Database and Remote Server Support
Authentication and Accounting Configuration Quick Start
Configuring Authentication Settings on the TACACS+ Server
Configuring Accounting Settings on the TACACS+ Server
Defining Private Attributes for Virtualization Support in a TACACS+ Server
Configuring Authentication Settings on the RADIUS Server
Configuring Accounting Settings on the RADIUS Server
Defining Private Attributes for Virtualization Support in a RADIUS Server
Defining Private Attributes for Virtualization Support in an LDAP Server
Configuring the ACE as a Client of a RADIUS, TACACS+, or LDAP Server
Setting the RADIUS Server Parameters
Configuring the RADIUS NAS-IP-Address Attribute
Setting the Global RADIUS Server Preshared Key
Configuring the Global RADIUS Server Dead-Time
Setting the Global RADIUS Server Number of Retransmissions
Setting the Global RADIUS Server Timeout Value
Configuring TACACS+ on the ACE
Setting the TACACS+ Server Parameters
Setting the Global Preshared Key
Setting the Global TACACS+ Server Dead-Time
Setting the Global TACACS+ Server Timeout Value
Setting the LDAP Server Parameters
Setting the Global LDAP Server Port Setting
Setting the Global LDAP Server Timeout Value
Creating a TACACS+, RADIUS, or LDAP Server Group
Setting the Dead-Time for a TACACS+ Server Group
Setting the Dead-Time for a RADIUS Server Group
Configuring the User Profile Attribute Type for an LDAP Server Group
Configuring the Base DN for an LDAP Server Group
Configuring the Search Filter for an LDAP Server Group
Defining the Login Authentication Method
Defining the Default Accounting Method
Viewing AAA Status and Statistics
Displaying RADIUS Server Configuration Information
Displaying TACACS+ Server Configuration Information
Displaying LDAP Server Configuration Information
Displaying Accounting Configuration Information
Displaying Accounting Log Information
Displaying Authentication Configuration Information
Configuring Authentication and Accounting Services
This chapter describes how to configure the Cisco Application Control Engine (ACE) module to perform user authentication and accounting (AAA) services to provide a higher level of security for users accessing the ACE. The AAA services allow you to use multiple AAA servers to control who can access the ACE and to track the actions of each user who accesses the ACE. Based on the username and password combination provided, the ACE performs local user authentication using the local database, or remote user authentication and accounting using external AAA servers.
This chapter contains the following major sections:
•
Authentication and Accounting Configuration Quick Start
•
•
•
•
AAA Overview
AAA provides management security for user access to the ACE through a combination of authentication and accounting services. AAA informs the ACE who the user is and what the user did. You can use authentication alone, or in combination with accounting. ACE provides security for the management access methods to the ACE, including the command-line interface (CLI) or Simple Network Management Protocol (SNMP).
Access to the ACE CLI can be performed through the console port or by a Telnet or SSH session. When you log in to the ACE using either a Telnet or SSH connection, and if the ACE is configured for AAA server-based authentication, a temporary SNMP user entry is automatically created. The SNMPv3 protocol data units (PDUs) with the associated Telnet or SSH login name as the SNMPv3 user are authenticated by the ACE.
As part of the authentication process, the ACE associates each user with a user role and a domain privilege pair under a specific virtual context. Each virtual context behaves like an independent device with its own configuration, security policies, interfaces, and domains. A user context can be independently managed along with other user contexts. A domain provides a namespace in which a user operates, and each user is associated with at least one domain. The role assigned to a user determines the operations that a user can perform on the objects in a domain and the command set available to that user. Each context has a virtual AAA instance running to provide authentication for the users logging in and accounting services to log user activity.
Each virtual context on the ACE can have its own IP address. Access to each virtual context in an ACE is performed through console port or Telnet or SSH session by specifying this IP address. Users can also send SNMP requests to the ACE by using this IP address.
Note
The administrator of each virtual context is able to perform, independent from other contexts, the following actions:
•
•
•
•
•
Each user who accesses the ACE from a specific IP address needs only to authenticate a single time. The user authentication sequence remains in effect until the authentication session expires on the ACE.
The ACE runs the AAA client, which sits between the users and the AAA server. On one side, the ACE prompts each user for their credentials (username and password). On the other side, the ACE queries the identified AAA servers to determine if the user being authenticated has supplied the correct credentials and is authorized access to the ACE.
The ACE performs authentication using either the local user database, that resides on the ACE, or a remote AAA server. The ACE can use a Remote Access Dial-In User Service (RADIUS), Terminal Access Controller Access Control System Plus (TACACS+), or Lightweight Directory Access Protocol (v3) (LDAP) protocols for remote authentication and designation of access rights.
This section includes the following topics:
•
Local Database and Remote Server Support
The ACE supports local authentication using a local database on the ACE or remote authentication using one or more AAA servers. AAA remote servers are grouped into independent groups of TACACS+, RADIUS, or LDAP servers. For a group of servers, the ACE bases the selection of the server to use on the first active server in the group. "First" refers to the order with which servers have been configured. When a user logs in to an ACE, the servers are accessed one at a time, starting with the first server specified in the configuration, until a server responds to the ACE.
When you configure server groups using the server group authentication method, the ACE sends an authentication request to the first AAA server in the group.
•
•
•
If the user name and password is successfully authenticated, either locally or remotely, the ACE allows the user to log in, and the user is assigned a unique role (as specified through the role command, which determines the commands and resources available to each user).
Each server within a group can assume an active or an inactive state due to a network connection failure. The policy used to select the AAA server takes the server state into account. The ACE monitors AAA server operation by sending authentication requests to a timed-out server. If the ACE does not receive confirmation from the server within a user-specified number of retries, the ACE declares the server to be unresponsive and initiates the sequence to contact the next available server specified in the server group.
When a dead-time interval is specified for a AAA server, if the connection to server A fails, server A is temporarily marked as being "out of service." During the dead-time interval the nonresponsive server A is skipped by the ACE. The ACE sends probe access-request packets to verify that the AAA server is available and can receive authentication requests.When the server responds to a probe access-request packet, the connection resumes to server A.
This section includes the following topics:
Local Database
You can configure user account access to the local database on the ACE for CLI access authentication. When a user attempts to access the ACE CLI by using the console port or a Telnet or SSH session, the ACE consults the local user database for the username and password. By default, each user assumes the Network-Monitor role and is allowed to operate on all domains.
If you specify local authentication as the fallback method and the specified AAA servers in a server group are unavailable for authentication, the ACE then attempts to access the local database to perform user authentication and accounting.
TACACS+ Server
TACACS+ controls user access to the ACE by exchanging Network Access Server (NAS) information between the ACE and a centralized database to determine the identity of a user. TACACS+ is an enhanced version of TACACS, a User Datagram Protocol (UDP)-based access-control protocol that is specified by RFC 1492. TACACS+ uses TCP to ensure reliable delivery and encrypt all traffic between the TACACS+ server and the TACACS+ daemon on the ACE.
A TACACS+ server can provide user authentication and accounting functions. These services, while all part of TACACS+, are independent of one another, so a given TACACS+ configuration can use any or all of the services.
The TACACS+ protocol encrypts the user password information using the MD5 encryption algorithm and adds a TACACS+ packet header. This header information identifies the packet type being sent (for example, an authentication packet), the packet sequence number, the encryption type being used, and the total packet length. The TACACS+ protocol forwards the packet to the TACACS+ server.
To maintain security between the ACE and the TACACS+ server, you can specify an encryption key (shared secret) for all communication between the ACE and the TACACS+ server. For correct operation, you must specify the identical encryption key on both the ACE and the TACACS+ server.
RADIUS Server
RADIUS is a client-server access protocol that is used by the NAS to authenticate users attempting to connect to the ACE. The NAS functions as a client, passing user information to one or more RADIUS servers. The NAS permits or denies network access to a user based on the response it receives from a RADIUS server. RADIUS uses UDP for connectionless transport between the RADIUS client and server. For more information about how the RADIUS protocol operates, refer to RFC 2138.
To maintain security between the ACE and the RADIUS server, you can specify an encryption key (shared secret) for all communication between the ACE and the RADIUS server. For correct operation, you must specify the identical encryption key on both the ACE and the RADIUS server.
LDAP Directory Server
LDAP is an open-standard client-server authentication protocol for accessing X.500 Directory Access Protocol (DAP) directory services. LDAP runs over TCP/IP or other connection-oriented transfer services. The ACE supports only LDAP version 3 for simple authentication and search operations. For more information about how the LDAP protocol operates, refer to RFC 2251.
The LDAP information model is based on entries. An entry is a collection of attributes that has a globally-unique Distinguished Name (DN). The DN is used in the LDAP database to refer unambiguously to an entry. Each entry contains one or more attributes that describe the entry, and each attribute has a type and one or more values. The types are typically mnemonic strings, such as "cn" for common name, or "mail" for e-mail address.
The LDAP client (the ACE) requests user authentication with the LDAP server and retrieves the user profile by requesting a search through the directory database maintained by the server. The LDAP server maintains a directory of entries, which are arranged into a hierarchical tree-like structure called Directory Information Tree (DIT).
The LDAP client performs operations on directory data. LDAP supports searching the directory for data meeting arbitrary user-specified criteria. A user can specify what part of the directory to search and what information to return. A search filter that uses Boolean conditions specifies what directory data matches the search.
Note
Authentication Overview
Authentication allows you to control user access to the ACE CLI by requiring specification of a valid username and password. You can access the ACE CLI through the console port or by a Telnet or SSH session. For each management access path to the ACE, you can configure one or more of the following security control options: local database, remote (RADIUS, TACACS+, or LDAP), or no password verification.
The host is prompted by the ACE to provide a valid username and password. After the designated RADIUS, TACACS+, or LDAP server authenticates the username and password, the ACE provides access rights to the user.
Accounting Overview
Accounting tracks and maintains a log of useful information during each user management session with the ACE. You can use this information to generate reports for troubleshooting and auditing purposes. Accounting logs can be stored locally on the ACE or sent to remote AAA servers. If the ACE is also configured to authenticate the user, the AAA server maintains accounting information by username. Accounting information includes user commands entered on the ACE, the duration of each session, and when sessions start and stop.
When ACE user commands are being logged on a TACACS+ or RADIUS server, the server prefaces each command with either a "<0:>" or a "<1:>" to indicate the success or failure of the command as issued by a user on the ACE CLI. For example, when a user attempts to enter a command on the ACE and that user does not have the correct role privileges, a "<1:>" appears to indicate a failure.
Authentication and Accounting Configuration Quick Start
Table 2-1 provides a quick overview of the steps required to create and configure authentication and accounting for the ACE. Each step includes the CLI command required to complete the task.
Configuring the AAA Server
This section provides general background information on how to set up a TACACS+ or RADIUS server such as the Cisco Secure Access Control Server (ACS). It also covers general guidelines for setting up an LDAP directory server, such as OpenLDAP Software available from OpenLDAP Project. This section is intended as a guide to help ensure proper communication with the AAA server and an ACE operating as the AAA client.
For details on configuring the Cisco Secure ACS, OpenLDAP Software, or another AAA server, consult the documentation provided with the software.
Configuring a TACACS+ Server
The following sections summarize the recommended Cisco Secure ACS TACACS+ user authentication and accounting settings.
•
•
•
Note
Configuring Authentication Settings on the TACACS+ Server
To configure the TACACS+ authentication settings on Cisco Secure ACS:
1.
2.
•
•
•
•
Note
3.
Configuring Accounting Settings on the TACACS+ Server
To configure the TACACS+ accounting service for the Cisco Secure ACS:
1.
2.
3.
4.
Defining Private Attributes for Virtualization Support in a TACACS+ Server
The same username can be created across contexts and can be associated with a unique role in a context and multiple domains. Contexts can share a TACACS+ server, but the user must be authenticated for each context and must use the same password.
When a user attempts to log in to the ACE, the TACACS+ client on the ACE sends the username and password to the remote TACACS+ server for authentication. The TACACS+ server retrieves a user's profile as part of the authentication request. Once the user is successfully authenticated, the TACACS+ server returns a user profile to the TACACS+ client on the ACE along with the authentication status. If the associated context of the user attempting to log in matches the contexts of the user profile obtained through the TACACS+ server, then the TACACS+ client updates the user profile with the remote server user profile. If the contexts do not match, then the user profile is updated with the default role (Network-Monitor) and the default domain (default-domain).
Configure the user profile on the TACACS+ server to run an Exec shell to configure a shell command authorization for the user. Define a custom attribute with the value string of the following format:
shell:<contextname>=<role> <domain1> <domain2>...<domainN>
Note
To configure the TACACS+ role and domain settings on Cisco Secure ACS:
1.
a.
b.
c.
2.
a.
b.
3.
4.
–
–
–
shell:<contextname>=<role> <domain1> <domain2>...<domainN>For example, to assign the selected user to the C1 context with the role ROLE1 and the domain DOMAIN1, enter shell:C1=ROLE1 DOMAIN1.
5.
6.
For example, assume that a user named USER1 is assigned the role ADMIN and the domain MYDOMAIN1 (where shell:Admin=ADMIN MYDOMAIN1):
•
•
Configuring a RADIUS Server
The following sections summarize the recommended settings for the Cisco Secure ACS RADIUS user authentication and accounting settings.
•
•
•
Configuring Authentication Settings on the RADIUS Server
To configure the RADIUS authentication settings on Cisco Secure ACS:
1.
Note
2.
3.
•
•
•
•
4.
CiscoSecure ACS saves the AAA client entry and restarts its services, after which it will accept and process RADIUS requests from the ACE.
Configuring Accounting Settings on the RADIUS Server
To configure the RADIUS accounting settings on Cisco Secure ACS:
1.
2.
3.
4.
Note
5.
CiscoSecure ACS saves and implements the changes you made to its RADIUS accounting configuration.
Defining Private Attributes for Virtualization Support in a RADIUS Server
The same username can be created across contexts and can be associated with a unique role in a context and multiple domains. Contexts can share a RADIUS server, but the user must be authenticated for each context and must use the same password.
When a user attempts to log in to the ACE, the RADIUS client on the ACE sends the username and password to the remote RADIUS server for authentication. The RADIUS server retrieves a user's profile as part of the authentication request. Once the user is successfully authenticated, the RADIUS server returns a user profile to the RADIUS client on the ACE along with the authentication status. If the associated context of the user attempting to log in matches the contexts of the user profile obtained through the RADIUS server, then the RADIUS client updates the user profile with the remote server user profile. If the contexts do not match, then the user profile is updated with the default role (Network-Monitor) and the default domain (default-domain).
Configure the user profile on the RADIUS server as a Vendor Specific Attribute with vendor Id Cisco (09) and subattribute type CiscoAVPair (type 01) with a value string of the following format:
shell:<contextname>=<role> <domain1> <domain2>...<domainN>
Note
To configure the RADIUS role and domain settings on Cisco Secure ACS:
1.
2.
–
–
shell:<contextname>=<role> <domain1> <domain2>...<domainN>For example, to assign the selected user to the C1 context with the role ROLE1 and the domain DOMAIN1, enter shell:C1=ROLE1 DOMAIN1.
3.
For example, assume that a user named USER1 is assigned the role ADMIN and the domain MYDOMAIN1 (where shell:Admin=ADMIN MYDOMAIN1):
•
•
Configuring an LDAP Server
This section provides background information on the setup of an LDAP directory server, such as the OpenLDAP and Microsoft Active Directory Servers. This section is intended as a general guide to help ensure proper communication with an LDAP server and an ACE operating as an LDAP client.
As an example, the following section summarizes the recommended configuration setup for the OpenLDAP directory server.
1.
2.
3.
4.
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: Example Corporation
description: The Example Corporation
dn: cn=Manager,dc=example,dc=com
objectclass: organizationalRole
cn: Manager
5.
ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret -fexample.ldifDefining Private Attributes for Virtualization Support in an LDAP Server
The LDAP client on the ACE does not assume any specifics about the database structure maintained by the LDAP server. The assumption is that the {userid, contextid} pair uniquely identifies an entry in the database and that this entry contains the user profile attribute. The LDAP client performs a search based on these two attributes using the search filter configured on the ACE. The LDAP server locates the correct user entry and the user profile attribute, which is part of that entry, and returns this information in the search response.
The LDAP client can operate in applications where virtualization is not a requirement. In this case, the username alone uniquely identifies the user entry. You configure the search filter to include only the $userid variable (no $contextid). You define these two private attributes from the ACE CLI through the attribute user-profile command (see the "Configuring the User Profile Attribute Type for an LDAP Server Group" section).
You define the user profile attribute value in the following format:
shell:<contextname>=<role> <domain1> <domain2>...<domainN>
Note
When virtualization is a requirement, the LDAP server must have the contextid attributes defined in the schema. The user-profile attribute (the role-domain information) is required if you need to assign different roles and domains to different users. Consult the LDAP client documentation for information on how to extend the attributetype directive used by the slapd LDAP directory server.
The following steps provide a general example on how to define private attributes for virtualization support in an LDAP server:
1.
attributetype (2.5.4.55 NAME ( 'ctxid' 'contextid' )DESC 'virtual context name'SUP name )attributetype ( 2.5.4.56 NAME ( 'usrprof' 'userprofile' )DESC 'user profile'SUP name )objectclass ( 2.5.6.30 NAME 'ctxperson'DESC 'a person'SUP top STRUCTURALMUST cnMAY ( $ ctxid $ usrprof ) )The example outlined above includes arbitrary OIDs. The OIDs that you define must not overlap with any of the existing OIDs in the LDAP server database.
2.
3.
dn: ctxid=admin,cn=john,ou=employees,dc=example,dc=comobjectClass: ctxpersonctxid: admincn: johnusrprof: shell:Admin=ROLE-1 DOMAIN-1userPassword: xxxxxxxx4.
The LDAP client and LDAP server initiate their interaction, as follows:
•
•
–
–
–
–
•
•
•
•
Creating User Accounts
Every user associated with a virtual context has account information stored on the ACE. The authentication information, user name, user password, password expiration date, and user role membership are all stored as part of each user's profile.
As the ACE global administrator, you can assign one user in each context as the context administrator. The context administrator can then log in to the context or contexts on the ACE for which he or she is responsible and create additional users.
If you do not assign a user role to a new user, the default user role is Network-Monitor. By default, the user will be allowed to operate on all domains. For users that you create in the Admin context, the default scope of access is the entire device. For users that you create in other contexts, the default scope of access is the entire context. If you need to restrict a user's access, you must assign a role-domain pair.
Note the following when assigning a user for a context in the ACE:
•
•
•
For detailed information on creating contexts and user accounts to provide access to the local database on the ACE for CLI access authentication, refer to the Cisco Application Control Engine Module Virtualization Configuration Guide.
Configuring the ACE as a Client of a RADIUS, TACACS+, or LDAP Server
You can specify one or more AAA server groups to identify the server and the remote authentication protocol, RADIUS, TACACS+, or LDAP. You can configure multiple AAA servers (of the same server type) for each server group.
For each AAA server, you can specify:
•
•
•
•
•
•
This section includes the following topics:
•
•
•
Configuring RADIUS on the ACE
The ACE supports the RADIUS protocol to communicate with a remote RADIUS server for authentication and accounting services. This section defines the configuration of the ACE to operate as a client of a RADIUS server.
This section contains the following procedures:
•
•
•
•
•
•
Setting the RADIUS Server Parameters
Use the radius-server host command to specify the RADIUS server IP address, encrypted key, destination UDP port, and other options. You can define multiple radius-server host commands to configure multiple RADIUS servers.
The syntax of this command is:
radius-server host ip_address [key shared_secret [0 shared_secret | 7 shared_secret]] [auth-port port_number] [acct-port port_number] [authentication] [accounting] [timeout seconds] [retransmit count]
The arguments, keywords, and options are:
•
•
•
•
•
•
•
•
Note
•
Note
•
•
For example, to configure RADIUS server authentication parameters, enter:
host1/Admin(config)# radius-server host 192.168.2.3 key HostKeyhost1/Admin(config)# radius-server host 192.168.2.3 key 7 secret_1256host1/Admin(config)# radius-server host 192.168.2.3 auth-port 1645host1/Admin(config)# radius-server host 192.168.2.3 acct-port 1646host1/Admin(config)# radius-server host 192.168.2.3 authenticationhost1/Admin(config)# radius-server host 192.168.2.3 accountinghost1/Admin(config)# radius-server host 192.168.2.3 timeout 25host1/Admin(config)# radius-server host 192.168.2.3 retransmit 3To revert to a default RADIUS server authentication setting, enter:
host1/Admin(config)# no radius-server host 192.168.2.3 acct-port 1646Configuring the RADIUS NAS-IP-Address Attribute
RADIUS servers normally check the source IP address in the IP header of the RADIUS packets to track the source of the RADIUS requests. Also, some servers use the NAS-IP-Address RADIUS attribute to identify the RADIUS clients which could expose your ACE internal private network interface IP addresses.
By default, the NAS-IP-Address is not configured. The ACE performs a route lookup on the RADIUS server IP address and uses the result. Use the radius-server attribute nas-ipaddr command to specify an RADIUS NAS-IP-Address attribute. This attribute allows you to configure an arbitrary IP address to be used as RADIUS attribute 4, NAS-IP-Address for each context. The radius-server attribute nas-ipaddr command allows the ACE to behave as a single RADIUS client from the perspective of the RADIUS server. The configured NAS-IP-Address will be encapsulated in all outgoing RADIUS authentication request and accounting packets.
The syntax of this command is:
radius-server attribute nas-ipaddr nas_ip_address
The nas_ip_address argument configures an IP address to be used as the RADIUS NAS-IP-Address, attribute 4.
For example, to specify a RADIUS NAS-IP-Address, enter:
host1/Admin(config)# radius-server attribute nas-ipaddr 192.168.1.1To delete the RADIUS NAS-IP-Address and return to the default configuration, enter:
host1/Admin(config)# no radius-server attribute nas-ipaddr 192.168.1.1Setting the Global RADIUS Server Preshared Key
To globally configure an authentication key for communication between the ACE and the RADIUS daemon running on each RADIUS server, use the radius-server key command. The key is a text string that must match the encryption key used on the RADIUS server. RADIUS keys are always stored in encrypted form in persistent storage on the ACE. This global key will be applied to those RADIUS servers in a named server group for which a shared secret is not individually configured by the radius-server host command.
The syntax of this command is:
radius-server key {shared_secret | 0 shared_secret | 7 shared_secret}
The arguments and keywords are:
•
•
•
For example, to globally configure an authentication key to be sent in encrypted text (indicated by 7) to the RADIUS server, enter:
host1/Admin(config)# radius-server key 7 abe4DFeeweo00oTo delete the key, enter:
host1/Admin(config)# no radius-server key 7 abe4DFeeweo00oConfiguring the Global RADIUS Server Dead-Time
During the dead-time interval, the ACE sends probe access-request packets to verify that the RADIUS server is available and can receive authentication requests. The dead-time interval starts when the server does not respond to the number of authentication request transmissions configured through either the radius-server retransmit command or the radius-server host retransmit command. When the server responds to a probe access-request packet, the ACE transmits the authentication request to the server.
Use the radius-server deadtime command to globally set the time interval in which the ACE verifies whether a nonresponsive server is operational.
Use of this command causes the ACE to mark as "dead" any RADIUS servers that fail to respond to authentication requests. This action avoids the wait for the request to time out before trying the next configured server. The ACE skips a RADIUS server that is marked as "dead" by additional requests for the duration of the specified minutes argument.
The syntax of this command is:
radius-server deadtime minutes
The minutes argument specifies the length of time that the ACE skips a nonresponsive RADIUS server for transaction requests. Valid entries are 0 to 1440 minutes (24 hours). The default is 0.
For example, to globally configure a fifteen-minute dead-time for RADIUS servers that fail to respond to authentication requests, enter:
host1/Admin(config)# radius-server deadtime 15To set the RADIUS server dead-time request to 0, enter:
host1/Admin(config)# no radius-server deadtime 15Setting the Global RADIUS Server Number of Retransmissions
By default, the ACE sends one authentication request to a RADIUS server before declaring the server to be unresponsive and contacting the next server in the group. Use the radius-server retransmit command to globally change the number of times the ACE sends an authentication request to a RADIUS server. If all servers in the group are unavailable for authentication and accounting, the ACE tries the local database if it is configured as a local fallback method in the aaa authentication login or the aaa accounting default commands. If you do not have a fallback method, the ACE continues to contact one of the AAA servers listed in the server group.
The ACE applies this global retransmission value to those RADIUS servers for which a value is not individually configured by the radius-server host command.
The syntax of this command is:
radius-server retransmit count
The count argument specifies the number of times the ACE attempts to connect to a RADIUS server before trying to contact the next available server. The range is 1 to 5 times. The default is 1.
For example, to globally configure the number of retransmissions to 3, enter:
host1/Admin(config)# radius-server retransmit 3To revert to the default of one transmission attempt, enter:
host1/Admin(config)# no radius-server retransmit 3Setting the Global RADIUS Server Timeout Value
By default, the ACE waits one second for the RADIUS server to send a reply to an authentication request to an unresponsive server before retransmitting an authentication request to the server. Use the radius-server timeout command to globally change the time interval that the ACE waits for the RADIUS server to reply before retransmitting an authentication request to the RADIUS server. The ACE applies this global timeout value to those RADIUS servers for which a timeout value is not individually configured by the radius-server host command.
The syntax of this command is:
radius-server timeout seconds
The seconds argument specifies the time in seconds between retransmissions to the RADIUS server. Valid entries are 1 to 60 seconds. The default is 1 second.
For example, to globally configure the timeout value to 30 seconds, enter:
host1/Admin(config)# radius-server timeout 30To revert to the default of one second between transmission attempts, enter:
host1/Admin(config)# no radius-server timeout 30Configuring TACACS+ on the ACE
The ACE supports the TACACS+ protocol to communicate with a TACACS+ server for authentication and accounting services. This section defines the configuration of the ACE to operate as a client of a TACACS+ server.
This section contains the following procedures:
•
•
•
•
Setting the TACACS+ Server Parameters
Use the tacacs-server host command to specify the TACACS+ server IP address, encrypted key, destination port, and other options. You can define multiple tacacs-server host commands to configure multiple TACACS+ servers.
The syntax of this command is:
tacacs-server host ip_address [key shared_secret [0 shared_secret | 7 shared_secret]] [port port_number] [timeout seconds]
The arguments, keywords, and options are:
•
•
•
•
•
•
•
For example, to configure TACACS+ server authentication parameters, enter:
host1/Admin(config)# tacacs-server host 192.168.3.2 key HostKeyhost1/Admin(config)# tacacs-server host 192.168.3.2 port 1645host1/Admin(config)# tacacs-server host 192.168.3.2 timeout 5To remove the TACACS+ server from the configuration, enter:
host1/Admin(config)# no tacacs-server host 192.168.3.2 key HostKEYSetting the Global Preshared Key
To globally configure an authentication key for communication between the ACE and the TACACS+ daemon running on each TACACS+ server, use the tacacs-server key command. The key is a text string that must match the encryption key used on the TACACS+ server. TACACS+ keys are always stored in encrypted form in persistent storage on the ACE. This global key will be applied to those TACACS+ servers in a named server group for which a shared secret is not individually configured by the tacacs-server host command.
The syntax of this command is:
tacacs-server key shared_secret | 0 shared_secret | 7 shared_secret
The arguments and keywords are:
•
•
•
For example, to globally configure an authentication key in encrypted text (indicated by 7) to authenticate communication between the TACACS+ client and server, enter:
host1/Admin(config)# tacacs-server key 7 abe4DFeeweo00oTo delete the key, enter:
host1/Admin(config)# no tacacs-server key 7 abe4DFeeweo00oSetting the Global TACACS+ Server Dead-Time
During the dead-time interval, the ACE sends probe access-request packets to verify that the TACACS+ server is available and can receive authentication requests. The dead-time interval starts when the server does not respond to an authentication request transmission. When the server responds to a probe access-request packet, the ACE retransmits the authentication request to the server.
Use the tacacs-server deadtime command to globally set the time interval in which the ACE verifies whether a nonresponsive server is operational.
Use of this command causes the ACE to mark as "dead" any TACACS+ servers that fail to respond to authentication requests. This action avoids the wait for the request to time out before trying the next configured server. The ACE skips a TACACS+ server that is marked as "dead" by additional requests for the duration of the minutes argument.
The syntax of this command is:
tacacs-server deadtime minutes
The minutes argument specifies the length of time that the ACE skips a nonresponsive TACACS+ server for transaction requests. Valid entries are 0 to 1440 minutes (24 hours). The default is 0.
For example, to globally configure a fifteen-minute dead-time for TACACS+ servers that fail to respond to authentication requests, enter:
host1/Admin(config)# tacacs-server deadtime 15To set the TACACS+ server dead-time request to 0, enter:
host1/Admin(config)# no tacacs-server deadtime 15Setting the Global TACACS+ Server Timeout Value
By default, the ACE waits one second to receive a response from a TACACS+ server before it declares a timeout failure and attempts to contact the next server in the group. Use the tacacs-server timeout command to globally change the time interval that the ACE waits for the TACACS+ server to reply before retransmitting an authentication request to the TACACS+ server. The ACE applies this global timeout value to those TACACS+ servers for which a timeout value is not individually configured by the tacacs-server host command.
The syntax of this command is:
tacacs-server timeout seconds
The seconds argument specifies the timeout value in seconds. Valid entries are 1 to 60 seconds. The default is 1 second.
For example, to globally configure the timeout value to 30 seconds, enter:
host1/Admin(config)# tacacs-server timeout 30To revert to the default of one second between transmission attempts, enter:
host1/Admin(config)# no tacacs-server timeout 30Configuring LDAP on the ACE
The ACE supports the LDAP protocol to communicate with a remote LDAP directory server for authentication services. This section defines the configuration of the ACE to operate as a client of an LDAP server.
This section contains the following procedures:
•
•
•
Setting the LDAP Server Parameters
Use the ldap-server host command to specify the LDAP server host name or IP address, destination port, and other options. You can define multiple ldap-server host commands to configure multiple LDAP servers.
The syntax of this command is:
ldap-server host ip_address [port port_number] [timeout seconds] [rootDN "DN_string" [password bind_password]]
The arguments, keywords, and options are:
•
•
•
•
•
For example, to configure LDAP server authentication parameters, enter:
host1/Admin(config)# ldap-server host 192.168.2.3 port 2003host1/Admin(config)# ldap-server host 192.168.2.3 timeout 60host1/Admin(config)# ldap-server host 192.168.2.3 rootDN "cn=manager,dc=cisco,dc=com" password labTo remove the LDAP server authentication setting, enter:
host1/Admin(config)# no ldap-server host 192.168.2.3Setting the Global LDAP Server Port Setting
By default, the TCP destination port for communicating authentication requests to the LDAP directory server is 389. If your LDAP server uses a port other than port 389, use the ldap-server port command to globally configure the ACE for the appropriate port prior to starting the LDAP service. This global port setting will be applied to those LDAP servers for which a TCP port value is not individually configured by the ldap-server host command.
The syntax of this command is:
ldap-server port port_number
The port_number argument specifies the destination port to the LDAP server. Valid values are from 1 to 65535. The default is TCP port 389.
For example, to globally configure the TCP port, enter:
host1/Admin(config)# ldap-server port 2003To revert to the default of TCP port 389, enter:
host1/Admin(config)# no ldap-server port 2003Setting the Global LDAP Server Timeout Value
By default, the ACE waits five seconds to receive a response from an LDAP server before it declares a timeout failure and attempts to contact the next server in the group. Use the ldap-server timeout command to globally change the time interval that the ACE waits for the LDAP server to reply to a response before it declares a timeout failure. The ACE applies this global timeout value to those LDAP servers for which a timeout value is not individually configured by the ldap-server host command.
The syntax of this command is:
ldap-server timeout seconds
The seconds argument specifies the timeout value in seconds. Valid entries are 1 to 60 seconds. The default is 5 seconds.
For example, to globally configure the timeout value to 30 seconds, enter:
host1/Admin(config)# ldap-server timeout 30To change to the default of five seconds between transmission attempts, enter:
host1/Admin(config)# no ldap-server timeout 30Configuring AAA Server Groups
This section contains the following procedures
•
•
•
•
Creating a TACACS+, RADIUS, or LDAP Server Group
A server group is a list of server hosts of a particular type. The ACE allows you to configure multiple TACACS+, RADIUS, and LDAP servers as a named server group. You group the different AAA server hosts into distinct lists. The ACE searches for the server hosts in the order in which you specify them within a group.
Use the aaa group server command to configure independent server groups of TACACS+, RADIUS, or LDAP servers. You can configure server groups at any time, but they only take effect when you apply them to the AAA service using the aaa authentication login or the aaa accounting default commands.
You can configure a maximum of 100 server groups for each context in the ACE.
The ACE attempts to contact the first server listed in the server group for user authentication and accounting. If that server is unavailable, the ACE attempts to contact the next configured server listed in the group. If all servers in the group are unavailable, the ACE then tries the servers in the next configured server group. The ACE repeats this process until the authentication request can be handled by an AAA server. If the specified AAA servers in a server group are unavailable, and you specify local authentication as the fallback method (as specified through the aaa authentication login command), the ACE attempts to authenticate the user against the local database on the ACE. If you do not have a fallback method, the ACE continues to contact one of the AAA servers listed in the server group.
The syntax of this command is:
aaa group server {ldap | radius | tacacs+} group_name
The arguments and keywords are:
•
•
•
•
The CLI displays the TACACS+, RADIUS, or LDAP server configuration mode where you identify the name of one or more previously configured servers that you want added to the server group.
The syntax of this server configuration mode command is:
server ip_address
The ip_address argument specifies the IP address for an existing RADIUS, TACACS+, or LDAP server that you want to add to the server group. Enter the address in dotted-decimal IP notation (for example, 192.168.11.1). You can add multiple servers to the server group by entering multiple server commands while in server configuration mode. The same server can belong to multiple server groups.
For example, to create a RADIUS server group, enter:
host1/Admin(config)# aaa group server radius RAD_Server_Group1host1/Admin(config-radius)# server 192.168.252.1host1/Admin(config-radius)# server 192.168.252.2host1/Admin(config-radius)# server 192.168.252.3To remove a server from a server group, enter:
host1/Admin(config-radius)# no server 192.168.252.3To remove a server group, enter:
host1/Admin(config)# no aaa group server radius RAD_Server_Group1For the TACACS+, RADIUS, and LDAP server groups, you can also configure the following parameters:
•
•
•
–
–
–
Setting the Dead-Time for a TACACS+ Server Group
For a TACACS+ server group, you can specify a dead-time interval for the server group. During the dead-time interval, the ACE sends probe access-request packets to verify that the TACACS+ server is available and can receive authentication requests. The dead-time interval starts when the server does not respond to an authentication request transmissions. When the server responds to a probe access-request packet, the ACE retransmits the authentication request to the server.
Use the deadtime command to globally set the time interval in which the ACE verifies whether a nonresponsive server group is operational.
Use of this command causes the ACE to mark as "dead" any TACACS+ servers that fail to respond to authentication requests. This action avoids the wait for the request to time out before trying the next configured server. The ACE skips a TACACS+ server that is marked as "dead" by additional requests for the duration of the minutes argument.
The syntax of this command is:
deadtime minutes
The minutes argument specifies the length of time that the ACE skips a nonresponsive TACACS+ server for transaction requests. Valid entries are 0 to 1440 minutes (24 hours). The default is 0.
For example, to globally configure a fifteen-minute dead-time for TACACS+ servers that fail to respond to authentication requests, enter:
host1/Admin(config-tacacs)# deadtime 15To reset the RADIUS server dead-time request to 0, enter:
host1/Admin(config-tacacs)# no deadtime 15Setting the Dead-Time for a RADIUS Server Group
For a RADIUS server group, you can specify a dead-time interval for the server group. During the dead-time interval, the ACE sends probe access-request packets to verify that the RADIUS server is available and can receive authentication requests. The dead-time interval starts when the server does not respond to an authentication request transmissions. When the server responds to a probe access-request packet, the ACE retransmits the authentication request to the server.
Use the deadtime command to globally set the time interval in which the ACE verifies whether a nonresponsive server group is operational.
Use of this command causes the ACE to mark as "dead" any RADIUS servers that fail to respond to authentication requests. This action avoids the wait for the request to time out before trying the next configured server. The ACE skips a RADIUS server that is marked as "dead" by additional requests for the duration of the minutes argument.
The syntax of this command is:
deadtime minutes
The minutes argument specifies the length of time that the ACE skips a nonresponsive RADIUS server for transaction requests. Valid entries are 0 to 1440 minutes (24 hours). The default is 0.
For example, to globally configure a fifteen-minute dead-time for RADIUS servers that fail to respond to authentication requests, enter:
host1/Admin(config-radius)# deadtime 15To reset the RADIUS server dead-time request to 0, enter:
host1/Admin(config-radius)# no deadtime 15Configuring the User Profile Attribute Type for an LDAP Server Group
A LDAP server retrieves a user's profile as part of the search request. During a search request, the LDAP client requests the user profile attribute from the LDAP server by including this attribute type (the configured string) in the search request. The search request must match the attribute type used by the LDAP server to properly identify the user profile attribute, as defined in private schema on the LDAP server. The LDAP server uses the search filter to locate the user profile entry in its database. Once the LDAP server finds the entry, it replies with a search response in which it includes the value of the user profile attribute that was stored in that entry. This value contains the role and domain pair of the user for that context.
You define the user profile attribute value in the following format:
shell:<contextname>=<role> <domain1> <domain2>...<domainN>
Note
This is the attribute type for the user profile attribute. Since this is a private attribute, the LDAP server database should use the same attribute type for the user profile. The LDAP client (the ACE) sends the search request with this attribute type as the attribute it wants to download. If the lookup was successful, the search response contains this attribute value. The attribute value must contain a string that represents the user role and domain pair for this particular context.
Use the attribute user-profile command to specify which user profile attribute to use by the LDAP server.
You configure the LDAP user profile attribute at the subconfiguration level for the LDAP server group (created as described in the "Configuring AAA Server Groups" section).
The syntax of this command is:
attribute user-profile text
The text argument specifies the user profile. The user profile is an unquoted text string of a maximum of 63 characters without spaces.
For example, to configure an LDAP user profile attribute, enter:
host1/Admin(config-ldap)# attribute user-profile usrprofTo delete the user profile attribute, enter:
host1/Admin(config-ldap)# no attribute user-profile usrprofConfiguring the Base DN for an LDAP Server Group
When you create an LDAP server group, the top level of the LDAP directory tree is the base, referred to as the "base DN". The base DN is used to perform the search operation in the LDAP server directory. A base DN can take a form such as "dc=your,dc=domain", where the base DN uses the DNS domain name as its basis and is split into the domain components. Use the base-DN server group command to configure the base DN that you want to use to perform search operations in the LDAP directory tree.
Note
You configure the base DN at the submode for the LDAP server group (created as described in the "Configuring AAA Server Groups" section).
The syntax of this command is:
base-DN text
The text argument identifies the distinguished name of the search base. The base DN name is a quoted text string of a maximum of 63 characters without spaces.
For example, to configure the base DN, enter:
host1/Admin(config)# aaa group server ldap LDAP_Server_Group1host1/Admin(config-ldap)# base-DN "dc=sns,dc=cisco,dc=com"To delete the configured base DN, enter:
host1/Admin(config-ldap)# no base-DN "dc=sns,dc=cisco,dc=com"Configuring the Search Filter for an LDAP Server Group
For an LDAP server group, the ACE transmits a search filter to the LDAP server to lookup a user in the database. Search filters enable you to define search criteria and provide more efficient and effective searches. The search filter is used in the search request sent by the LDAP client to the server to locate the user's node in the DIT. Use the filter search-user command to configure the exact filter to use. The $user and $contextid are substituted with actual values when sending the request.
The search filter should follow the format defined in RFC 2254. The LDAP client sends the search request with the configured search filter after replacing the $userid and $contextid with the userid that the client is trying to authenticate and the associated virtual context name.The ACE allows $userid and $contextid to be used as placeholders for user id and context name.
Note
You configure the LDAP search filter at the subconfiguration level for the LDAP server group (created as described in the "Configuring AAA Server Groups" section).
The syntax of this command is:
filter search-user text
The text argument specifies the search request. The search filter is a quoted text string of a maximum of 63 characters without spaces.
For example, to configure a search request, enter:
host1/Admin(config)# aaa group server ldap LDAP_Server_Group1host1/Admin(config-ldap)# filter search-user "(&(objectclass=person) (&(cn=$userid)(cid=$contextid)))"To delete the search request, enter:
host1/Admin(config-ldap)# no filter search-user "(&(objectclass=person)(&(cn=$userid)(cid=$contextid)))"Defining the Login Authentication Method
Authentication is the process of verifying the identity of the person attempting to login to the ACE CLI by console port or by Telnet or SSH session. This identity verification is based on the user name and password combination provided by the person attempting to access the ACE.
The ACE supports local authentication using the lookup database on the ACE or remote authentication using one or more TACACS+, RADIUS, or LDAP servers. You can specify the local database on the ACE as the fallback authentication method in case the configured AAA servers fail to respond to the authentication request.
The default login method of user authentication is by Telnet or SSH session. You can override the default login authentication method and specify authentication through the console port.
To configure the authentication method used for login to the ACE CLI, use the aaa authentication login command in configuration mode.
The syntax of this command is:
aaa authentication login {{console | default} {{group group_name} {local} {none}}} | error-enable
The arguments, keywords, and options are:
•
•
•
•
•
Caution
•
Remote AAA servers unreachable; local authentication done.For example, to enable console authentication using the TacServers server group, followed by local login as the fallback method, enter:
host1/Admin(config)# aaa authentication login console group TacServers local nonePassword verification remains enabled for login authentication.
For example, to turn off password validation, enter:
host1/Admin(config)# no aaa authentication login console group TacServers local noneFor example, to revert to the local authentication method, enter:
host1/Admin(config)# no aaa authentication login console group TacServers local noneDefining the Default Accounting Method
Accounting refers to the log information that is maintained for each user's management session with an ACE. This information may be used to generate reports for troubleshooting and auditing purposes. Accounting can be implemented locally on the ACE or remotely using a RADIUS or TACACS+ server.
Use the aaa accounting default command to configure the default accounting method. You specify either a previously created AAA server group that identifies separate groups of TACACS+ or RADIUS servers or the local database on the ACE.
The syntax of this command is:
aaa accounting default {group group_name} {local} {none}
The arguments, keywords, and options are:
•
•
Caution
•
For example, to enable user accounting to be performed using remote TACACS+ servers, followed by local login as the fallback method, enter:
host1/Admin(config-context)# aaa accounting default group TacServers localTo revert to the default local accounting method, enter:
host1/Admin(config-context)# no aaa accounting default group TacServers localViewing AAA Status and Statistics
This section contains the following procedures:
•
•
•
•
•
Displaying AAA Groups
To display the configured server groups, use the show aaa groups command. The syntax of this command is:
show aaa groups
For example, to display configured server groups, enter:
host1/Admin# show aaa groupsTACACS:TACACS_group1RADIUS:RAD_group1LDAP:LDAP_group2Displaying RADIUS Server Configuration Information
To display the configured RADIUS server and group parameters, use the show radius-server command.
The syntax of this command is:
show radius-server [groups | sorted]
The keywords are:
•
•
For example, to display configured RADIUS server parameters, enter:
host1/Admin# show radius-serverretransmission count:1timeout value:1deadtime value:20total number of servers:2following RADIUS servers are configured:192.168.34.45:available for authentication on port:1812available for accounting on port:1813192.168.2.3:available for authentication on port:1812available for accounting on port:1813RADIUS shared secret:********For example, to display the configured RADIUS server groups, enter:
host1/Admin# show radius-server groupstotal number of groups:2following RADIUS server groups are configured:group radius:server: all configured radius serversgroup RAD_Server_Group:deadtime is 0For example, to display the sorted RADIUS server groups, enter:
host1/Admin# show radius-server sortedretransmission count:1timeout value:1deadtime value:20total number of servers:2following RADIUS servers are configured:192.168.34.45:available for authentication on port:1812available for accounting on port:1813192.168.2.3:available for authentication on port:1812available for accounting on port:1813RADIUS shared secret:********Displaying TACACS+ Server Configuration Information
To display the configured TACACS+ server and group parameters, use the show tacacs-server command.
The syntax of this command is:
show tacacs-server [groups | sorted]
The keywords options are:
•
•
For example, to display the configured TACACS+ server parameters, enter:
host1/Admin# show tacacs-serverGlobal TACACS+ shared secret:tacacsPwordtimeout value:30total number of servers:3following TACACS+ servers are configured:192.168.58.91:available on port:2cisco.com:available on port:49192.168.22.95:available on port:49TACACS+ shared secret:MyKeyThe following command displays the configured TACACS+ server groups.
host1/Admin# show tacacs-server groupstotal number of groups:1following TACACS+ server groups are configured:group TacServers:server 192.168.58.91 on port 2The following command displays the sorted TACACS+ servers.
host1/Admin# show tacacs-server sortedtimeout value:1total number of servers:1Displaying LDAP Server Configuration Information
To display the configured LDAP server and server group parameters, use the show ldap-server command.
The syntax of this command is:
show ldap-server [groups]
The optional groups keyword displays configured LDAP server group information.
To display configured LDAP server parameters.
host1/Admin# show ldaptimeout : 5port : 389total number of servers : 1The following command displays the configured LDAP server groups.
host1/Admin# show ldap-server groupstotal number of groups: 1following LDAP server groups are configured:group LDAP_Server_Group1:baseDN: "dc=sns,dc=cisco,dc=com"user profile attribute: usrprofsearch filter: "(&(objectclass=person) (&(cn=$userid)(cid=$contextid)))"Displaying Accounting Configuration Information
To display accounting configuration information for the ACE, use the show aaa accounting command.
The syntax of this command is:
show aaa accounting
For example, to display accounting configuration information, enter:
host1/Admin# show aaa accountingdefault: localDisplaying Accounting Log Information
To display accounting log information for the ACE, use the show accounting log command.
The syntax of this command is:
show accounting log [size]
The size option specifies the size of the local accounting log file to display in bytes from 0 to 250000. The default is 250000 bytes.
For example, to display accounting log information, enter:
host1/Admin# show aaa accounting logSat Jan 1 00:02:55 2000:start:/dev/ttyS00_946684975:admin:Sat Nov 5 00:20:04 2005:update:/dev/ttyS00_946684975:admin:0:ft interface vlan50Sat Nov 5 00:20:05 2005:update:/dev/ttyS00_946684975:admin:1:ip address 12.1.1.2 255.255.255.0Sat Nov 5 00:20:05 2005:update:/dev/ttyS00_946684975:admin:1:peer ip 12.1.1.1 255.255.255.0Sat Nov 5 00:20:05 2005:update:/dev/ttyS00_946684975:admin:1:no shutdownSat Nov 5 00:20:12 2005:update:/dev/ttyS00_946684975:admin:0:ft peer 1Sat Nov 5 00:20:12 2005:update:/dev/ttyS00_946684975:admin:0:ft-interface vlan50Sat Nov 5 00:20:41 2005:update:/dev/ttyS00_946684975:admin:0:log console 6Sat Nov 5 00:20:58 2005:update:/dev/ttyS00_946684975:admin:0:ft group 1Sat Nov 5 00:20:58 2005:update:/dev/ttyS00_946684975:admin:0:peer 1Sat Nov 5 00:20:58 2005:update:/dev/ttyS00_946684975:admin:0:priority 50Sat Nov 5 00:20:58 2005:update:/dev/ttyS00_946684975:admin:0:associate-contextAdminSat Nov 5 00:20:58 2005:update:/dev/ttyS00_946684975:admin:0:inservice..Displaying Authentication Configuration Information
To display authentication configuration information for the ACE, use the show aaa authentication command.
The syntax of this command is:
show aaa authentication [login error-enable]
The login error-enable option allows you to view the current display status of the login error message.
For example, to display the configured authentication parameters, enter:
host1/Admin# show aaa authenticationdefault: group TacServers local noneconsole: localhost1/Admin# show aaa authentication login error-enableenabled
