Table of Contents

Working with User Databases

Cisco Secure Access Control Server (Cisco Secure ACS) for Windows Server version 3.1 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 2000/NT user database for standard network users and a token server for network administrators.

This chapter contains the following sections:

For information about the Unknown User Policy and group mapping features, see "Administering External User Databases."

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, and PEAP(EAP-GTC).

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.

About the CiscoSecure User Database

The CiscoSecure user database draws information from a number of data sources, including a memory-mapped, hash-indexed file, VarsDB.MDB (in Microsoft Jet database format), and the Windows Registry. VarsDB.MDB uses an index and tree structure, so searches can occur logarithmically rather than linearly, thus yielding very fast lookup times. This enables the CiscoSecure user database to authenticate users quickly.

Unless you have configured 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 five ways to create user accounts in the CiscoSecure user database in Cisco Secure ACS for Windows 2000 Servers. Of these, RDBMS Synchronization and CSUtil.exe support 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 CiscoSecure user database 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 Database Group Mappings.

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.

In addition to performing 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   You can only use external users databases to authenticate users and to determine which group Cisco Secure ACS assigns a user to. The CiscoSecure user database, internal to Cisco Secure ACS, provides all authorization services. With few exceptions, Cisco Secure ACS cannot retrieve authorization data from external user databases. Exceptions are noted where applicable in the discussions of specific databases in this chapter. For more information about group mapping for unknown users, see Database Group Mappings.

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 third-party authentication source. The Cisco Secure ACS communicates with the external user database using the API. For Windows NT/2000 and Generic LDAP, the program interface for the external authentication is local to Cisco Secure ACS. In these cases, no further components are required.

In the case of Novell NDS authentication, Novell Requestor must be installed on the same Windows server as Cisco Secure ACS.

In the case of ODBC authentication sources, in addition to the Windows ODBC interface, the third-party ODBC driver must be installed on the Cisco Secure ACS Windows server.

To communicate with an RSA token server, you must have installed software components provided by RSA.

For RADIUS-based token servers, such as ActivCard, CRYPTOCard, PassGo, SafeWord, and Vasco, the standard RADIUS interface serves as the third-party API.

Authenticating with External User Databases

Authenticating users with an external user database requires more than configuring 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.

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 NT/2000 user databases, Cisco Secure ACS uses the authentication API provided in the Windows operating system. With the exception of RSA token servers, Cisco Secure ACS communicates with token servers using RADIUS. For RSA token servers, Cisco Secure ACS acts an RSA client in order to use the RSA proprietary interface.

For more information, see the section regarding the database type you are interested in.

Windows NT/2000 User Database

You can configure Cisco Secure ACS to use a Windows NT/2000 user database to authenticate users.

This section contains the following topics:

What's Supported with Windows NT/2000 User Databases

Cisco Secure ACS supports the use of Windows external user databases for the following features:

---

Note    Authentication protocols not supported with Windows NT/2000 external user databases may be supported by a different external user database. For more information about authentication protocols and the external database types that support them, see Authentication Protocol-Database Compatibility.

---

The Cisco Secure ACS Authentication Process with Windows NT/2000 User Databases

Cisco Secure ACS forwards user credentials to a Windows NT/2000 database by passing the user credentials to the Windows operating system of the server that Cisco Secure ACS runs on. The Windows NT/2000 database either passes or fails the authentication request from Cisco Secure ACS. Upon receiving the response from the Windows NT/2000 database, Cisco Secure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the Windows NT/2000 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 NT/2000 database, it is Cisco Secure ACS that grants authorization privileges.

To further control access by a user from within the Windows NT User Manager or the Windows 2000 Active Directory Users and Computers, you can configure Cisco Secure ACS to also check the setting for granting dialin 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. If this feature is disabled for the user, access is not permitted, 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 NT/2000 domains. If the domain that contains Cisco Secure ACS 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.

Note   If Cisco Secure ACS is running on a member server rather than a domain controller, taking advantage of trust relationships depends upon proper configuration of Cisco Secure ACS at installation. For more information, see "Windows Authentication from a Member Server" in Installing Cisco Secure ACS for Windows 2000/NT Servers.

If your domains are Windows 2000 domains, Cisco Secure ACS can take advantage of indirect trusts for Windows authentication. Consider the example of Windows 2000 domains A, B, and C, where Cisco Secure ACS resides on a Windows 2000 server in domain A. Domain A trusts domain B, but no trust relationship is established between domain A and domain C. If domain B trusts domain C, the Cisco Secure ACS server 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 NT/2000 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:

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    You can also prefix your username with the name of the domain you want to log in to. For more information about the implications of prefixing or not prefixing the domain name before the username, see Windows Authentication.

---

Windows Authentication

While different versions of Windows provide different methods of specifying a domain name, the effect of providing or not providing the domain name while logging in is the same. The most reliable method of authenticating users against a specific domain is to require users to submit the domains they should be authenticated against along with their usernames.

With the dial-up networking client provided with Windows NT, Windows 2000, and Windows XP Professional, submitting a domain name is accomplished by typing the domain name in the domain field (or selecting it from the drop-down list). With the dial-up networking client provided with Windows 95, Windows 98, Windows ME, and Windows XP Home, this is accomplished by submitting the username in the fully qualified format. Users submitting a fully qualified username must enter the domain name before their username in the following format:

