-
User Guide for Cisco Secure ACS Solution Engine 4.0
-
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
-
Posture Validation
-
Network Access Profiles
-
Unknown User Policy
-
User Group Mapping and Specification
-
Troubleshooting
-
TACACS+ Attribute-Value Pairs
-
RADIUS Attributes
-
VPDN Processing
-
RDBMS Synchronization Import Definitions
-
Internal Architecture
-
Index
-
Feedback
Table Of Contents
About the ACS Internal Database
Authenticating with External User Databases
External User Database Authentication Process
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
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 User Database Configuration Options
Configuring a Windows External User Database
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
LDAP Admin Logon Connection Management
Configuring a Generic LDAP External User Database
Downloading a Certificate Database
LEAP Proxy RADIUS Server Database
Configuring a LEAP Proxy RADIUS Server External User Database
About RADIUS-Enabled Token Servers
Token Server RADIUS Authentication Request and Response Contents
Configuring a RADIUS Token Server External User Database
Deleting an External User Database Configuration
User Databases
The Cisco Secure Access Control Server Release 4.0 Solution Engine, hereafter referred to as ACS, authenticates users against one of several possible databases, including its internal database. You can configure ACS to authenticate users with more than one type of database. With this flexibility you can use user account data that is collected in different locations without having to explicitly import the users from each external user database into the ACS internal database. You can also apply different databases to different types of users, depending on the security requirements that are 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 Chapter 16, "Unknown User Policy" and Chapter 17, "User Group Mapping and Specification."
This chapter contains the following topics:
•
•
•
ACS Internal Database
The ACS internal database supports authentication by using:
•
•
•
•
•
•
•
•
•
•
•
The ACS internal 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, ACS authorizes network services for users based on group membership and specific user settings in the ACS internal database. Thus, all users that ACS authenticates, even those authenticated by an external user database, have an account in the ACS internal database.
About the ACS Internal Database
For users who are authenticated by using the ACS internal database, ACS stores user passwords in a database which is protected by an administration password and encrypted by using the AES 128 algorithm. For users who are authenticated with external user databases, ACS does not store passwords in the ACS internal database.
Unless you have configured ACS to authenticate users with an external user database, ACS uses usernames and passwords in the ACS internal database during authentication. For more information about specifying an external user database for authentication of a user, see Adding a Basic User Account, page 7-3.
User Import and Creation
Of the four ways to create user accounts in ACS, Relational Database Management System (RDBMS) Synchronization supports importing user accounts from external sources. The four ways are:
•
•
If you use the Unknown User Policy, you can also configure group mappings so that each time a user who was added to ACS by the 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 who were authenticated by a given database are assigned to a single ACS user group. For more information about group mapping, see Chapter 17, "User Group Mapping and Specification."
•
•
About External User Databases
You can configure ACS to forward authentication of users to one or more external user databases. Support for external user databases means that ACS does not require that you create duplicate user entries in the user database. In organizations in which a substantial user database already exists, ACS can leverage the work already invested in building the database without any additional input.
In addition to performing authentication for network access, ACS can perform authentication for TACACS+ enabling privileges by using external user databases. For more information about TACACS+ enable passwords, see Setting TACACS+ Enable Password Options for a User, page 7-23.
Note
Users can be authenticated by using the following databases:
•
•
•
•
•
For ACS to interact with an external user database, ACS requires an API for the third-party authentication source. The ACS communicates with the external user database using the API.
Authenticating with External User Databases
Authenticating users with an external user database requires more than configuring ACS to communicate with an external user database. Performing one of the configuration procedures in this chapter for an external database does not, on its own, instruct ACS to authenticate any users with that database.
After you have configured ACS to communicate with an external user database, you can configure 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 by using the external user database. In addition, the users may be placed in the desired ACS group and thereby receive the applicable access profile.
•
You can also configure ACS with both of the previous methods; these two methods are not mutually exclusive.
External User Database Authentication Process
When ACS attempts user authentication with an external user database, it forwards the user credentials to the external user database. The external user database passes or fails the authentication request from ACS. On receiving the response from the external user database, ACS instructs the requesting AAA client to grant or deny the user access, depending on 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 that is used to communicate with the external user database vary with the database type. For LDAP and Novell NDS, ACS uses TCP connections. For Windows user databases, ACS uses the authentication API provided in the Windows operating system. ACS communicates with token servers by using RADIUS.
For more information, see the section regarding the database type in which you are interested.
Windows User Database
You can configure ACS to use a Windows user database to authenticate users.
This section contains the following topics:
•
•
•
–
–
•
–
–
•
–
–
•
•
•
•
Windows User Database Support
ACS supports the use of Windows external user databases for:
•
Note
•
•
•
•
•
Authentication with Windows User Databases
ACS forwards user credentials to a Windows database by passing the user credentials to the Windows operating system of the computer that is running the remote agent. The Windows database passes or fails the authentication request from ACS. When receiving the response from the Windows database, the remote agent forwards the response to ACS, and ACS instructs the requesting AAA client to grant or deny the user access, depending on the response from the Windows database.
ACS grants authorization based on the ACS group to which the user is assigned. While you can determine the group to which a user is assigned information from the Windows database, it is ACS that grants authorization privileges.
To further control access by a user, you can configure ACS to also check the setting for granting dial-in permission to the user. This setting is labeled Grant dialin permission to user in Windows NT and Allow access in the Remote Access Permission area in Windows 2000 and Windows 2003. If this feature is disabled for the user, access is denied; even if the username and password are typed correctly.
Trust Relationships
ACS can take advantage of trust relationships established between Windows domains. If the domain that contains the computer running the Windows remote agent trusts another domain, ACS can authenticate users whose accounts reside in the other domain. ACS can also reference the Grant dialin permission to user setting across trusted domains.
Note
ACS can take advantage of indirect trusts for Windows authentication. Consider the example of Windows domains A, B, and C, where the remote agent resides 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/2003/XP Professional and Windows 95/98/Millennium Edition (ME)/XP Home enable users to connect to your network remotely; but the fields that are provided differ.
Windows Dial-Up Networking Clients with a Domain Field
If users dial in to your network by using the dial-up networking client that is provided with Windows NT, Windows 2000, Windows 2003, or Windows XP Professional, three fields appear:
•
•
•
Note
Windows Dial-Up Networking Clients without a Domain Field
If users access your network by using the dial-up networking client that is 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
ACS supports Windows authentication for usernames in a variety of formats. When 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 ACS, you must understand how ACS determines a username format, how it supports each of these formats, and how the types of support are related.
To determine the format of a username that is submitted for Windows authentication, ACS searches the username for the:
•
•
Based on the presence and position of these two characters in the username, ACS determines username format by using the following logic:
1.
2.
–
–
For more information, see Domain-Qualified Usernames.
3.
–
–
–
–
–
For more information, see UPN Usernames.
Nondomain-Qualified Usernames
ACS supports Windows authentication of usernames that are not domain qualified, provided the username does not contain an at symbol (@). Users with at symbols (@) in their usernames must submit the username in UPN format or in a domain-qualified format. Examples of nondomain-qualified usernames are cyril.yang and msmith.
In Windows environments with multiple domains, authentication results with nondomain-qualified usernames can vary. This variance occurs because Windows, not ACS, determines which domains are used to authenticate a nondomain-qualified username. If Windows does not find the username in its local domain database, it then checks all trusted domains. If the 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.
When Windows authentication for a nondomain-qualified username succeeds, the privileges that are assigned during authentication will be those that are associated with the Windows user account in the first domain with a matching username and password. This condition 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 that nondomain-qualified usernames cause. If you have configured the Domain List in the Windows User Database Configuration page of the External User Databases section, ACS submits the username and password to each domain in the list in a domain-qualified format until it successfully authenticates the user. If ACS has tried each domain in the Domain List or if no trusted domains have been configured in the Domain List, 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 that they should be authenticated against along with their usernames. Authentication of a domain-qualified username is directed to a specific domain; rather than depending on Windows to attempt authentication with the correct domain or on using the Domain List to direct 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 symbol (@), 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 symbol (@) is received in a nondomain-qualified format, ACS perceives it as a username in UPN format. For more information, see UPN Usernames.
UPN Usernames
ACS supports authentication of usernames in UPN format, such as cyril.yang@example.com or cyril.yang@central-office@example.com.
If the authentication protocol is EAP-TLS, by default, ACS submits the username to Windows in UPN format; however, you can configure ACS to strip from the username all characters after and including the last at symbol (@). For more information, see EAP-TLS Domain Stripping.
For all other authentication protocols that it can support with Windows databases, ACS submits the username to Windows that is stripped of all characters after and including the last at symbol (@). This behavior allows for usernames that contain an at symbol (@). For example:
•
•
Note
EAP and Windows Authentication
This section contains 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, you can use ACS to strip the domain name from the username that is stored in the Subject Alternative Name (SAN) 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 might contain jsmith@corporation.com but jsmith might need to authenticate by 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 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 Nondomain-Qualified Usernames.
You can enable EAP-TLS domain name stripping on the Windows User Database Configuration page.
Note
Machine Authentication
ACS supports the authentication of computers that are running the 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 feature 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. When starting a computer, the authentications occur in this order:
•
•
Tip
•
Note
ACS supports EAP-TLS and PEAP (EAP-MS-CHAPv2) for machine authentication. You can enable each separately on the Windows User Database Configuration page, which allows a mix of computers that authenticate with EAP-TLS or PEAP (EAP-MS-CHAPv2). Microsoft operating systems that perform machine authentication might limit the user authentication protocol to the same protocol that is 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 that were previously unknown to 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 that is configured to perform machine authentication, machine authentication occurs when the computer started. Provided that the AAA client sends RADIUS accounting data to 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-MS-CHAPv2) 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 to which the computer belongs. The domain segment might also include subdomains, if they are used; so that the format may be:
host/computer.subdomain.domainThe usernames of computers that are authenticated must appear in the ACS internal database. If you enable unknown user processing, 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 that is using a client certificate. The certificate that the computer uses 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 ACS internal database in the format contained in the computer client certificate and the user profile corresponding to the computer name must be configured to authenticate by using the Windows external user database. If you enable unknown user processing, ACS adds the computer names to the ACS internal database automatically; once they authenticate successfully. It also automatically configures the user profiles that are created to use the external user database in which the user was found. For machine authentication, this will always be the Windows external user database.
Machine Access Restrictions
You can use the machine access restrictions (MAR) feature as an additional means of controlling authorization for Windows-authenticated EAP-TLS, EAP-FASTv1a, and Microsoft PEAP users, based on machine authentication of the computer used to access the network.
When you enable the feature:
•
Calling-Station-Idattribute (31)as evidence of the successful machine authentication. ACS stores eachCalling-Station-Idattribute value for the number of hours that is specified on the Windows User Database Configuration page before deleting it from the cache.•
Calling-Station-Idvalues from successful machine authentications for theCalling-Station-Idvalue received in the user authentication request. Whether ACS finds the user-authenticationCalling-Station-Idvalue in the cache affects how ACS assigns the user requesting authentication to a user group.–
–
Note
The MAR feature supports full EAP-TLS, EAP-FASTv1a, 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:
•
•
•
Calling-Station-Idattribute (31).•
Calling-Station-Idattribute values from successful machine authentications.•
Setting Up a MAR Exception List
You might need to set up a MAR exception list if you need to set up specific users (for example managers and administrators) to have access to the network; regardless of whether they pass machine authentication. This feature allows you to select user groups that would be exempt from the MAR.
Before You Begin
So that users can immediately authenticate as part of the MAR exception list, you should set up the required number of groups and permissions before changing your Windows database settings. To manage your group settings, see Group TACACS+ Settings, page 6-2 and Listing Users in a User Group, page 6-40.
To set up a MAR exception list for selected user groups:
Step 1
Step 2
Step 3
Step 4
The exception list is based on ACS user groups to which the relevant NT groups would map. You can create exceptions for several user groups, and map different authorization permission to each group.
Microsoft Windows and Machine Authentication
ACS supports machine authentication with Active Directory in Windows 2000 and 2003. To enable machine authentication support in Windows Active Directory you must:
1.
2.
Modify Dial-In Permissions for Computers That Use Wireless Networking.Client operating systems that support 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 that is 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 the Microsoft Knowledge Base Article 313407, HOW TO: Create Automatic Certificate Requests with Group Policy in Windows.
Enabling Machine Authentication
This procedure contains an overview of the detailed procedures required to configure ACS to support machine authentication.
Note
Before You Begin
Windows authentication requires that you install at least one ACS Remote Agent for Windows and complete the steps in Adding a Remote Agent, page 4-21. For information about installing the ACS Remote Agent for Windows, see the Installation and Configuration Guide for Cisco Secure ACS Remote Agents 4.0.
To enable ACS to perform machine authentication:
Step 1
Note
Step 2
Step 3
•
•
Note
You can use ACS to complete this step only after you have successfully completed Step 1. For detailed steps, see Configuring Authentication Options, page 10-19.
Step 4
•
•
•
Note
For detailed steps, see Configuring a Windows External User Database.
Note
ACS is ready to perform machine authentication for computers whose names exist in the ACS internal database.
Step 5
Note
Step 6
ACS is ready to perform machine authentication for computers; regardless of whether the computer names exist in ACS internal database.
User-Changeable Passwords with Windows User Databases
For network users who are authenticated by a Windows user database, ACS supports user-changeable passwords on 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. The use of this feature in your network requires that:
•
•
•
•
–
–
When the previous conditions are met and this feature is enabled, users receive a dialog box prompting them to change their passwords on their first successful authentication after their passwords have expired. The dialog box is the same as Windows presents to users when a user with an expired password accesses a network via a remote-access server.
For more information about password aging support in ACS, see Enabling Password Aging for Users in Windows Databases, page 6-19.
Preparing Users for Authenticating with Windows
Before using the Windows user database for authentication:
Step 1
Step 2
•
•
Step 3
Selecting Remote Agents for Windows Authentication
Before you can configure 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 for ACS to use if the primary remote agent is unavailable.
Before You Begin
To complete this procedure, you must have installed at least one ACS Remote Agent for Windows and completed the steps in Adding a Remote Agent, page 4-21.
To select remote agents for Windows authentication:
Step 1
Step 2
ACS displays a list of all possible external user database types.
Step 3
ACS displays the External User Database Configuration page.
Step 4
ACS displays the Windows Remote Agent Selection lists.
Step 5
Step 6
Note
Step 7
ACS saves the remote agent selections that you made. The Windows User Database Configuration page appears.
Windows User Database Configuration Options
The Windows User Database Configuration page contains:
•
Note
Tip
•
Note
•
1326(bad username or password)is returned. ACS treats this error as awrong passworderror and does not default to another external database. You should enable this option when additional external databases appear after the Windows database in the Selected Databases list. When enabled, ACS searches for the unknown user in the other external databases.•
–
–
–
When usernames are not domain-prefixed, and the same username occurs multiple times across the entire network, if no domains are in the Domain List, Windows can try to authenticate the wrong credentials. When Windows rejects the initial user-authentication request, ACS stops attempting to authenticate the user. For more information, see Nondomain-Qualified Usernames. If domains are in the Domain List, ACS qualifies the username with a domain from the list and submits the domain-qualified username to Windows, once for each domain in the Domain List, until each domain has rejected the user or until one of the domains authenticates the user.
In all other cases, leave the Domain List empty as it might cause performance problems if you use it when you do not need to. Also, each time ACS uses the Domain List and checks the wrong account, Windows counts that as a failed login for that user, which can cause an account lockout.
•
Note
For more information about Windows password changes, see Enabling Password Aging for Users in Windows Databases, page 6-19.
•
–
–
Performing domain name stripping can speed EAP-TLS authentication when the domain that must authenticate a user is not the domain that is represented in the SAN field. For example, a user's SAN field might contain jsmith@corporation.com but jsmith might need to authenticate by 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 ACS use the Domain List and find the user in the engineering domain. The additional delay could last several seconds.
–
–
–
Note
–
Note
Tip
–
Calling-Station-Idattribute values from successful machine authentications, for use with the MAR feature. The default value is 12 hours, which means that ACS does not cacheCalling-Station-Idvalues.
Note
Tip
Calling-Station-Idvalues, type zero (0) in the Aging time (hours) box and click Submit.–
Note
–
Note
Caution
•
•
Configuring a Windows External User Database
Before You Begin
To complete this procedure, you must have completed the steps in Selecting Remote Agents for Windows Authentication.
For information about the options that are available on the Windows User Database Configuration page, see Windows User Database Configuration Options.
To configure ACS to authenticate users against the Windows user database in the trusted domains of your network:
Step 1
Step 2
ACS displays a list of all possible external user database types.
Step 3
If no Windows database configuration exists, the Database Configuration Creation table appears. Otherwise, the External User Database Configuration page appears.
Step 4
The Windows User Database Configuration page appears.
Step 5
•
•
•
•
•
•
For information about the options on the Windows User Database Configuration page, see Windows User Database Configuration Options.
Note
Step 6
ACS saves the Windows user database configuration that 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, page 16-3. For more information about configuring user accounts to authenticate by using this database, see Chapter 7, "User Management."
Generic LDAP
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 the SunOne Directory Server. Other authentication protocols are not supported with LDAP external user databases.
Note
ACS supports group mapping for unknown users by requesting group membership information from LDAP user databases. For more information about group mapping for users who are authenticated with an LDAP user database, see Group Mapping by Group Set Membership, page 17-3.
Configuring 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:
•
•
•
•
•
ACS Authentication Process with a Generic LDAP User Database
ACS forwards the username and password to an LDAP database by using a Transmission Control Protocol (TCP) connection on a port that you specify. The LDAP database passes or fails the authentication request from ACS. When receiving the response from the LDAP database, ACS instructs the requesting AAA client to grant or deny the user access, depending on the response from the LDAP server.
ACS grants authorization based on the 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, ACS grants authorization privileges.
Multiple LDAP Instances
You can create more than one LDAP configuration in ACS. By creating more than one LDAP configuration with different IP address or port settings, you can configure ACS to authenticate by using different LDAP servers or 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 ACS LDAP configuration instance.
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 method 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 ACS should submit authentication requests.
For each LDAP instance, you can add it to or omit it from the Unknown User Policy. For more information, see About Unknown User Authentication, page 16-3.
For each LDAP instance, you can establish unique group mapping. For more information, see Group Mapping by Group Set Membership, page 17-3.
Multiple LDAP instances are also important when you use domain filtering. For more information, see Domain Filtering.
LDAP Organizational Units and Groups
LDAP groups do not need the same name as their corresponding ACS groups. You can map the LDAP group to an ACS group with any name that 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 ACS, see Chapter 17, "User Group Mapping and Specification."
Domain Filtering
Using domain filtering, you can control which LDAP instance is authenticates a user based on domain-qualified usernames. Domain filtering is based on parsing the characters at the beginning or end of a username that is submitted for authentication. Domain filtering provides you with greater control over the LDAP instance to which ACS submits any given user authentication request. You can also control whether usernames are submitted to an LDAP server with their domain qualifiers intact.
For example, when EAP-TLS authentication a Windows XP client initiates, ACS receives the username in
username@domainnameformat. When PEAP authentication is initiated by a Cisco Aironet end-user client, 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, ACS can strip the domain qualifier. If separate user accounts are maintained in the LDAP database—domain-qualified and nondomain-qualified user accounts—ACS can pass usernames to the LDAP database without domain filtering.If you choose to make use of domain filtering, each LDAP configuration that you create in ACS can perform domain filtering:
•
With this option, each LDAP configuration is limited to one domain and to one type of domain qualification. You can specify whether 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 ACS to strip domain qualifiers.
Limiting users to one domain is useful when the LDAP server stores usernames differently per domain: by user context or how the username is stored in ACS—domain qualified or nondomain qualified. The end-user client or AAA client must submit the username to ACS in a domain-qualified format; otherwise 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.
•
ACS supports 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 ACS.
Allowing usernames of any domain but stripping domain qualifiers is useful when the LDAP server stores usernames in a nondomain-qualified format but the AAA client or end-user client submits the username to ACS in a domain-qualified format.
Note
LDAP Failover
ACS supports failover between a primary LDAP server and secondary LDAP server. In the context of LDAP authentication with ACS, failover applies when an authentication request fails because ACS could not connect to an LDAP server, such as when the server is down or is otherwise unreachable by ACS. To use this feature, you must define the primary and secondary LDAP servers on the LDAP Database Configuration page. Also, you must check 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 you check the On Timeout Use Secondary check box, and if the first LDAP server that ACS attempts to contact cannot be reached, ACS always attempts to contact the other LDAP server. The first server ACS attempts to contact might not always be the primary LDAP server. Instead, the first LDAP server that ACS attempts to contact depends on the previous LDAP authentications attempt and on the value that you enter in the Failback Retry Delay box.
Successful Previous Authentication with the Primary LDAP Server
If, on the previous LDAP authentication attempt, ACS successfully connected to the primary LDAP server, ACS attempts to connect to the primary LDAP server. If ACS cannot connect to the primary LDAP server, ACS attempts to connect to the secondary LDAP server.
If ACS cannot connect with LDAP server, ACS stops attempting LDAP authentication for the user. If the user is an unknown user, ACS tries the next external user database in the Unknown User Policy list. For more information about the Unknown User Policy list, see About Unknown User Authentication, page 16-3.
Unsuccessful Previous Authentication with the Primary LDAP Server
If, on the previous LDAP authentication attempt, ACS could not connect to the primary LDAP server, whether 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 zero (0), ACS always attempts to connect to the primary LDAP server first. And if ACS cannot connect to the primary LDAP server, ACS then attempts to connect to the secondary LDAP server.
If the Failback Retry Delay box is set to a number other than zero (0), ACS determines how many minutes have passed since the last authentication attempt by using the primary LDAP server. If more minutes have passed than the value in the Failback Retry Delay box, ACS attempts to connect to the primary LDAP server first. And if ACS cannot connect to the primary LDAP server, ACS then attempts to connect to the secondary LDAP server.
If fewer minutes have passed than the value in the Failback Retry Delay box, ACS attempts to connect to the secondary LDAP server first. And if ACS cannot connect to the secondary LDAP server, ACS then attempts to connect to the primary LDAP server.
If ACS cannot connect to either LDAP server, ACS stops attempting LDAP authentication for the user. If the user is an unknown user, ACS tries the next external user database in the Unknown User Policy list. For more information about the Unknown User Policy list, see About Unknown User Authentication, page 16-3.
LDAP Admin Logon Connection Management
When ACS checks authentication and authorization of a user on an LDAP server, it uses a connection with the LDAP administrator account permissions. It uses the connection to search for the user and user groups on the Directory subtree. ACS retains the administrator connections that are open for successive use and additional administrator binds are not required for each authentication request. You can limit the maximum number of concurrent administrator connections per Generic LDAP External DB configuration (primary and secondary).
Distinguished Name Caching
Searching can be an expensive LDAP operation, which introduces an element of unpredictability into the authentication. ACS takes the username that the authentication process supplies, and asks the LDAP server to search a full subtree of unknown depth, over an unknown user population.
After successful authentication ACS caches the Distinguished Name (DN) that the search returns. Reauthentications can then use the cached DN to perform an immediate lookup of the user.
A cached DN cannot appear on a screen. If a bind to a cached DN fails, ACS falls back to a full search of the data base for authenticating a user.
LDAP Configuration Options
The LDAP Database Configuration page contains many options, presented in three tables:
•
This table contains:
–
–
–
Note
–
For example, if the domain name is mydomain, the delimiting character is the at symbol (@), and Suffix is selected on the Qualified by list, the Domain box should contain @mydomain. If the domain name is yourdomain, the delimiting character is the backslash (\), and Prefix is selected on the Qualified by list, the Domain Qualifier box should contain yourdomain\.
–
–
–
For example, if the delimiter character is the backslash (\) and the username is DOMAIN\echamberlain, ACS submits echamberlain to an LDAP server.
Note
–
For example, if the delimiter character is the at symbol (@) and the username is jwiedman@domain, then ACS submits jwiedman to an LDAP server.
Note
•
•
–
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.
–
–
objectTypeattribute that identifies the record as a user. Often, user records have several values for theobjectTypeattribute, some of which are unique to the user, some of which are shared with other object types. This box should contain a value that is not shared.–
–
objectTypeattribute in the group record that identifies the record as a group.–
–
–
–
–
•
–
–
–
–
–
–
To perform secure authentication by using SSL with this option, you must provide a Netscape cert7.db certificate database file. ACS requires a certificate database so that it can establish the SSL connection. Since the certificate database must be local to the ACS Solution Engine, you must use FTP to transfer the certificate database to ACS.
ACS requires a Netscape cert7.db certificate database file for each LDAP server that you configure. For example, to support users distributed in multiple LDAP trees, you might configure two LDAP instances in ACS that can communicate with the same LDAP servers. Each LDAP instance then has 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 ACS.
Note
–
uid=user id,[ou=organizational unit,][ou=next organizational unit]o=organization
where 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 ACS information that enables it to pass authentication requests to an LDAP database. This information reflects the way that 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.
Note
Before You Begin
For information about the options on the LDAP Database Configuration page, see LDAP Configuration Options.
To configure ACS to use the LDAP User Database or to configure LDAP to authenticate Novell NDS Users:
Step 1
Step 2
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.
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
a.
Note
b.
c.
Note
Step 10
If you are authenticating Novell NDS users, set UserDirectorySubtree to o=lab.
Step 11
If you are authenticating Novell NDS users, set GroupDirectorySubtree to o=lab.
Step 12
Note
If you are authenticating Novell NDS users, set the user object type to cn.
Step 13
uid=joesmith,ou=members,ou=administrators,o=ciscoattribute that identifies the record as a user. Often, user records have several values for theobjectTypeattribute, some of which are unique to the user, some of which are shared with other object types. Select a value that is not shared.Step 14
Step 15
objectTypeattribute in the group record that identifies the record as a group.If you are authenticating Novell NDS users, set the GroupObjectClass to groupOfNames.
Step 16
Step 17
Step 18
Step 19
Note
Step 20
Step 21
Note
a.
b.
c.
d.
e.
–
–
Note
f.
–
–
g.
In the Admin DN box, type the following information from your LDAP server:
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.
For example:
uid=joesmith,ou=members,ou=administrators,o=cisco
Tip
Example-Novell NDS Server:
uid=admin.ou=Chicago.o=CorporationYou can use anonymous credentials for the administrator username if you configure the Novell NDS server 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.
If the administrator username that you specified does not have permission to see the group name attribute in searches, group mapping fails for users who are authenticated by Novell NDS.
For more information, refer to your specific LDAP database documentation.
h.
Step 22
ACS saves the generic LDAP configuration that 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, page 16-3. For more information about configuring user accounts to authenticate by using this database, see Chapter 7, "User Management."
Downloading a Certificate Database
Before You Begin
The database must be a Netscape cert7.db certificate database file generated by a Netscape web browser. No other filename is supported. For information about generating a Netscape cert7.db file, refer to Netscape documentation.
Note
To download a certificate database for a primary or a secondary LDAP server:
Step 1
a.
Note
b.
Note
Step 2
Note
Step 3
Step 4
Step 5
For example, if the Netscape cert7.db file is located in
objectTypeand the user provided in the Login box starts its FTP sessions inc:\ACS-files\LDAPcertdb, you then typec:\.The Directory box accepts a maximum of 512 characters.
Step 6
ACS downloads the Netscape cert7.db file from the FTP server. ACS displays the LDAP Database Configuration page.
LEAP Proxy RADIUS Server Database
For ACS-authenticated users who access your network via Cisco Aironet devices, ACS supports PAP based MAC Exception Handling, 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. This feature is useful if your own RADIUS-based user database can support MS-CHAP but not LEAP/EAP-FAST. ACS manages the LEAP/EAP-FAST protocol handling and forwards just the MS-CHAP authentication to your server.
Note
ACS uses MS-CHAP Version 1 for LEAP Proxy RADIUS Server authentication. With LEAP Proxy, only the MS-CHAP authentication is proxied to the remote server in a separate RADIUS access request. To manage your proxy RADIUS database, refer to your RADIUS database documentation.
You can use the LEAP proxy RADIUS server authentication 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
ACS-files\LDAPcertdb. If the third-party RADIUS server does not return the MPPE keys, the authentication fails and is logged in the Failed Attempts log.ACS supports RADIUS-based group specification for users who are authenticated by LEAP Proxy RADIUS Server databases. The RADIUS-based group specification overrides group mapping. For more information, see RADIUS-Based Group Specification, page 17-8.
ACS supports group mapping for unknown users who are 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 of users who are authenticated by a LEAP Proxy RADIUS Server database, see Group Mapping by External User Database, page 17-1.
Configuring a LEAP Proxy RADIUS Server External User Database
You should install and configure your proxy RADIUS server before configuring ACS to authenticate users with it. For information about installing the proxy RADIUS server, refer to the documentation that is included with your RADIUS server.
To configure LEAP proxy RADIUS authentication:
Step 1
Step 2
ACS lists 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.
ACS lists the new configuration in the External User Database Configuration table.
Step 5
Note
Step 6
Step 7
•
•
•
•
•
•
•
Note
Step 8
ACS saves the proxy RADIUS token server database configuration that 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, page 16-3. For more information about configuring user accounts to authenticate by using this database, see Chapter 7, "User Management."
Token Server User Databases
ACS supports the use of token servers for the increased security that one-time passwords (OTPs) provide.
This section contains the following topics:
About Token Servers and ACS
ACS provides ASCII, PAP, and PEAP (EAP-GTC) authentication by using token servers. Other authentication protocols are not supported with token server databases.
Note
Requests from the AAA client are first sent to ACS. If ACS has been configured to authenticate against a token server and finds the username, it forwards the authentication request to the token server. If it does not find the username, ACS checks the database that is configured to authenticate unknown users. If the request for authentication is passed, the appropriate authorizations are forwarded to the AAA client along with the approved authentication. ACS then maintains the accounting information.
ACS acts as a client to the token server. For all token servers, ACS acts as a client by using the RADIUS interface of the token server. For more information about ACS support of token servers with a RADIUS interface, see RADIUS-Enabled Token Servers.
Token Servers and ISDN
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.
ACS caches the token to help make the OTPs easier for users. Therefore, if a token card is being used to authenticate a user on the first B channel, you can set a specified period 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 that the second B channel is up. Furthermore, you can configure the second B channel to use the CHAP password that is 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.
RADIUS-Enabled Token Servers
This section describes support for token servers that provide a standard RADIUS interface.
This section contains the following topics:
•
•
•
About RADIUS-Enabled Token Servers
ACS supports token servers by using the RADIUS server that is built into the token server. Rather than using a vendor-proprietary API, ACS sends standard RADIUS authentication requests to the RADIUS authentication port on the token server. This feature enables ACS to support any IETF RFC 2865-compliant token server.
You can create multiple instances of RADIUS token servers. For information about configuring ACS to authenticate users with one of these token servers, see Configuring a RADIUS Token Server External User Database.
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, page 17-8.
ACS also supports mapping users who are 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, page 17-1.
Token Server RADIUS Authentication Request and Response Contents
When ACS forwards an authentication request to a RADIUS-enabled token server, the RADIUS authentication request contains the following attributes:
•
MS-CHAP-MPPE-Keys (VSA 12)(RADIUS attribute 1)•
User-Name(RADIUS attribute 2)•
User-Password(RADIUS attribute 4)•
NAS-IP-Address(RADIUS attribute 5)•
NAS-Port(RADIUS attribute 32)ACS expects to receive one of the following three responses:
•
•
•
–
NAS-Identifier(RADIUS attribute 24)–
State(RADIUS attribute 18)Configuring a RADIUS Token Server External User Database
Use this procedure to configure RADIUS Token Server external user databases.
Before You Begin
You should install and configure your RADIUS token server before configuring ACS to authenticate users with it. For information about installing the RADIUS token server, refer to the documentation included with your token server.
To configure ACS to authenticate users with a RADIUS Token Sever:
Step 1
Step 2
ACS lists all possible external user database types.
Step 3
The Database Configuration Creation table appears. If at least one RADIUS token server configuration exists, the External User Database Configuration table also appears.
Step 4
a.
b.
c.
ACS lists the new configuration in the External User Database Configuration table.
Step 5
Note
Step 6
Step 7
•
•
•
•
Note
•
•
•
Note
Step 8
•
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
•
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 will receive a username prompt and a challenge prompt.
Tip
Note
Step 9
ACS saves the RADIUS token server database configuration that 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, page 16-3. For more information about configuring user accounts to authenticate by using this database, see Chapter 7, "User Management."
Deleting an External User Database Configuration
If you no longer need a particular external user database configuration, you can delete it from ACS.
To delete an external user database configuration:
Step 1
Step 2
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 that you selected is deleted from ACS.
