User Guide for Cisco Secure ACS for Windows Server Version 3.3
User Databases

Table Of Contents

User Databases

CiscoSecure User Database

About the CiscoSecure User Database

User Import and Creation

About External User Databases

Authenticating with External User Databases

External User Database Authentication Process

Windows User Database

What's Supported with Windows User Databases

Authentication with Windows User Databases

Trust Relationships

Windows Dial-up Networking Clients

Windows Dial-up Networking Clients with a Domain Field

Windows Dial-up Networking Clients without a Domain Field

Usernames and Windows Authentication

Username Formats and Windows Authentication

Non-domain-qualified Usernames

Domain-Qualified Usernames

UPN Usernames

EAP and Windows Authentication

EAP-TLS Domain Stripping

Machine Authentication

Machine Access Restrictions

Microsoft Windows and Machine Authentication

Enabling Machine Authentication

User-Changeable Passwords with Windows User Databases

Preparing Users for Authenticating with Windows

Windows User Database Configuration Options

Configuring a Windows External User Database

Generic LDAP

Cisco Secure ACS Authentication Process with a Generic LDAP User Database

Multiple LDAP Instances

LDAP Organizational Units and Groups

Domain Filtering

LDAP Failover

Successful Previous Authentication with the Primary LDAP Server

Unsuccessful Previous Authentication with the Primary LDAP Server

LDAP Configuration Options

Configuring a Generic LDAP External User Database

Novell NDS Database

About Novell NDS User Databases

User Contexts

Novell NDS External User Database Options

Configuring a Novell NDS External User Database

ODBC Database

What is Supported with ODBC User Databases

Cisco Secure ACS Authentication Process with an ODBC External User Database

Preparing to Authenticate Users with an ODBC-Compliant Relational Database

Implementation of Stored Procedures for ODBC Authentication

Type Definitions

Microsoft SQL Server and Case-Sensitive Passwords

Sample Routine for Generating a PAP Authentication SQL Procedure

Sample Routine for Generating an SQL CHAP Authentication Procedure

Sample Routine for Generating an EAP-TLS Authentication Procedure

PAP Authentication Procedure Input

PAP Procedure Output

CHAP/MS-CHAP/ARAP Authentication Procedure Input

CHAP/MS-CHAP/ARAP Procedure Output

EAP-TLS Authentication Procedure Input

EAP-TLS Procedure Output

Result Codes

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

Configuring an ODBC External User Database

LEAP Proxy RADIUS Server Database

Configuring a LEAP Proxy RADIUS Server External User Database

Token Server User Databases

About Token Servers and Cisco Secure ACS

Token Servers and ISDN

RADIUS-Enabled Token Servers

About RADIUS-Enabled Token Servers

Token Server RADIUS Authentication Request and Response Contents

Configuring a RADIUS Token Server External User Database

RSA SecurID Token Servers

Configuring an RSA SecurID Token Server External User Database

Deleting an External User Database Configuration


User Databases


Cisco Secure ACS for Windows Server authenticates users against one of several possible databases, including its internal database. You can configure Cisco Secure ACS to authenticate users with more than one type of database. This flexibility enables you to use user accounts data collected in different locations without having to explicitly import the users from each external user database into the CiscoSecure user database. It also enables you to apply different databases to different types of users, depending on the security requirements associated with user authorizations on your network. For example, a common configuration is to use a Windows user database for standard network users and a token server for network administrators.


Note For information about the Unknown User Policy and group mapping features, see "Unknown User Policy" and "User Group Mapping and Specification".


This chapter contains the following topics:

CiscoSecure User Database

About External User Databases

Windows User Database

Generic LDAP

Novell NDS Database

ODBC Database

LEAP Proxy RADIUS Server Database

Token Server User Databases

Deleting an External User Database Configuration

CiscoSecure User Database

The CiscoSecure user database is the database internal to Cisco Secure ACS. It supports authentication using ASCII, PAP, CHAP, MS-CHAP, ARAP, LEAP, EAP-MD5, EAP-TLS, PEAP(EAP-GTC), PEAP(EAP-MSCHAPv2), and EAP-FAST (phase zero and phase two).

The CiscoSecure user database is crucial for the authorization process. Regardless of whether a user is authenticated by the internal user database or by an external user database, Cisco Secure ACS authorizes network services for users based upon group membership and specific user settings found in the CiscoSecure user database. Thus, all users authenticated by Cisco Secure ACS, even those authenticated by an external user database, have an account in the CiscoSecure user database.

About the CiscoSecure User Database

The CiscoSecure user database draws information from several 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.

For users authenticated using the CiscoSecure user database, Cisco Secure ACS stores user passwords in an encrypted format, using RC2 encryption with a 40-bit key. For users authenticated with external user databases, Cisco Secure ACS does not store passwords in the CiscoSecure user database.

Unless you have configured Cisco Secure ACS to authenticate users with an external user database, Cisco Secure ACS uses usernames and passwords in the CiscoSecure user database during authentication. For more information about specifying an external user database for authentication of a user, see Adding a Basic User Account.

User Import and Creation

There are five ways to create user accounts in the in Cisco Secure ACS for Windows 2000 Servers. Of these, RDBMS Synchronization and CSUtil.exe support importing user accounts from external sources.

Cisco Secure ACS HTML interface—The HTML interface provides the ability to create user accounts manually, one user at a time. Regardless of how a user account was created, you can edit a user account by using the HTML interface. For detailed steps, see Adding a Basic User Account.

Unknown User Policy—The Unknown User Policy enables Cisco Secure ACS to add users automatically when a user without an account in the is found in an external user database. The creation of a user account in the occurs only when the user attempts to access the network and is successfully authenticated by an external user database. For more information, see "Unknown User Policy".

If you use Unknown User Policy, you can also configure group mappings so that each time a user added to the by Unknown User Policy is authenticated, the user group assignment is made dynamically. For some external user database types, user group assignment is based on group membership in the external user database. For other database types, all users authenticated by a given database are assigned to a single Cisco Secure ACS user group. For more information about group mapping, see "User Group Mapping and Specification".

RDBMS Synchronization—RDBMS Synchronization enables you to create large numbers of user accounts and to configure many settings for user accounts. We recommend using this feature whenever you need to import users by bulk; however, setting up RDBMS Synchronization for the first time requires several important decisions and time to implement them. For more information, see RDBMS Synchronization.

CSUtil.exe—The CSUtil.exe command-line utility provides a simple means of creating basic user accounts. When compared to RDBMS Synchronization, its functionality is limited; however, it is simple to prepare for importing basic user accounts and assigning users to groups. For more information, see "CSUtil Database Utility".

Database Replication—Database Replication creates user accounts on a secondary Cisco Secure ACS by overwriting all existing user accounts on a secondary Cisco Secure ACS with the user accounts from the primary Cisco Secure ACS. Any user accounts unique to a secondary Cisco Secure ACS are lost in the replication. For more information, see CiscoSecure Database Replication.

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 "User Group Mapping and Specification".


Users can be authenticated using the following databases:

Windows Database

Generic LDAP

Novell NetWare Directory Services (NDS)

Open Database Connectivity (ODBC)-compliant relational databases

LEAP Proxy RADIUS servers

RSA SecurID token servers

RADIUS-compliant token servers

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 user databases 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 token servers by other vendors, 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:

By Specific User Assignment—You can configure Cisco Secure ACS to authenticate specific users with an external user database. To do this, the user must exist in the CiscoSecure user database and the Password Authentication list in User Setup must be set to the external user database that Cisco Secure ACS should use to authenticate the user.

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.

By Unknown User Policy—You can configure Cisco Secure ACS to attempt authentication of users not found in the CiscoSecure user database by using an external user database. Users do not need to be defined in the CiscoSecure user database for this method. For more information about the Unknown User Policy, see About Unknown User Authentication.

You can also configure Cisco Secure ACS with both methods above; these two methods are not mutually exclusive.

External User Database Authentication Process

When Cisco Secure ACS attempts user authentication with an external user database, it forwards the user credentials to the external user database. The external user database either passes or fails the authentication request from Cisco Secure ACS. Upon receiving the response from the external user database, Cisco Secure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the external user database. Figure 13-1 shows a AAA configuration with an external user database.

Figure 13-1 A Simple AAA Scenario

The specifics of the method used to communicate with the external user database vary with the database type. For LDAP and Novell NDS, Cisco Secure ACS uses TCP connections. For Windows user databases, Cisco Secure ACS uses the authentication API provided in the Windows operating system. 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 User Database

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

This section contains the following topics:

What's Supported with Windows User Databases

Authentication with Windows User Databases

Trust Relationships

Windows Dial-up Networking Clients

Windows Dial-up Networking Clients with a Domain Field

Windows Dial-up Networking Clients without a Domain Field

Usernames and Windows Authentication

Username Formats and Windows Authentication

Non-domain-qualified Usernames

Domain-Qualified Usernames

UPN Usernames

EAP and Windows Authentication

EAP-TLS Domain Stripping

Machine Authentication

Machine Access Restrictions

Microsoft Windows and Machine Authentication

Enabling Machine Authentication

User-Changeable Passwords with Windows User Databases

Preparing Users for Authenticating with Windows

Windows User Database Configuration Options

Configuring a Windows External User Database

What's Supported with Windows User Databases

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

User Authentication—Cisco Secure ACS supports ASCII, PAP, MS-CHAP (versions 1 and 2), LEAP, PEAP(EAP-GTC), PEAP(EAP-MSCHAPv2), and EAP-FAST (phase zero and phase two) authentication with Windows Security Accounts Manager (SAM) database or a Windows Active Directory database. Cisco Secure ACS also supports EAP-TLS authentication with a Windows Active Directory database. Other authentication protocols are not supported with Windows external user databases.


Note Authentication protocols not supported with Windows 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.


Machine Authentication—Cisco Secure ACS supports machine authentication with EAP-TLS and PEAP(EAP-MSCHAPv2). For more information, see EAP and Windows Authentication.

Group Mapping for Unknown Users—Cisco Secure ACS supports group mapping for unknown users by requesting group membership information from Windows user databases. For more information about group mapping for users authenticated with a Windows user database, see Group Mapping by Group Set Membership.

