-
User Guide for Cisco Secure ACS Appliance 3.2
-
Preface
-
Overview
-
Deployment Considerations
-
Interface Configuration
-
Network Configuration
-
Shared Profile Components
-
User Group Management
-
User Management
-
System Configuration: Basic
-
System Configuration: Advanced
-
System Configuration: Authentication and Certificates
-
Logs and Reports
-
Administrators and Administrative Policy
-
User Databases
-
Unknown User Policy
-
User Group Mapping and Specification
-
Troubleshooting
-
TACACS+ Attribute-Value Pairs
-
RADIUS Attributes
-
VPDN Processing
-
RDBMS Synchronization Import Definitions
-
Internal Architecture
-
Index
-
Table Of Contents
Authenticating with External User Databases
External User Database Authentication Process
What's Supported with Windows User Databases
Authentication Process with Windows User Databases
Windows Dial-up Networking Clients
EAP and Windows Authentication
User-Changeable Passwords with Windows User Databases
Preparing Users for Authenticating with Windows
Selecting Remote Agents for Windows Authentication
Windows Authentication Configuration Options
Configuring Windows Authentication
Cisco Secure ACS Authentication Process with a Generic LDAP User Database
LDAP Organizational Units and Groups
Configuring a Generic LDAP External User Database
Downloading a Certificate Database
About Novell NDS User Databases
Novell NDS External User Database Options
Configuring a Novell NDS External User Database
LEAP Proxy RADIUS Server Database
Configuring a LEAP Proxy RADIUS Server External User Database
About Token Servers and Cisco Secure ACS
Token Server RADIUS Authentication Request and Response Contents
Configuring a RADIUS Token Server External User Database
Deleting an External User Database Configuration
User Databases
CiscoSecure AccessControlServer (ACS) Appliance authenticates users against one of several possible databases, including its internal database. You can configure CiscoSecure ACS to authenticate users with more than one type of database. This flexibility enables you to use user accounts data collected in different locations without having to explicitly import the users from each external user database into the CiscoSecure user database. It also enables you to apply different databases to different types of users, depending on the security requirements associated with user authorizations on your network. For example, a common configuration is to use a Windows user database for standard network users and a token server for network administrators.
Note
For information about the Unknown User Policy and group mapping features, see "Unknown User Policy," and "User Group Mapping and Specification"
This chapter contains the following topics:
•
•
•
CiscoSecure User Database
The CiscoSecure user database is the database internal to CiscoSecure ACS. It supports authentication using ASCII, PAP, CHAP, MS-CHAP, ARAP, LEAP, EAP-MD5, EAP-TLS, PEAP(EAP-GTC), PEAP(EAP-MSCHAPv2), and EAP-FAST (phase zero and phase two).
The CiscoSecure user database is crucial for the authorization process. Regardless of whether a user is authenticated by the internal user database or by an external user database, CiscoSecure ACS authorizes network services for users based upon group membership and specific user settings found in the CiscoSecure user database. Thus, all users authenticated by CiscoSecure ACS, even those authenticated by an external user database, have an account in the CiscoSecure user database.
The CiscoSecure user database uses an index and tree structure, so searches can occur logarithmically rather than linearly, thus yielding very fast lookup times. This enables the CiscoSecure user database to authenticate users quickly.
Unless you have configured CiscoSecure ACS to authenticate users with an external user database, CiscoSecure ACS uses usernames and passwords in the CiscoSecure user database during authentication. For more information about specifying an external user database for authentication of a user, see Adding a Basic User Account.
User Import and Creation
There are four ways to create user accounts in the in CiscoSecure ACS Appliance. Of these, only RDBMS Synchronization supports importing user accounts from external sources.
•
•
If you use Unknown User Policy, you can also configure group mappings so that each time a user added to the by Unknown User Policy is authenticated, the user group assignment is made dynamically. For some external user database types, user group assignment is based on group membership in the external user database. For other database types, all users authenticated by a given database are assigned to a single CiscoSecure ACS user group. For more information about group mapping, see "User Group Mapping and Specification"
•
•
About External User Databases
You can configure CiscoSecure ACS to forward authentication of users to one external user database or more. Support for external user databases means that CiscoSecure ACS does not require that you create duplicate user entries in the CiscoSecure user database. In organizations in which a substantial user database already exists, CiscoSecure ACS can leverage the work already invested in building the database without any additional input. This eliminates the need for separate databases.
In addition to authentication for network access, CiscoSecure ACS can perform authentication for TACACS+ enable privileges using external user databases. For more information about TACACS+ enable passwords, see Setting TACACS+ Enable Password Options for a User.
Note
Users can be authenticated using the following databases.
•
•
•
•
•
•
–
–
–
–
–
–
For CiscoSecure ACS to interact with an external user database, CiscoSecure ACS requires an API for the third-party authentication source. The CiscoSecure ACS communicates with the external user database using the API. For Windows, you must have installed and configured CiscoSecure ACS Remote Agent for Windows. The Windows remote agent interacts with the Windows operating system to provide authentication.
For Generic LDAP and Novell NDS authentication, the interface for the external authentication is provided by the CiscoSecure ACS Appliance.
For RADIUS-based token servers, such as ActivCard, CRYPTOCard, PassGo, SafeWord, and Vasco, the standard RADIUS interface serves as the third-party API.
Authenticating with External User Databases
Authenticating users with an external user database requires more than configuring CiscoSecure ACS to communicate with an external user database. Performing one of the configuration procedures for an external database that are provided in this chapter does not on its own instruct CiscoSecure ACS to authenticate any users with that database.
After you have configured CiscoSecure ACS to communicate with an external user database, you can configure CiscoSecure ACS to authenticate users with the external user database in one of two ways:
•
While setting the Password Authentication for every user account is time consuming, this method of determining which users are authenticated with an external user database is secure because it requires explicit definition of who should authenticate using the external user database. In addition, the users may be placed in the desired CiscoSecure ACS group and thereby receive the applicable access profile.
•
You can also configure CiscoSecure ACS with both methods above; these two methods are not mutually exclusive.
External User Database Authentication Process
When CiscoSecure ACS attempts user authentication with an external user database, it forwards the user credentials to the external user database. The external user database either passes or fails the authentication request from CiscoSecure ACS. Upon receiving the response from the external user database, CiscoSecure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the external user database. Figure13-1 shows a AAA configuration with an external user database.
Figure 13-1 A Simple AAA Scenario
The specifics of the method used to communicate with the external user database vary with the database type. For LDAP and Novell NDS, CiscoSecure ACS uses TCP connections. For Windows user databases, CiscoSecure ACS uses the authentication API provided in the Windows operating system. With the exception of RSA token servers, CiscoSecure ACS communicates with token servers using RADIUS. For RSA token servers, CiscoSecure ACS acts an RSA client in order to use the RSA proprietary interface.
For more information, see the section regarding the database type you are interested in.
Windows User Database
You can configure CiscoSecure ACS to use a Windows user database to authenticate users.
This section contains the following topics:
•
•
•
–
–
•
–
–
•
•
•
•
•
What's Supported with Windows User Databases
CiscoSecure ACS supports the use of Windows external user databases for the following features:
•
Note
•
•
•
•
•
Authentication Process with Windows User Databases
CiscoSecure ACS forwards user credentials to a Windows user database by passing the user credentials to a remote agent. In turn, the remote agent passes the user credentials to the Windows operating system of the computer running the remote agent. The Windows user database either passes or fails the authentication request from CiscoSecure ACS. Upon receiving the response from the Windows user database, the remote agent forwards the response to CiscoSecure ACS, which instructs the requesting AAA client to grant or deny the user access, depending upon the response from the Windows user database.
CiscoSecure ACS grants authorization based on the CiscoSecure ACS group to which the user is assigned. While the group to which a user is assigned can be determined by information from the Windows user database, it is CiscoSecure ACS that grants authorization privileges.
To further control access by a user from within the Windows User Manager or Active Directory Users and Computers, you can configure CiscoSecure ACS to also check the setting for granting dialin permission to user. If this feature is disabled for the user, access is denied, even if the username and password are typed correctly.
Trust Relationships
CiscoSecure ACS can take advantage of trust relationships that have been established between Windows domains. If the domain containing the computer running the Windows remote agent trusts another domain, CiscoSecure ACS can authenticate users whose accounts reside in the other domain. CiscoSecure ACS can also reference the "Grant dialin permission to user" setting across trusted domains.
If your domains are Windows 2000 domains, CiscoSecure ACS can take advantage of indirect trusts for Windows authentication. Consider the example of Windows 2000 domains A, B, and C, where the remote agent runs on a Windows 2000 server in domain A. Domain A trusts domain B, but no trust relationship is established between domain A and domain C. If domain B trusts domain C, the remote agent in domain A can authenticate users whose accounts reside in domain C, making use of the indirect trust of domain C.
For more information on trust relationships, refer to your Microsoft Windows documentation.
Windows Dial-up Networking Clients
The dial-up networking clients for Windows NT/2000/XP Professional and Windows 95/98/Millennium Edition (ME)/XP Home enable users to connect to your network remotely, but the fields provided differ.
Windows Dial-up Networking Clients with a Domain Field
If users dial in to your network using the dial-up networking client provided with WindowsNT, Windows 2000, or Windows XP Professional, three fields appear:
•
•
•
Note
Windows Dial-up Networking Clients without a Domain Field
If users access your network using the dial-up networking client provided with Windows 95, Windows 98, Windows ME, or Windows XP Home, two fields appear:
•
Note
•
Windows Authentication
While different versions of Windows provide different methods of specifying a domain name, the effect of providing or not providing the domain name while logging in is the same. The most reliable method of authenticating users against a specific domain is to require users to submit the domains they should be authenticated against along with their usernames.
With the dial-up networking client provided with WindowsNT, Windows 2000, and Windows XP Professional, submitting a domain name is accomplished by typing the domain name in the domain field (or selecting it from the drop-down list). With the dial-up networking client provided with Windows95, Windows 98, Windows ME, and Windows XP Home, this is accomplished by submitting the username in the fully qualified format. Users submitting a fully qualified username must enter the domain name before their username in the following format:
DOMAIN_NAME\username
For example, user Mary Smith (msmith) in Domain10 would enter the following:
Domain10\msmith
Another reason to provide the username in the format shown above is if a user is included in more than one domain. In this case, the privileges assigned upon authentication will be those associated with the account in the first domain with a matching username and password. This also illustrates the importance of removing usernames from a domain when the privileges associated with the user are no longer required.
Tip
Note
If you do not specify a domain name when typing the username, CiscoSecure ACS submits the username to the Windows by way of the Windows remote agent. If Windows does not find the username in its local domain database, it then checks all trusted domains. If the Windows remote agent runs on a member server and the username is not found in trusted domains, Windows also checks its local accounts database. Windows attempts to authenticate a user with the first occurrence of the username that it finds.
Note
Use of the Domain List is not required to support Windows authentication, but it can alleviate authentication failures caused by non-domain-qualified usernames. If you have configured the Domain List in the Windows User Database Configuration page of the External User Databases section, CiscoSecure ACS submits the username and password to each domain in the list in a fully qualified format until it successfully authenticates the user. If CiscoSecure ACS has tried each domain listed in the Domain List or if no trusted domains have been configured in the Domain List, CiscoSecure ACS stops attempting to authenticate the user and does not grant that user access.
Note
EAP and Windows Authentication
This section provides information about Windows-specific EAP features that you can configure on the Windows User Database Configuration page.
This section contains the following topics:
•
•
EAP-TLS Domain Stripping
If you use Windows Active Directory to authenticate users with EAP-TLS, CiscoSecure ACS enables you to strip the domain name from the username stored in the Subject Alternative Name field of the user certificate. Performing domain name stripping can speed EAP-TLS authentication when the domain that must authenticate a user is not the domain represented in the SAN field.
For example, a user's SAN field may contain "jsmith@corporation.com" but jsmith may need to authenticate using the domain controller for a subdomain named "engineering". Stripping "@corporation.com" from the username eliminates the needless attempt at authenticating jsmith against the corporation.com domain controller. Without stripping the domain name, only after jsmith cannot be found in corporation.com will CiscoSecure ACS use the Domain List and find the user in the engineering domain. The additional delay could be several seconds. For more information about the Domain List, see Windows Authentication.
You can enable EAP-TLS domain name stripping on the Windows User Database Configuration page.
Machine Authentication
CiscoSecure ACS supports the authentication of computers running Microsoft Windows operating systems that support EAP computer authentication, such as Windows XP with Service Pack 1. Machine authentication, also called computer authentication, allows networks services only for computers known to Active Directory. This is especially useful for wireless networks, where unauthorized users outside the physical premises of your workplace can access your wireless access points.
When machine authentication is enabled, there are three different types of authentications. Upon starting up a computer, the authentications occur in the following order:
1.
2.
Tip
3.
Note
CiscoSecure ACS supports both EAP-TLS and PEAP(EAP-MSCHAPv2) for machine authentication. You can enable each separately on the Windows User Database Configuration page, which allows a mix of computers authenticating with EAP-TLS or with PEAP(EAP-MSCHAPv2). Microsoft operating systems that perform machine authentication may limit the user authentication protocol to the same protocol used for machine authentication. For more information about Microsoft operating systems and machine authentication, see Microsoft Windows and Machine Authentication.
The Unknown User Policy supports machine authentication. Computers previously unknown to CiscoSecure ACS are handled similarly to users. If the Unknown User Policy is enabled and an Active Directory external user database is included on the Selected Databases list on the Configure Unknown User Policy page, machine authentication succeeds, provided that the machine credentials presented to Active Directory are valid.
On a computer configured to perform machine authentication, machine authentication occurs when the computer started. Provided that the AAA client sends RADIUS accounting data to CiscoSecure ACS, when a computer is started and before a user logs in on that computer, the computer appears on the Logged-In Users List in the Reports and Activity section. Once user authentication begins, the computer no longer appears on the Logged-In Users List.
PEAP-based machine authentication uses PEAP(EAP-MSCHAPv2) and the password for the computer established automatically when it was added to the Microsoft Windows domain. The computer sends its name as the username and the format is:
host/computer.domain
where computer is the name of the computer and domain is the domain the computer belongs to. The domain segment may include subdomains, too, if they are used, so that the format may be:
host/computer.subdomain.domain
The usernames of computers authenticated must appear in the CiscoSecure user database. If you enable unknown user processing, CiscoSecure ACS adds them automatically once they authenticate successfully. During authentication, the domain name is not used.
EAP-TLS-based machine authentication uses EAP-TLS to authenticate the computer using a client certificate. The certificate used by the computer can be one installed automatically when the computer was added to the domain or one that was added to the local machine storage later. As with PEAP-based machine authentication, the computer name must appear in the CiscoSecure user database in the format contained in the computer client certificate and the user profile corresponding to the computer name must be configured to authenticate using the Windows external user database. If you enable unknown user processing, CiscoSecure ACS adds the computer names to the CiscoSecure user database automatically once they authenticate successfully. It also automatically configures the user profiles created to use the external user database that the user was found in. For machine authentication, this will always be the Windows external user database.
Microsoft Windows and Machine Authentication
CiscoSecure ACS supports machine authentication with Active Directory in Windows 2000. To enable machine authentication support in Windows 2000 Active Directory you must:
•
•
Client operating systems supporting machine authentication are:
•
•
–
–
The following list describes the essential details of enabling machine authentication on a client computer with a Cisco Aironet 350 wireless adapter. For more information about enabling machine authentication in Microsoft Windows operating systems, please refer to Microsoft documentation.
1.
2.
3.
–
–
4.
a.
b.
c.
d.
e.
5.
a.
b.
c.
d.
e.
If you have a Microsoft certification authority server configured on the domain controller, you can configure a policy in Active Directory to produce a client certificate automatically when a computer is added to the domain. For more information, see Microsoft Knowledge Base Article 313407, HOW TO: Create Automatic Certificate Requests with Group Policy in Windows.
Machine Access Restrictions
You can use the machine access restrictions (MAR) feature as an additional means of controlling authorization for Windows-authenticated EAP-TLS and Microsoft PEAP users, based upon machine authentication of the computer used to access the network.
Note
When you enable the MAR feature, CiscoSecure ACS does the following:
•
•
–
–
Note
The MAR feature supports full EAP-TLS and Microsoft PEAP authentication, as well as resumed sessions for EAP-TLS and Microsoft PEAP and fast reconnections for Microsoft PEAP.
The MAR feature has the following limitations and requirements:
•
•
•
•
Enabling Machine Authentication
This procedure provides an overview of the detailed procedures required to configure CiscoSecure ACS to support machine authentication.
Note
Before You Begin
Windows authentication requires that you install at least one CiscoSecure ACS Remote Agent for Windows and complete the steps in Adding a Remote Agent. For information about installing CiscoSecure ACS Remote Agent for Windows, see Installation and Configuration Guide for CiscoSecure ACS Remote Agents.
To enable CiscoSecure ACS to perform machine authentication, follow these steps:
Step1
Note
Step2
Step3
•
•
CiscoSecure ACS allows you to complete this step only after you have successfully completed Step 1. For detailed steps, see Configuring Authentication Options.
Step4
•
•
•
Note
For detailed steps, see Configuring Windows Authentication.
Note
CiscoSecure ACS is ready to perform machine authentication for computers whose names exist in the CiscoSecure user database.
Step5
We strongly recommend that you use the Unknown User Policy. Most other means of adding all computer names in precisely the format required would be labor intensive and prone to human error.
Note
CiscoSecure ACS is ready to perform machine authentication for computers, regardless of whether the computer names exist in CiscoSecure user database.
User-Changeable Passwords with Windows User Databases
For network users who are authenticated by a Windows user database, CiscoSecure ACS supports user-changeable passwords upon password expiration. You can enable this feature in the MS-CHAP Settings and Windows EAP Settings tables on the Windows User Database Configuration page in the External User Databases section. Using this feature in your network requires the following:
•
•
•
•
–
–
When the conditions above are met and this feature is enabled, users receive a dialog box prompting them to change their passwords upon their first successful authentication after their passwords have expired. The dialog box is the same as presented to users by Windows when a user with an expired password accesses a network via a remote access server.
For more information about password aging support in CiscoSecure ACS, see Enabling Password Aging for Users in Windows Databases.
Preparing Users for Authenticating with Windows
Before using the Windows user database for authentication, follow these steps:
Step1
Step2
•
•
Step3
Selecting Remote Agents for Windows Authentication
Before you can configure CiscoSecure ACS to authenticate users with a Windows external user database, you must select a primary remote agent that is to deliver authentication requests to the Windows operating system. You may also select a secondary remote agent that CiscoSecure ACS is to use if the primary remote agent is unavailable.
Before You Begin
To complete this procedure, you must have already installed at least one CiscoSecure ACS Remote Agent for Windows and completed the steps in Adding a Remote Agent.
To select remote agents for Windows authentication, follow these steps:
Step1
Step2
CiscoSecure ACS displays a list of all possible external user database types.
Step3
The External User Database Configuration page appears.
Step4
The Windows User Database Configuration page appears.
Step5
The Windows Remote Agent Selection appears.
Step6
Step7
Note
Step8
CiscoSecure ACS saves the remote agent selections you made. The Windows User Database Configuration page appears.
Windows Authentication Configuration Options
The Windows Authentication Configuration page contains the following configuration options:
•
Note
Tip
•
Note
Caution
–
–
•
Note
For more information about Windows password changes, see Enabling Password Aging for Users in Windows Databases.
•
•
Performing domain name stripping can speed EAP-TLS authentication when the domain that must authenticate a user is not the domain represented in the SAN field. For example, a user's SAN field may contain "jsmith@corporation.com" but jsmith may need to authenticate using the domain controller for a subdomain named "engineering". Stripping "@corporation.com" from the username eliminates the needless attempt at authenticating jsmith against the corporation.com domain controller. Without stripping the domain name, only after jsmith cannot be found in corporation.com will CiscoSecure ACS use the Domain List and find the user in the engineering domain. The additional delay could be several seconds.
•
•
•
Note
•
Note
•
Note
Tip
Tip
•
Note
Configuring Windows Authentication
Before You Begin
To complete this procedure, you must have completed the steps in Selecting Remote Agents for Windows Authentication.
To configure Windows authentication, follow these steps:
Step1
Step2
CiscoSecure ACS displays a list of all possible external user database types.
Step3
The External User Database Configuration page appears.
Step4
The Windows User Database Configuration page appears.
Step5
The Windows Authentication Configuration page appears.
Step6
•
•
•
•
For information about the options on the Windows User Database Configuration page, see Windows Authentication Configuration Options.
Note
Step7
CiscoSecure ACS saves the Windows user database configuration you created. You can now add it to your Unknown User Policy or assign specific user accounts to use this database for authentication. For more information about the Unknown User Policy, see Unknown User Processing. For more information about configuring user accounts to authenticate using this database, see "User Management"
Generic LDAP
CiscoSecure ACS supports ASCII, PAP, EAP-TLS, PEAP(EAP-GTC), and EAP-FAST (phase two only) authentication via generic Lightweight Directory Access Protocol (LDAP) databases, such as Netscape Directory Services. Other authentication protocols are not supported with LDAP external user databases.
Note
CiscoSecure ACS supports group mapping for unknown users by requesting group membership information from LDAP user databases. For more information about group mapping for users authenticated with an LDAP user database, see Group Mapping by Group Set Membership.
Configuring CiscoSecure ACS to authenticate against an LDAP database has no effect on the configuration of the LDAP database. To manage your LDAP database, see your LDAP database documentation.
This section contains the following topics:
•
•
•
•
Cisco Secure ACS Authentication Process with a Generic LDAP User Database
CiscoSecure ACS forwards the username and password to an LDAP database using a TCP connection on a port that you specify. The LDAP database either passes or fails the authentication request from CiscoSecure ACS. Upon receiving the response from the LDAP database, CiscoSecure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the LDAP server.
CiscoSecure ACS grants authorization based on the CiscoSecure ACS group to which the user is assigned. While the group to which a user is assigned can be determined by information from the LDAP server, it is CiscoSecure ACS that grants authorization privileges.
Multiple LDAP Instances
You can create more than one LDAP configuration in CiscoSecure ACS. By creating more than one LDAP configuration with different IP address or port settings, you can configure CiscoSecure ACS to authenticate using different LDAP servers or using different databases on the same LDAP server. Each primary server IP address and port configuration, along with the secondary server IP address and port configuration, forms an LDAP instance that corresponds to one CiscoSecure ACS LDAP configuration instance.
CiscoSecure ACS does not require that each LDAP instance corresponds to a unique LDAP database. You can have more than one LDAP configuration set to access the same database. This is useful when your LDAP database contains more than one subtree for users or groups. Because each LDAP configuration supports only one subtree directory for users and one subtree directory for groups, you must configure separate LDAP instances for each user directory subtree and group directory subtree combination for which CiscoSecure ACS should submit authentication requests.
For each LDAP instance, you can add or leave it out of the Unknown User Policy. For more information, see Unknown User Processing.
For each LDAP instance, you can establish unique group mapping. For more information, see Group Mapping by Group Set Membership.
Multiple LDAP instances is also important when you use domain filtering. For more information, see Domain Filtering.
LDAP Organizational Units and Groups
LDAP groups do not need to have the same name as their corresponding CiscoSecure ACS groups. The LDAP group can be mapped to a CiscoSecure ACS group with any name you want to assign. For more information about how your LDAP database handles group membership, see your LDAP database documentation. For more information on LDAP group mappings and CiscoSecure ACS, see "User Group Mapping and Specification"
Domain Filtering
Using domain filtering, you can control which LDAP instance is used to authenticate a user based on domain-qualified usernames. Domain filtering is based on parsing the characters either at the beginning or end of a username submitted for authentication. Domain filtering provides you with greater control over the LDAP instance that CiscoSecure ACS submits any given user authentication request to. You also have control of whether usernames are submitted to an LDAP server with their domain qualifiers intact.
For example, when EAP-TLS authentication is initiated by a Windows XP client, CiscoSecure ACS receives the username in
username@domainnameformat. When PEAP authentication is initiated by a Cisco Aironet end-user client, CiscoSecure ACS receives the username without a domain qualifier. If both clients are to be authenticated with an LDAP database that stores usernames without domain qualifiers, CiscoSecure ACS can strip the domain qualifier. If separate user accounts are maintained in the LDAP database—both domain-qualified and non-domain-qualified user accounts—CiscoSecure ACS can pass usernames to the LDAP database without domain filtering.If you choose to make use of domain filtering, each LDAP configuration you create in CiscoSecure ACS can perform domain filtering in one of two ways:
•
With this option, each LDAP configuration is limited to one domain and to one type of domain qualification. You can specify whether CiscoSecure ACS strips the domain qualification before submitting the username to an LDAP server. If the LDAP server stores usernames in a domain-qualified format, you should not configure CiscoSecure ACS to strip domain qualifiers.
Limiting users to one domain is useful when the LDAP server stores usernames differently per domain, either by user context or by how the username is stored in CiscoSecure ACS—domain qualified or non-domain qualified. The end-user client or AAA client must submit the username to CiscoSecure ACS in a domain-qualified format, otherwise CiscoSecure ACS cannot determine the user's domain and does not attempt to authenticate the user with the LDAP configuration that uses this form of domain filtering.
•
CiscoSecure ACS supports both prefixed and suffixed domain qualifiers. A single LDAP configuration can attempt to strip both prefixed and suffixed domain qualifiers; however, you can only specify one delimiting character each for prefixed and suffixed domain qualifiers. To support more than one type of domain-qualifier delimiting character, you can create more than one LDAP configuration in CiscoSecure ACS.
Allowing usernames of any domain but stripping domain qualifiers is useful when the LDAP server stores usernames in a non-domain qualified format but the AAA client or end-user client submits the username to CiscoSecure ACS in a domain-qualified format.
Note
LDAP Failover
CiscoSecure ACS supports failover between a primary LDAP server and secondary LDAP server. In the context of LDAP authentication with CiscoSecure ACS, failover applies when an authentication request fails because CiscoSecure ACS could not connect to an LDAP server, such as when the server is down or is otherwise unreachable by CiscoSecure ACS. To use this feature, you must define the primary and secondary LDAP servers on the LDAP Database Configuration page. Also, you must select the On Timeout Use Secondary check box. For more information about configuring an LDAP external user database, see Configuring a Generic LDAP External User Database.
If the On Timeout Use Secondary check box is selected, and if the first LDAP server that CiscoSecure ACS attempts to contact cannot be reached, CiscoSecure ACS always attempts to contact the other LDAP server. The first server CiscoSecure ACS attempts to contact may not always be the primary LDAP server. Instead, the first LDAP server that CiscoSecure ACS attempts to contact depends on the previous LDAP authentication attempt and on the value specified in the Failback Retry Delay box.
Successful Previous Authentication with the Primary LDAP Server
If, on the previous LDAP authentication attempt, CiscoSecure ACS successfully connected to the primary LDAP server, CiscoSecure ACS attempts to connect to the primary LDAP server. If CiscoSecure ACS cannot connect to the primary LDAP server, CiscoSecure ACS attempts to connect to the secondary LDAP server.
If CiscoSecure ACS cannot connect with either LDAP server, CiscoSecure ACS stops attempting LDAP authentication for the user. If the user is an unknown user, CiscoSecure ACS tries the next external user database listed in the Unknown User Policy list. For more information about the Unknown User Policy list, see Unknown User Processing.
Unsuccessful Previous Authentication with the Primary LDAP Server
If, on the previous LDAP authentication attempt, CiscoSecure ACS could not connect to the primary LDAP server, whether CiscoSecure ACS first attempts to connect to the primary server or secondary LDAP server for the current authentication attempt depends on the value in the Failback Retry Delay box. If the Failback Retry Delay box is set to 0 (zero), CiscoSecure ACS always attempts to connect to the primary LDAP server first. And if CiscoSecure ACS cannot connect to the primary LDAP server, CiscoSecure ACS then attempts to connect to the secondary LDAP server.
If the Failback Retry Delay box is set to a number other than zero, CiscoSecure ACS determines how many minutes have passed since the last authentication attempt using the primary LDAP server occurred. If more minutes have passed than the value specified in the Failback Retry Delay box, CiscoSecure ACS attempts to connect to the primary LDAP server first. And if CiscoSecure ACS cannot connect to the primary LDAP server, CiscoSecure ACS then attempts to connect to the secondary LDAP server.
If fewer minutes have passed than the value specified in the Failback Retry Delay box, CiscoSecure ACS attempts to connect to the secondary LDAP server first. And if CiscoSecure ACS cannot connect to the secondary LDAP server, CiscoSecure ACS then attempts to connect to the primary LDAP server.
If CiscoSecure ACS cannot connect to either LDAP server, CiscoSecure ACS stops attempting LDAP authentication for the user. If the user is an unknown user, CiscoSecure ACS tries the next external user database listed in the Unknown User Policy list. For more information about the Unknown User Policy list, see Unknown User Processing.
LDAP Configuration Options
The LDAP Database Configuration page contains many options, presented in three tables:
•
This table contains the following options:
–
–
