User Guide for Cisco Secure ACS for Windows Server 3.2
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

The Cisco Secure ACS Authentication Process with Windows User Databases

Trust Relationships

Windows Dial-up Networking Clients

Windows Authentication

EAP and Windows 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

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

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

RADIUS-Enabled Token Servers

RSA SecurID Token Servers

Deleting an External User Database Configuration

User Databases


CiscoSecure AccessControlServer (ACS) for WindowsServer authenticates users against one of several possible databases, including its internal database. You can configure CiscoSecure 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 CiscoSecure 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, CiscoSecure 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 CiscoSecure 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.

Unless you have configured CiscoSecure ACS to authenticate users with an external user database, CiscoSecure 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 CiscoSecure ACS for Windows 2000 Servers. Of these, RDBMS Synchronization and CSUtil.exe support importing user accounts from external sources.

CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 "RDBMS Synchronization Import Definitions."

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

About External User Databases

You can configure CiscoSecure ACS to forward authentication of users to one external user database or more. Support for external user databases means that CiscoSecure 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, CiscoSecure ACS can leverage the work already invested in building the database without any additional input.

In addition to performing authentication for network access, CiscoSecure 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 CiscoSecure ACS assigns a user to. The CiscoSecure user database, internal to CiscoSecure ACS, provides all authorization services. With few exceptions, CiscoSecure 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-based token servers, including:

ActivCard token servers

CRYPTOCard token servers

Vasco token servers

PassGo token servers

SafeWord token servers

Generic RADIUS token servers

For CiscoSecure ACS to interact with an external user database, CiscoSecure ACS requires an API for third-party authentication source. The CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS Windows server.

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

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

Authenticating with External User Databases

Authenticating users with an external user database requires more than configuring CiscoSecure 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 CiscoSecure ACS to authenticate any users with that database.

After you have configured CiscoSecure ACS to communicate with an external user database, you can configure CiscoSecure ACS to authenticate users with the external user database in one of two ways:

By Specific User Assignment —You can configure CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS group and thereby receive the applicable access profile.

By Unknown User Policy —You can configure CiscoSecure 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 Unknown User Processing.

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

External User Database Authentication Process

When CiscoSecure 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 CiscoSecure ACS. Upon receiving the response from the external user database, CiscoSecure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the external user database. Figure13-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, CiscoSecure ACS uses TCP connections. For Windows user databases, CiscoSecure ACS uses the authentication API provided in the Windows operating system. With the exception of RSA token servers, CiscoSecure ACS communicates with token servers using RADIUS. For RSA token servers, CiscoSecure 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 CiscoSecure ACS to use a Windows user database to authenticate users.

This section contains the following topics:

What's Supported with Windows User Databases

The CiscoSecure ACS Authentication Process 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

Windows Authentication

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

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

User Authentication —CiscoSecure 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. CiscoSecure 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 —CiscoSecure ACS supports machine authentication with EAP-TLS and PEAP(EAP-MSCHAPv2). For more information, see EAP and Windows Authentication.

Group Mapping for Unknown Users —CiscoSecure 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 —CiscoSecure 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 —CiscoSecure ACS supports use of dial-in permissions from Windows user databases. For more information, see Preparing Users for Authenticating with Windows.

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

The Cisco Secure ACS Authentication Process with Windows User Databases

CiscoSecure ACS forwards user credentials to a Windows database by passing the user credentials to the Windows operating system of the computer running CiscoSecure ACS. The Windows database either passes or fails the authentication request from CiscoSecure ACS. Upon receiving the response from the Windows database, CiscoSecure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the Windows database.

CiscoSecure ACS grants authorization based on the CiscoSecure 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 CiscoSecure ACS that grants authorization privileges.

To further control access by a user, you can configure CiscoSecure ACS to also check the setting for granting dialin permission to the user. This setting is labeled "Grant dialin permission to user" in WindowsNT and "Allow access" in the Remote Access Permission area in Windows2000. If this feature is disabled for the user, access is denied, even if the username and password are typed correctly.

Trust Relationships

CiscoSecure ACS can take advantage of trust relationships that have been established between Windows domains. If the domain that contains CiscoSecure ACS trusts another domain, CiscoSecure ACS can authenticate users whose accounts reside in the other domain. CiscoSecure ACS can also reference the "Grant dialin permission to user" setting across trusted domains.