Password-Aging—Cisco Secure ACS supports password aging for users authenticated by a Windows user database. For more information, see User-Changeable Passwords with Windows User Databases.

Dial-in Permissions—Cisco Secure ACS supports use of dial-in permissions from Windows user databases. For more information, see Preparing Users for Authenticating with Windows.

Callback Settings—Cisco Secure ACS supports use of callback settings from Windows user databases. For information about configuring Cisco Secure ACS to use Windows callback settings, see Setting User Callback Option.

Authentication with Windows User Databases

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

To further control access by a user, 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 denied, even if the username and password are typed correctly.

Trust Relationships

Cisco Secure ACS can take advantage of trust relationships that have been established between Windows domains. If the domain 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 Installation Guide for Cisco Secure ACS for Windows Server.


Cisco Secure ACS can take advantage of indirect trusts for Windows authentication. Consider the example of Windows domains A, B, and C, where Cisco Secure ACS resides on a server in domain A. Domain A trusts domain B, but no trust relationship is established between domain A and domain C. If domain B trusts domain C, Cisco Secure ACS in domain A can authenticate users whose accounts reside in domain C, making use of the indirect trust of domain C.

For more information on trust relationships, refer to your Microsoft Windows documentation.

Windows Dial-up Networking Clients

The dial-up networking clients for Windows NT/2000/XP Professional and Windows 95/98/Millennium Edition (ME)/XP Home enable users to connect to your network remotely, but the fields provided differ.

Windows Dial-up Networking Clients with a Domain Field

If users dial in to your network using the dial-up networking client provided with Windows NT, Windows 2000, or Windows XP Professional, three fields appear:

username—Type your username.

password—Type your password.

domain—Type your valid domain name.


Note For more information about the implications of completing or leaving the domain box blank, see Non-domain-qualified Usernames.


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:

username—Type your username.


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 Non-domain-qualified Usernames.


password—Type your password.

Usernames and Windows Authentication

This section contains the following topics:

Username Formats and Windows Authentication

Non-domain-qualified Usernames

Domain-Qualified Usernames

UPN Usernames

Username Formats and Windows Authentication

Cisco Secure ACS supports Windows authentication for usernames in a variety of formats. When Cisco Secure ACS attempts Windows authentication, it first determines the username format and submits the username to Windows in the applicable manner. To implement reliable Windows authentication with Cisco Secure ACS, you need to understand how Cisco Secure ACS determines username format, how it supports for each of these formats, and how the types of support are related.

To determine the format of a username submitted for Windows authentication, Cisco Secure ACS searches the username for the presence of the following two special characters:

@ (the "at" character)

\ (the "backslash" character)

Based upon the presence and position of these two characters in the username, Cisco Secure ACS determines username format as follows:

1. If the username does not contain a "backslash" character and does not contain an "at" character, Cisco Secure ACS considers the username to be non-domain qualified. For example, the username cyril.yang is non-domain qualified. For more information, see Non-domain-qualified Usernames.

2. If the username contains a "backslash" character that precedes any "at" characters, Cisco Secure ACS considers the username to be domain qualified. For example, Cisco Secure ACS considers the following usernames to be domain qualified:

MAIN\cyril.yang

MAIN\cyril.yang@central-office

For more information, see Domain-Qualified Usernames.

3. If the username contains an "at" character that is not preceded by a "backslash" character, Cisco Secure ACS considers the username to be in UPN format. For example, Cisco Secure ACS considers the following usernames to be UPN usernames:

cyril.yang@example.com

cyril.yang@main.example.com

cyril.yang@main

cyril.yang@central-office@example.com

cyril.yang@main\example.com

For more information, see UPN Usernames.

Non-domain-qualified Usernames

Cisco Secure ACS supports Windows authentication of usernames that are not domain qualified, provided the username does not contain an "at" character. Users with "at" characters in their usernames must either submit the username in UPN format or in a domain-qualified format. Examples of non-domain-qualified usernames are cyril.yang and msmith.

In Windows environments with multiple domains, authentication results with non-domain-qualified usernames can vary. This is because Windows, not Cisco Secure ACS, determines which domains are used to authenticate a non-domain-qualified username. If Windows does not find the username in its local domain database, it then checks all trusted domains. If Cisco Secure ACS runs on a member server and the username is not found in trusted domains, Windows also checks its local accounts database. Windows attempts to authenticate a user with the first occurrence of the username that it finds.

When Windows authentication for a non-domain-qualified username succeeds, the privileges assigned upon authentication will be those associated with the Windows user account in the first domain with a matching username and password. This also illustrates the importance of removing usernames from a domain when the user account is no longer needed.


Note 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 User Database Configuration page of the External User Databases section, Cisco Secure ACS submits the username and password to each domain in the list in a domain-qualified format until it successfully authenticates the user. If Cisco Secure ACS has tried each domain listed in the Domain List or if no trusted domains have been configured in the Domain List, Cisco Secure ACS stops attempting to authenticate the user and does not grant that user access.


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


Domain-Qualified Usernames

The most reliable method of authenticating users against a specific domain is to require users to submit the domains they should be authenticated against along with their usernames. Authentication of a domain-qualified username is directed to a specific domain rather than depending upon Windows to attempt authentication with the correct domain or upon using the Domain List to direct Cisco Secure ACS to submit the username repeatedly in a domain-qualified format.

Domain-qualified usernames have the following format:

DOMAIN\user 

For example, the domain-qualified username for user Mary Smith (msmith) in Domain10 would be Domain10\msmith.

For usernames containing an "at" character, such as cyril.yang@central-office, using a domain-qualified username format is required. For example, MAIN\cyril.yang@central-office. If a username containing an "at" character is received in a non-domain-qualified format, Cisco Secure ACS perceives it as a username in UPN format. For more information, see UPN Usernames.

UPN Usernames

Cisco Secure ACS supports authentication of usernames in User Principal Name (UPN) format, such as cyril.yang@example.com or cyril.yang@central-office@example.com.

If the authentication protocol used is EAP-TLS, by default, Cisco Secure ACS submits the username to Windows in UPN format; however, you can configure Cisco Secure ACS to strip from the username all characters after and including the last "at" character (@). For more information, see EAP-TLS Domain Stripping.

For all other authentication protocols that it can support with Windows databases, Cisco Secure ACS submits to Windows the username stripped of all characters after and including the last "at" character (@). This behavior allows for usernames that contain an "at" character. For example:

If the username received is cyril.yang@example.com, Cisco Secure ACS submits to Windows an authentication request containing the username cyril.yang.

If the username received is cyril.yang@central-office@example.com, Cisco Secure ACS submits to Windows an authentication request containing the username cyril.yang@central-office.


Note Cisco Secure ACS cannot tell the difference between a non-domain-qualified username that contains an "at" character and a UPN username; all usernames containing an "at" character that are not preceded by a "backslash" character are submitted to Windows with the final "at" character and the characters that follow it removed. Users with "at" characters in their usernames must either submit the username in UPN format or in a domain-qualified format.


EAP and Windows Authentication

This section provides information about Windows-specific EAP features that you can configure on the Windows User Database Configuration page.

This section contains the following topics:

EAP-TLS Domain Stripping

Machine Authentication

Machine Access Restrictions

Microsoft Windows and Machine Authentication

Enabling Machine Authentication

EAP-TLS Domain Stripping

If you use Windows Active Directory to authenticate users with EAP-TLS, Cisco Secure ACS enables you to strip the domain name from the username stored in the Subject Alternative Name field of the user certificate. Performing domain name stripping can speed EAP-TLS authentication when the domain that must authenticate a user is not the domain represented in the SAN field.

For example, a user's SAN field may contain "jsmith@corporation.com" but jsmith may need to authenticate using the domain controller for a subdomain named "engineering". Stripping "@corporation.com" from the username eliminates the needless attempt at authenticating jsmith against the corporation.com domain controller. Without stripping the domain name, only after jsmith cannot be found in corporation.com will Cisco Secure ACS use the Domain List and find the user in the engineering domain. The additional delay could be several seconds. For more information about the Domain List, see Non-domain-qualified Usernames.

You can enable EAP-TLS domain name stripping on the Windows User Database Configuration page.


Note EAP-TLS domain name stripping operates independently of support for UPN-formatted usernames. For information about support for Windows authentication of UPN-formatted usernames, see UPN Usernames.


Machine Authentication

Cisco Secure ACS supports the authentication of computers running Microsoft Windows operating systems that support EAP computer authentication, such as Windows XP with Service Pack 1. Machine authentication, also called computer authentication, allows networks services only for computers known to Active Directory. This is especially useful for wireless networks, where unauthorized users outside the physical premises of your workplace can access your wireless access points.

When machine authentication is enabled, there are three different types of authentications. Upon starting up a computer, the authentications occur in the following order:

Machine authentication—The computer is authenticated by Cisco Secure ACS prior to user authentication. Cisco Secure ACS checks the credentials provided by the computer against the Windows user database. If you use Active Directory and the matching computer account in Active Directory has the same credentials, the computer gains access to Windows domain services.

User domain authentication—If machine authentication succeeded, the user is authenticated by the Windows domain. If machine authentication failed, the computer does not have access to Windows domain services and the user credentials are authenticated using cached credentials kept by the local operating system. When a user is authenticated by cached credentials instead of the domain, the computer does not enforce domain policies, such as running login scripts dictated by the domain.


Tip If a computer fails machine authentication and the user hasn't successfully logged in to the domain using the computer since the most recent user password change, the cached credentials on the computer will not match the new password. Instead, the cached credentials will match an older password of the user, provided that the user once logged in to the domain successfully from this computer.


User network authentication—The user is authenticated by Cisco Secure ACS, allowing the user to have network connectivity. If the user profile exists, the user database specified is used to authenticate the user. While the user database is not required to be the Windows user database, most Microsoft clients can be configured to automatically perform network authentication using the same credentials used for user domain authentication. This allows for a single sign-on.