For example, user Mary Smith (msmith) in Domain10 would enter the following:

Another reason to provide the username in the format shown above is if a user is included in more than one domain. In this case, the privileges assigned upon authentication will be those associated with the account in the first domain with a matching username and password. This also illustrates the importance of removing usernames from a domain when the privileges associated with the user are no longer required.

Tip Entering the domain name can speed up authentication, because authentication is directed to a specific domain rather than depending upon Windows to search through the local domain and all trusted domains until it finds the username.

Note   Cisco Secure ACS does not support the user@domain (UPN) format of qualified usernames when authenticating users with Windows user databases of any type, including local and domain SAM databases and Active Directory databases.

If you do not specify a domain name when typing the username, Cisco Secure ACS submits the username to the Windows operating system on the server than runs Cisco Secure ACS. 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.

Note   If the credentials submitted by the user do not match the credentials associated with the first matching username that Windows finds, authentication fails. Thus, if different users in different domains share the same exact username, logging in with a non-domain-qualified username can result in inadvertent authentication failure.

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 NT/2000 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 fully 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   If your Domain List contains domains and your Windows SAM or Active Directory user databases are configured to lock out users after a number of failed attempts, users can be inadvertently locked out because Cisco Secure ACS tries each domain in the Domain List explicitly, resulting in failed attempts for identical usernames that reside in different domains.

User-Changeable Passwords with Windows NT/2000 User Databases

For network users who are authenticated by a Windows NT/2000 user database, Cisco Secure ACS supports the user-changeable passwords upon password expiration. You can enable this feature in the MS-CHAP Settings on the Windows NT/2000 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.

Preparing Users for Authenticating with Windows NT/2000

Before using the Windows NT/2000 user database for authentication, follow these steps:

Step 2   In the Windows NT User Manager or in Windows 2000 Active Directory Users and Computers, clear the following User Properties check boxes:

Step 3   If you want to control dial-in access from within Windows NT, click Dial-in and select Grant dialin permission to user. In Windows 2000, access the User Properties dialog box, select the Dial-In tab, and in the Remote Access area, click Allow access. You must also configure the option to reference this feature under Database Group Mappings in the External User Databases section of Cisco Secure ACS.

Configuring a Windows NT/2000 External User Database

To configure Cisco Secure ACS to authenticate users against the Windows NT/2000 user database in the trusted domains of your network, follow these steps:

Step 2   Click Database Configuration.

Result: Cisco Secure ACS displays a list of all possible external user database types.

Step 3   Click Windows NT/2000.

Result: If no Windows NT/2000 database configuration exists, the Database Configuration Creation table appears. Otherwise, the External User Database Configuration page appears.

Step 4   If you are creating a configuration, follow these steps:

Result: Cisco Secure ACS lists the new configuration in the External User Database Configuration table.

Step 5   Click Configure.

Result: The Windows NT/2000 User Database Configuration page appears.

Step 6   To restrict network access to users who have Windows dialin permission, select the Grant dialin permission to user check box.

---

Note    Windows dialin permission is enabled in the Dialin section of user properties in Windows NT and on the Dial-In tab of the user properties in Windows 2000.

---

Step 7   If you want Cisco Secure ACS to authenticate explicitly using each trusted Windows domain for usernames that are not domain-qualified, select the domains you want Cisco Secure ACS to use to authenticate unqualified usernames in the Available Domains list and move them to the Domain List list by clicking —>.

---

Note    Configuring the Domain List list is optional. For more information about the Domain List, see Windows Authentication.

---

Caution   If your Domain List contains domains and your Windows SAM or Active Directory user databases are configured to lock out users after a number of failed attempts, users can be inadvertently locked out because Cisco Secure ACS tries each domain in the Domain List explicitly, resulting in failed attempts for identical usernames that reside in different domains.

Step 8   In the MS-CHAP table, follow these steps:

Step 9   Click Submit.

Result: Cisco Secure ACS saves the Windows NT/2000 user database configuration you created. You can now add it to your Unknown User Policy or assign specific user accounts to use this database for authentication. For more information about the Unknown User Policy, see Unknown User Processing. For more information about configuring user accounts to authenticate using this database, see "Setting Up and Managing User Accounts."

Generic LDAP

Cisco Secure ACS supports ASCII, PAP, EAP-TLS, and PEAP(EAP-GTC) 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   Authentication protocols not supported with LDAP databases may be supported by another type of external user database. For more information about authentication protocols and the external database types that support them, see Authentication Protocol-Database Compatibility.

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 Unknown User Processing.

For each LDAP instance, you can establish unique group mapping. For more information, see Group Mapping by Group Set Membership.

Multiple LDAP instances is also important when you use domain filtering. For more information, see Domain Filtering.

LDAP Organizational Units and Groups

LDAP groups do not need to have the same name as their corresponding 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 Database Group Mappings.

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 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    With this option, Cisco Secure ACS submits usernames that are non-domain qualified, too. Usernames are not required to be domain qualified to be submitted to an LDAP server.

---

LDAP Failover