Note If CiscoSecure ACS is running on a member server rather than a domain controller, taking advantage of trust relationships depends upon proper configuration of CiscoSecure ACS at installation. For more information, see "Windows Authentication from a Member Server" in Installation Guide for CiscoSecure ACS for Windows Server.


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


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


password —Type your password.

Windows Authentication

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

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

DOMAIN_NAME\USER_NAME

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

Domain10\msmith

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


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



Note Except in EAP-TLS authentication against Active Directory, CiscoSecure ACS does not support the user@domain (UPN) format of qualified usernames when authenticating users with Windows user databases of any type, including local and domain SAM databases and Active Directory databases. With Active Directory, EAP-TLS authentication with user certificates using UPN format is supported.


If you do not specify a domain name when typing the username, CiscoSecure ACS submits the username to the Windows. If Windows does not find the username in its local domain database, it then checks all trusted domains. If CiscoSecure ACS runs on a member server and the username is not found in trusted domains, Windows also checks its local accounts database. Windows attempts to authenticate a user with the first occurrence of the username that it finds.


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


Use of the Domain List is not required to support Windows authentication, but it can alleviate authentication failures caused by non-domain-qualified usernames. If you have configured the Domain List in the Windows User Database Configuration page of the External User Databases section, CiscoSecure ACS submits the username and password to each domain in the list in a fully qualified format until it successfully authenticates the user. If CiscoSecure ACS has tried each domain listed in the Domain List or if no trusted domains have been configured in the Domain List, CiscoSecure 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 CiscoSecure ACS tries each domain in the Domain List explicitly, resulting in failed attempts for identical usernames that reside in different domains.


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, CiscoSecure 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 CiscoSecure 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 Windows Authentication.

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

Machine Authentication

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

1. Machine authentication —The computer is authenticated by CiscoSecure ACS prior to user authentication. CiscoSecure 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.

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


3. User network authentication —The user is authenticated by CiscoSecure 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.


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


Note The MAR feature is available beginning in CiscoSecure ACS version 3.2.3. Earlier versions of CiscoSecure ACS do not include this feature.


When you enable the MAR feature, CiscoSecure ACS does the following:

For every successful machine authentication, CiscoSecure ACS caches the value received in IETF RADIUS Calling-Station-Id attribute (31) as evidence of the successful machine authentication. CiscoSecure 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, CiscoSecure 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 CiscoSecure ACS finds the user-authentication Calling-Station-Id value in the cache affects how CiscoSecure ACS assigns the user requesting authentication to a user group.

Calling-Station-Id value found in the cache —CiscoSecure 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, CiscoSecure ACS applies to the user session the authorization settings specified in group 137.

Calling-Station-Id value not found in the cache —CiscoSecure 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, CiscoSecure 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).

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

Microsoft Windows and Machine Authentication

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

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 CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS only. For information about configuring Microsoft Windows operating systems to support machine authentication, see Microsoft Windows and Machine Authentication.


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


Step1 Install a server certificate in CiscoSecure ACS. PEAP(EAP-MSCHAPv2) and EAP-TLS require a server certificate. CiscoSecure ACS uses a single certificate to support both protocols. For detailed steps, see Installing a CiscoSecure 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 CiscoSecure ACS administration, you do not need to perform this step. A single server certificate will support all certificate-based CiscoSecure ACS services and remote administration.


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

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

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

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

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

Step5 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 CiscoSecure 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. CiscoSecure ACS makes no distinction in unknown user support between computers and users.


CiscoSecure 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, CiscoSecure 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 CiscoSecure 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 CiscoSecure 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:


Step1 Make sure the username exists in the Windows user database.

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

User must change password at next logon

Account disabled

Step3 If you want to control dial-in access from within WindowsNT, click Dial-in and select Grant dialin permission to user . In Windows2000, 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 CiscoSecure 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 CiscoSecure 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 PIXFirewall to authenticate Telnet sessions using CiscoSecure ACS as a RADIUS server, a user authenticated by a Windows external user database would be denied Telnet access to the PIXFirewall 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 WindowsNT and on the Dial-In tab of the user properties in Windows2000.