Note Microsoft PEAP clients also initiate machine authentication whenever a user logs off. This prepares the network connection for the next user login. Microsoft PEAP clients may also initiate machine authentication when a user has selected to shutdown or restart the computer rather than just logging off.


Cisco Secure ACS supports both EAP-TLS and PEAP(EAP-MSCHAPv2) for machine authentication. You can enable each separately on the Windows User Database Configuration page, which allows a mix of computers authenticating with EAP-TLS or with PEAP(EAP-MSCHAPv2). Microsoft operating systems that perform machine authentication may limit the user authentication protocol to the same protocol used for machine authentication. For more information about Microsoft operating systems and machine authentication, see Microsoft Windows and Machine Authentication.

The Unknown User Policy supports machine authentication. Computers previously unknown to Cisco Secure ACS are handled similarly to users. If the Unknown User Policy is enabled and an Active Directory external user database is included on the Selected Databases list on the Configure Unknown User Policy page, machine authentication succeeds, provided that the machine credentials presented to Active Directory are valid.

On a computer configured to perform machine authentication, machine authentication occurs when the computer started. Provided that the AAA client sends RADIUS accounting data to Cisco Secure ACS, when a computer is started and before a user logs in on that computer, the computer appears on the Logged-In Users List in the Reports and Activity section. Once user authentication begins, the computer no longer appears on the Logged-In Users List.

PEAP-based machine authentication uses PEAP(EAP-MSCHAPv2) and the password for the computer established automatically when it was added to the Microsoft Windows domain. The computer sends its name as the username and the format is:

host/computer.domain 

where computer is the name of the computer and domain is the domain the computer belongs to. The domain segment may include subdomains, too, if they are used, so that the format may be:

host/computer.subdomain.domain 

The usernames of computers authenticated must appear in the CiscoSecure user database. If you enable unknown user processing, Cisco Secure ACS adds them automatically once they authenticate successfully. During authentication, the domain name is not used.

EAP-TLS-based machine authentication uses EAP-TLS to authenticate the computer using a client certificate. The certificate used by the computer can be one installed automatically when the computer was added to the domain or one that was added to the local machine storage later. As with PEAP-based machine authentication, the computer name must appear in the CiscoSecure user database in the format contained in the computer client certificate and the user profile corresponding to the computer name must be configured to authenticate using the Windows external user database. If you enable unknown user processing, Cisco Secure ACS adds the computer names to the CiscoSecure user database automatically once they authenticate successfully. It also automatically configures the user profiles created to use the external user database that the user was found in. For machine authentication, this will always be the Windows external user database.

Machine Access Restrictions

You can use the machine access restrictions (MAR) feature as an additional means of controlling authorization for Windows-authenticated EAP-TLS and Microsoft PEAP users, based upon machine authentication of the computer used to access the network. When you enable the MAR feature, Cisco Secure ACS does the following:

For every successful machine authentication, Cisco Secure ACS caches the value received in IETF RADIUS Calling-Station-Id attribute (31) as evidence of the successful machine authentication. Cisco Secure ACS stores each Calling-Station-Id attribute value for the number of hours specified on the Windows User Database Configuration page before deleting it from the cache.

When a user authenticates with an EAP-TLS or Microsoft PEAP end-user client, Cisco Secure ACS searches the cache of Calling-Station-Id values from successful machine authentications for the Calling-Station-Id value received in the user authentication request. Whether Cisco Secure ACS finds the user-authentication Calling-Station-Id value in the cache affects how Cisco Secure ACS assigns the user requesting authentication to a user group.

Calling-Station-Id value found in the cache—Cisco Secure ACS assigns the user to a user group by normal methods, which include manual specification of a group in the user profile, group mapping, or RADIUS-based group specification. For example, if a user logs in with a computer that was successfully authenticated and the user profile indicates that the user is a member of group 137, Cisco Secure ACS applies to the user session the authorization settings specified in group 137.

Calling-Station-Id value not found in the cache—Cisco Secure ACS assigns the user to the user group specified by "Group map for successful user authentication without machine authentication" list. This can include the <No Access> group.


Note User profile settings always override group profile settings. If a user profile grants an authorization that is denied by the group specified in the "Group map for successful user authentication without machine authentication" list, Cisco Secure ACS grants the authorization.


The MAR feature supports full EAP-TLS and Microsoft PEAP authentication, as well as resumed sessions for EAP-TLS and Microsoft PEAP and fast reconnections for Microsoft PEAP.

The MAR feature has the following limitations and requirements:

Machine authentication must be enabled.

Users must authenticate with EAP-TLS or a Microsoft PEAP client. MAR does not apply to users authenticated by other protocols, such as EAP-FAST, LEAP, or MS-CHAP.

The AAA client must send a value in the IETF RADIUS Calling-Station-Id attribute (31).

Cisco Secure ACS does not replicate the cache of Calling-Station-Id attribute values from successful machine authentications.

Microsoft Windows and Machine Authentication

Cisco Secure ACS supports machine authentication with Active Directory in Windows 2000. To enable machine authentication support in Windows 2000 Active Directory you must:

Apply Service Pack 4 to the computer running Active Directory.

Complete the steps in Microsoft Knowledge Base Article 306260: Cannot
Modify Dial-In Permissions for Computers That Use Wireless Networking.

Client operating systems supporting machine authentication are:

Microsoft Windows XP with Service Pack 1 applied.

Microsoft Windows 2000 with the following:

Service Pack 4 applied.

Patch Q313664 applied (available from Microsoft.com).

The following list describes the essential details of enabling machine authentication on a client computer with a Cisco Aironet 350 wireless adapter. For more information about enabling machine authentication in Microsoft Windows operating systems, please refer to Microsoft documentation.

1. Make sure the wireless network adapter is installed correctly. For more information, see the documentation provided with the wireless network adapter.

2. Make sure the certification authority (CA) certificate of the CA that issued the Cisco Secure ACS server certificate is stored in machine storage on client computers. User storage is not available during machine authentication; therefore, if the CA certificate is in user storage, machine authentication fails.

3. Select the wireless network:

In Windows XP, you can select the network on the Wireless Networks tab of the wireless network connection properties.

In Windows 2000, you can enter the SSID of the wireless network manually. This is done on the Advanced tab of the properties dialog box for the wireless network adapter.

4. To enable PEAP machine authentication, configure the Authentication tab. In Windows XP, the Authentication tab is available from the properties of the wireless network. In Windows 2000, it is available from the properties of the wireless network connection.

a. Select the Enable network access control using IEEE 802.1X check box.

b. Select the Authenticate as computer when computer information is available check box.

c. From the EAP type list, select Protected EAP (PEAP).

d. On the Protected EAP Properties dialog box, you can enforce that Cisco Secure ACS has a valid server certificate by selecting the Validate server certificate check box. If you do select this check box, you must also select the applicable Trusted Root Certification Authorities.

e. Also open the PEAP properties dialog box, from the Select Authentication Method list, select Secured password (EAP-MSCHAP v2).

5. To enable EAP-TLS machine authentication, configure the Authentication tab. In Windows XP, the Authentication tab is available from the properties of the wireless network. In Windows 2000, it is available from the properties of the wireless network connection.

a. Select the Enable network access control using IEEE 802.1X check box.

b. Select the Authenticate as computer when computer information is available check box.

c. From the EAP type list, select Smart Card or other Certificate.

d. On the Smart Card or other Certificate Properties dialog box, select the Use a certificate on this computer option.

e. Also on the Smart Card or other Certificate Properties dialog box, you can enforce that Cisco Secure ACS has a valid server certificate by selecting the Validate server certificate check box. If you do select this check box, you must also select the applicable Trusted Root Certification Authorities.

If you have a Microsoft certification authority server configured on the domain controller, you can configure a policy in Active Directory to produce a client certificate automatically when a computer is added to the domain. For more information, see Microsoft Knowledge Base Article 313407, HOW TO: Create
Automatic Certificate Requests with Group Policy in Windows.

Enabling Machine Authentication

This procedure provides an overview of the detailed procedures required to configure Cisco Secure ACS to support machine authentication.


Note End-user client computers and the applicable Active Directory must be configured to support machine authentication. This procedure is specific to configuration of Cisco Secure ACS only. For information about configuring Microsoft Windows operating systems to support machine authentication, see Microsoft Windows and Machine Authentication.


To enable Cisco Secure ACS to perform machine authentication, follow these steps:


Step 1 Install a server certificate in Cisco Secure ACS. PEAP(EAP-MSCHAPv2) and EAP-TLS require a server certificate. Cisco Secure ACS uses a single certificate to support both protocols. For detailed steps, see Installing a Cisco Secure ACS Server Certificate.


Note If you have installed a certificate to support EAP-TLS or PEAP user authentication or to support HTTPS protection of remote Cisco Secure ACS administration, you do not need to perform this step. A single server certificate will support all certificate-based Cisco Secure ACS services and remote administration.


Step 2 For EAP-TLS machine authentication, if certificates on end-user clients are issued by a different CA than the CA that issued the server certificate on Cisco Secure ACS, you must edit the certification trust list so that CAs issuing end-user client certificates are trusted. If you do not perform this step and the CA of the server certificate is not the same as the CA of an end-user client certificate CA, EAP-TLS will operate normally but reject the EAP-TLS machine authentication because it does not trust the correct CA. For detailed steps, see Editing the Certificate Trust List.

Step 3 Enable the applicable protocols on the Global Authentication Setup page:

To support machine authentication with PEAP, enable the PEAP(EAP-MSCHAPv2) protocol.

To support machine authentication with EAP-TLS, enable the EAP-TLS protocol.

Cisco Secure ACS allows you to complete this step only after you have successfully completed Step 1. For detailed steps, see Configuring Authentication Options.

Step 4 Configure a Windows external user database and enable the applicable types of machine authentication on the Windows User Database Configuration page:

To support machine authentication with PEAP, select the Permit PEAP machine authentication check box.

To support machine authentication with EAP-TLS, select the Permit EAP-TLS machine authentication check box.

To require machine authentication in addition to user authentication, select the Enable machine access restrictions check box.


Note If you already have a Windows external user database configured, modify its configuration to enable the applicable machine authentication types.


For detailed steps, see Configuring a Windows External User Database.

