Table of Contents

Working with User Databases

Cisco Secure Access Control Server for Windows NT/2000 Servers Version 3.0 (Cisco Secure ACS) 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. 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 NT/2000 Registry. The memory-mapped, hash-indexed file 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. See Figure 11-1.

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. If you have configured the Unknown User policy, Cisco Secure ACS does not rely on a username and password in the CiscoSecure user database for authentication. For more information about the Unknown User Policy feature, see the "Unknown User Processing" section. If you have configured specific user accounts to use an external user database to authenticate those users, Cisco Secure ACS uses information from the specified external user database to perform authentication. For more information about specifying an external user database for authentication of a user, see the "Adding a Basic User Account" section.

There are five ways to create user accounts in the CiscoSecure user database:

The CiscoSecure user database also 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 whose authentication is performed with an external user database, have an account in the CiscoSecure user database. As always, user settings override group settings.

If you implement an external user database, Cisco Secure ACS offers two powerful features that you must configure. The first feature is the Unknown User Policy. This feature automates the creation of user accounts in the CiscoSecure user database for users authenticated by an external user database. The other feature is Cisco Secure ACS user group mappings for users authenticated by external user databases. For information on these features, see "Administering External User Databases."

The CiscoSecure user database supports authentication for PAP, CHAP, MS-CHAP, ARAP, LEAP, and ASCII passwords. It also supports the certificate-based EAP-TLS authentication protocol.

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. Users can be authenticated using the following databases.

Regardless of which database is used to authenticate users, the CiscoSecure user database, internal to Cisco Secure ACS, is used to authorize requested network services.

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, Generic LDAP, and Novell NDS authentication, the program interface for the external authentication is local to the Cisco Secure ACS system and is provided by the local operating system. In these cases, no further components are required.

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 server.

To communicate with each traditional token server, you must have software components provided by the OTP vendors installed, in addition to the Cisco Secure ACS components. You must also specify in User Setup that a token card server is to be used.

For RADIUS-based token servers, such as ActivCard, CRYPTOCard, 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 is to 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.

Windows NT/2000 User Database

Cisco Secure ACS supports PAP and MS-CHAP authentication with Windows NT 4.0 Security Accounts Manager (SAM) database or a Windows 2000 Active Directory database. Cisco Secure ACS supports EAP-TLS authentication with a Windows 2000 Active Directory database. You can configure Cisco Secure ACS to authenticate usernames and passwords against those already in a Windows NT/2000 user database. In organizations in which a substantial Windows NT/2000 user database already exists, Cisco Secure ACS can leverage the work already invested in building the database without any additional input. This eliminates the need for separate databases.

This section contains the following topics:

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

Cisco Secure ACS forwards user authentication requests to a Windows NT/2000 database in one of two scenarios. The first scenario is when the user's account in the CiscoSecure user database lists a Windows NT/2000 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 a Windows NT/2000 database is the next external user database to try.

In either case, Cisco Secure ACS forwards the username and password to the Windows NT/2000 database. 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. See Figure 11-2.

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 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.

For the most secure authentication with Windows NT/2000 user databases, use MS-CHAP.

Trust Relationships

Cisco Secure ACS can take advantage of trust relationships that have been established between Windows NT/2000 servers. If the domain that contains the Cisco Secure ACS server 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.

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 and Windows 95/98/Millennium Edition (ME) allow users to connect to your network remotely, but the fields provided differ.

About the Windows NT/2000 Dial-up Networking Client

If you use the Windows NT/2000 Dial-Up Networking client to dial in to the AAA client, three fields appear:

---

Note    For more information about the implications of completing or leaving the domain field blank, see the "Windows NT/2000 Authentication" section.

---

About the Windows 95/98/Millennium Edition Dial-up Networking Client

If you use the Windows 95/98/ME Dial-Up Networking client to dial in to the AAA client, two fields appear:

---

Note    You also have the option of prefixing 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 the "Windows NT/2000 Authentication" section.

---

Windows NT/2000 Authentication

While the Windows NT/2000 and Windows 95/98/ME 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 Windows NT/2000 dial-up client, this is accomplished by typing the domain in the domain field (or selecting it from the drop-down list). With the Windows 95/98/ME dial-up client, 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 For Windows 95/98/ME and Windows NT/2000, entering the domain name can speed up authentication, because Cisco Secure ACS can go directly to the domain rather than searching 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.

