User Guide for Cisco Secure ACS Appliance 3.2 - User Databases [Cisco Secure Access Control Server Solution Engine]

Table Of Contents

User Databases

CiscoSecure User Database

User Import and Creation

About External User Databases

Authenticating with External User Databases

External User Database Authentication Process

Windows User Database

What's Supported with Windows User Databases

Authentication 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

Selecting Remote Agents for Windows Authentication

Windows Authentication Configuration Options

Configuring Windows Authentication

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

Downloading a Certificate Database

Novell NDS Database

About Novell NDS User Databases

User Contexts

Novell NDS External User Database Options

Configuring a Novell NDS External User Database

LEAP Proxy RADIUS Server Database

Configuring a LEAP Proxy RADIUS Server External User Database

Token Server User Databases

About Token Servers and Cisco Secure ACS

Token Server RADIUS Authentication Request and Response Contents

Configuring a RADIUS Token Server External User Database

Deleting an External User Database Configuration

User Databases

CiscoSecure AccessControlServer (ACS) Appliance 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

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

The CiscoSecure user database 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 four ways to create user accounts in the in CiscoSecure ACS Appliance. Of these, only RDBMS Synchronization supports 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.

•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. This eliminates the need for separate databases.

In addition to 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 User Database

•Generic LDAP

•Novell NetWare Directory Services (NDS)

•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 the third-party authentication source. The CiscoSecure ACS communicates with the external user database using the API. For Windows, you must have installed and configured CiscoSecure ACS Remote Agent for Windows. The Windows remote agent interacts with the Windows operating system to provide authentication.

For Generic LDAP and Novell NDS authentication, the interface for the external authentication is provided by the CiscoSecure ACS Appliance.

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

• 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

– Microsoft Windows and Machine Authentication

– Machine Access Restrictions

– Enabling Machine Authentication

• User-Changeable Passwords with Windows User Databases

• Preparing Users for Authenticating with Windows

• Selecting Remote Agents for Windows Authentication

• Windows Authentication Configuration Options

• Configuring Windows Authentication

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.

Authentication Process with Windows User Databases

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

To further control access by a user from within the Windows User Manager or Active Directory Users and Computers, you can configure CiscoSecure ACS to also check the setting for granting dialin permission to user. 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 containing the computer running the Windows remote agent 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.

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 the remote agent runs on a Windows 2000 server in domain A. Domain A trusts domain B, but no trust relationship is established between domain A and domain C. If domain B trusts domain C, the remote agent in domain A can authenticate users whose accounts reside in domain C, making use of the indirect trust of domain C.

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

Windows Dial-up Networking Clients

The dial-up networking clients for Windows NT/2000/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\username
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 by way of the Windows remote agent. If Windows does not find the username in its local domain database, it then checks all trusted domains. If the Windows remote agent runs on a member server and the username is not found in trusted domains, Windows also checks its local accounts database. Windows attempts to authenticate a user with the first occurrence of the username that it finds.

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

• Microsoft Windows and Machine Authentication

• Machine Access Restrictions

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

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

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

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

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

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

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

e. Also on the Smart Card or other Certificate Properties dialog box, you can enforce that 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.

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

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

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.

Before You Begin