Cisco Secure ACS is ready to perform machine authentication for computers whose names exist in CiscoSecure user database.

Step 5 If you have not already enabled the Unknown User Policy and added the Windows external user database to the Selected Databases list, consider doing so to allow computers that are not known to Cisco Secure ACS to authenticate. For detailed steps, see Configuring the Unknown User Policy.


Note Enabling the Unknown User Policy to support machine authentication also enables the Unknown User Policy for user authentication. Cisco Secure ACS makes no distinction in unknown user support between computers and users.


Cisco Secure ACS is ready to perform machine authentication for computers, regardless of whether the computer names exist in CiscoSecure user database.


User-Changeable Passwords with Windows User Databases

For network users who are authenticated by a Windows user database, Cisco Secure ACS supports user-changeable passwords upon password expiration. You can enable this feature in the MS-CHAP Settings and Windows EAP Settings tables on the Windows User Database Configuration page in the External User Databases section. Using this feature in your network requires the following:

Users must be present in the Windows Active Directory or SAM user database.

User accounts in Cisco Secure ACS must specify the Windows user database for authentication.

End-user clients must be compatible with MS-CHAP, PEAP(EAP-GTC), PEAP(EAP-MSCHAPv2), or EAP-FAST.

The AAA client that the end-user clients connect to must support the applicable protocols:

For MS-CHAP password aging, the AAA client must support RADIUS-based MS-CHAP authentication.

For PEAP(EAP-MSCHAPv2), PEAP(EAP-GTC), and EAP-FAST password aging, the AAA client must support EAP.

When the conditions above are met and this feature is enabled, users receive a dialog box prompting them to change their passwords upon their first successful authentication after their passwords have expired. The dialog box is the same as presented to users by Windows when a user with an expired password accesses a network via a remote access server.

For more information about password aging support in Cisco Secure ACS, see Enabling Password Aging for Users in Windows Databases.

Preparing Users for Authenticating with Windows

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


Step 1 Make sure the username exists in the Windows user database.

Step 2 In Windows, for each user account, clear the following User Properties check boxes:

User must change password at next logon

Account disabled

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.


Windows User Database Configuration Options

The Windows User Database Configuration page contains the following configuration options:

Dialin Permission—You can restrict network access to users whose Windows accounts have Windows dialin permission. The Grant dialin permission to user check box controls this feature.


Note This feature applies to all users authenticated by Cisco Secure ACS with a Windows external user database; despite the name of the feature, it is not limited to users who access the network with a dialup client but is applied regardless of client type. For example, if you have configured a PIX Firewall to authenticate Telnet sessions using Cisco Secure ACS as a RADIUS server, a user authenticated by a Windows external user database would be denied Telnet access to the PIX Firewall if the Dialin Permission feature is enabled and the Windows user account does not have dialin permission.



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


Configure Domain List—The Domain List controls what Cisco Secure ACS does when user authentication is requested for a username that is not domain-qualified. If no domains are in the Domain List and the initial user authentication request is rejected by Windows, Cisco Secure ACS stops attempting to authenticate the user. If domains are in the Domain List, Cisco Secure ACS qualifies the username with a domain from the list and submits the domain-qualified username to Windows, once for each domain in the Domain List, until each domain has rejected the user or until one of the domains authenticates the user.


Note Configuring the Domain List list is optional. For more information about the Domain List, see Non-domain-qualified Usernames.



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.

Available Domains—This list represents the domains that Cisco Secure ACS does not send domain-qualified authentication requests to.

Domain List—This list represents the domains that Cisco Secure ACS does send domain-qualified authentication requests to.

MS CHAP Settings—You can control whether Cisco Secure ACS supports MS-CHAP-based password changes for Windows user accounts. The Permit password changes using MS-CHAP version N check boxes enable you to specify which versions of MS CHAP Cisco Secure ACS supports password changes using.


Note The check boxes under MS CHAP Settings do no affect password aging for Microsoft PEAP, EAP-FAST, or machine authentication.


For more information about Windows password changes, see Enabling Password Aging for Users in Windows Databases.

Enable password change inside PEAP or EAP-FAST—The Permit password change inside PEAP or EAP-FAST check box controls whether Cisco Secure ACS supports PEAP-based or EAP-FAST-based password changes for Windows user accounts. PEAP password changes are supported only when the end-user client uses PEAP(EAP-MSCHAPv2) for user authentication. For EAP-FAST, Cisco Secure ACS supports password changes in phase zero and phase two.

EAP-TLS Strip Domain Name—The EAP-TLS Strip Domain Name check box controls whether Cisco Secure ACS removes the domain name from a username derived from the Subject Alternative Name (SAN) field in an end-user certificate.

Performing domain name stripping can speed EAP-TLS authentication when the domain that must authenticate a user is not the domain represented in the SAN field. For example, a user's SAN field may contain "jsmith@corporation.com" but jsmith may need to authenticate using the domain controller for a subdomain named "engineering". Stripping "@corporation.com" from the username eliminates the needless attempt at authenticating jsmith against the corporation.com domain controller. Without stripping the domain name, only after jsmith cannot be found in corporation.com will Cisco Secure ACS use the Domain List and find the user in the engineering domain. The additional delay could be several seconds.

Enable PEAP machine authentication—This check box controls whether Cisco Secure ACS performs machine authentication using machine name and password with PEAP(EAP-MSCHAPv2). For more information about machine authentication, see Machine Authentication.

Enable EAP-TLS machine authentication—This check box controls whether Cisco Secure ACS performs machine authentication using machine name and password with EAP-TLS. For more information about machine authentication, see Machine Authentication.

EAP-TLS and PEAP machine authentication name prefix—This box defines the string of characters that Cisco Secure ACS adds to the beginning of any machine name being authenticated. By default, the end-user client prefixes machine names with "host/". If any text is present in the PEAP machine authentication name prefix box, Cisco Secure ACS prefixes the machine name with this instead.


Note If you configure the EAP-TLS and PEAP machine authentication name prefix box with a string other than "host/", authentication may fail.


Enable machine access restrictions—If you enable PEAP or EAP-TLS machine authentication, the "Enable machine access restrictions" check box controls whether Cisco Secure ACS restricts network access of users who access the network with computer that fail machine authentication. For more information about the MAR feature, see Machine Access Restrictions.


Note Be sure you have enabled the types of machine authentication that your Windows computers are configured to use—either PEAP machine authentication or EAP-TLS authentication, or both. If the MAR feature is enabled but Cisco Secure ACS does not perform machine authentication for a computer, EAP-TLS and Microsoft PEAP users accessing the network with that computer will be assigned to the group specified in the "Group map for successful user authentication without machine authentication" list.



Tip To enable machine access restrictions, you must specify a number greater than zero in the Aging time (hours) box.


Aging time (hours)—This box specifies the number of hours that Cisco Secure ACS caches IETF RADIUS Calling-Station-Id attribute values from successful machine authentications, for use with the MAR feature. The default value is zero hours, which means that Cisco Secure ACS does not cache Calling-Station-Id values.


Note If you do not change the value of the Aging time (hours) box to something other than zero, all EAP-TLS and Microsoft PEAP users whose computers perform machine authentication are assigned to the group specified in the "Group map for successful user authentication without machine authentication" list.



Tip To clear the cache of Calling-Station-Id values, type 0 in the Aging time (hours) box and click Submit.


Group map for successful user authentication without machine authentication—This list specifies the group profile that Cisco Secure ACS applies to a user accessing the network from a computer that has not passed machine authentication for longer than the number of hours specified in the Aging time (hours) box. To deny such users any access to the network, select <No Access> (which is the default setting).


Note User profile settings always override group profile settings. If a user profile grants an authorization that is denied by the group specified in the "Group map for successful user authentication without machine authentication" list, Cisco Secure ACS grants the authorization.


Configuring a Windows External User Database

For information about the options available on the Windows User Database Configuration page, see Windows User Database Configuration Options.

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


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

Step 2 Click Database Configuration.

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

Step 3 Click Windows Database.

If no Windows 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:

a. Click Create New Configuration.

b. Type a name for the new configuration for Windows authentication in the box provided, or accept the default name in the box.

c. Click Submit.

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

Step 5 Click Configure.

The Windows User Database Configuration page appears.

Step 6 As needed, configure the options in the following tables:

Dialin Permission

Domain List

MS CHAP Settings

EAP Settings

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


Note All the settings on the Windows User Database Configuration page are optional and need not be enabled unless you want to permit and configure the specific features they support.


Step 7 Click Submit.

Cisco Secure ACS saves the Windows user database configuration you created. You can now add it to your Unknown User Policy or assign specific user accounts to use this database for authentication. For more information about the Unknown User Policy, see About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".


Generic LDAP

Cisco Secure ACS supports ASCII, PAP, EAP-TLS, PEAP(EAP-GTC), and EAP-FAST (phase two only) authentication via generic Lightweight Directory Access Protocol (LDAP) databases, such as Netscape Directory Services. Other authentication protocols are not supported with LDAP external user databases.


Note 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

Multiple LDAP Instances

LDAP Organizational Units and Groups

Domain Filtering

LDAP Failover

LDAP Configuration Options

Configuring a Generic LDAP External User Database

Cisco Secure ACS Authentication Process with a Generic LDAP User Database

Cisco Secure ACS forwards the username and password to an LDAP database using a TCP connection on a port that you specify. The LDAP database either passes or fails the authentication request from Cisco Secure ACS. Upon receiving the response from the LDAP database, Cisco Secure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the LDAP server.

Cisco Secure ACS grants authorization based on the Cisco Secure ACS group to which the user is assigned. While the group to which a user is assigned can be determined by information from the LDAP server, it is Cisco Secure ACS that grants authorization privileges.

Multiple LDAP Instances

You can create more than one LDAP configuration in Cisco Secure ACS. By creating more than one LDAP configuration with different IP address or port settings, you can configure Cisco Secure ACS to authenticate using different LDAP servers or using different databases on the same LDAP server. Each primary server IP address and port configuration, along with the secondary server IP address and port configuration, forms an LDAP instance that corresponds to one Cisco Secure ACS LDAP configuration instance.