Cisco Secure ACS supports failover between a primary 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 Unknown User Processing.

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 Unknown User Processing.

LDAP Configuration Options

The LDAP Database Configuration page contains many options, presented in three tables:

This table contains the following options:

---

Note    Regardless of the domain qualifier type selected, the domain name must match the domain specified in the Domain Qualifier box.

---

For example, if the domain name is "mydomain", the delimiting character is "@", and Suffix is selected on the "Qualified by" list, the Domain box should contain "@mydomain". If the domain name is "radioman", the delimiting character is "\", and Prefix is selected on the "Qualified by" list, the Domain Qualifier box should contain "yourdomain\".

For example, if the delimiter character is "\" and the username is "DOMAIN\echamberlain", Cisco Secure ACS submits "echamberlain" to an LDAP server.

---

Note    The X box cannot contain the following special characters: # ? " * > < Cisco Secure ACS does not allow these characters in usernames; therefore, if any of these characters are in the X box, stripping fails.

---

For example, if the delimiter character is "@" and the username is "jwiedman@domain", then Cisco Secure ACS submits "jwiedman" to an LDAP server.

---

Note    The X box cannot contain the following special characters: # ? " * > < Cisco Secure ACS does not allow these characters in usernames; therefore, if any of these characters are in the X box, stripping fails.

---

If the tree containing users is the base DN, type:

or

as applicable to your LDAP configuration. For more information, refer to your LDAP database documentation.

If the tree containing groups is the base DN, type:

or

as 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. The certificate database must be local to the Cisco Secure ACS Windows server.

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 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    The database must be a cert7.db certificate database file. No other filename is supported.

---

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=cisco

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.

Before You Begin

For information about the options on the LDAP Database Configuration page, see LDAP Configuration Options.

To configure Cisco Secure ACS to use the LDAP User Database, follow these steps:

Step 2   Click Database Configuration.

Result: Cisco Secure ACS displays a list of all possible external user database types.

Step 3   Click Generic LDAP.

---

Note    The user authenticates against only one LDAP database.

---

Result: 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   If you are creating a configuration, follow these steps:

Result: Cisco Secure ACS lists the new configuration in the External User Database Configuration table.

Step 5   Under External User Database Configuration, select the name of the LDAP database you need to configure.

---

Note    If only one LDAP configuration exists, the name of that configuration appears instead of the list. Proceed to Step 6.

---

Step 6   Click Configure.

Caution   If you click Delete, the configuration of the selected LDAP database is deleted.

Step 7   If you do not want Cisco Secure ACS to filter LDAP authentication requests by username, under Domain Filtering, select Process all usernames.

Step 8   If you want to limit authentications processed by this LDAP configuration to usernames with a specific domain qualification, follow these steps:

---

Note    For information about domain filtering, see Domain Filtering 11-18.

---

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.

Only one domain name is supported per LDAP configuration. You can type up to 512 characters.

Step 9   If you want to enable Cisco Secure ACS to strip domain qualifiers from usernames before submitting them to an LDAP server, follow these steps:

---

Note    For information about domain filtering, see Domain Filtering 11-18.

---

---

Note    The X box cannot contain the following special characters: # ? " * > < If any of these characters are in the X box, stripping fails.

---

---

Note    The X box cannot contain the following special characters: # ? " * > < If any of these characters are in the X box, stripping fails.

---

Step 10   Under Common LDAP Configuration, in the User Directory Subtree box, type the DN of the tree containing all your users.

Step 11   In the Group Directory Subtree box, type the DN of the subtree containing all your groups.

Step 12   In the User Object Type box, type the name of the attribute in the user record that contains the username. You can obtain this attribute name from your Directory Server. For more information, refer to your LDAP database documentation.

---

Note    The default values in the UserObjectType and following fields reflect the default configuration of the Netscape Directory Server. Confirm all values for these fields with your LDAP server configuration and documentation.

---

Step 13   In the User Object Class box, type the value of the LDAP "objectType" attribute that identifies the record as a user. Often, user records have several values for the objectType attribute, 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   In the GroupObjectType box, type the name of the attribute in the group record that contains the group name.

Step 15   In the GroupObjectClass box, type a value of the LDAP "objectType" attribute in the group record that identifies the record as a group.

Step 16   In the GroupAttributeName box, type the name of the attribute of the group record that contains the list of user records who are a member of that group.

Step 17   In the Server Timeout box, type the number of seconds Cisco Secure ACS waits for a response from an LDAP server before determining that the connection with that server has failed.

Step 18   To enable failover of LDAP authentication attempts, select the On Timeout Use Secondary check box. For more information about the LDAP failover feature, see LDAP Failover.

Step 19   In the Failback Retry Delay box, type the number of minutes after the primary LDAP server fails to authenticate a user that Cisco Secure ACS resumes sending authentication requests to the primary LDAP server first.

---

Note    To specify that Cisco Secure ACS should always use the primary LDAP server first, type 0 (zero) in the Failback Retry Delay box.

---

Step 20   For the Primary LDAP Server and Secondary LDAP Server tables, follow these steps:

---

Note    If you did not select the On Timeout Use Secondary check box, you do not need to complete the options in the Secondary LDAP Server table.

