-
User Guide for Cisco Secure ACS Solution Engine Version 3.3
-
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
-
Network Admission Control
-
Unknown User Policy
-
User Group Mapping and Specification
-
Troubleshooting
-
TACACS+ Attribute-Value Pairs
-
RADIUS Attributes
-
VPDN Processing
-
RDBMS Synchronization Import Definitions
-
Internal Architecture
-
Feedback
Table Of Contents
Authenticating with External User Databases
External User Database Authentication Process
What's Supported with Windows User Databases
Authentication with Windows User Databases
Windows Dial-up Networking Clients
Windows Dial-up Networking Clients with a Domain Field
Windows Dial-up Networking Clients without a Domain Field
Usernames and Windows Authentication
Username Formats and Windows Authentication
Non-domain-qualified Usernames
EAP and Windows Authentication
Microsoft Windows and Machine Authentication
Enabling Machine 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
Successful Previous Authentication with the Primary LDAP Server
Unsuccessful Previous Authentication with the Primary LDAP Server
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
Cisco Secure ACS Solution Engine authenticates users against one of several possible databases, including its internal database. You can configure Cisco Secure 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 Cisco Secure 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, Cisco Secure 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 Cisco Secure 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.
For users authenticated using the CiscoSecure user database, Cisco Secure ACS stores user passwords in an encrypted format, using RC2 encryption with a 40-bit key. For users authenticated with external user databases, Cisco Secure ACS does not store passwords in the CiscoSecure user database.
Unless you have configured Cisco Secure ACS to authenticate users with an external user database, Cisco Secure 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 Cisco Secure ACS Solution Engine. 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 Cisco Secure ACS user group. For more information about group mapping, see "User Group Mapping and Specification".
•
•
About External User Databases
You can configure Cisco Secure ACS to forward authentication of users to one external user database or more. Support for external user databases means that Cisco Secure 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, Cisco Secure 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, Cisco Secure 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 Cisco Secure ACS to interact with an external user database, Cisco Secure ACS requires an API for the third-party authentication source. The Cisco Secure ACS communicates with the external user database using the API. For Windows, you must have installed and configured Cisco Secure 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 Cisco Secure ACS Solution Engine.
For token servers, the RADIUS interface of the token server function as the third-party API.
Authenticating with External User Databases
Authenticating users with an external user database requires more than configuring Cisco Secure 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 Cisco Secure ACS to authenticate any users with that database.
After you have configured Cisco Secure ACS to communicate with an external user database, you can configure Cisco Secure 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 Cisco Secure ACS group and thereby receive the applicable access profile.
•
You can also configure Cisco Secure ACS with both methods above; these two methods are not mutually exclusive.
External User Database Authentication Process
When Cisco Secure 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 Cisco Secure ACS. Upon receiving the response from the external user database, Cisco Secure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the external user database. Figure 13-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, Cisco Secure ACS uses TCP connections. For Windows user databases, Cisco Secure ACS uses the authentication API provided in the Windows operating system. Cisco Secure ACS communicates with token servers using RADIUS.
For more information, see the section regarding the database type you are interested in.
Windows User Database
You can configure Cisco Secure ACS to use a Windows user database to authenticate users.
This section contains the following topics:
•
•
•
–
–
•
–
–
•
–
–
•
•
•
•
•
What's Supported with Windows User Databases
Cisco Secure ACS supports the use of Windows external user databases for the following features:
•
Note
•
•
•
•
•
Authentication with Windows User Databases
Cisco Secure 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 Cisco Secure ACS. Upon receiving the response from the Windows user database, the remote agent forwards the response to Cisco Secure ACS, which instructs the requesting AAA client to grant or deny the user access, depending upon the response from the Windows user database.
Cisco Secure ACS grants authorization based on the Cisco Secure 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 Cisco Secure 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 Cisco Secure 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
Cisco Secure 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, Cisco Secure ACS can authenticate users whose accounts reside in the other domain. Cisco Secure ACS can also reference the "Grant dialin permission to user" setting across trusted domains.
Cisco Secure ACS can take advantage of indirect trusts for Windows authentication. Consider the example of Windows domains A, B, and C, where the remote agent runs on a 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 Windows NT, 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
•
Usernames and Windows Authentication
This section contains the following topics:
•
•
Username Formats and Windows Authentication
Cisco Secure ACS supports Windows authentication for usernames in a variety of formats. When Cisco Secure ACS attempts Windows authentication, it first determines the username format and submits the username to Windows in the applicable manner. To implement reliable Windows authentication with Cisco Secure ACS, you need to understand how Cisco Secure ACS determines username format, how it supports for each of these formats, and how the types of support are related.
To determine the format of a username submitted for Windows authentication, Cisco Secure ACS searches the username for the presence of the following two special characters:
•
•
Based upon the presence and position of these two characters in the username, Cisco Secure ACS determines username format as follows:
1.
2.
–
–
For more information, see Domain-Qualified Usernames.
3.
–
–
–
–
–
For more information, see UPN Usernames.
Non-domain-qualified Usernames
Cisco Secure ACS supports Windows authentication of usernames that are not domain qualified, provided the username does not contain an "at" character. Users with "at" characters in their usernames must either submit the username in UPN format or in a domain-qualified format. Examples of non-domain-qualified usernames are cyril.yang and msmith.
In Windows environments with multiple domains, authentication results with non-domain-qualified usernames can vary. This is because Windows, not Cisco Secure ACS, determines which domains are used to authenticate a non-domain-qualified username. If Windows does not find the username in its local domain database, it then checks all trusted domains. If Cisco Secure ACS 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.
When Windows authentication for a non-domain-qualified username succeeds, the privileges assigned upon authentication will be those associated with the Windows user account in the first domain with a matching username and password. This also illustrates the importance of removing usernames from a domain when the user account is no longer needed.
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, Cisco Secure ACS submits the username and password to each domain in the list in a domain-qualified format until it successfully authenticates the user. If Cisco Secure ACS has tried each domain listed in the Domain List or if no trusted domains have been configured in the Domain List, Cisco Secure ACS stops attempting to authenticate the user and does not grant that user access.
Note
Domain-Qualified Usernames
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. Authentication of a domain-qualified username is directed to a specific domain rather than depending upon Windows to attempt authentication with the correct domain or upon using the Domain List to direct Cisco Secure ACS to submit the username repeatedly in a domain-qualified format.
Domain-qualified usernames have the following format:
DOMAIN\userFor example, the domain-qualified username for user Mary Smith (msmith) in Domain10 would be Domain10\msmith.
For usernames containing an "at" character, such as cyril.yang@central-office, using a domain-qualified username format is required. For example, MAIN\cyril.yang@central-office. If a username containing an "at" character is received in a non-domain-qualified format, Cisco Secure ACS perceives it as a username in UPN format. For more information, see UPN Usernames.
UPN Usernames
Cisco Secure ACS supports authentication of usernames in User Principal Name (UPN) format, such as cyril.yang@example.com or cyril.yang@central-office@example.com.
If the authentication protocol used is EAP-TLS, by default, Cisco Secure ACS submits the username to Windows in UPN format; however, you can configure Cisco Secure ACS to strip from the username all characters after and including the last "at" character (@). For more information, see EAP-TLS Domain Stripping.
For all other authentication protocols that it can support with Windows databases, Cisco Secure ACS submits to Windows the username stripped of all characters after and including the last "at" character (@). This behavior allows for usernames that contain an "at" character. For example:
•
•
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, Cisco Secure 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 Cisco Secure 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 Non-domain-qualified Usernames.
You can enable EAP-TLS domain name stripping on the Windows User Database Configuration page.
Note
Machine Authentication
Cisco Secure 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:
•
•
Tip
•
Note
Cisco Secure 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 Cisco Secure 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 Cisco Secure 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.domainwhere 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.domainThe usernames of computers authenticated must appear in the CiscoSecure user database. If you enable unknown user processing, Cisco Secure 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, Cisco Secure 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
Cisco Secure ACS supports machine authentication with Active Directory in Windows 2000. To enable machine authentication support in Windows 2000 Active Directory you must:
•
•
Modify Dial-In Permissions for Computers That Use Wireless Networking.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. When you enable the MAR feature, Cisco Secure 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 Cisco Secure ACS to support machine authentication.
Note
Before You Begin
Windows authentication requires that you install at least one Cisco Secure ACS Remote Agent for Windows and complete the steps in Adding a Remote Agent. For information about installing Cisco Secure ACS Remote Agent for Windows, see Installation and Configuration Guide for Cisco Secure ACS Remote Agents.
To enable Cisco Secure ACS to perform machine authentication, follow these steps:
Step 1
Note
Step 2
Step 3
•
•
Cisco Secure ACS allows you to complete this step only after you have successfully completed Step 1. For detailed steps, see Configuring Authentication Options.
Step 4
•
•
•
Note
For detailed steps, see Configuring Windows Authentication.
Note
Cisco Secure ACS is ready to perform machine authentication for computers whose names exist in the CiscoSecure user database.
Step 5
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
Cisco Secure 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, Cisco Secure 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 Cisco Secure 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:
Step 1
Step 2
•
•
Step 3
Selecting Remote Agents for Windows Authentication
Before you can configure Cisco Secure 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 Cisco Secure 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 Cisco Secure ACS Remote Agent for Windows and completed the steps in Adding a Remote Agent.
To select remote agents for Windows authentication, follow these steps:
Step 1
Step 2
Cisco Secure ACS displays a list of all possible external user database types.
Step 3
The External User Database Configuration page appears.
Step 4
The Windows User Database Configuration page appears.
Step 5
The Windows Remote Agent Selection appears.
Step 6
Step 7
Note
Step 8
Cisco Secure 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 Cisco Secure ACS use the Domain List and find the user in the engineering domain. The additional delay could be several seconds.
•
•
•
Note
•
Note
Tip
•
Note
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:
Step 1
Step 2
Cisco Secure ACS displays a list of all possible external user database types.
Step 3
The External User Database Configuration page appears.
Step 4
The Windows User Database Configuration page appears.
Step 5
The Windows Authentication Configuration page appears.
Step 6
•
•
•
•
For information about the options on the Windows User Database Configuration page, see Windows Authentication Configuration Options.
Note
Step 7
Cisco Secure 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 About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".
Generic LDAP
Cisco Secure 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
Cisco Secure 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 Cisco Secure 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
Cisco Secure 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 Cisco Secure ACS. Upon receiving the response from the LDAP database, Cisco Secure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the LDAP server.
Cisco Secure ACS grants authorization based on the Cisco Secure 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 Cisco Secure ACS that grants authorization privileges.
Multiple LDAP Instances
You can create more than one LDAP configuration in Cisco Secure ACS. By creating more than one LDAP configuration with different IP address or port settings, you can configure Cisco Secure 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 Cisco Secure ACS LDAP configuration instance.
Cisco Secure 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 Cisco Secure 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 About Unknown User Authentication.
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 Cisco Secure ACS groups. The LDAP group can be mapped to a Cisco Secure 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 Cisco Secure 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 Cisco Secure 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, Cisco Secure ACS receives the username in username@domainname format. When PEAP authentication is initiated by a Cisco Aironet end-user client, Cisco Secure 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, Cisco Secure 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—Cisco Secure 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 Cisco Secure 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 Cisco Secure 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 Cisco Secure 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 Cisco Secure ACS—domain qualified or non-domain qualified. The end-user client or AAA client must submit the username to Cisco Secure ACS in a domain-qualified format, otherwise Cisco Secure 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.
•
Cisco Secure 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 Cisco Secure 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 Cisco Secure ACS in a domain-qualified format.
Note
LDAP Failover
Cisco Secure ACS supports failover between a primary LDAP server and secondary LDAP server. In the context of LDAP authentication with Cisco Secure ACS, failover applies when an authentication request fails because Cisco Secure ACS could not connect to an LDAP server, such as when the server is down or is otherwise unreachable by Cisco Secure 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 Cisco Secure ACS attempts to contact cannot be reached, Cisco Secure ACS always attempts to contact the other LDAP server. The first server Cisco Secure ACS attempts to contact may not always be the primary LDAP server. Instead, the first LDAP server that Cisco Secure 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, Cisco Secure ACS successfully connected to the primary LDAP server, Cisco Secure ACS attempts to connect to the primary LDAP server. If Cisco Secure ACS cannot connect to the primary LDAP server, Cisco Secure ACS attempts to connect to the secondary LDAP server.
If Cisco Secure ACS cannot connect with either LDAP server, Cisco Secure ACS stops attempting LDAP authentication for the user. If the user is an unknown user, Cisco Secure ACS tries the next external user database listed in the Unknown User Policy list. For more information about the Unknown User Policy list, see About Unknown User Authentication.
Unsuccessful Previous Authentication with the Primary LDAP Server
If, on the previous LDAP authentication attempt, Cisco Secure ACS could not connect to the primary LDAP server, whether Cisco Secure 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), Cisco Secure ACS always attempts to connect to the primary LDAP server first. And if Cisco Secure ACS cannot connect to the primary LDAP server, Cisco Secure ACS then attempts to connect to the secondary LDAP server.
If the Failback Retry Delay box is set to a number other than zero, Cisco Secure 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, Cisco Secure ACS attempts to connect to the primary LDAP server first. And if Cisco Secure ACS cannot connect to the primary LDAP server, Cisco Secure 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, Cisco Secure ACS attempts to connect to the secondary LDAP server first. And if Cisco Secure ACS cannot connect to the secondary LDAP server, Cisco Secure ACS then attempts to connect to the primary LDAP server.
If Cisco Secure ACS cannot connect to either LDAP server, Cisco Secure ACS stops attempting LDAP authentication for the user. If the user is an unknown user, Cisco Secure ACS tries the next external user database listed in the Unknown User Policy list. For more information about the Unknown User Policy list, see About Unknown User Authentication.
LDAP Configuration Options
The LDAP Database Configuration page contains many options, presented in three tables:
•
This table contains the following options:
–
–
–
Note
–
For example, if the domain name is "mydomain", the delimiting character is "@", and Suffix is selected in the "Qualified by" list, the Domain box should contain "@mydomain". If the domain name is "yourdomain", the delimiting character is "\", and Prefix is selected in the "Qualified by" list, the Domain box should contain "yourdomain\"
–
–
–
For example, if the delimiter character is "\" and the username is "DOMAIN\jwiedman", Cisco Secure ACS submits "jwiedman" to an LDAP server.
–
For example, if the delimiter character is "@" and the username is "jwiedman@domain", Cisco Secure ACS submits "jwiedman" to an LDAP server.
•
–
ou=organizational unit[,ou=next organizational unit]o=corporation.comIf the tree containing users is the base DN, type:
o=corporation.comor
dc=corporation,dc=comas applicable to your LDAP configuration. For more information, refer to your LDAP database documentation.
–
ou=organizational unit[,ou=next organizational unit]o=corporation.comIf the tree containing groups is the base DN, type:
o=corporation.comor
dc=corporation,dc=comas applicable to your LDAP configuration. For more information, refer to your LDAP database documentation.
–
–
–
–
–
–
–
–
•
–
–
–
–
–
To perform secure authentication using SSL, you must provide a cert7.db certificate database file. Cisco Secure ACS requires a certificate database so that it can establish the SSL connection. Since the certificate database must be local to the Cisco Secure ACS Solution Engine, you must use FTP to transfer the certificate database to Cisco Secure ACS.
Cisco Secure ACS requires a cert7.db certificate database file for each LDAP server you configure. For example, to support users distributed in multiple LDAP trees, you could configure two LDAP instances in Cisco Secure ACS that would communicate with the same LDAP servers. Each LDAP instance would have a primary and a secondary LDAP server. Even though the two LDAP configurations share the same primary server, each LDAP configuration requires that you download a certificate database file to Cisco Secure ACS.
Note
–
adducer id,[ou=organizational unit,][ou=next organizational unit]o=organizationwhere user id is the username, organizational unit is the last level of the tree, and next organizational unit is the next level up the tree.
For example:
uid=joesmith,ou=members,ou=administrators,o=ciscoYou can use anonymous credentials for the administrator username if the LDAP server is configured to make the group name attribute visible in searches by anonymous credentials. Otherwise, you must specify an administrator username that permits the group name attribute to be visible to searches.
Note
–
Configuring a Generic LDAP External User Database
Creating a generic LDAP configuration provides Cisco Secure ACS information that enables it to pass authentication requests to an LDAP database. This information reflects the way you have implemented your LDAP database and does not dictate how your LDAP database is configured or functions. For information about your LDAP database, refer to your LDAP documentation.
To configure Cisco Secure ACS to use the LDAP User Database, follow these steps:
Step 1
Step 2
Cisco Secure ACS displays a list of all possible external user database types.
Step 3
Note
If no LDAP database configuration exists, only the Database Configuration Creation table appears. Otherwise, in addition to the Database Configuration Creation table, the External User Database Configuration table appears.
Step 4
a.
b.
c.
Cisco Secure ACS lists the new configuration in the External User Database Configuration table.
Step 5
Note
Step 6
Caution
Step 7
Step 8
Note
a.
b.
For example, if you want this LDAP configuration to authenticate usernames that begin with a specific domain name, select Prefix. If you want this LDAP configuration to authenticate usernames that end with a specific domain name, select Suffix.
c.
Only one domain name is supported per LDAP configuration. You can type up to 512 characters.
d.
e.
Step 9
Note
a.
b.
c.
Step 10
Step 11
Step 12
Note
Step 13
Note
Step 14
Step 15
Step 16
Step 17
Step 18
Step 19
Note
Step 20
Note
a.
b.
c.
d.
Note
e.
Note
f.
uid=user id,[ou=organizational unit,] [ou=next organizational unit]o=organizationwhere user id is the username
organizational unit is the last level of the tree
next organizational unit is the next level up the tree.
Tip
For more information, refer to your LDAP database documentation.
g.
Step 21
Cisco Secure ACS saves the generic LDAP 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 About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".
Downloading a Certificate Database
Before You Begin
The database must be a cert7.db certificate database file generated by a Netscape web browser. No other filename is supported. For information about generating a cert7.db file, refer to Netscape documentation.
To download a certificate database for a primary or a secondary LDAP server, follow these steps:
Note
Step 1
a.
Note
b.
Note
Step 2
Note
Step 3
Step 4
Step 5
For example, if the cert7.db file is located in c:\ACS-files\LDAPcertdb and the user provided in the Login box starts its FTP sessions in c:\, you would type ACS-files\LDAPcertdb.
The Directory box accepts a maximum of 512 characters.
Step 6
Cisco Secure ACS downloads the cert7.db file from the FTP server. The LDAP Database Configuration page appears.
Novell NDS Database
Cisco Secure ACS supports user authentication with Novell NetWare Directory Services (NDS) servers.
This section contains the following topics:
•
•
•
About Novell NDS User Databases
To use NDS authentication with a Cisco Secure ACS Solution Engine, you must have a Novell NDS database that is configured to use standard LDAP.
Note
Cisco Secure ACS Solution Engine supports ASCII, PAP, EAP-TLS, PEAP(EAP-GTC), and EAP-FAST (phase two only) authentication with Novell NetWare Directory Services (NDS) servers. Other authentication protocols are not supported with Novell NDS external user databases.
Note
For users to authenticate against a Novell NDS database, Cisco Secure ACS must be correctly configured to recognize the Novell NDS structure. Cisco Secure ACS supports up to twenty NDS servers. For a user to authenticate against a Novell NDS context, the applicable user object must exist in one of the contexts provided and the user password must be able to log the name into the tree. If you enable subtree searching, authentication can succeed if the user object is in a subtree of one of the contexts provided.
Cisco Secure ACS supports group mapping for unknown users by requesting group membership information from Novell NDS user databases. For more information about group mapping for users authenticated with a Novell NDS user database, see Group Mapping by Group Set Membership.
Note
Configuring Cisco Secure ACS to authenticate against an NDS database does not affect the configuration of the NDS database. To manage your NDS database, refer to your NDS database documentation.
User Contexts
You must supply one or more contexts when you configure Cisco Secure ACS to authenticate with an NDS database; however, users can supply an additional portion of the full context that defines their fully qualified usernames. In other words, if none of the contexts in the list of contexts contains a username submitted for authentication, the username must specify exactly how they are subordinate to the contexts in the list of contexts. The user specifies the manner in which a username is subordinate to a context by providing the additional context information needed to uniquely identify the user in the NDS database.
Consider the following example tree:
[Root] whose treename=ABC OU=ABC-Company OU=sales CN=Agamemnon OU=marketing CN=Odysseus OU=marketing-research CN=Penelope OU=marketing-product CN=TelemachusIf the context list configured in Cisco Secure ACS were:
o=ABC-Company,ou=sales.o=ABC-CompanyAgamemnon would successfully authenticate if he submitted "Agamemnon" as his username. If he submitted "Agamemnon.sales", authentication would fail.
Table 13-1 lists the users given in the example tree and the username with context that would allow each user to authenticate successfully.
Novell NDS External User Database Options
You create and maintain configurations for Novell NDS database authentication on the NDS Authentication Support page in Cisco Secure ACS. This page enables you to add a configuration for a Novell NDS host, change existing host configurations, and delete existing host configurations in a single submission to the Cisco Secure ACS web server. Cisco Secure ACS displays information for each host configured, plus a blank form for creating a host. The configuration items presented for each host are as follows:
•
•
•
•
Note
•
•
uid=admin.ou=Chicago.o=CorporationYou can use anonymous credentials for the administrator username if the Novell NDS server is configured to make the group name attribute visible in searches by anonymous credentials. Otherwise, you must specify an administrator username that permits the group name attribute to be visible to searches.
Note
•
•
ou=Engineering.ou=Chicago.o=Corporation,ou=Marketing.ou=Chicago.o=CorporationYou do not need to add users in the Context List box.
Note
•
Configuring a Novell NDS External User Database
Creating an Novell NDS database configuration is a process that provides Cisco Secure ACS information that enables it to pass authentication requests to an NDS database. This information reflects the way you have implemented your NDS database and does not dictate how your NDS database is configured or functions. For information about your NDS database, refer to your Novell NDS documentation.
Tip
To configure Novell NDS authentication, follow these steps:
Step 1
Step 2
Step 3
Cisco Secure ACS lists all possible external user database types.
Step 4
If no Novell NDS database has yet been configured, the Database Configuration Creation page appears. Otherwise, the External User Database Configuration page appears.
Step 5
a.
b.
c.
Cisco Secure ACS lists the new configuration in the External User Database Configuration table.
Step 6
Caution
The NDS Authentication Support page appears. The NDS Authentication Support page enables you to add a configuration for a Novell NDS host, change existing host configurations, and delete existing host configurations.
For more information about the content of the NDS Authentication Support page, see Novell NDS External User Database Options.
Step 7
Note
Step 8
Note
Step 9
Step 10
Cisco Secure ACS saves the NDS configuration you created. You can 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 About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".
LEAP Proxy RADIUS Server Database
For Cisco Secure ACS-authenticated users accessing your network via Cisco Aironet devices, Cisco Secure ACS supports ASCII, PAP, MS-CHAP (versions 1 and 2), LEAP, and EAP-FAST (phase zero and phase two) authentication with a proxy RADIUS server. Other authentication protocols are not supported with LEAP Proxy RADIUS Server databases.
Note
Cisco Secure ACS uses MS-CHAP version 1 for LEAP Proxy RADIUS Server authentication. To manage your proxy RADIUS database, refer to your RADIUS database documentation.
Lightweight extensible authentication protocol (LEAP) proxy RADIUS server authentication allows you to authenticate users against existing Kerberos databases that support MS-CHAP authentication. You can use the LEAP Proxy RADIUS Server database to authenticate users with any third-party RADIUS server that supports MS-CHAP authentication.
Note
Cisco Secure ACS supports RADIUS-based group specification for users authenticated by LEAP Proxy RADIUS Server databases. RADIUS-based group specification overrides group mapping. For more information, see RADIUS-Based Group Specification.
Cisco Secure ACS supports group mapping for unknown users authenticated by LEAP Proxy RADIUS Server databases. Group mapping is only applied to an unknown user if RADIUS-based group specification did not occur. For more information about group mapping users authenticated by a LEAP Proxy RADIUS Server database, see Group Mapping by External User Database.
Configuring a LEAP Proxy RADIUS Server External User Database
You should install and configure your proxy RADIUS server before configuring Cisco Secure ACS to authenticate users with it. For information about installing the proxy RADIUS server, refer to the documentation included with your RADIUS server.
To configure LEAP proxy RADIUS authentication, follow these steps:
Step 1
Step 2
Cisco Secure ACS displays a list of all possible external user database types.
Step 3
If no LEAP Proxy RADIUS Server configuration exists, only the Database Configuration Creation table appears. Otherwise, in addition to the Database Configuration Creation table, the External User Database Configuration table appears.
Step 4
a.
b.
c.
Cisco Secure ACS lists the new configuration in the External User Database Configuration table.
Step 5
Note
Step 6
Step 7
•
•
•
•
•
•
•
Note
Step 8
Cisco Secure ACS saves the proxy RADIUS token server database configuration you created. You can 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 About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".
Token Server User Databases
Cisco Secure ACS supports the use of token servers for the increased security provided by one-time passwords (OTPs).
This section contains the following topics:
•
•
•
About Token Servers and Cisco Secure ACS
Cisco Secure ACS provides ASCII, PAP, and PEAP(EAP-GTC) authentication using token servers. Other authentication protocols are not supported with token server databases.
Note
Cisco Secure ACS Solution Engine supports token servers that are compliant with IETF RFC 2865. Requests from the AAA client are first sent to Cisco Secure ACS, which then acts as a RADIUS client to the token server. Rather than using the proprietary API of the vendor, Cisco Secure ACS sends standard RADIUS authentication requests to the RADIUS authentication port on the token server.
Cisco Secure ACS provides a means for specifying a user group assignment in the RADIUS response from the RADIUS-enabled token server. Group specification always takes precedence over group mapping. For more information, see RADIUS-Based Group Specification.
Cisco Secure ACS also supports mapping users authenticated by a RADIUS-enabled token server to a single group. Group mapping only occurs if group specification does not occur. For more information, see Group Mapping by External User Database.
Token Servers and ISDN
Cisco Secure ACS supports token caching for ISDN terminal adapters and routers. One inconvenience of using token cards for OTP authentication with ISDN is that each B channel requires its own OTP. Therefore, a user must enter at least 2 OTPs, plus any other login passwords, such as those for Windows networking. If the terminal adapter supports the ability to turn on and off the second B channel, users might have to enter many OTPs each time the second B channel comes into service.
Cisco Secure ACS caches the token to help make the OTPs easier for users. This means that if a token card is being used to authenticate a user on the first B channel, a specified period can be set during which the second B channel can come into service without requiring the user to enter another OTP. To lessen the risk of unauthorized access to the second B channel, you can limit the time the second B channel is up. Furthermore, you can configure the second B channel to use the CHAP password specified during the first login to further lessen the chance of a security problem. When the first B channel is dropped, the cached token is erased.
Token Server RADIUS Authentication Request and Response Contents
When Cisco Secure ACS forwards an authentication request to a RADIUS-enabled token server, the RADIUS authentication request contains the following attributes:
•
•
•
•
•
Cisco Secure ACS expects to receive one of the following three responses:
•
•
•
–
–
Configuring a RADIUS Token Server External User Database
Use this procedure to configure a token server external user databases in Cisco Secure ACS.
Before You Begin
You should install and configure your RADIUS-enabled token server before configuring Cisco Secure ACS to authenticate users with it. For information about installing the RADIUS-enabled token server, refer to the documentation included with your token server.
To configure Cisco Secure ACS to authenticate users with a token server, follow these steps:
Step 1
Step 2
Cisco Secure ACS displays a list of all possible external user database types.
Step 3
The Database Configuration Creation table appears. If at least one configuration exists, the External User Database Configuration table also appears.
Step 4
a.
b.
c.
Cisco Secure ACS lists the new configuration in the External User Database Configuration table.
Step 5
Note
Step 6
Step 7
•
•
•
•
Note
•
•
•
Note
Step 8
a.
For example, if you type "Enter your PassGo token" in the Prompt box, users receive an "Enter your PassGo token" prompt rather than a password prompt.
Note
b.
For example, if the token server requires the string "challengeme" in order to evoke a challenge, you should type "challengeme" in the Password box. Users receive a username prompt and a challenge prompt.
Tip
Note
Step 9
Cisco Secure ACS saves the token server database configuration you created. You can 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 About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".
Deleting an External User Database Configuration
If you no longer need a particular external user database configuration, you can delete it from Cisco Secure ACS.
To delete an external user database configuration, follow these steps:
Step 1
Step 2
Cisco Secure ACS lists all possible external user database types.
Step 3
The External User Database Configuration table appears.
Step 4
Step 5
A confirmation dialog box appears.
Step 6
The external user database configuration you selected is deleted from Cisco Secure ACS.