Cisco Secure ACS does not require that each LDAP instance corresponds to a unique LDAP database. You can have more than one LDAP configuration set to access the same database. This is useful when your LDAP database contains more than one subtree for users or groups. Because each LDAP configuration supports only one subtree directory for users and one subtree directory for groups, you must configure separate LDAP instances for each user directory subtree and group directory subtree combination for which Cisco Secure ACS should submit authentication requests.

For each LDAP instance, you can add or leave it out of the Unknown User Policy. For more information, see About Unknown User Authentication.

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

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

LDAP Organizational Units and Groups

LDAP groups do not need to have the same name as their corresponding Cisco Secure ACS groups. The LDAP group can be mapped to a Cisco Secure ACS group with any name you want to assign. For more information about how your LDAP database handles group membership, see your LDAP database documentation. For more information on LDAP group mappings and Cisco Secure ACS, see "User Group Mapping and Specification".

Domain Filtering

Using domain filtering, you can control which LDAP instance is used to authenticate a user based on domain-qualified usernames. Domain filtering is based on parsing the characters either at the beginning or end of a username submitted for authentication. Domain filtering provides you with greater control over the LDAP instance that Cisco Secure ACS submits any given user authentication request to. You also have control of whether usernames are submitted to an LDAP server with their domain qualifiers intact.

For example, when EAP-TLS authentication is initiated by a Windows XP client, Cisco Secure ACS receives the username in username@domainname format. When PEAP authentication is initiated by a Cisco Aironet end-user client, Cisco Secure ACS receives the username without a domain qualifier. If both clients are to be authenticated with an LDAP database that stores usernames without domain qualifiers, Cisco Secure ACS can strip the domain qualifier. If separate user accounts are maintained in the LDAP database—both domain-qualified and non-domain-qualified user accounts—Cisco Secure ACS can pass usernames to the LDAP database without domain filtering.

If you choose to make use of domain filtering, each LDAP configuration you create in Cisco Secure ACS can perform domain filtering in one of two ways:

Limiting users to one domain—Per each LDAP configuration in Cisco Secure ACS, you can require that Cisco Secure ACS only attempts to authenticate usernames that are qualified with a specific domain name. This corresponds to the "Only process usernames that are domain qualified" option on the LDAP Configuration page. For more information about this option, see LDAP Configuration Options.

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.

Allowing any domain but stripping domain qualifiers—Per each LDAP configuration in Cisco Secure ACS, you can configure Cisco Secure ACS to attempt to strip domain qualifiers based on common domain-qualifier delimiting characters. This corresponds to the "Process all usernames after stripping domain name and delimiter" option on the LDAP Configuration page. For more information about this option, see LDAP Configuration Options.

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 LDAP server and secondary LDAP server. In the context of LDAP authentication with Cisco Secure ACS, failover applies when an authentication request fails because Cisco Secure ACS could not connect to an LDAP server, such as when the server is down or is otherwise unreachable by Cisco Secure ACS. To use this feature, you must define the primary and secondary LDAP servers on the LDAP Database Configuration page. Also, you must select the On Timeout Use Secondary check box. For more information about configuring an LDAP external user database, see Configuring a Generic LDAP External User Database.

If the On Timeout Use Secondary check box is selected, and if the first LDAP server that Cisco Secure ACS attempts to contact cannot be reached, Cisco Secure ACS always attempts to contact the other LDAP server. The first server Cisco Secure ACS attempts to contact may not always be the primary LDAP server. Instead, the first LDAP server that Cisco Secure ACS attempts to contact depends on the previous LDAP authentication attempt and on the value specified in the Failback Retry Delay box.

Successful Previous Authentication with the Primary LDAP Server

If, on the previous LDAP authentication attempt, Cisco Secure ACS successfully connected to the primary LDAP server, Cisco Secure ACS attempts to connect to the primary LDAP server. If Cisco Secure ACS cannot connect to the primary LDAP server, Cisco Secure ACS attempts to connect to the secondary LDAP server.

If Cisco Secure ACS cannot connect with either LDAP server, Cisco Secure ACS stops attempting LDAP authentication for the user. If the user is an unknown user, Cisco Secure ACS tries the next external user database listed in the Unknown User Policy list. For more information about the Unknown User Policy list, see About Unknown User Authentication.

Unsuccessful Previous Authentication with the Primary LDAP Server

If, on the previous LDAP authentication attempt, Cisco Secure ACS could not connect to the primary LDAP server, whether Cisco Secure ACS first attempts to connect to the primary server or secondary LDAP server for the current authentication attempt depends on the value in the Failback Retry Delay box. If the Failback Retry Delay box is set to 0 (zero), Cisco Secure ACS always attempts to connect to the primary LDAP server first. And if Cisco Secure ACS cannot connect to the primary LDAP server, Cisco Secure ACS then attempts to connect to the secondary LDAP server.

If the Failback Retry Delay box is set to a number other than zero, Cisco Secure ACS determines how many minutes have passed since the last authentication attempt using the primary LDAP server occurred. If more minutes have passed than the value specified in the Failback Retry Delay box, Cisco Secure ACS attempts to connect to the primary LDAP server first. And if Cisco Secure ACS cannot connect to the primary LDAP server, Cisco Secure ACS then attempts to connect to the secondary LDAP server.

If fewer minutes have passed than the value specified in the Failback Retry Delay box, Cisco Secure ACS attempts to connect to the secondary LDAP server first. And if Cisco Secure ACS cannot connect to the secondary LDAP server, Cisco Secure ACS then attempts to connect to the primary LDAP server.

If Cisco Secure ACS cannot connect to either LDAP server, Cisco Secure ACS stops attempting LDAP authentication for the user. If the user is an unknown user, Cisco Secure ACS tries the next external user database listed in the Unknown User Policy list. For more information about the Unknown User Policy list, see About Unknown User Authentication.

LDAP Configuration Options

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

Domain Filtering—This table contains options for domain filtering. The settings in this table affect all LDAP authentication performed using this configuration, regardless of whether the authentication is handled by the primary or secondary LDAP server. For more information about domain filtering, see Domain Filtering

This table contains the following options:

Process all usernames—When this option is selected, Cisco Secure ACS does not perform domain filtering on usernames before submitting them to the LDAP server for authentication.

Only process usernames that are domain qualified—When this option is selected, Cisco Secure ACS only attempts authentication for usernames that are domain qualified for a single domain. You must specify the type of domain qualifier and the domain in the "Qualified by" and Domain options. Cisco Secure ACS only submits usernames that are qualified in the method specified in the "Qualified by" option and that are qualified with the username specified in the Domain Qualifier box. You can also specify whether Cisco Secure ACS removes the domain qualifier from usernames before submitting them to an LDAP server.

Qualified by—When "Only process usernames that are domain qualified" is selected, this option specifies the type of domain qualification. If you select Prefix, Cisco Secure ACS only processes usernames that begin with the characters specified in the Domain Qualifier box. If you select Suffix, Cisco Secure ACS only processes usernames that end in the characters specified in the Domain Qualifier box.


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


Domain Qualifier—When "Only process usernames that are domain qualified" is selected, this option specifies the domain name and delimiting character that must qualify usernames so Cisco Secure ACS can submit the username to an LDAP server. The Domain box accepts up to 512 characters; however, only one domain name and its delimiting character are permitted.

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 "yourdomain", the delimiting character is "\", and Prefix is selected on the "Qualified by" list, the Domain Qualifier box should contain "yourdomain\"

Strip domain before submitting username to LDAP server—When "Only process usernames that are domain qualified" is selected, this option specifies whether Cisco Secure ACS removes the domain qualifier and its delimiting character before submitting a username to an LDAP server. For example, if the username is "jwiedman@domain.com", the stripped username is "jwiedman".

Process all usernames after stripping domain name and delimiter—When this option is selected, Cisco Secure ACS submits all usernames to an LDAP server after attempting to strip domain names. Usernames that are not domain qualified are processed, too. Domain name stripping occurs as specified by the following two options.

Strip starting characters through the last X character—When "Process all usernames after stripping domain name and delimiter" is selected, this option specifies that Cisco Secure ACS attempts to strip a prefixed domain qualifier. If, in the username, Cisco Secure ACS finds the delimiter character that is specified in the X box, it strips all characters from the beginning of the username through the delimiter character. If the username contains more than one of the characters specified in the X box, Cisco Secure ACS strips characters through the last occurrence of the delimiter character.

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.


Strip ending characters through the first Y character—When "Process all usernames after stripping domain name and delimiter" is selected, this option specifies that Cisco Secure ACS attempts to strip a suffixed domain qualifier. If, in the username, Cisco Secure ACS finds the delimiter character that is specified in the Y box, it strips all characters from the delimiter character through the end of the username. If the username contains more than one of the character specified in the Y box, Cisco Secure ACS strips characters starting with the first occurrence of the delimiter character.

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.


Common LDAP Configuration—This table contains options that apply to all LDAP authentication performed using this configuration. Cisco Secure ACS uses the settings in this section regardless of whether the authentication is handled by the primary or secondary LDAP server. This table contains the following options:

User Directory Subtree—The distinguished name (DN) for the subtree that contains all users. For example:

ou=organizational unit[,ou=next organizational unit]o=corporation.com 

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

o=corporation.com 

or

dc=corporation,dc=com 

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

Group Directory Subtree—The DN for the subtree that contains all groups. For example:

ou=organizational unit[,ou=next organizational unit]o=corporation.com 

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

o=corporation.com 

or

dc=corporation,dc=com 

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

UserObjectType—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. Cisco Secure ACS provides default values that reflect the default configuration of a Netscape Directory Server. Confirm all values for these fields with your LDAP server configuration and documentation.

UserObjectClass—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. This box should contain a value that is not shared.

GroupObjectType—The name of the attribute in the group record that contains the group name.

GroupObjectClass—A value of the LDAP "objectType" attribute in the group record that identifies the record as a group.

Group Attribute Name—The name of the attribute of the group record that contains the list of user records that are a member of that group.

Server Timeout—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.