---

In the Admin DN box, type the following information from your LDAP server:

where 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:

Tip If you are using Netscape DS as your LDAP software, you can copy this information from the Netscape Console.

For more information, refer to your LDAP database documentation.

Step 21   Click Submit.

Result: 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 Unknown User Processing. For more information about configuring user accounts to authenticate using this database, see "Setting Up and Managing User Accounts."

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

Cisco Secure ACS supports ASCII, PAP, and PEAP(EAP-GTC) authentication with Novell NetWare Directory Services (NDS) servers. To use NDS authentication, you must have a Novell NDS database. Other authentication protocols are not supported with Novell NDS external user databases.

Note   Authentication protocols not supported with Novell NDS external user databases may be supported by another type of external user database. For more information about authentication protocols and the external database types that support them, see Authentication Protocol-Database Compatibility.

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   Aside from user group membership information, Cisco Secure ACS retrieves no user settings from Novell NDS databases; however, Cisco Secure ACS enforces password restrictions, login restrictions, time restrictions, and account restrictions for each user. Cisco Secure ACS accomplishes this by interpreting authentication responses received from a Novell NDS database. Cisco Secure ACS does not enforce address restrictions.

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.

Some versions of Novell NDS provide standard LDAP implementations. If your Novell NDS supports standard LDAP and you have implemented standard LDAP, you should configure a Cisco Secure ACS generic LDAP external user database to authenticate users defined in your Novell NDS. For more information about generic LDAP external user databases, see Generic LDAP.

To authenticate users with a Novell NDS database, Cisco Secure ACS depends upon Novell Requestor. Novell Requestor must be installed on the same Windows server as Cisco Secure ACS. You can download the Requestor software from the Novell website. For more information, refer to your Novell and Microsoft documentation.

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 trees. Each tree has several containers, and each container can have several contexts. NDS trees can be thought of as similar to Windows NT/2000 domains. For a user to authenticate against a Novell NDS context, a user object must exist, and the password must be able to log the name into the tree.

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:

If the context list configured in Cisco Secure ACS were:

Agamemnon would successfully authenticate if he submitted "Agamemnon.sales" as his username. If he submitted only "Agamemnon", authentication would fail.

Table 11-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 tree, change existing tree configurations, and delete existing tree configurations in a single submission to the Cisco Secure ACS web server. Cisco Secure ACS displays information for each tree configured, plus a blank section for creating a tree. The configuration items presented for each tree are as follows:

You do not need to add users in the Context List box.

---

Note    Users can provide a portion of their context when they login. For more information, see User Contexts, page 11-35.

---

Configuring a Novell NDS External User Database

You can allow users to enter their own context as part of the login process.

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.

Before You Begin

The Novell Requestor Software for Novell NDS must be installed on the same Windows NT server as Cisco Secure ACS. If the Novell Requestor Software for Novell NDS is not on the same Windows NT server as Cisco Secure ACS, you cannot complete this procedure.

To configure Novell NDS authentication, follow these steps:

Step 2   In the navigation bar, click External User Databases.

Step 3   Click Database Configuration.

Result: Cisco Secure ACS lists all possible external user database types.

Step 4   Click Novell NDS.

Result: 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   If you are creating a configuration, follow these steps:

Result: Cisco Secure ACS lists the new configuration in the External User Database Configuration table.

Step 6   Click Configure.

Caution   If you click Delete, the Cisco Secure ACS configuration for your Novell NDS database is deleted.

Result: The NDS Authentication Support page appears. The NDS Authentication Support page enables you to add a configuration for an Novell NDS tree, change existing tree configurations, and delete existing tree configurations.

For more information about the content of the NDS Authentication Support page, see Novell NDS External User Database Options.

Step 7   To add a new tree configuration, complete the fields in the blank form at the bottom of the NDS Authentication Support page.

---

Note    You must select the Add Tree check box to confirm that you want to create a tree configuration.

---

Step 8   To change an existing tree configuration, edit the values you need to change.

---

Note    The name of a tree is not changeable. If you need to change a tree name, click Delete Tree? on the misnamed tree section and click Submit. Then, add a new tree with the same configuration data as the deleted, misnamed tree, making sure the tree name is correct before clicking Submit.

---

Step 9   To delete an existing tree configuration, select the Delete Tree check box.

Step 10   Click Submit.

Result: 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 Unknown User Processing. For more information about configuring user accounts to authenticate using this database, see "Setting Up and Managing User Accounts."

ODBC Database

As with Windows NT/2000 database support, Cisco Secure ACS ODBC-compliant relational database support enables you to make use of existing user records held in an external ODBC-compliant relational database. Configuring Cisco Secure ACS to authenticate against an ODBC-compliant relational database does not affect the configuration of the relational database. To manage your relational database, refer to your relational database documentation.

The Windows ODBC feature enables you to create a data source name (DSN), which specifies the database and other important parameters necessary for communicating with the database. Among the parameters you provide are the username and password required for the ODBC driver to gain access to your ODBC-compliant relational database.

This section contains the following topics:

What is Supported with ODBC User Databases

Cisco Secure ACS supports the use of ODBC external user databases for the following features:

---