If you do not specify a domain name when typing the username, Cisco Secure ACS submits the username to the Windows NT/2000 operating system on the Cisco Secure ACS server. If the Windows NT/2000 server does not find the username in its local database, it then checks all trusted domains. If the password of the first occurrence of the username in the trusted domains does not match the password submitted by Cisco Secure ACS, authentication fails. If the Domain List in the Windows NT/2000 User Database Configuration of the External User Databases section has been configured with a list of trusted domains, 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 your network's trusted domains, 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 new 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 dial-in 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   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 —>.

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

Generic LDAP

Cisco Secure ACS supports PAP and EAP-TLS authentication via generic Lightweight Directory Access Protocol (LDAP) databases, such as Netscape Directory Services. Configuring Cisco Secure ACS to authenticate against an LDAP database does not affect 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 user authentication requests to an LDAP database in one of two scenarios. The first scenario is when the user's account in the CiscoSecure user database lists an LDAP 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 LDAP database is the next external user database to try.

In either case, Cisco Secure ACS forwards the username and password to the LDAP database. 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. See Figure 11-3.

Multiple LDAP Instances

You can create several LDAP configurations in Cisco Secure ACS. For each LDAP configuration, you can add or leave it out of the Unknown User Policy. Also for each LDAP configuration, you can establish unique group mapping.

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.

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 the "Database Group Mappings" section.

Directed Authentications

You can configure Cisco Secure ACS to filter user authentications that it submits to LDAP databases. Filtering is based on a string of characters either at the beginning or end of the username submitted for authentication. This enables you to have greater control over which LDAP instance Cisco Secure ACS submits user authentication requests. For example, you could configure a different LDAP instance per domain in your network and direct the authentications for each as applicable.

Depending upon how an LDAP database is configured, the different LDAP instances in Cisco Secure ACS can authenticate users using the same LDAP database but with different contexts. Using directed authentications in conjunction with this flexibility allows you to specify which user and group directory subtrees the LDAP database uses to authenticate users of a given domain.

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 the Cisco Secure ACS server. 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 the "Configuring a Generic LDAP External User Database" section.

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

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

Configuring a Generic LDAP External User Database

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

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

Step 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 the next step.

---

Step 6   Click Configure.

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

Step 7   To enable Cisco Secure ACS to process LDAP authentications without domain filtering, from the Filter Domains list, select No.

Step 8   To enable Cisco Secure ACS to direct LDAP authentications by filtering on the beginning of a username, follow these steps:

For example, if users to be authenticated by this LDAP configuration submit a username that begins with "ofc1-", such as ofc1-stanley or ofc1-mwiliams, type ofc1- in the Domain Markup box.

Step 9   To enable Cisco Secure ACS to direct LDAP authentications by filtering on the end of a username, follow these steps:

For example, if users to be authenticated by this LDAP configuration submit a username that ends with "@mydomain.com", such as stanley@mydomain.com or mwiliams@mydomain.com, in the Domain Markup box, type @mydomain.com.

Step 10   In the User Directory Subtree box, type the following:

where subtree is the tree in which all of your users are located. This is configured when you set up your LDAP database. For more information, refer to your LDAP database documentation.

---

Note    Your users could be located under an organizational unit rather than an organization. If this is the case, type ou= subtree in the User Directory Subtree.

---

Step 11   In the Group Directory Subtree box, type the following:

where subtree is the tree in which all of your groups are located. This can be the same location as the user subtree, entered in the User Directory Subtree box. This is configured when you set up your LDAP database. For more information, refer to your LDAP database documentation.

---

Note    Your groups could be located under an organizational unit rather than an organization. If this is the case, in the Group Directory Subtree, type ou=subtree.

---

Step 12   In the User Object Type box, type the name of the attribute in the user record that contains the user name. 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's 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 the "LDAP Failover" section.

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, 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 the "Unknown User Processing" section. 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 PAP authentication with Novell NetWare Directory Services (NDS) servers. To use NDS authentication, you must have a Novell NDS database. 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 the "Generic LDAP" section.

To authenticate users with a Novell NDS database, Cisco Secure ACS depends upon Novell Requestor. Novell Requestor must be installed on the same Windows NT/2000 server as Cisco Secure ACS. You can download the Requestor software from the Novell web site. 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.

This section contains the following topics:

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:

then 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 the "User Contexts" section.