On Timeout Use Secondary—Whether Cisco Secure ACS performs failover of LDAP authentication attempts. For more information about the LDAP failover feature, see LDAP Failover.

Failback Retry Delay—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. A value of 0 (zero) causes Cisco Secure ACS to always use the primary LDAP server first.

Primary and Secondary LDAP Servers—The Primary LDAP Server table and the Secondary LDAP Server table enable you to identify the LDAP servers and make settings that are unique to each. The Secondary LDAP Server table does not need to be completed if you do not intend to use LDAP failover. These tables contain the following options:

Hostname—The name or IP address of the server that is running the LDAP software. If you are using DNS on your network, you can type the hostname instead of the IP address.

Port—The TCP/IP port number on which the LDAP server is listening. The default is 389, as stated in the LDAP specification. If you do not know the port number, you can find this information by viewing those properties on the LDAP server. If you want to use secure authentication, port 636 is usually used.

LDAP Version—Whether Cisco Secure ACS uses LDAP version 3 or version 2 to communicate with your LDAP database. If this check box is selected, Cisco Secure ACS uses LDAP version 3. If it is not selected, Cisco Secure ACS uses LDAP version 2.

Security—Whether Cisco Secure ACS uses SSL to provide more secure communication with the LDAP server. If you do not enable SSL, user credentials are passed to the LDAP server in clear text.

Certificate Database Path—The path to the cert7.db file. This file must contain the certificates for the server to be queried and the trusted CA. You can use a Netscape web browser to generate cert7.db files. For information about generating a cert7.db file, refer to Netscape 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 a secondary LDAP server. Even though the two LDAP configurations share the same primary server, each LDAP configuration requires that you download a certificate database file to Cisco Secure ACS.


Note The database must be a cert7.db certificate database file. No other filename is supported.


Admin DN—The DN of the administrator; that is, the LDAP account which, if bound to, permits searches for all required users under the User Directory Subtree. It must contain the following information about your LDAP server:

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 

You can use anonymous credentials for the administrator username if the LDAP server is configured to make the group name attribute visible in searches by anonymous credentials. Otherwise, you must specify an administrator username that permits the group name attribute to be visible to searches.


Note If the administrator username specified does not have permission to see the group name attribute in searches, group mapping fails for users authenticated by LDAP.


Password—The password for the administrator account specified in the Admin DN box. Password case sensitivity is determined by the LDAP server.

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 1 In the navigation bar, click External User Databases.

Step 2 Click Database Configuration.

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.


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:

a. Click Create New Configuration.

b. Type a name for the new configuration for generic LDAP in the box provided.

c. Click Submit.

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.


a. Under Domain Filtering, select Only process usernames that are domain qualified.

b. From the "Qualified by" list, select the applicable type of domain qualification, either Suffix or Prefix. Only one type of domain qualification is supported per LDAP configuration.

For example, if you want this LDAP configuration to authenticate usernames that begin with a specific domain name, select Prefix. If you want this LDAP configuration to authenticate usernames that end with a specific domain name, select Suffix.

c. In the Domain Qualifier box, type the name of the domain that you want this LDAP configuration to authenticate usernames for. Include the delimiting character that separates the user ID from the domain name. Be sure that the delimiting character appears in the applicable position: at the end of the domain name if Prefix is selected on the "Qualified by" list; at the beginning of the domain name if Suffix is selected on the "Qualified by" list.

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

d. If you want Cisco Secure ACS to remove the domain qualifier before submitting it to the LDAP database, select the Strip domain before submitting username to LDAP server check box.

e. If you want Cisco Secure ACS to pass the username to the LDAP database without removing the domain qualifier, clear the Strip domain before submitting username to LDAP server check box.

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.


a. Under Domain Filtering, select Process all usernames after stripping domain name and delimiter.

b. If you want Cisco Secure ACS to strip prefixed domain qualifiers, select the Strip starting characters through the last X character check box, and then type the domain-qualifier delimiting character in the X box.


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


c. If you want Cisco Secure ACS to strip suffixed domain qualifiers, select the Strip ending characters from the first X character check box, and then type the domain-qualifier delimiting character in the X box.


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.


a. In the Hostname box, type the name or IP address of the server that is running the LDAP software. If you are using DNS on your network, you can type the hostname instead of the IP address.

b. In the Port box, type the TCP/IP port number on which the LDAP server is listening. The default is 389, as stated in the LDAP specification. If you do not know the port number, you can find this information by viewing those properties on the LDAP server. If you want to use secure authentication, port 636 is usually used.

c. To specify that Cisco Secure ACS should use LDAP version 3 to communicate with your LDAP database, select the LDAP Version check box. If the LDAP Version check box is not selected, Cisco Secure ACS uses LDAP version 2.

d. The username and password credentials are normally passed over the network to the LDAP directory in clear text. To enhance security, select the Use secure authentication check box.

e. In the Certificate Database Path box, type the path to the uid=joesmith,ou=members,ou=administrators,o=cisco file, which contains the certificates for the server to be queried and the trusted CA.

f. The Admin DN box requires the fully qualified (DN) of the administrator; that is, the LDAP account which, if bound to, permits searches for all required users under the User Directory Subtree.

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

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

next organizational unit is the next level up the tree.

For example:

uid=joesmith,ou=members,ou=administrators,o=cisco 


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.

g. In the Password box, type the password for the administrator account specified in the Admin DN box. Password case sensitivity is determined by the server.

Step 21 Click Submit.

Cisco Secure ACS saves the generic LDAP configuration you created. You can now add it to your Unknown User Policy or assign specific user accounts to use this database for authentication. For more information about the Unknown User Policy, see About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".


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

User Contexts

Novell NDS External User Database Options

Configuring a Novell NDS External User Database

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 Novell NDS trees. Each Novell NDS tree configuration can support a list of user contexts. For a user to authenticate against a Novell NDS context, the applicable user object must exist in one of the contexts provided and the user password must be able to log the name into the tree.

User Contexts

You must supply one or more contexts when you configure Cisco Secure ACS to authenticate with an NDS database; however, users can supply an additional portion of the full context that defines their fully qualified usernames. In other words, if none of the contexts in the list of contexts contains a username submitted for authentication, the username must specify exactly how they are subordinate to the contexts in the list of contexts. The user specifies the manner in which a username is subordinate to a context by providing the additional context information needed to uniquely identify the user in the NDS database.

Consider the following example tree:

[Root] whose treename=ABC 
 OU=ABC-Company 
  OU=sales 
     CN=Agamemnon 
  OU=marketing 
    CN=Odysseus 
    OU=marketing-research 
       CN=Penelope 
    OU=marketing-product 
       CN=Telemachus 

If the context list configured in Cisco Secure ACS were:

ABC-Company,sales.ABC-Company 

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

Table 13-1 lists the users given in the example tree and the username with context that would allow each user to authenticate successfully.

Table 13-1 Example Usernames with Contexts 

User
Valid Username With Context

Agamemnon

Agamemnon

Odysseus

Odysseus.marketing

Penelope

Penelope.marketing-research.marketing

Telemachus

Telemachus.marketing-product.marketing


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:

Add New Tree—Appears only on the blank form for new trees. Selecting this check box confirms that you want to add a new tree.

Delete Tree—Appears only on existing tree configurations. Selecting this check box indicates that you want to delete the tree configuration when you click Submit.

Test Login—Selecting this check box causes Cisco Secure ACS to test the administrative login of the tree to the Novell server when you click Submit.

Tree Name—Appears only on the blank form for new trees. The name of the Novell NDS tree against which Cisco Secure ACS should authenticate users.

Administrator Username—The fully qualified, typeless username for the administrator of the Novell server. For example:

admin.Chicago.Corporation 

You can use anonymous credentials for the administrator username if the Novell NDS server is configured to make the group name attribute visible in searches by anonymous credentials. Otherwise, you must specify a administrator username that permits the group name attribute to be visible to searches.


Note If the administrator username specified does not have permission to see the group name attribute in searches, group mapping fails for users authenticated by Novell NDS.


Administrator Password—The password for the administrator of the Novell server.

Context List—The full context list with each context specified in canonical, typeless form; that is, remove the cert7.db and o= and separate each part of the context using a period (.). You can enter more than one context list. If you do, separate them with a comma. For example, if your Organization is Corporation, your Organization Name is Chicago, and you want to enter two Context names, Marketing and Engineering, you would type:

Engineering.Chicago.Corporation,Marketing.Chicago.Corporation 

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.


Context Subtree—Selecting this check box causes Cisco Secure ACS to search subtrees for users during authentication. The subtrees searched are those of the contexts specified in the Context List box.

Configuring a Novell NDS External User Database

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


Tip You can allow users to enter their own context as part of the login process. For more information, see User Contexts.


Before You Begin

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

To configure Novell NDS authentication, follow these steps:


Step 1 See your Novell NetWare administrator to get the names and other information on the Tree, Container, and Context.

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

Step 3 Click Database Configuration.

Cisco Secure ACS lists all possible external user database types.

Step 4 Click Novell NDS.

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:

a. Click Create New Configuration.

b. Type a name for the new configuration for Novell NDS Authentication in the box provided.

c. Click Submit.

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.

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

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

Step 7 If you want to add a new Novell NDS server configuration, complete the fields in the blank form at the bottom of the NDS Authentication Support page.


Note You must select the Add New NDS Host check box to confirm that you want to create a Novell NDS server configuration.


Step 8 If you want 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 If you want to delete an existing tree configuration, select the Delete Tree check box.

Step 10 Click Submit.

Cisco Secure ACS saves the NDS configuration you created. You can add it to your Unknown User Policy or assign specific user accounts to use this database for authentication. For more information about the Unknown User Policy, see About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".


ODBC Database

As with Windows user 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.


Note As with all other external databases supported by Cisco Secure ACS, the ODBC-compliant relational database is not supplied as part of Cisco Secure ACS. For general guidance with setting up your ODBC external user database, see Preparing to Authenticate Users with an ODBC-Compliant Relational Database.


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 Authentication Process with an ODBC External User Database

Preparing to Authenticate Users with an ODBC-Compliant Relational Database

Implementation of Stored Procedures for ODBC Authentication