Note    Authentication protocols not supported with ODBC external user databases may be supported by another type of external user database. For more information about authentication protocols and the external database types that support them, see Authentication Protocol-Database Compatibility.

---

For more information about expected query output, see PAP Procedure Output, and CHAP/MS-CHAP/ARAP Procedure Output.

Cisco Secure ACS Authentication Process with an ODBC External User Database

Cisco Secure ACS forwards user authentication requests to an ODBC database in either of the two following scenarios. The first scenario is when the user account in the CiscoSecure user database lists an ODBC database configuration as the authentication method. The second is when the user is unknown to the CiscoSecure user database and the Unknown User Policy dictates that an ODBC database is the next external user database to try.

In either case, Cisco Secure ACS forwards the username and password to the ODBC database via an ODBC connection. The ODBC database either passes or fails the authentication request from Cisco Secure ACS. The relational database must have a stored procedure that queries the appropriate tables and returns values to Cisco Secure ACS. If the returned values indicate that the username and password provided are valid, Cisco Secure ACS instructs the requesting AAA client to grant the user access; otherwise, Cisco Secure ACS denies the user access (Figure 11-2). Upon receiving the response from the ODBC database, Cisco Secure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the ODBC 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 ODBC database using a process known as "group specification", it is Cisco Secure ACS that grants authorization privileges.

Cisco Secure ACS passes the user information to the relational database via the ODBC connection. The relational database must have a stored procedure that queries the appropriate tables and returns values to Cisco Secure ACS. If the returned values indicate that the username and password provided are valid, Cisco Secure ACS grants the user access. Otherwise, Cisco Secure ACS denies the user access (Figure 11-2).

Preparing to Authenticate Users with an ODBC-Compliant Relational Database

Authenticating users with an ODBC-compliant relational database requires that you complete several significant steps external to Cisco Secure ACS before configuring Cisco Secure ACS with an ODBC external user database.

To prepare for authenticating with an ODBC-compliant relational database, follow these steps:

Step 2   Create the database to hold the usernames and passwords. The database name is irrelevant to Cisco Secure ACS, so you can name the database however you like.

Step 3   Create the table or tables that will hold the usernames and passwords for your users. The table names are irrelevant to Cisco Secure ACS, so you can name the tables and columns however you like.

Step 4   Write the stored procedures intended to return the required authentication information to Cisco Secure ACS. For more information about these stored procedures, see Implementation of Stored Procedures for ODBC Authentication.

Step 5   Set up a system DSN on the Cisco Secure ACS server. For steps, see Configuring a System Data Source Name for an ODBC External User Database.

Step 6   Configure Cisco Secure ACS to authenticate users with an ODBC database. For steps, see Configuring an ODBC External User Database.

Implementation of Stored Procedures for ODBC Authentication

When you configure Cisco Secure ACS to authenticate users against an ODBC-compliant relational database, you must create a stored procedure to perform the necessary query and return the values that Cisco Secure ACS expects. Cisco Secure ACS supports ODBC authentication for PAP or CHAP/MS-CHAP/ARAP protocols; however, the method of authentication differs for these two sets of protocols.

Authentication for PAP protocol occurs within the relational database; that is, if the stored procedure finds a record with both the username and the password matching the input, the user is considered authenticated.

Authentication for CHAP/MS-CHAP/ARAP occurs within Cisco Secure ACS. The stored procedure returns the fields for the record with a matching username, including the password. Cisco Secure ACS confirms or denies authentication based on the values returned from the procedure.

To support the two protocols, Cisco Secure ACS provides different input to, and expects different output from, the ODBC authentication request. This requires a separate stored procedure in the relational database to support each protocol.

The Cisco Secure ACS product CD provides "stub" routines for creating a procedure in either Microsoft SQL Server or an Oracle database. You can either modify a copy of these routines to create your stored procedure or write your own. Example routines for creating PAP and CHAP/MS-CHAP/ARAP authentication stored procedures in SQL Server are given in Sample Routine for Generating a PAP Authentication SQL Procedure, and Sample Routine for Generating an SQL CHAP Authentication Procedure.

The following sections provide reference information about Cisco Secure ACS data types versus SQL data types, PAP authentication procedure inputs and outputs, CHAP/MS-CHAP/ARAP authentication procedure inputs and outputs, and expected result codes. You can use this information while writing your authentication stored procedures in your relational database.

Type Definitions

The Cisco Secure ACS types and their matching SQL types are as follows:

Microsoft SQL Server and Case-Sensitive Passwords

If you want your passwords to be case sensitive and are using Microsoft SQL Server as your ODBC-compliant relational database, configure your SQL Server to accommodate this feature. If your users are authenticating using PPP via PAP or Telnet login, the password might not be case sensitive, depending on how the case-sensitivity option is set on the SQL Server. For example, an Oracle database will default to case sensitive, whereas Microsoft SQL Server defaults to case insensitive. However, in the case of CHAP/ARAP, the password is case sensitive if the CHAP stored procedure is configured.

For example, with Telnet or PAP authentication, the passwords cisco or CISCO or CiScO will all work if the SQL Server is configured to be case insensitive.

For CHAP/ARAP, the passwords cisco or CISCO or CiScO are not the same, regardless of whether or not the SQL Server is configured for case-sensitive passwords.