---

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 displays a list of 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 the "Novell NDS External User Database Options" section.

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

ODBC Database

Cisco Secure ACS supports PAP, CHAP, MS-CHAP, and ARAP authentication using a relational database via the ODBC authenticator feature. As with Windows NT/2000 database support, Cisco Secure ACS's 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:

Cisco Secure ACS Authentication Process with an ODBC External User Database

Cisco Secure ACS forwards user authentication requests to an ODBC database in one of two scenarios. The first scenario is when the user's 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. See Figure 11-4. 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. See Figure 11-4.

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 the "Implementation of Stored Procedures for ODBC Authentication" section.

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

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

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 the "Sample Routine for Generating a PAP Authentication SQL Procedure" section and the "Sample Routine for Generating an SQL CHAP Authentication Procedure" section.

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. 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 the "ODBC Database" section.

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's schema are presented in variable text. For more information about data type definitions, procedure parameters, and procedure results, see the "ODBC Database" section.

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's password is not an input. See 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 NT/2000 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 is a process that 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 the "Preparing to Authenticate Users with an ODBC-Compliant Relational Database" section 11-32.

To configure Cisco Secure ACS for ODBC authentication, 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 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 the "Configuring a System Data Source Name for an ODBC External User Database" section.

---

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 NT/2000 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 the "Unknown User Processing" section. 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 MS-CHAP and EAP-TLS authentication with a proxy RADIUS server. 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 support RADIUS-based group mapping for users authenticated by LEAP Proxy RADIUS Server databases. For more information, see the "RADIUS-Based Group Specification" section.

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 displays a list of 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 LDAP 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 the next step.

---

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 the "Unknown User Processing" section. 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 PAP authentication using token servers. Requests from the access device 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 access device 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 the token servers supported, Cisco Secure ACS accomplishes this in one of two ways. The first method uses the token server's RADIUS interface. For more information about Cisco Secure ACS support of token servers with a RADIUS interface, see the "RADIUS-Enabled Token Servers" section.

For some token servers, Cisco Secure ACS uses the token server vendor's proprietary API. For more information about Cisco Secure ACS support of token servers using the token server vendor's proprietary API, see the "Token Servers with Vendor-Proprietary Interfaces" section.

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 vendor's proprietary API, 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:

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 the "Configuring a RADIUS Token Server External User Database" section.

Cisco Secure ACS also supports any token server that is a RADIUS server compliant with IETF RFC 2865. So, in addition to the RADIUS-enabled token server vendors explicitly supported, this enables you to use any token server that supports RADIUS-based authentication.

Although Cisco Secure ACS supports mapping users authenticated by a RADIUS-enabled token server to a single group, Cisco Secure ACS also provides a means for specifying a user's group assignment in the RADIUS response from the RADIUS-enabled token server. For more information, see the "RADIUS-Based Group Specification" section.

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 following three responses:

Configuring a RADIUS Token Server External User Database

Use this procedure to configure ActivCard, CRYPTOCard, Vasco, 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, or generic RADIUS Token Sever, follow these steps:

Step 2   Click Database Configuration.

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

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

Token Servers with Vendor-Proprietary Interfaces

Cisco Secure ACS supports several token servers by communicating via the token server vendor's proprietary API.

About Token Servers with Proprietary Interfaces

For token servers supported by using the token server vendor's proprietary API, Cisco Secure ACS acts as a token-card client to the token server. In some cases, this means that the token-card client software is installed on the Cisco Secure ACS server. In others, you must provide Cisco Secure ACS with information about the token server. The token servers supported through their vendor's proprietary API are as follows:

Configuring a SafeWord Token Server External User Database

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

Before You Begin

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

To configure Cisco Secure ACS to authenticate users with a SafeWord token server, 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 SafeWord Token Server.

Result: If no SafeWord token server 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.

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

Step 7   Click Submit.

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

Configuring an AXENT Token Server External User Database AXENT

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

Before You Begin

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

To configure Cisco Secure ACS to authenticate users with an AXENT token server, 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 AXENT Token Server.

Result: If no AXENT token server 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.

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

Step 7   Click Submit.

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

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.

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

For example:

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

Step 3   Click Database Configuration.

Result: Cisco Secure ACS displays a list of 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 the "Unknown User Processing" section. 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 displays a list of 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 the next step.

Step 5   Click Delete.

Result: A confirmation dialog box appears.

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

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