Configure Domain List —The Domain List controls what CiscoSecure 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, CiscoSecure ACS stops attempting to authenticate the user. If domains are in the Domain List, CiscoSecure 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 Windows Authentication.



Caution If your Domain List contains domains and your Windows SAM or Active Directory user databases are configured to lock out users after a number of failed attempts, users can be inadvertently locked out because CiscoSecure 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 CiscoSecure ACSdoes not send domain-qualified authentication requests to.

Domain List —This list represents the domains that CiscoSecure ACSdoes send domain-qualified authentication requests to.

MS CHAP Settings —You can control whether CiscoSecure 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 CiscoSecure 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 CiscoSecure 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, CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure 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, CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 PEAP or EAP-TLS machine authentication, 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure 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, CiscoSecure 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 CiscoSecure ACS to authenticate users against the Windows user database in the trusted domains of your network, follow these steps:


Step1 In the navigation bar, click External User Databases .

Step2 Click Database Configuration .

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

Step3 Click Windows Database .

If no Windows database configuration exists, the Database Configuration Creation table appears. Otherwise, the External User Database Configuration page appears.

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

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

Step5 Click Configure .

The Windows User Database Configuration page appears.

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


Step7 Click Submit .

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


Generic LDAP

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


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

CiscoSecure 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

CiscoSecure 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 CiscoSecure ACS. Upon receiving the response from the LDAP database, CiscoSecure ACS instructs the requesting AAA client to grant or deny the user access, depending upon the response from the LDAP server.

CiscoSecure ACS grants authorization based on the CiscoSecure 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 CiscoSecure ACS that grants authorization privileges.

Multiple LDAP Instances

You can create more than one LDAP configuration in CiscoSecure ACS. By creating more than one LDAP configuration with different IP address or port settings, you can configure CiscoSecure 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 CiscoSecure ACS LDAP configuration instance.

CiscoSecure 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 CiscoSecure ACS should submit authentication requests.

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

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

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

LDAP Organizational Units and Groups

LDAP groups do not need to have the same name as their corresponding CiscoSecure ACS groups. The LDAP group can be mapped to a CiscoSecure 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 CiscoSecure 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 CiscoSecure 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, CiscoSecure ACS receives the username in username@domainname format. When PEAP authentication is initiated by a Cisco Aironet end-user client, CiscoSecure 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, CiscoSecure 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—CiscoSecure 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 CiscoSecure ACS can perform domain filtering in one of two ways:

Limiting users to one domain —Per each LDAP configuration in CiscoSecure ACS, you can require that CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS—domain qualified or non-domain qualified. The end-user client or AAA client must submit the username to CiscoSecure ACS in a domain-qualified format, otherwise CiscoSecure 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 CiscoSecure ACS, you can configure CiscoSecure 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.

CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS in a domain-qualified format.


Note With this option, CiscoSecure 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

CiscoSecure ACS supports failover between a primary LDAP server and secondary LDAP server. In the context of LDAP authentication with CiscoSecure ACS, failover applies when an authentication request fails because CiscoSecure ACS could not connect to an LDAP server, such as when the server is down or is otherwise unreachable by CiscoSecure 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 CiscoSecure ACS attempts to contact cannot be reached, CiscoSecure ACS always attempts to contact the other LDAP server. The first server CiscoSecure ACS attempts to contact may not always be the primary LDAP server. Instead, the first LDAP server that CiscoSecure 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, CiscoSecure ACS successfully connected to the primary LDAP server, CiscoSecure ACS attempts to connect to the primary LDAP server. If CiscoSecure ACS cannot connect to the primary LDAP server, CiscoSecure ACS attempts to connect to the secondary LDAP server.

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

Unsuccessful Previous Authentication with the Primary LDAP Server

If, on the previous LDAP authentication attempt, CiscoSecure ACS could not connect to the primary LDAP server, whether CiscoSecure 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), CiscoSecure ACS always attempts to connect to the primary LDAP server first. And if CiscoSecure ACS cannot connect to the primary LDAP server, CiscoSecure ACS then attempts to connect to the secondary LDAP server.