Microsoft SQL Server and Case-Sensitive Passwords

Sample Routine for Generating a PAP Authentication SQL Procedure

Sample Routine for Generating an SQL CHAP Authentication Procedure

Sample Routine for Generating an EAP-TLS Authentication Procedure

PAP Authentication Procedure Input

PAP Procedure Output

CHAP/MS-CHAP/ARAP Authentication Procedure Input

CHAP/MS-CHAP/ARAP Procedure Output

EAP-TLS Authentication Procedure Input

EAP-TLS Procedure Output

Result Codes

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

Configuring an ODBC External User Database

What is Supported with ODBC User Databases

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

Authentication—Cisco Secure ACS supports ASCII, PAP, ARAP, CHAP, MS-CHAP (versions 1 and 2), LEAP, EAP-TLS, EAP-MD5, PEAP (EAP-GTC), PEAP (EAP-MSCHAPv2), and EAP-FAST (phase zero and phase two) authentication using a relational database via the ODBC authenticator feature. Other authentication protocols are not supported with ODBC external user databases.


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.


Group Specification—Cisco Secure ACS supports group assignment for users authenticated by an ODBC user database. Authentication queries to the ODBC database must contain the group number you want to assign a user to. For unknown users authenticated by an ODBC user database, group specification overrides group mapping.

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

Group Mapping for Unknown Users—Cisco Secure ACS supports group mapping for unknown users by requesting group membership information from Windows user databases. For more information about group mapping for users authenticated with a Windows user database, see Group Mapping by Group Set Membership.

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 user credentials to the ODBC database via an 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 user credentials 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 13-2).

Figure 13-2 Using the ODBC Database for Authentication

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.

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 1 Install your ODBC-compliant relational database on its server. For more information, refer to the relational database documentation.


Note The relational database you use is not supplied with Cisco Secure ACS.


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.


Note For SQL database columns that hold user passwords, we recommend using varchar format. If you define password columns as char, password comparison may fail if the password does not use the full length of the field. For example, if a password column is 16 characters wide but the password is only ten characters long, the database may append six spaces make the value used for password comparison 16 characters long, causing comparison to the actual password submitted by the user to fail.


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 computer running Cisco Secure ACS. 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. The values returned and the tasks required of the stored procedure varies depending upon the authentication protocol used.

Authentication for ASCII, PAP, or PEAP (EAP-GTC) 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, LEAP, or EAP-MD5 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.

Authentication for EAP-TLS occurs within Cisco Secure ACS. The stored procedure returns the field for the record, indicating whether it found the username in the ODBC database. Cisco Secure ACS confirms or denies authentication based on the values returned from the procedure and upon the validity of the user certificate. For more information about Cisco Secure ACS support for the EAP-TLS protocol, see EAP-TLS Authentication.

To support the three sets of 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 of the three sets of protocols.

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, ASCII/PAP/PEAP(EAP-GTC) authentication procedure input and output, CHAP/MS-CHAP/ARAP authentication procedure input and output, EAP-TLS authentication procedure input and output, 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:

Integer—SQL_INTEGER

String—SQL_CHAR or SQL_VARCHAR


Note For SQL database columns that hold user passwords, we recommend using varchar format. If you define password columns as char, password comparison may fail if the password does not use the full length of the field. For example, if a password column is 16 characters wide but the password is only ten characters long, the database may append six spaces make the value used for password comparison 16 characters long, causing comparison to the actual password submitted by the user to fail.


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.