Sample Routine for Generating a PAP Authentication SQL Procedure

The following example routine creates a procedure named CSNTAuthUserPap in Microsoft SQL Server, the default procedure used by Cisco Secure ACS for PAP authentication. Table and column names that could vary for your database schema are presented in variable text. For your convenience, the Cisco Secure ACS product CD includes a stub routine for creating a procedure in either SQL Server or Oracle. For more information about data type definitions, procedure parameters, and procedure results, see ODBC Database.

Sample Routine for Generating an SQL CHAP Authentication Procedure

The following example routine creates in Microsoft SQL Server a procedure named CSNTExtractUserClearTextPw, the default procedure used by Cisco Secure ACS for CHAP/MS-CHAP/ARAP authentication. Table and column names that could vary for your database schema are presented in variable text. For more information about data type definitions, procedure parameters, and procedure results, see ODBC Database.

PAP Authentication Procedure Input

Table 11-2 details the input provided by Cisco Secure ACS to the stored procedure supporting PAP authentication. The stored procedure should accept the named input values as variables.

The input names are for guidance only. Procedure variables created from them can have different names; however, they must be defined in the procedure in the order shown—the username must precede the password variable.

PAP Procedure Output

The stored procedure must return a single row containing the non-null fields. Table 11-3 lists the procedure results Cisco Secure ACS expects as output from stored procedure.

The CSNTGroup and CSNTacctInfo fields are processed only after a successful authentication. The CSNTerrorString file is logged only after a failure (if the result is greater than or equal to 4).

The procedure must return the result fields in the order listed above.

CHAP/MS-CHAP/ARAP Authentication Procedure Input

Cisco Secure ACS provides a single value for input to the stored procedure supporting CHAP/MS-CHAP/ARAP authentication. The stored procedure should accept the named input value as a variable.

Note   Because Cisco Secure ACS performs authentication for CHAP/MS-CHAP/ARAP, the user password is not an input (Table 11-4).

The input name is for guidance only. A procedure variable created from it can have a different name.

CHAP/MS-CHAP/ARAP Procedure Output

The stored procedure must return a single row containing the non-null fields. Table 11-5 lists the procedure results Cisco Secure ACS expects as output from stored procedure.

The CSNTGroup and CSNTacctInfo fields are processed only after a successful authentication. The CSNTerrorString file is logged only after a failure (if the result is greater than or equal to 4).

The procedure must return the result fields in the order listed above.

Result Codes

You can set the result codes listed in Table 11-6.

The SQL procedure can decide among 1, 2, or 3 to indicate a failure, depending on how much information you want the failed authentication log files to include.

A return code of 4 or higher results in an authentication error event. These errors do not increment per-user failed attempt counters. Additionally, error codes are returned to the AAA client so it can distinguish between errors and failures and, if configured to do so, fall back to a backup AAA server.

Successful or failed authentications are not logged; general Cisco Secure ACS logging mechanisms apply. In the event of an error (CSNTresult equal to or less than 4), the contents of the CSNTerrorString are written to the Windows Event Log under the Application Log.

Configuring a System Data Source Name for an ODBC External User Database

On the Cisco Secure ACS server, you must create a system DSN for Cisco Secure ACS to communicate with the relational database.

To create a system DSN for use with an ODBC external user database, follow these steps:

Step 2   In the ODBC Data Source Administrator window, click the System DSN tab.

Step 3   Click Add.

Step 4   Select the driver you need to use with your new DSN, and then click Finish.

Result: A dialog box displays fields requiring information specific to the ODBC driver you selected.

Step 5   Type a descriptive name for the DSN in the Data Source Name box.

Step 6   Complete the other fields required by the ODBC driver you selected. These fields may include information such as the IP address of the server on which the ODBC-compliant database runs.

Step 7   Click OK.

Result: The name you assigned to the DSN appears in the System Data Sources list.

Step 8   Close the ODBC window and Windows Control Panel.

Result: The system DSN to be used by Cisco Secure ACS for communication with the relational database is created on your Cisco Secure ACS server.

Configuring an ODBC External User Database

Creating an ODBC database configuration provides Cisco Secure ACS information that enables it to pass authentication requests to an ODBC-compliant relational database. This information reflects the way you have implemented your relational database and does not dictate how your relational database is configured or functions. For information about your relational database, refer to your relational documentation.

Note   Before performing this procedure, you should have completed the steps in Preparing to Authenticate Users with an ODBC-Compliant Relational Database.

To configure Cisco Secure ACS for ODBC authentication, follow these steps:

Step 2   Click Database Configuration.

Result: Cisco Secure ACS lists all possible external user database types.

Step 3   Click External ODBC Database.

Step 4   If you are creating a configuration, follow these steps:

Result: Cisco Secure ACS lists the new configuration in the External User Database Configuration table.

Step 5   Click Configure.

Step 6   From the System DSN list, select the DSN that is configured on the Cisco Secure ACS server to communicate with the ODBC-compliant relational database you want to use.

---

Note     If you have not configured on the Cisco Secure ACS server a DSN for the relational database, do so before completing these steps. For more information about creating a DSN for Cisco Secure ACS ODBC authentication, see Configuring a System Data Source Name for an ODBC External User Database.