If the Failback Retry Delay box is set to a number other than zero, CiscoSecure 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, CiscoSecure ACS attempts to connect to the primary LDAP server first. And if CiscoSecure ACS cannot connect to the primary LDAP server, CiscoSecure 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, CiscoSecure ACS attempts to connect to the secondary LDAP server first. And if CiscoSecure ACS cannot connect to the secondary LDAP server, CiscoSecure ACS then attempts to connect to the primary LDAP server.

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

LDAP Configuration Options

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

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, CiscoSecure 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, CiscoSecure 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. CiscoSecure 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 CiscoSecure 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, CiscoSecure ACS only processes usernames that begin with the characters specified in the Domain Qualifier box. If you select Suffix, CiscoSecure 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 CiscoSecure 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 CiscoSecure 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, CiscoSecure 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 CiscoSecure ACS attempts to strip a prefixed domain qualifier. If, in the username, CiscoSecure 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, CiscoSecure 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:
# ? " * > <
CiscoSecure 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 CiscoSecure ACS attempts to strip a suffixed domain qualifier. If, in the username, CiscoSecure 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, CiscoSecure 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:
# ? " * > <
CiscoSecure 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. CiscoSecure 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. CiscoSecure 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 CiscoSecure ACS waits for a response from an LDAP server before determining that the connection with that server has failed.

On Timeout Use Secondary —Whether CiscoSecure 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 CiscoSecure ACS resumes sending authentication requests to the primary LDAP server first. A value of 0 (zero) causes CiscoSecure 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 CiscoSecure ACS uses LDAP version 3 or version 2 to communicate with your LDAP database. If this check box is selected, CiscoSecure ACS uses LDAP version 3. If it is not selected, CiscoSecure ACS uses LDAP version 2.

Security —Whether CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS to use the LDAP User Database, follow these steps:


Step1 In the navigation bar, click External User Databases .

Step2 Click Database Configuration .

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

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

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

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

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


Step6 Click Configure .


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


Step7 If you do not want CiscoSecure ACS to filter LDAP authentication requests by username, under Domain Filtering, select Process all usernames .

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

Step9 If you want to enable CiscoSecure 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.


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

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

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


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

Step14 In the GroupObjectType box, type the name of the attribute in the group record that contains the group name.

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

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

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

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

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


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


Step20 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 cert7.db 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.

Step21 Click Submit .

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


Novell NDS Database

CiscoSecure 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

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


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


Configuring CiscoSecure 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 CiscoSecure 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, CiscoSecure ACS depends upon Novell Requestor. Novell Requestor must be installed on the same Windows server as CiscoSecure 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, CiscoSecure ACS must be correctly configured to recognize the Novell NDS structure. CiscoSecure 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 CiscoSecure 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 CiscoSecure 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.

Table13-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 CiscoSecure 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 CiscoSecure ACS web server. CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 o= and ou= 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS. If the Novell Requestor Software for Novell NDS is not on the same computer as CiscoSecure ACS, you cannot complete this procedure.

To configure Novell NDS authentication, follow these steps:


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

Step2 In the navigation bar, click External User Databases .

Step3 Click Database Configuration .

CiscoSecure ACS lists all possible external user database types.

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

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

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

Step6 Click Configure .


Caution If you click Delete, the CiscoSecure 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.

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


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


Step9 If you want to delete an existing tree configuration, select the Delete Tree check box.

Step10 Click Submit .

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


ODBC Database

As with Windows user database support, CiscoSecure ACS ODBC-compliant relational database support enables you to make use of existing user records held in an external ODBC-compliant relational database. Configuring CiscoSecure 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 CiscoSecure ACS, the ODBC-compliant relational database is not supplied as part of CiscoSecure 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

CiscoSecure 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

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

Authentication —CiscoSecure ACS supports ASCII, PAP, ARAP, CHAP, MS-CHAP (versions 1 and 2), LEAP, EAP-TLS, EAP-MD5, PEAP(EAP-GTC), 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 —CiscoSecure 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 —CiscoSecure 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

CiscoSecure 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, CiscoSecure 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 CiscoSecure ACS. If the returned values indicate that the user credentials provided are valid, CiscoSecure ACS instructs the requesting AAA client to grant the user access; otherwise, CiscoSecure ACS denies the user access ( Figure13-2).