if exists (select * from sysobjects where id = object_id (`dbo.CSNTAuthUserPap') and 
sysstat & 0xf = 4) 
drop procedure dbo.CSNTAuthUserPap 
GO 
 
CREATE PROCEDURE CSNTAuthUserPap 
@username varchar(64), @pass varchar(255) 
AS 
SET NOCOUNT ON 
IF EXISTS( SELECT  username 
FROM  users 
WHERE  username  = @username 
AND  csntpassword  = @pass ) 
SELECT 0,csntgroup,csntacctinfo,"No Error" 
FROM  users 
WHERE  username  = @username 
ELSE 
SELECT 3,0,"odbc","ODBC Authen Error" 
GO 
 
GRANT EXECUTE ON dbo.CSNTAuthUserPap TO ciscosecure 
GO 

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.

 if exists (select * from sysobjects where id = 
object_id(`dbo.CSNTExtractUserClearTextPw') and sysstat & 0xf = 4) 
drop procedure dbo.CSNTExtractUserClearTextPw 
GO 
 
CREATE PROCEDURE CSNTExtractUserClearTextPw 
@username varchar(64) 
AS 
SET NOCOUNT ON 
IF EXISTS( SELECT  username 
FROM  users 
WHERE  username  = @username ) 
SELECT 0,csntgroup,csntacctinfo,"No Error",csntpassword 
FROM  users 
WHERE  username  = @username 
ELSE 
SELECT 3,0,"odbc","ODBC Authen Error" 
GO 
 
GRANT EXECUTE ON dbo.CSNTExtractUserClearTextPw TO ciscosecure 
GO 

Sample Routine for Generating an EAP-TLS Authentication Procedure

The following example routine creates in Microsoft SQL Server a procedure named CSNTFindUser, the default procedure used by Cisco Secure ACS for EAP-TLS 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.

if exists (select * from sysobjects where id = object_id(`dbo.CSNTFindUser') and sysstat & 
0xf = 4) 
drop procedure dbo.CSNTFindUser 
GO 
 
CREATE PROCEDURE CSNTFindUser 
@username varchar(64) 
AS 
SET NOCOUNT ON 
IF EXISTS( SELECT  username 
FROM  users 
WHERE  username  = @username ) 
SELECT 0,csntgroup,csntacctinfo,"No Error" 
FROM  users 
WHERE  username  = @username 
ELSE 
SELECT 3,0,"odbc","ODBC Authen Error" 
GO 
 
GRANT EXECUTE ON dbo.CSNTFindUser TO ciscosecure 
GO 

PAP Authentication Procedure Input

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

Table 13-2 PAP Stored Procedure Input 

Field
Type
Explanation

CSNTusername

String

0-64 characters

CSNTpassword

String

0-255 characters


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 13-3 lists the procedure results Cisco Secure ACS expects as output from stored procedure.

Table 13-3 PAP Stored Procedure Results 

Field
Type
Explanation

CSNTresult

Integer

See Table 13-8.

CSNTgroup

Integer

The Cisco Secure ACS group number for authorization. 0xFFFFFFFF is used to assign the default value. Values other than 0-499 are converted to the default.

Note The group specified in the CSNTgroup field overrides group mapping configured for the ODBC external user database.

CSNTacctInfo

String

0-16 characters. A customer-defined string that Cisco Secure ACS adds to subsequent account log file entries.

CSNTerrorString

String

0-255 characters. A customer-defined string that Cisco Secure ACS writes to the CSAuth service log file if an error occurs.


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


Note If the ODBC database returns data in recordset format rather than in parameters, 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 13-4).


Table 13-4 CHAP Stored Procedure Input 

Field
Type
Explanation

CSNTusername

String

0-64 characters


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 13-5 lists the procedure results Cisco Secure ACS expects as output from stored procedure.

Table 13-5 CHAP/MS-CHAP/ARAP Stored Procedure Results 

Field
Type
Explanation

CSNTresult

Integer

See Table 13-8 Result Codes.

CSNTgroup

Integer

The Cisco Secure ACS group number for authorization. 0xFFFFFFFF is used to assign the default value. Values other than 0-499 are converted to the default.

Note The group specified in the CSNTgroup field overrides group mapping configured for the ODBC external user database.

CSNTacctInfo

String

0-15 characters. A customer-defined string that Cisco Secure ACS adds to subsequent account log file entries.

CSNTerrorString

String

0-255 characters. A customer-defined string that Cisco Secure ACS writes to the CSAuth service log file if an error occurs.

CSNTpassword

String

0-255 characters. The password is authenticated by Cisco Secure ACS.

Note If the password field in the database is defined using a CHAR datatype rather than VARCHAR, the database may return a string 255 characters long, regardless of actual password length. We recommend using the VARCHAR datatype for the CHAP password field in your ODBC database.


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


Note If the ODBC database returns data in recordset format rather than in parameters, the procedure must return the result fields in the order listed above.


EAP-TLS Authentication Procedure Input

Cisco Secure ACS provides a single value for input to the stored procedure supporting EAP-TLS authentication. The stored procedure should accept the named input value as a variable.


Note Because Cisco Secure ACS performs authentication for EAP-TLS, the user password is not an input (Table 13-4).


Table 13-6 EAP-TLS Stored Procedure Input 

Field
Type
Explanation

CSNTusername

String

0-64 characters


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

EAP-TLS Procedure Output

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

Table 13-7 EAP-TLS Stored Procedure Results 

Field
Type
Explanation

CSNTresult

Integer

See Table 13-8 Result Codes.

CSNTgroup

Integer

The Cisco Secure ACS group number for authorization. 0xFFFFFFFF is used to assign the default value. Values other than 0-499 are converted to the default.

Note The group specified in the CSNTgroup field overrides group mapping configured for the ODBC external user database.

CSNTacctInfo

String

0-15 characters. A customer-defined string that Cisco Secure ACS adds to subsequent account log file entries.

CSNTerrorString

String

0-255 characters. A customer-defined string that Cisco Secure ACS writes to the CSAuth service log file if an error occurs.


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


Note If the ODBC database returns data in recordset format rather than in parameters, the procedure must return the result fields in the order listed above.


Result Codes

You can set the result codes listed in Table 13-8.

Table 13-8 Result Codes 

Result Code
Meaning

0 (zero)

Authentication successful

1

Unknown username

2

Invalid password

3

Unknown username or invalid password

4+

Internal error—authentication not processed


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 computer running Cisco Secure ACS, 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 1 Using the local administrator account, log in to the computer running Cisco Secure ACS.

Step 2 In Windows Control Panel, double-click the ODBC Data Sources icon.

Step 3 Choose Start > Settings > Control Panel > Administrative Tools > Data Sources (ODBC)


Tip If Control Panel is not expanded on the Start menu, choose Start > Settings > Control Panel, double-click Administrative Tools, and then double-click Data Sources (ODBC).


The ODBC Data Source Administrator window appears.

Step 4 Click the System DSN tab.

Step 5 Click Add.

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

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

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

Step 8 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 9 Click OK.

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

Step 10 Close the ODBC Data Source Administrator window and Windows Control Panel.

The system DSN to be used by Cisco Secure ACS for communication with the relational database is created on the computer running Cisco Secure ACS.


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 1 In the navigation bar, click External User Databases.

Step 2 Click Database Configuration.

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:

a. Click Create New Configuration.

b. Type a name for the new configuration for ODBC authentication in the box provided, or accept the default name in the box.

c. Click Submit.

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 to communicate with the ODBC-compliant relational database you want to use.


Note If you have not configured on the computer running Cisco Secure ACS 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:

Returns Recordset—The database returns a raw record set in response to an ODBC query. Microsoft SQL Server responds in this manner.

Returns Parameters—The database returns a set of named parameters in response to an ODBC query. Oracle databases respond in this manner.

Step 12 To support ASCII, PAP, or PEAP(EAP-GTC) authentication with the ODBC database, follow these steps:

a. Select the Support PAP authentication check box.

b. In the PAP SQL Procedure box, type the name of the PAP SQL procedure routine that runs on the ODBC server. The default value in this box is CSNTAuthUserPap. If you named the PAP SQL procedure something else, change this entry to match the name given to the PAP SQL procedure. For more information and an example routine, see Sample Routine for Generating a PAP Authentication SQL Procedure.


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, MS-CHAP, ARAP, EAP-MD5, or LEAP authentication with the ODBC database, follow these steps:

a. Select the Support CHAP/MS-CHAP/ARAP Authentication check box.

b. In the CHAP SQL Procedure box, type the name of the CHAP SQL procedure routine on the ODBC server. The default value in this box is CSNTExtractUserClearTextPw. If you named the CHAP SQL procedure something else, change this entry to match the name given to the CHAP SQL procedure. For more information and an example routine, see Sample Routine for Generating an SQL CHAP Authentication Procedure.


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 To support EAP-TLS authentication with the ODBC database, follow these steps:

a. Select the Support EAP-TLS Authentication check box.

b. In the EAP-TLS SQL Procedure box, type the name of the EAP-TLS SQL procedure routine on the ODBC server. The default value in this box is CSNTFindUser. If you named the EAP-TLS SQL procedure something else, change this entry to match the name given to the EAP-TLS SQL procedure. For more information and an example routine, see Sample Routine for Generating an EAP-TLS Authentication Procedure.


Note If you enabled EAP-TLS authentication, the EAP-TLS authentication SQL procedure must exist on the ODBC database and must have the exact name specified in the EAP-TLS 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 15 Click Submit.

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 About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".


LEAP Proxy RADIUS Server Database

For Cisco Secure ACS-authenticated users accessing your network via Cisco Aironet devices, Cisco Secure ACS supports ASCII, PAP, MS-CHAP (versions 1 and 2), LEAP, and EAP-FAST (phase zero and phase two) authentication with a proxy RADIUS server. Other authentication protocols are not supported with LEAP Proxy RADIUS Server databases.


Note 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 1 In the navigation bar, click External User Databases.

Step 2 Click Database Configuration.

Cisco Secure ACS lists all possible external user database types.

Step 3 Click LEAP Proxy RADIUS Server.

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:

a. Click Create New Configuration.

b. Type a name for the new configuration for the LEAP Proxy RADIUS Server in the box provided, or accept the default name in the box.

c. Click Submit.

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:

Primary Server Name/IP—IP address of the primary proxy RADIUS server.

Secondary Server Name/IP—IP address of the secondary proxy RADIUS server.

Shared Secret—The shared secret of the proxy RADIUS server. This must be identical to the shared secret with which the proxy RADIUS server is configured.

Authentication Port—The UDP port over which the proxy RADIUS server conducts authentication sessions. If the LEAP Proxy RADIUS server is installed on the same Windows server as Cisco Secure ACS, this port should not be the same port used by Cisco Secure ACS for RADIUS authentication. For more information about the ports used by Cisco Secure ACS for RADIUS, see RADIUS.

Timeout (seconds):—The number of seconds Cisco Secure ACS waits before sending notification to the user that the authentication attempt has timed out.

Retries—The number of authentication attempts Cisco Secure ACS makes before failing over to the secondary proxy RADIUS server.

Failback Retry Delay (minutes)—The number of minutes after which Cisco Secure ACS attempts authentications using a failed primary proxy RADIUS server.


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


Step 8 Click Submit.

Cisco Secure ACS saves the proxy RADIUS token server database configuration you created. You can add it to your Unknown User Policy or assign specific user accounts to use this database for authentication. For more information about the Unknown User Policy, see About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".


Token Server User Databases

Cisco Secure ACS supports the use of token servers for the increased security provided by one-time passwords (OTPs).

This section contains the following topics:

About Token Servers and Cisco Secure ACS

RADIUS-Enabled Token Servers

RSA SecurID Token Servers

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 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 support for token servers that provide a standard RADIUS interface.

This section contains the following topics:

About RADIUS-Enabled Token Servers

Token Server RADIUS Authentication Request and Response Contents

Configuring a RADIUS Token Server External User Database

About RADIUS-Enabled Token Servers

Cisco Secure ACS supports token servers using the RADIUS server built into the token server. Rather than using a vendor-proprietary API, Cisco Secure ACS sends standard RADIUS authentication requests to the RADIUS authentication port on the token server. This feature enables Cisco Secure ACS to support any IETF RFC 2865-compliant token server.

You can create multiple instances of RADIUS token servers. 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:

User-Name (RADIUS attribute 1)

User-Password (RADIUS attribute 2)

NAS-IP-Address (RADIUS attribute 4)

NAS-Port (RADIUS attribute 5)

NAS-Identifier (RADIUS attribute 32)

Cisco Secure ACS expects to receive one of the following three responses:

access-accept—No attributes are required; however, the response can indicate the Cisco Secure ACS group to which the user should be assigned. For more information, see RADIUS-Based Group Specification.

access-reject—No attributes required.

access-challenge—Attributes required, per IETF RFC, are as follows:

State (RADIUS attribute 24)

Reply-Message (RADIUS attribute 18)

Configuring a RADIUS Token Server External User Database

Use this procedure to configure RADIUS Token Server external user databases.

Before You Begin

You should install and configure your RADIUS token server before configuring 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 RADIUS Token Sever, follow these steps:


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

Step 2 Click Database Configuration.

Cisco Secure ACS lists all possible external user database types.

Step 3 Click RADIUS Token Server.

The Database Configuration Creation table appears. If at least one RADIUS token server configuration exists, the External User Database Configuration table also appears.

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

a. Click Create New Configuration.

b. Type a name for the new configuration for the RADIUS-enabled token server in the box provided, or accept the default name in the box.

c. Click Submit.

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:

Primary Server Name/IP—The hostname or IP address of the primary RADIUS token server. If you provide the hostname, the hostname must be resolvable by DNS.

Secondary Server Name/IP—The hostname or IP address of the secondary RADIUS token server. If you provide the hostname, the hostname must be resolvable by DNS.

Shared Secret—The shared secret of the RADIUS server. This must be identical to the shared secret with which the RADIUS token server is configured.

Authentication Port—The UDP port over which the RADIUS server conducts authentication sessions. If the RADIUS token server is installed on the same Windows server as Cisco Secure ACS, this port should not be the same port used by Cisco Secure ACS for RADIUS authentication. For more information about the ports used by Cisco Secure ACS for RADIUS, see RADIUS.


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.


Timeout (seconds):—The number of seconds Cisco Secure ACS waits for a response from the RADIUS token server before retrying the authentication request.

Retries—The number of authentication attempts Cisco Secure ACS makes before failing over to the secondary RADIUS token server.

Failback Retry Delay (minutes)—The number of minutes that Cisco Secure ACS sends authentication requests to the secondary server when the primary server has failed. When this duration is ended, Cisco Secure ACS reverts to sending authentication requests to the primary server.


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:

a. If you want Cisco Secure ACS to present a custom prompt for tokens, select Static (sync and async tokens), and then type in the Prompt box the prompt that Cisco Secure ACS will present.

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.


b. If you want Cisco Secure ACS to send the token server a password to trigger a challenge, select From Token Server (async tokens only), and then, in the Password box, type the password that Cisco Secure ACS will forward to the token server.

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.

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 About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".


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 computer running Cisco Secure ACS. The following procedure includes steps required to install the RSA client correctly on the computer running Cisco Secure ACS.

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 applicable RSA ACE Client.

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


Step 1 Install the RSA client on the computer running Cisco Secure ACS:

a. With a username that has administrative privileges, log in to the computer running Cisco Secure ACS.

b. Run the Setup program of the ACE Client software, following setup instructions provided by RSA.


Note Do not restart Windows when installation is complete.


c. Locate the ACE Server data directory, for example, ou=.

d. Get the file named /sdi/ace/data and place it in the following Windows directory: sdconf.rec.

For example:

\winnt\system32 

e. Make sure the ACE server hostname is in the Windows local host file:

\Windows directory\system32\drivers\etc\hosts 

f. Restart the computer running Cisco Secure ACS.

g. Verify connectivity by running the Test Authentication function of your ACE client application. You can run this from Control Panel.

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

Step 3 Click Database Configuration.

Cisco Secure ACS lists all possible external user database types.

Step 4 Click RSA SecurID Token Server.

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:

a. Click Create New Configuration.

b. Type a name for the new configuration for the RSA SecurID token server in the box provided, or accept the default name in the box.

c. Click Submit.

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

Step 6 Click Configure.

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 About Unknown User Authentication. For more information about configuring user accounts to authenticate using this database, see "User Management".


Deleting an External User Database Configuration

If you no longer need a particular external user database configuration, you can delete it from Cisco Secure ACS.

To delete an external user database configuration, follow these steps:


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

Step 2 Click Database Configuration.

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.

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.

A confirmation dialog box appears.

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

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