---

Step 7   In the DSN Username box, type the username required to perform transactions with your ODBC database.

Step 8   In the DSN Password box, type the password required to perform transactions with your ODBC database.

Step 9   In the DSN Connection Retries box, type the number of times Cisco Secure ACS should try to connect to the ODBC database before timing out. The default is 3.

---

Note    If you have connection problems when Windows starts, increase this value.

---

Step 10   To change the ODBC worker thread count, in the ODBC Worker Threads box, type the number of ODBC worker threads. The maximum thread count is 10. The default is 1.

---

Note    Increase the ODBC worker thread count only if the ODBC driver you are using is certified thread safe. For example, the Microsoft Access ODBC driver is not thread safe and can cause Cisco Secure ACS to become unstable if multiple threads are used. Where possible, Cisco Secure ACS queries the driver to find out if it is thread safe. The thread count to use is a factor of how long the DSN takes to execute the procedure and the rate at which authentications are required.

---

Step 11   From the DSN Procedure Type list, select the type of output your relational database provides. Different databases return different output:

Step 12   To support PAP authentication with the ODBC database, follow these steps:

---

Note    If you enabled PAP authentication, the PAP authentication SQL procedure must exist on the ODBC database and must have the exact name specified in the PAP SQL Procedure box. If it does not, be sure to create it in the ODBC database before attempting to authenticate users against the ODBC database.

---

Step 13   To support CHAP authentication with the ODBC database, follow these steps:

---

Note    If you enabled CHAP/MS-CHAP/ARAP authentication, the CHAP authentication SQL procedure must exist on the ODBC database and must have the exact name specified in the PAP SQL Procedure box. If it does not, be sure to create it in the ODBC database before attempting to authenticate users against the ODBC database.

---

Step 14   Click Submit.

Result: Cisco Secure ACS saves the ODBC 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 Unknown User Processing. For more information about configuring user accounts to authenticate using this database, see "Setting Up and Managing User Accounts."

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-TLS authentication with a proxy RADIUS server. Other authentication protocols are not supported with LEAP Proxy RADIUS Server databases.

Note   Authentication protocols not supported with LEAP Proxy RADIUS Server databases may be supported by another type of external user database. For more information about authentication protocols and the external database types that support them, see Authentication Protocol-Database Compatibility.

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   The third-party RADIUS server must return Microsoft Point-to-Point Encryption (MPPE) keys in the Microsoft RADIUS vendor-specific attribute (VSA) MSCHAP-MPPE-Keys (VSA 12). If the third-party RADIUS server does not return the MPPE keys, the authentication fails and is logged in the Failed Attempts log.

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 2   Click Database Configuration.

Result: Cisco Secure ACS lists all possible external user database types.

Step 3   Click LEAP Proxy RADIUS Server.

Result: 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   If you are creating a configuration, follow these steps:

Result: Cisco Secure ACS lists the new configuration in the External User Database Configuration table.

Step 5   Under External User Database Configuration, select the name of the LEAP Proxy RADIUS Server database you need to configure.

---

Note    If only one LEAP Proxy RADIUS Server configuration exists, the name of that configuration appears instead of the list. Proceed to Step 6.

---

Step 6   Click Configure.

Step 7   In the following boxes, type the required information:

---

Note    If both the primary and the secondary servers fail, Cisco Secure ACS alternates between both servers until one responds.

---

Step 8   Click Submit.

Result: 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 Unknown User Processing. For more information about configuring user accounts to authenticate using this database, see "Setting Up and Managing User Accounts."

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 includes 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   Authentication protocols not supported with token server databases may be supported by another type of external user database. For more information about authentication protocols and the external database types that support them, see Authentication Protocol-Database Compatibility.

Requests from the AAA client are first sent to Cisco Secure ACS. If Cisco Secure 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, Cisco Secure ACS checks the database 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. Cisco Secure ACS then maintains the accounting information.

Cisco Secure ACS acts as a client to the token server. For all token servers except RSA SecurID, Cisco Secure ACS accomplishes this using the RADIUS interface of the token server. For more information about Cisco Secure ACS support of token servers with a RADIUS interface, see RADIUS-Enabled Token Servers.

For RSA SecurID, Cisco Secure ACS uses an RSA proprietary API. For more information about Cisco Secure ACS support of RSA SecurID token servers, see RSA SecurID Token Servers.

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 NT/2000 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.

RADIUS-Enabled Token Servers

This section describes Cisco Secure ACS support for token servers that provide a standard RADIUS interface.

About RADIUS-Enabled Token Servers

Cisco Secure ACS can support token servers using the RADIUS server built into 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. The token servers supported through their RADIUS servers are as follows:

---

Note    PassGo was formerly known as AXENT.

---

You can create multiple instances of each of these token server types in Cisco Secure ACS. For information about configuring Cisco Secure ACS to authenticate users with one of these token servers, see Configuring a RADIUS Token Server External User Database.

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 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 ActivCard, CRYPTOCard, Vasco, Safeword, PassGo, and RADIUS Token Server external user databases in Cisco Secure ACS.

Before You Begin