Figure 13-2 Using the ODBC Database for Authentication

CiscoSecure ACS grants authorization based on the CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS before configuring CiscoSecure ACS with an ODBC external user database.

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


Step1 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 CiscoSecure ACS.


Step2 Create the database to hold the usernames and passwords. The database name is irrelevant to CiscoSecure ACS, so you can name the database however you like.

Step3 Create the table or tables that will hold the usernames and passwords for your users. The table names are irrelevant to CiscoSecure 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.


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

Step5 Set up a system DSN on the computer running CiscoSecure ACS. For steps, see Configuring a System Data Source Name for an ODBC External User Database.

Step6 Configure CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS. The stored procedure returns the fields for the record with a matching username, including the password. CiscoSecure ACS confirms or denies authentication based on the values returned from the procedure.

Authentication for EAP-TLS occurs within CiscoSecure ACS. The stored procedure returns the field for the record, indicating whether it found the username in the ODBC database. CiscoSecure 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 CiscoSecure ACS support for the EAP-TLS protocol, see EAP-TLS Authentication.

To support the three sets of protocols, CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure 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 CiscoSecure ACS for PAP authentication. Table and column names that could vary for your database schema are presented in variable text. For your convenience, the CiscoSecure 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 CiscoSecure 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 CiscoSecure 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

Table13-2 details the input provided by CiscoSecure 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. Table13-3 lists the procedure results CiscoSecure ACS expects as output from stored procedure.

Table 13-3 PAP Stored Procedure Results 

Field
Type
Explanation

CSNTresult

Integer

See Table13-8.

CSNTgroup

Integer

The CiscoSecure 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 CiscoSecure ACS adds to subsequent account log file entries.

CSNTerrorString

String

0-255 characters. A customer-defined string that CiscoSecure 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