Windows authentication requires that you install at least one CiscoSecure ACS Remote Agent for Windows and complete the steps in Adding a Remote Agent. For information about installing CiscoSecure ACS Remote Agent for Windows, see Installation and Configuration Guide for CiscoSecure ACS Remote Agents.

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 Cisco Secure ACS 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 certification authority (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 Windows Authentication.

Note Windows authentication requires a CiscoSecure ACS Remote Agent for Windows.

CiscoSecure ACS is ready to perform machine authentication for computers whose names exist in the 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.

We strongly recommend that you use the Unknown User Policy. Most other means of adding all computer names in precisely the format required would be labor intensive and prone to human error.

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.

Selecting Remote Agents for Windows Authentication

Before you can configure CiscoSecure ACS to authenticate users with a Windows external user database, you must select a primary remote agent that is to deliver authentication requests to the Windows operating system. You may also select a secondary remote agent that CiscoSecure ACS is to use if the primary remote agent is unavailable.

Before You Begin

To complete this procedure, you must have already installed at least one CiscoSecure ACS Remote Agent for Windows and completed the steps in Adding a Remote Agent.

To select remote agents for Windows authentication, 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 .

The External User Database Configuration page appears.

Step4 Click Configure .

The Windows User Database Configuration page appears.

Step5 Click Windows Remote Agent Selection .

The Windows Remote Agent Selection appears.

Step6 From the Primary list, select the remote agent that CiscoSecure ACS should always use to authenticate users, provided that the remote agent is available.

Step7 From the Secondary list, select the remote agent that CiscoSecure ACS should use to authenticate users when the remote agent selected in the Primary list is unavailable.

Note If you do not want to use a secondary remote agent, from the Secondary list, select None.

Step8 Click Submit .

CiscoSecure ACS saves the remote agent selections you made. The Windows User Database Configuration page appears.

Windows Authentication Configuration Options

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

•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 enable machine access restrictions, you must specify a number greater than zero in the Aging time (hours) box.

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

Before You Begin

To complete this procedure, you must have completed the steps in Selecting Remote Agents for Windows Authentication.

To configure Windows authentication, 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 .

The External User Database Configuration page appears.

Step4 Click Configure .

The Windows User Database Configuration page appears.

Step5 Click Windows Authentication Configuration .

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

• Downloading a Certificate 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 by the "Qualified by" option and that are qualified with the username specified in the Domain option. 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 box. If you select Suffix, CiscoSecure ACS only processes usernames that end in the characters specified in the Domain box.

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

–Domain —When "Only process usernames that are domain qualified" is selected, this option specifies the domain name and delimiting character that must qualify usernames in order for CiscoSecure ACS to 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 in the "Qualified by" list, the Domain box should contain "@mydomain". If the domain name is "yourdomain", the delimiting character is "\", and Prefix is selected in the "Qualified by" list, the Domain 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 before submitting a username to an LDAP server. CiscoSecure ACS also removes the delimiter between the domain qualifier and the username. 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 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\jwiedman", Cisco Secure ACS submits "jwiedman" to an LDAP server.

–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 specified in the Y box, it strips all characters from the delimiter character through the end of the user name. If the username contains more than one of the characters 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", Cisco Secure ACS submits "jwiedman" to an LDAP server.

•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 distinguished name (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 machine 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 number 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 secure socket layer (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 cleartext.

–Download Certificate database —A link to the Download Certificate Database page, on which you can download a cert7.db certificate database file to CiscoSecure ACS. The cert7.db file must contain the certificates for the server to be queried and the trusted CA. You can generate cert7.db files using a Netscape web browser. For information about generating a cert7.db file, refer to Netscape documentation. For information about the Download Certificate Database page, see Downloading a Certificate Database.

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. Since the certificate database must be local to the Cisco Secure ACS Appliance, you must use FTP to transfer the certificate database to Cisco Secure ACS.

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

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

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

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.

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

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.

Note User records often have several values for the objectType attribute, some of which are unique to the user, some of which are shared with other object types. Make sure that the value you provide in the User Object Class box is 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 machine 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 number 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. If you want Cisco Secure ACS to use SSL to connect to the LDAP server, select the Use secure authentication check box and complete the next three steps.

Note If you do not use SSL, the username and password credentials are passed over the network to the LDAP directory in clear text.

e. To download a cert7.db certificate database file to Cisco Secure ACS now, complete the steps in Downloading a Certificate Database , and then continue with step F.

Note You can download a certificate database later. Until a certificate database is downloaded for the current LDAP server, secure authentication to this LDAP server fails.

f. In the Admin DN box, type the following information about an LDAP account that permits searches for all required users under the User Directory Subtree:
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.

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

For more information, refer to your LDAP database documentation.

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 LDAP 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"

Downloading a Certificate Database

Before You Begin

The database must be a cert7.db certificate database file generated by a Netscape web browser. No other filename is supported. For information about generating a cert7.db file, refer to Netscape documentation.

To download a certificate database for a primary or a secondary LDAP server, follow these steps:

Note Downloading a certificate database is a part of the larger process of configuring an LDAP external user database. For more information, see Configuring a Generic LDAP External User Database.

Step1 To access the Download Certificate Database page, follow these steps:

a. Open the LDAP Database Configuration page that contains the information for the LDAP server whose certificate database file you want to download.

Note If you are already on the applicable LDAP Database Configuration page, proceed to Step b.

b. For the LDAP server whose certificate database file you want to download, click Download Certificate database.

Note CiscoSecure ACS lists a primary and secondary LDAP server for each LDAP database configuration. To support secure authentication to both servers, you must download a certificate database file twice, once for the primary LDAP server and once for the secondary LDAP server.

Step2 In the FTP Server box, type the IP address or hostname of the FTP server. The FTP Server box accepts a maximum of 512 characters.

Note Providing the hostname requires that DNS is operating correctly on your network.

Step3 In the Login box, type a valid username to enable CiscoSecure ACS to access the FTP server. The Login box accepts a maximum of 512 characters.

Step4 In the Password box, type the password for the username provided in the Login box. The Password box accepts a maximum of 512 characters.

Step5 In the Directory box, type the path to the cert7.db file. The path is relative to the starting directory at login to the FTP server.

For example, if the cert7.db file is located in c:\ACS-files\LDAPcertdb and the user provided in the Login box starts its FTP sessions in c:\, you would type ACS-files\LDAPcertdb.

The Directory box accepts a maximum of 512 characters.

Step6 Click Download .

CiscoSecure ACS downloads the cert7.db file from the FTP server. The LDAP Database Configuration page appears.

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

To use NDS authentication with a CiscoSecure ACS Appliance, you must have a Novell NDS database that is configured to use standard LDAP.

Note CiscoSecure ACS Appliance only supports NDS servers that are configured to use standard LDAP.

CiscoSecure ACSAppliance supports ASCII, PAP, EAP-TLS, PEAP(EAP-GTC), and EAP-FAST (phase two only) authentication with Novell NetWare Directory Services (NDS) servers. 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.

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 NDS servers. 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. If you enable subtree searching, authentication can succeed if the user object is in a subtree of one of the contexts provided.

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, authentication responses from a Novell NDS database may reflect user settings applied to the authentication response by the Novell NDS database. For example, CiscoSecure ACS does not fetch and process network access restrictions but the Novell NDS database may fail an authentication request based on network access restrictions stored in the Novell NDS database.

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.

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:
o=ABC-Company,ou=sales.o=ABC-Company
Agamemnon would successfully authenticate if he submitted "Agamemnon" as his username. If he submitted "Agamemnon.sales", 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 host, change existing host configurations, and delete existing host configurations in a single submission to the CiscoSecure ACS web server. CiscoSecure ACS displays information for each host configured, plus a blank form for creating a host. The configuration items presented for each host are as follows:

•Add New NDS Host —Appears only on the blank form for a new NDS host. Selecting this check box confirms that you want to add a new NDS host.

•Delete NDS Host —Appears only on existing NDS host configurations. Selecting this check box indicates that you want to delete the NDS host configuration when you click Submit.

•Test Login —Selecting this check box causes CiscoSecure ACS to test the administrative login to the NDS host when you click Submit. If the login fails, either because the credentials specified are incorrect or because CiscoSecure ACS could not connect to the NDS host, CiscoSecure ACS displays an error message.

•NDS Host —Appears only on the blank form for a new NDS host. The name of the Novell NDS host configuration you are creating.

Note The name specified in the NDS Host box is an arbitrary name and does not affect connectivity to the actual computer running Novell NDS.

•Host IP —The hostname or IP address of the Novell NDS host against which CiscoSecure ACS should authenticate users. If you specify a hostname, be sure DNS is operating correctly on your network.

•Administrator Username —The fully qualified, typed username for the administrator of the Novell server. For example:
uid=admin.ou=Chicago.o=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 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 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, typed form; that is, include 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:
ou=Engineering.ou=Chicago.o=Corporation,ou=Marketing.ou=Chicago.o=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.

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 host, change existing host configurations, and delete existing host 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 host 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 host configuration.

Step8 If you want to change an existing host configuration, edit the values you need to change.

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

Step9 If you want to delete an existing host 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"

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

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.

•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

• Token Server RADIUS Authentication Request and Response Contents

• Configuring a RADIUS Token Server External User Database

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. CiscoSecure ACS then acts as a RADIUS client to 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 that CiscoSecure ACS Appliance supports by means of their RADIUS interface are as follows:

•RSA SecureID

•ActivCard

•CRYPTOCard

•Vasco

•SafeWord

•PassGo

•Any IETF RFC 2865-compliant token server

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

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 a token server external user databases in CiscoSecure ACS.

Before You Begin

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

To configure CiscoSecure ACS to authenticate users with a token server, 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 the link for the applicable token server.

Note If you are using a token server from a vendor other than those listed in the HTML interface, select RADIUS 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 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 token server configuration exists, the name of that configuration appears instead of the list. Continue with Step6.

Step6 Click Configure .

Step7 In the following boxes, type the required information:

•Primary Server Name/IP —The hostname or IP address of the primary 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 token server. If you provide the hostname, the hostname must be resolvable by DNS.

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

•Authentication Port —The UDP port over which the token server conducts RADIUS authentication sessions.

Note For CiscoSecure ACS to send RADIUS OTP messages to a token server, you must ensure that gateway devices between the 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 token server before retrying the authentication request.

•Retries —The number of authentication attempts CiscoSecure ACS makes before failing over to the secondary 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 the prompt that Cisco Secure ACS will present in the Prompt box.

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 vendor 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 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"

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.