You should install and configure your RADIUS token server before configuring Cisco Secure 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 Cisco Secure ACS to authenticate users with a ActivCard token server, CRYPTOCard token server, Vasco token server, Safeword token server, PassGo token server, or generic RADIUS Token Sever, follow these steps:

Step 2   Click Database Configuration.

Result: Cisco Secure ACS lists all possible external user database types. The external user databases that represent RADIUS-enabled token servers are as follows:

---

Note    PassGo was formerly known as AXENT.

---

Step 3   Click the link for the applicable RADIUS-enabled token server.

Result: The Database Configuration Creation table appears. If at least one configuration exists for the selected external user database type, the External User Database Configuration table also appears.

Step 4   If you are creating a configuration, follow these steps:

Result: Cisco Secure ACS lists the new configuration in the External User Database Configuration table.

Step 5   Under External User Database Configuration, select the name of the RADIUS-enabled token server you need to configure.

---

Note    If only one RADIUS-enabled token server configuration exists, the name of that configuration appears instead of the list. Proceed to Step 6.

---

Step 6   Click Configure.

Step 7   In the RADIUS Configuration table, type the required information in the following boxes:

---

Note    For Cisco Secure ACS to send RADIUS OTP messages to a RADIUS-enabled token server, you must ensure that gateway devices between the RADIUS-enabled token server and Cisco Secure ACS allow communication over the UDP port specified in the Authentication Port box.

---

---

Note    If both the primary and the secondary servers fail, Cisco Secure ACS alternates between both servers until one responds.

---

Step 8   If you want to support token users performing a shell login to a TACACS+ AAA client, you must configure the options in the TACACS+ Shell Configuration table. Do one of the following:

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    If some tokens submitted to this server are synchronous tokens, you must use the Static (sync and async tokens) option.

---

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 Most token servers accept a blank password as the trigger to send a challenge prompt.

---

Note    You should only use the From Token Server (async tokens only) option if all tokens submitted to this token server are asynchronous tokens.

---

Step 9   Click Submit.

Result: Cisco Secure ACS saves the 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 Unknown User Processing. For more information about configuring user accounts to authenticate using this database, see "Setting Up and Managing User Accounts."

RSA SecurID Token Servers

Cisco Secure ACS supports ASCII, PAP, and PEAP(EAP-GTC) authentication for RSA SecurID token servers. Other authentication protocols are not supported with RSA SecurID external user databases.

Note   Authentication protocols not supported with RSA SecurID databases may be supported by another type of external user database. For more information about authentication protocols and the external database types that support them, see Authentication Protocol-Database Compatibility.

Cisco Secure ACS supports mapping users authenticated by a RSA token server to a single group. For more information, see Group Mapping by External User Database.

Cisco Secure ACS supports PPP (ISDN and async) and Telnet for RSA SecurID token servers. It does so by acting as a token-card client to the RSA SecurID token server. This requires that RSA token-card client software must be installed on the Cisco Secure ACS Windows 2000 server. The following procedure includes steps required to install the RSA client correctly on the Cisco Secure ACS Windows 2000 server.

Configuring an RSA SecurID Token Server External User Database

Cisco Secure ACS supports the RSA SecurID token server custom interface for authentication of users. You can create only one RSA SecurID configuration within Cisco Secure ACS.

Before You Begin

You should install and configure your RSA SecurID token server before configuring Cisco Secure ACS to authenticate users with it. For information about installing the RSA SecurID server, refer to the documentation included with your token server.

Make sure you have the RSA ACE Client for Windows 2000 software.

To configure Cisco Secure ACS to authenticate users with an RSA token server, follow these steps:

---

Note    Do not restart your Windows server when installation is complete.

---

For example:

\winnt\system32

\Windows directory\system32\drivers\etc\hosts

Step 2   In the navigation bar, click External User Databases.

Step 3   Click Database Configuration.

Result: Cisco Secure ACS lists all possible external user database types.

Step 4   Click RSA SecurID Token Server.

Result: If no RSA SecurID token server configuration exists, the Database Configuration Creation table appears. Otherwise, the External User Database Configuration page appears.

Step 5   If you are creating a configuration, follow these steps:

Result: Cisco Secure ACS lists the new configuration in the External User Database Configuration table.

Step 6   Click Configure.

Result: Cisco Secure ACS displays the name of the token server and the path to the authenticator DLL. This information confirms that Cisco Secure ACS can contact the RSA client. You can add the RSA SecurID external user database to your Unknown User Policy or assign specific user accounts to use this database for authentication. For more information about the Unknown User Policy, see Unknown User Processing. For more information about configuring user accounts to authenticate using this database, see "Setting Up and Managing User Accounts."

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 2   Click Database Configuration.

Result: Cisco Secure ACS lists all possible external user database types.

Step 3   Click the external user database type for which you want to delete a configuration.

Result: The External User Database Configuration table appears.

Step 4   If a list appears in the External User Database Configuration table, select the configuration you want to delete. Otherwise, proceed to Step 5.

Step 5   Click Delete.

Result: A confirmation dialog box appears.

Step 6   Click OK to confirm that you want to delete the selected external user database configuration.

Result: The external user database configuration you selected is deleted from Cisco Secure ACS.