CiscoSecure 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 CiscoSecure ACS performs authentication for CHAP/MS-CHAP/ARAP, the user password is not an input ( Table13-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. Table13-5 lists the procedure results CiscoSecure ACS expects as output from stored procedure.

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

Field
Type
Explanation

CSNTresult

Integer

See Table13-8 Result Codes.

CSNTgroup

Integer

The CiscoSecure 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 CiscoSecure ACS adds to subsequent account log file entries.

CSNTerrorString

String

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

CSNTpassword

String

0-255 characters. The password is authenticated by CiscoSecure ACS.


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

CiscoSecure 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 CiscoSecure ACS performs authentication for EAP-TLS, the user password is not an input ( Table13-6).


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. Table13-7 lists the procedure results CiscoSecure ACS expects as output from stored procedure.

Table 13-7 EAP-TLS Stored Procedure Results 

Field
Type
Explanation

CSNTresult

Integer

See Table13-8 Result Codes.

CSNTgroup

Integer

The CiscoSecure 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 CiscoSecure ACS adds to subsequent account log file entries.

CSNTerrorString

String

0-255 characters. A customer-defined string that CiscoSecure 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 Table13-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 CiscoSecure 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 CiscoSecure ACS, you must create a system DSN for CiscoSecure ACS to communicate with the relational database.

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


Step1 Using the local administrator account, log in to the computer running CiscoSecure ACS.

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

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

Step4 Click the System DSN tab.

Step5 Click Add .

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

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

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

Step9 Click OK .

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

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

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


Configuring an ODBC External User Database

Creating an ODBC database configuration provides CiscoSecure 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 CiscoSecure ACS for ODBC authentication, follow these steps:


Step1 In the navigation bar, click External User Databases .

Step2 Click Database Configuration .

CiscoSecure ACS lists all possible external user database types.

Step3 Click External ODBC Database .

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

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

Step5 Click Configure .

Step6 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 CiscoSecure ACS a DSN for the relational database, do so before completing these steps. For more information about creating a DSN for CiscoSecure ACS ODBC authentication, see Configuring a System Data Source Name for an ODBC External User Database.


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

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

Step9 In the DSN Connection Retries box, type the number of times CiscoSecure 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.


Step10 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 CiscoSecure ACS to become unstable if multiple threads are used. Where possible, CiscoSecure 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.


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

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


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


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


Step15 Click Submit .

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


LEAP Proxy RADIUS Server Database

For CiscoSecure ACS-authenticated users accessing your network via Cisco Aironet devices, CiscoSecure 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.


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


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

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


Step1 In the navigation bar, click External User Databases .

Step2 Click Database Configuration .

CiscoSecure ACS lists all possible external user database types.

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

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

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

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


Step6 Click Configure .

Step7 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 CiscoSecure ACS, this port should not be the same port used by CiscoSecure ACS for RADIUS authentication. For more information about the ports used by CiscoSecure ACS for RADIUS, see RADIUS.

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

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

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


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


Step8 Click Submit .

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


Token Server User Databases

CiscoSecure 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 CiscoSecure ACS

RADIUS-Enabled Token Servers

RSA SecurID Token Servers

About Token Servers and Cisco Secure ACS

CiscoSecure 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 CiscoSecure ACS. If CiscoSecure 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, CiscoSecure 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. CiscoSecure ACS then maintains the accounting information.

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

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

Token Servers and ISDN

CiscoSecure ACS supports token caching for ISDN terminal adapters and routers. One inconvenience of using token cards for OTP authentication with ISDN is that each Bchannel 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 Bchannel, users might have to enter many OTPs each time the second Bchannel comes into service.

CiscoSecure 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 Bchannel, 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 Bchannel, you can limit the time the second Bchannel is up. Furthermore, you can configure the second Bchannel to use the CHAP password specified during the first login to further lessen the chance of a security problem. When the first Bchannel is dropped, the cached token is erased.

RADIUS-Enabled Token Servers

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

About RADIUS-Enabled Token Servers

CiscoSecure ACS can support token servers using the RADIUS server built into the token server. Rather than using the proprietary API of the vendor, CiscoSecure ACS sends standard RADIUS authentication requests to the RADIUS authentication port on the token server. The token servers supported through their RADIUS servers are as follows:

ActivCard

CRYPTOCard

Vasco

SafeWord

PassGo

Any IETF RFC 2865-compliant token server

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

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

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

CiscoSecure ACS expects to receive one of the following three responses:

access-accept —No attributes are required; however, the response can indicate the CiscoSecure 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 ActivCard, CRYPTOCard, Vasco, Safeword, PassGo, and RADIUS Token Server external user databases in CiscoSecure ACS.

Before You Begin

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


Step1 In the navigation bar, click External User Databases .

Step2 Click Database Configuration .

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

ActivCard

CRYPTOCard

RADIUS Token Server

Vasco

SafeWord

PassGo

Step3 Click the link for the applicable RADIUS-enabled token server.

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

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

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

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


Step6 Click Configure .

Step7 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 CiscoSecure ACS, this port should not be the same port used by CiscoSecure ACS for RADIUS authentication. For more information about the ports used by CiscoSecure ACS for RADIUS, see RADIUS.


Note For CiscoSecure 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 CiscoSecure ACS allow communication over the UDP port specified in the Authentication Port box.


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

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

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


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


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


Step9 Click Submit .

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


RSA SecurID Token Servers

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


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

CiscoSecure 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 CiscoSecure ACS Windows 2000 server. The following procedure includes steps required to install the RSA client correctly on the CiscoSecure ACS Windows 2000 server.

Configuring an RSA SecurID Token Server External User Database

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

Before You Begin

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

Make sure you have the RSA ACE Client for Windows2000 software.

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


Step1 Install the RSA client on the computer running CiscoSecure ACS:

a. Log in to the computer running Cisco Secure ACS with administrative privileges.

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


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


c. Locate the ACE Server data directory, for example, /sdi/ace/data.

d. Get the file named sdconf.rec and place it in your Windows directory: %SystemRoot%\system32.

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

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

Step2 In the navigation bar, click External User Databases .

Step3 Click Database Configuration .

CiscoSecure ACS lists all possible external user database types.

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

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

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

Step6 Click Configure .

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


Deleting an External User Database Configuration

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

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


Step1 In the navigation bar, click External User Databases .

Step2 Click Database Configuration .

CiscoSecure ACS lists all possible external user database types.

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

The External User Database Configuration table appears.

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

Step5 Click Delete .

A confirmation dialog box appears.

Step6 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 CiscoSecure ACS.