User Guide for Cisco Secure Access Control System 5.2
Managing Users and Identity Stores
Downloads: This chapterpdf (PDF - 1.2MB) The complete bookPDF (PDF - 17.78MB) | Feedback

Managing Users and Identity Stores

Table Of Contents

Managing Users and Identity Stores

Overview

Internal Identity Stores

External Identity Stores

Identity Stores with Two-Factor Authentication

Identity Groups

Certificate-Based Authentication

Identity Sequences

Managing Internal Identity Stores

Authentication Information

Identity Groups

Creating Identity Groups

Deleting an Identity Group

Managing Identity Attributes

Standard Attributes

User Attributes

Host Attributes

Configuring Authentication Settings for Users

Creating Internal Users

Deleting Users from Internal Identity Stores

Viewing and Performing Bulk Operations for Internal Identity Store Users

Creating Hosts in Identity Stores

Deleting Internal Hosts

Viewing and Performing Bulk Operations for Internal Identity Store Hosts

Managing External Identity Stores

LDAP Overview

Directory Service

Authentication Using LDAP

Multiple LDAP Instances

Failover

LDAP Connection Management

Authenticating a User Using a Bind Connection

Group Membership Information Retrieval

Attributes Retrieval

Certificate Retrieval

Creating External LDAP Identity Stores

Configuring an External LDAP Server Connection

Configuring External LDAP Directory Organization

Deleting External LDAP Identity Stores

Configuring LDAP Groups

Viewing LDAP Attributes

Leveraging Cisco NAC Profiler as an External MAB Database

Enabling the LDAP Interface on Cisco NAC Profiler to Communicate with ACS

Configuring NAC Profile LDAP Definition in ACS for Use in Identity Policy

Troubleshooting MAB Authentication with Profiler Integration

Microsoft AD

Machine Authentication

Attribute Retrieval for Authorization

Group Retrieval for Authorization

Certificate Retrieval for EAP-TLS Authentication

Concurrent Connection Management

User and Machine Account Restrictions

Machine Access Restrictions

Joining ACS to an AD Domain

Configuring an AD Identity Store

Selecting an AD Group

Configuring AD Attributes

RSA SecurID Server

Configuring RSA SecurID Agents

Creating and Editing RSA SecurID Token Servers

RADIUS Identity Stores

Supported Authentication Protocols

Failover

Password Prompt

User Group Mapping

Groups and Attributes Mapping

RADIUS Identity Store in Identity Sequence

Authentication Failure Messages

Username Special Format with Safeword Server

User Attribute Cache

Creating, Duplicating, and Editing RADIUS Identity Servers

Configuring CA Certificates

Adding a Certificate Authority

Editing a Certificate Authority and Configuring Certificate Revocation Lists

Deleting a Certificate Authority

Exporting a Certificate Authority

Configuring Certificate Authentication Profiles

Configuring Identity Store Sequences

Creating, Duplicating, and Editing Identity Store Sequences

Deleting Identity Store Sequences


Managing Users and Identity Stores


Overview

ACS manages your network devices and other ACS clients by using the ACS network resource repositories and identity stores. When a host connects to the network through ACS requesting access to a particular network resource, ACS authenticates the host and decides whether the host can communicate with the network resource.

To authenticate and authorize a user or host, ACS uses the user definitions in identity stores. There are two types of identity stores:

Internal—Identity stores that ACS maintains locally (also called local stores) are called internal identity stores. For internal identity stores, ACS provides interfaces for you to configure and maintain user records.

External—Identity stores that reside outside of ACS are called external identity stores. ACS requires configuration information to connect to these external identity stores to perform authentication and obtain user information.

In addition to authenticating users and hosts, most identity stores return attributes that are associated with the users and hosts. You can use these attributes in policy conditions while processing a request and can also populate the values returned for RADIUS attributes in authorization profiles.

Internal Identity Stores

ACS maintains different internal identity stores to maintain user and host records. For each identity store, you can define identity attributes associated with that particular store for which values are defined while creating the user or host records.

You can define these identity attributes as part of identity dictionaries under the System Administration section of the ACS application (System Administration > Configuration > Dictionaries > Identity).

Each internal user record includes a password, and you can define a second password as a TACACS+ enable password. You can configure the password stored within the internal user identity store to expire after a particular time period and thus force users to change their own passwords periodically.

Users can change their passwords over the RADIUS or TACACS+ protocols or use the UCP web service. Passwords must conform to the password complexity criteria that you define in ACS.

Internal user records consist of two component types: fixed and configurable.

Fixed components are:

Name

Description

Password

Enabled or disabled status

Identity group to which users belong

Configurable components are:

Enable password for TACACS+ authentication

Sets of identity attributes that determine how the user definition is displayed and entered

Cisco recommends that you configure identity attributes before you create users. When identity attributes are configured:

You can enter the corresponding values as part of a user definition.

They are available for use in policy decisions when the user authenticates.

They can be used to populate the values returned for RADIUS attributes in an authorization profile.

Internal user identity attributes are applied to the user for the duration of the user's session.

Internal identity stores contain the internal user attributes and credential information used to authenticate internal users.

Internal host records are similar to internal user records, except that they do not contain any password information. Hosts are identified by their MAC addresses. For information on managing internal identity stores, see Managing Internal Identity Stores.

External Identity Stores

External identity stores are external databases on which ACS performs authentications for internal and external users. ACS 5.2 supports the following external identity stores:

LDAP

Active Directory

RSA SecurID Token Server

RADIUS Identity Server

External identity store user records include configuration parameters that are required to access the specific store. You can define attributes for user records in all the external identity stores except the RSA SecurID Token Server. External identity stores also include certificate information for the ACS server certificate and certificate authentication profiles.

For more information on how to manage external identity stores, see Managing External Identity Stores.

Identity Stores with Two-Factor Authentication

You can use the RSA SecurID Token Server and RADIUS Identity Server to provide two-factor authentication. These external identity stores use an OTP that provides greater security. The following additional configuration options are available for these external identity stores:

Identity caching—You can enable identity caching for ACS to use the identity store while processing a request in cases where authentication is not performed. Unlike LDAP and AD, for which you can perform a user lookup without user authentication, the RSA SecurID Token Server and RADIUS Identity Server does not support user lookup.

For example, in order to authorize a TACACS+ request separately from the authentication request, taking into account that it is not possible for the identity store to retrieve the data because authentication is not performed, you can enable identity caching to cache results and attributes retrieved from the last successful authentication for the user. You can use this cache to authorize the request.

Treat authentication rejects as—The RSA and RADIUS identity stores do not differentiate between the following results when an authentication attempt is rejected:

Authentication Failed

User Not Found

This classification is very important when you determine the fail-open operation. A configuration option is available, allowing you to define which result must be used.

Identity Groups

Identity groups are logical entities that are defined within a hierarchy and are associated with users and hosts. These identity groups are used to make policy decisions. For internal users and hosts, the identity group is defined as part of the user or host definition.

When external identity stores are used, the group mapping policy is used to map attributes and groups retrieved from the external identity store to an ACS identity group. Identity groups are similar in concept to Active Directory groups but are more basic in nature.

Certificate-Based Authentication

Users and hosts can identify themselves with a certificate-based access request. To process this request, you must define a certificate authentication profile in the identity policy.

The certificate authentication profile includes the attribute from the certificate that is used to identify the user or host. It can also optionally include an LDAP or AD identity store that can be used to validate the certificate present in the request. For more information on certificates and certificate-based authentication, see:

Configuring CA Certificates

Configuring Certificate Authentication Profiles

Identity Sequences

You can configure a complex condition where multiple identity stores and profiles are used to process a request. You can define these identity methods in an Identity Sequence object. The identity methods within a sequence can be of any type.

The identity sequence is made up of two components, one for authentication and the other for retrieving attributes.

If you choose to perform authentication based on a certificate, a single certificate authentication profile is used.

If you choose to perform authentication on an identity database, you can define a list of identity databases to be accessed in sequence until the authentication succeeds. If the authentication succeeds, the attributes within the database are retrieved.

In addition, you can configure an optional list of databases from which additional attributes can be retrieved. These additional databases can be configured irrespective of whether you use password-based or certificate-based authentication.

If a certificate-based authentication is performed, the username is populated from a certificate attribute and this username is used to retrieve attributes from all the databases in the list. For more information on certificate attributes, see Configuring CA Certificates. When a matching record is found for the user, the corresponding attributes are retrieved. ACS retrieves attributes even for users whose accounts are disabled or whose passwords are marked for change.


Note An internal user account that is disabled is available as a source for attributes, but not for authentication.


For more information on identity sequences, see Configuring Identity Store Sequences.

This chapter contains the following sections:

Managing Internal Identity Stores

Managing External Identity Stores

Configuring CA Certificates

Configuring Certificate Authentication Profiles

Configuring Identity Store Sequences

Managing Internal Identity Stores

ACS contains an identity store for users and an identity store for hosts:

The internal identity store for users is a repository of users, user attributes, and user authentication options.

The internal identity store for hosts contains information about hosts for MAC Authentication Bypass (Host Lookup).

You can define each user and host in the identity stores, and you can import files of users and hosts.

The identity store for users is shared across all ACS instances in a deployment and includes for each user:

Standard attributes

User attributes

Authentication information


Note ACS 5.2 supports authentication for internal users against the internal identity store only.


This section contains the following topics:

Authentication Information

Identity Groups

Managing Identity Attributes

Configuring Authentication Settings for Users

Creating Internal Users

Viewing and Performing Bulk Operations for Internal Identity Store Users

Creating Hosts in Identity Stores

Viewing and Performing Bulk Operations for Internal Identity Store Hosts

Authentication Information

You can configure an additional password, stored as part of the internal user record that defines the user's TACACS+ enable password which sets the access level to device.. If you do not select this option, the standard user password is also used for TACACS+ enable.

If the system is not being used for TACACS+ enable operations, you should not select this option.

To use the identity store sequence feature, you define the list of identity stores to be accessed in a sequence. You can include the same identity store in authentication and attribute retrieval sequence lists; however, if an identity store is used for authentication, it is not accessed for additional attribute retrieval.

For certificate-based authentication, the username is populated from the certificate attribute and is used for attribute retrieval.

During the authentication process, authentication fails if more than one instance of a user or host exists in internal identity stores. Attributes are retrieved (but authentication is denied) for users who have disabled accounts or passwords that must be changed.

These types of failures can occur while processing the identity policy:

Authentication failure; possible causes include bad credentials, disabled user, and so on.

User or host does not exist in any of the authentication databases.

Failure occurred while accessing the defined databases.

You can define fail-open options to determine what actions to take when each of these failures occurs:

Reject—Send a reject reply.

Drop—Do not send a reply.

Continue—Continue processing to the next defined policy in the service.

The system attribute, AuthenticationStatus, retains the result of the identity policy processing. If you choose to continue policy processing when a failure occurs, you can use this attribute in a condition in subsequent policy processing to distinguish cases where identity policy processing did not succeed.

You can continue processing when authentication fails for PAP/ASCII, EAP-TLS, or EAP-MD5. For all other authentication protocols, the request is rejected and a message to this effect is logged.

Identity Groups

You can assign each internal user to one identity group. Identity groups are defined within a hierarchical structure. They are logical entities that are associated with users, but do not contain data or attributes other than the name you give to them.

You use identity groups within policy conditions to create logical groups of users to which the same policy results are applied. You can associate each user in the internal identity store with a single identity group.

When ACS processes a request for a user, the identity group for the user is retrieved and can then be used in conditions in the rule table. Identity groups are hierarchical in structure.

You can map identity groups and users in external identity stores to ACS identity groups by using a group mapping policy.

Creating Identity Groups

To create an identity group:


Step 1 Select Users and Identity Stores > Identity Groups.

The Identity Groups page appears.

Step 2 Click Create. You can also:

Check the check box next to the identity group that you want to duplicate, then click Duplicate.

Click the identity group name that you want to modify, or check the check box next to the name and click Edit.

Click File Operations to:

Add—Adds identity groups from the import to ACS.

Update—Overwrites the existing identity groups in ACS with the list from the import.

Delete—Removes the identity groups listed in the import from ACS.

Click Export to export a list of identity groups to your local hard disk.

For more information on the File Operations option, see Performing Bulk Operations for Network Resources and Users.

The Create page or the Edit page appears when you choose the Create, Duplicate, or Edit option.

Step 3 Enter information in the following fields:

Name—Enter a name for the identity group. If you are duplicating an identity group, you must enter a unique name; all other fields are optional.

Description—Enter a description for the identity group.

Parent—Click Select to select a network device group parent for the identity group.

Step 4 Click Submit to save changes.

The identity group configuration is saved. The Identity Groups page appears with the new configuration. If you created a new identity group, it is located within the hierarchy of the page beneath your parent identity group selection.


Related Topics

Managing Users and Identity Stores

Managing Internal Identity Stores

Performing Bulk Operations for Network Resources and Users

Identity Groups

Creating Identity Groups

Deleting an Identity Group

Deleting an Identity Group

To delete an identity group:


Step 1 Select Users and Identity Stores > Identity Groups.

The Identity Groups page appears.

Step 2 Check one or more check boxes next to the identity groups you want to delete and click Delete.

The following error message appears:

Are you sure you want to delete the selected item/items?

Step 3 Click OK.

The Identity Groups page appears without the deleted identity groups.


Related Topic

Managing Identity Attributes

Managing Identity Attributes

Administrators can define sets of identity attributes that become elements in policy conditions. For information about the ACS 5.2 policy model, see Chapter 3 "ACS 5.x Policy Model." During authentication, identity attributes are taken from the internal data store when they are part of a policy condition.

ACS 5.2 interacts with identity elements to authenticate users and obtain attributes for input to an ACS policy.

Attribute definitions include the associated data type and valid values. The set of values depends on the type. For example, if the type is integer, the definition includes the valid range. ACS 5.2 provides a default value definition that can be used in the absence of an attribute value. The default value ensures that all attributes have at least one value.

Related Topics

Standard Attributes

User Attributes

Host Attributes

Standard Attributes

Table 8-1 describes the standard attributes in the internal user record.

Table 8-1 Standard Attributes 

Attribute
Description

Username

ACS compares the username against the username in the authentication request. The comparison is case-insensitive.

Status

The enabled status indicates that the account is active. The disabled status means that authentications for the username will fail.

Description

A text description of the attribute.

Identity Group

ACS associates each user to an identity group. See Managing Identity Attributes for information.


User Attributes

Administrators can create and add user-defined attributes from the set of identity attributes. You can then assign default values for these attributes for each user in the internal identity store and define whether the default values are required or optional.

You need to define users in ACS, which includes associating each internal user with an identity group, a description (optional), a password, an enable password (optional), and internal and external user attributes.

Internal users are defined by two components: fixed and configurable. Fixed components consist of these attributes:

Name

Description

Password

Enabled or disabled status

Identity group to which they belong

Configurable components consist of these attributes:

Enable password for TACACS+ authentication

Sets of identity attributes that determine how the user definition is displayed and entered

Cisco recommends that you configure identity attributes before you create users. When identity attributes are configured:

You can enter the corresponding values as part of a user definition.

They are available for use in policy decisions when the user authenticates.

Internal user identity attributes are applied to the user for the duration of the user's session.

Internal identity stores contain the internal user attributes and credential information used to authenticate internal users (as defined by you within a policy).

External identity stores are external databases on which to perform credential and authentication validations for internal and external users (as defined by you within a policy).

In ACS 5.2, you can configure identity attributes that are used within your policies, in this order:

1. Define an identity attribute (using the user dictionary).

2. Define custom conditions to be used in a policy.

3. Populate values for each user in the internal database.

4. Define rules based on this condition.

As you become more familiar with ACS 5.2 and your identity attributes for users, the policies themselves will become more robust and complex.

You can use the user-defined attribute values to manage policies and authorization profiles. See Creating, Duplicating, and Editing an Internal User Identity Attribute for information on how to create a user attribute.

Host Attributes

You can configure additional attributes for internal hosts. You can do the following when you create an internal host:

Create host attributes

Assign default values to the host attributes

Define whether the default values are required or optional

You can enter values for these host attributes and can use these values to manage policies and authorization profiles. See Creating, Duplicating, and Editing an Internal Host Identity Attribute for information on how to create a host attribute.

Configuring Authentication Settings for Users

You can configure the authentication settings for user accounts in ACS to force users to use strong passwords. Any password policy changes that you make in the Authentication Settings page apply to all internal identity store user accounts. The User Authentication Settings page consists of the following tabs:

Password complexity

Advanced

To configure a password policy:


Step 1 Choose System Administration > Users > Authentication Settings.

The User Authentication Settings page appears with the Password Complexity and Advanced tabs.

Step 2 In the Password Complexity tab, check each check box that you want to use to configure your user password.

Table 8-2 describes the fields in the Password Complexity tab.

Table 8-2 Password Complexity Tab 

Option
Description
Applies to all ACS internal identity store user accounts

Minimum length

The required minimum length; the valid options are 4 to 20.

Password may not contain the username

Whether the password may contain the username or reverse username.

Password may not contain `cisco'

Check to specify that the password cannot contain the word cisco.

Password may not contain

Check to specify that the password does not contain the string that you enter.

Password may not contain repeated characters four or more times consecutively

Check to specify that the password cannot repeat characters four or more times consecutively.

Password must contain at least one character of each of the selected types

Lowercase alphabetic characters

Password must contain at least one lowercase alphabetic character.

Upper case alphabetic characters

Password must contain at least one uppercase alphabetic character.

Numeric characters

Password must contain at least one numeric character.

Non alphanumeric characters

Password must contain at least one nonalphanumeric character.


Step 3 In the Advanced tab, enter the values for the criteria that you want to configure for your user authentication process. Table 8-3 describes the fields in the Advanced tab.

Table 8-3 Advanced Tab

Options
Description
Password History

Password must be different from the previous n versions.

Specifies the number of previous passwords for this user to be compared against. The number of previous passwords include the default password as well. This option prevents the users from setting a password that was recently used. Valid options are 1 to 99.

Password Lifetime

Users can be required to periodically change password

Disable user account after n days if password is not changed

Specifies that the user account must be disabled after n days if the password is not changed; the valid options are 1 to 365. This option is applicable only for TACACS+ authentication.

Display reminder after n days

Displays a reminder after n days to change password; the valid options are 1 to 365. This option, when set, only displays a reminder. It does not prompt you for a new password. This option is applicable only for TACACS+ authentication.

TACACS Enable Password

Select whether a separate password should be defined in the user record to store the Enable Password

TACACS Enable Password

Check the check box to enable a separate password for TACACS+ authentication.


Step 4 Click Submit.

The user password is configured with the defined criteria. These criteria will apply only for future logins.


Creating Internal Users

In ACS, you can create internal users that do not access external identity stores for security reasons.

You can use the bulk import feature to import hundreds of internal users at a time; see Performing Bulk Operations for Network Resources and Users for more information. Alternatively, you can use the procedure described in this topic to create internal users one at a time.


Step 1 Select Users and Identity Stores > Internal Identity Store > Users.

The Internal Users page appears.

Step 2 Click Create. You can also:

Check the check box next to the user that you want to duplicate, then click Duplicate.

Click the username that you want to modify, or check the check box next to the name and click Edit.

Check the check box next to the user whose password you want to change, then click Change Password.

The Change Password page appears.

Step 3 Complete the fields as described in Table 8-4 to change the internal user password.

Table 8-4 Internal User - Change Password Page

Option
Description
Password Information

Password

The user's current password, which must comply with the password policies defined under System Administration > Users > Authentication Settings.

Confirm Password

The user's password, which must match the Password entry exactly.

Change Password on Next Login

Check this box to start the process to change the user's password at the next user login, after authentication with the old password.

Enable Password Information

Enable Password

(Optional) The internal user's TACACS+ enable password, from 4 to 32 characters. You can disable this option. See Authentication Information for more information.

Confirm Password

(Optional) The internal user's TACACS+ enable password, which must match the Enable Password entry exactly.


Click File Operations to:

Add—Adds internal users from the import to ACS.

Update—Overwrites the existing internal users in ACS with the list of users from the import.

Delete—Removes the internal users listed in the import from ACS.

Click Export to export a list of internal users to your local hard disk.

For more information on the File Operations option, see Performing Bulk Operations for Network Resources and Users.

The User Properties page appears when you choose the Create, Duplicate, or Edit option. In the Edit view, you can see the information on the original creation and last modification of the user. You cannot edit this information.

Step 4 Complete the fields as described in Table 8-5.

.

Table 8-5 Users and Identity Stores > Internal Identity Store > User Properties Page  

Option
Description
General

Name

The username of the user.

Status

Use the drop-down list box to select the status for the user:

Enabled—Authentication requests for this user are allowed.

Disabled—Authentication requests for this user fail.

Description

(Optional) The description of the user.

Identity Group

Click Select to display the Identity Groups window. Choose an identity group and click OK to configure the user with a specific identity group.

Password Information

Note This section of the page appears only when you create an internal user.

Password must contain at least 4 characters

Password

The user's password, which must comply with the password policies defined under System Administration > Users > Authentication Settings.

Confirm Password

The user's password, which must match the Password entry exactly.

Change Password on next login

Check this box to start the process to change the user's password at the next user login, after authentication with the old password.

Enable Password Information

Note This section of the page appears only when you create an internal user.

Password must contain 4-32 characters

Enable Password

(Optional) The internal user's TACACS+ enable password, from 4 to 32 characters. You can disable this option. See Authentication Information for more information.

Confirm Password

(Optional) The internal user's TACACS+ enable password, which must match the Enable Password entry exactly.

User Information

If defined, this section displays additional identity attributes defined for user records.

Creation/Modification Information

Note This section of the page appears only after you have created or modified an internal user.

Date Created

Display only. The date and time when the user's account was created, in the format Day Mon dd hh:mm:ss UTC YYYY, where:

Day = Day of the week.

Mon = Three characters that represent the month of the year: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sept, Oct, Nov, Dec

DD = Two digits that represent the day of the month; a space precedes single-digit days (1 to 9).

hh:mm:ss = Hour, minute, and second, respectively

YYYY = Four digits that represent the year

Date Modified

Display only. The date and time when the user's account was last modified (updated), in the format Day Mon dd hh:mm:ss UTC YYYY, where:

Day = Day of the week.

Mon = Three characters that represent the month of the year: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sept, Oct, Nov, Dec

DD = Two digits that represent the day of the month; a space precedes single-digit days (1 to 9).

hh:mm:ss = Hour, minute, and second, respectively

YYYY = Four digits that represent the year


Step 5 Click Submit.

The user configuration is saved. The Internal Users page appears with the new configuration.


Related Topics

Configuring Authentication Settings for Users

Viewing and Performing Bulk Operations for Internal Identity Store Users

Deleting Users from Internal Identity Stores

Deleting Users from Internal Identity Stores

To delete a user from an internal identity store:


Step 1 Select Users and Identity Stores > Internal Identity Store > Users.

The Internal Users page appears.

Step 2 Check one or more check boxes next to the users you want to delete.

Step 3 Click Delete.

The following message appears:

Are you sure you want to delete the selected item/items?
 
   

Step 4 Click OK.

The Internal Users page appears without the deleted users.


Related Topics

Viewing and Performing Bulk Operations for Internal Identity Store Users

Creating Internal Users

Viewing and Performing Bulk Operations for Internal Identity Store Users

To view and perform bulk operations to internal identity store users:


Step 1 Select Users and Identity Stores > Internal Identity Stores > Users.

The Internal Users page appears, with the following information for all configured users:

Status—The status of the user

User Name—The username of the user

Identity Group—The identity group to which the user belongs

Description—(Optional) A description of the user.

Step 2 Do one of the following:

Click Create. For more information on creating internal users, see Creating Internal Users.

Check the check box next to an internal user whose information you want to edit and click Edit. For more information on the various fields in the edit internal user page, see Creating Internal Users.

Check the check box next to an internal user whose information you want to duplicate and click Duplicate. For more information on the various fields in the duplicate internal user page, see Creating Internal Users.

Click File Operations to perform any of the following bulk operations:

Add—Choose this option to add internal users from the import file to ACS.

Update—Choose this option to replace the list of internal users in ACS with the list of internal users in the import file.

Delete—Choose this option to delete the internal users listed in the import file from ACS.

See Performing Bulk Operations for Network Resources and Users for a detailed description of the bulk operations.


Related Topics

Creating Internal Users

Viewing and Performing Bulk Operations for Internal Identity Store Users

Deleting Users from Internal Identity Stores

Creating Hosts in Identity Stores

To create, duplicate, or edit a MAC address and assign identity groups to internal hosts:


Step 1 Select Users and Identity Stores > Internal Identity Stores > Hosts.

The Internal Hosts page appears listing any configured internal hosts.

Step 2 Click Create. You can also:

Check the check box next to the MAC address you want to duplicate, then click Duplicate.

Click the MAC address that you want to modify, or check the check box next to the MAC address and click Edit.

Click File Operations to perform bulk operations. See Viewing and Performing Bulk Operations for Internal Identity Store Hosts for more information on the import process.

Click Export to export a list of hosts to your local hard drive.

The Internal Hosts General page appears when you click the Create, Duplicate, or Edit options.

Step 3 Complete the fields in the Internal MAC Address Properties page as described in Table 8-6:

Table 8-6 Internal Hosts Properties Page 

Option
Description
General

MAC Address

Enter a valid MAC address, using any of the following formats:

01-23-45-67-89-AB

01:23:45:67:89:AB

0123.4567.89AB

0123456789AB

ACS accepts a MAC address in any of the above formats, and converts and stores the MAC address as six hexadecimal digits separated by hyphens; for example, 01-23-45-67-89-AB.

Status

Use the drop-down list box to enable or disable the MAC address.

Description

(Optional) Enter a description of the MAC address.

Identity Group

Enter an identity group with which to associate the MAC address, or click Select to display the Identity Groups window. Choose an identity group with which to associate the MAC address, then click OK.

MAC Host Information

Display only. Contains MAC host identity attribute information.

Creation/Modification Information

Note This section of the page appears only after you have created or modified a MAC address.

Date Created

Display only. The date that the host account was created, in the format Day Mon dd hh:mm:ss UTC YYYY, where:

Day = Day of the week.

Mon = Three characters that represent the month of the year: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sept, Oct, Nov, Dec

DD = Two digits that represent the day of the month; a space precedes single-digit days (1 to 9).

hh:mm:ss = Hour, minute, and second, respectively

YYYY = Four digits that represent the year

Date Modified

Display only. The date that the host account was last modified (updated), in the format Day Mon dd hh:mm:ss UTC YYYY, where:

Day = Day of the week.

Mon = Three characters that represent the month of the year: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sept, Oct, Nov, Dec

DD = Two digits that represent the day of the month; a space precedes single-digit days (1 to 9).

hh:mm:ss = Hour, minute, and second, respectively

YYYY = Four digits that represent the year


Step 4 Click Submit to save changes.

The MAC address configuration is saved. The Internal MAC list page appears with the new configuration.


Related Topics

Host Lookup

Deleting Internal Hosts

Viewing and Performing Bulk Operations for Internal Identity Store Hosts

Policies and Identity Attributes

Configuring an Identity Group for Host Lookup Network Access Requests

Deleting Internal Hosts

To delete a MAC address:


Step 1 Select Users and Identity Stores > Internal Identity Stores > Hosts.

The Internal MAC List page appears, with any configured MAC addresses listed.

Step 2 Check one or more of the check boxes next to the internal hosts you want to delete.

Step 3 Click Delete.

The following message appears:

Are you sure you want to delete the selected item/items?
 
   

Step 4 Click OK.

The Internal MAC List page appears without the deleted MAC address(es).


Related Topics

Host Lookup

Viewing and Performing Bulk Operations for Internal Identity Store Hosts

Creating Hosts in Identity Stores

Policies and Identity Attributes

Configuring an Identity Group for Host Lookup Network Access Requests

Viewing and Performing Bulk Operations for Internal Identity Store Hosts

To view and perform bulk operations for internal identity stores:


Step 1 Select Users and Identity Stores > Internal Identity Stores > Hosts.

The Internal Hosts page appears, with any configured internal hosts listed.

Step 2 Click File Operations to perform any of the following functions:

Add—Choose this option to add internal hosts from an import file to ACS.

Update—Choose this option to replace the list of internal hosts in ACS with the internal hosts in the import file.

Delete—Choose this option to delete the internal hosts listed in the import file from ACS.

See Performing Bulk Operations for Network Resources and Users for a detailed description of the bulk operations.


Related Topics

Host Lookup

Creating Hosts in Identity Stores

Deleting Internal Hosts

Policies and Identity Attributes

Configuring an Identity Group for Host Lookup Network Access Requests

Managing External Identity Stores

ACS 5.2 integrates with external identity systems in a number of ways. You can leverage an external authentication service or use an external system to obtain the necessary attributes to authenticate a principal, as well to integrate the attributes into an ACS policy.

For example, ACS can leverage Microsoft AD to authenticate a principal, or it could leverage an LDAP bind operation to find a principal in the database and authenticate it. ACS can obtain identity attributes such as AD group affiliation to make an ACS policy decision.


Note ACS 5.2 does not have a built-in check for the dial-in permission attribute for Windows users. You must set the msNPAllowDialin attribute through LDAP or Windows AD. For information on how to set this attribute, refer to Microsoft documentation at: http://msdn.microsoft.com/en-us/library/ms678093%28VS.85%29.aspx


This section provides an overview of the external identity stores that ACS 5.2 supports and then describes how you can configure them.

This section contains the following topics:

LDAP Overview

Leveraging Cisco NAC Profiler as an External MAB Database

Microsoft AD

RSA SecurID Server

RADIUS Identity Stores

LDAP Overview

Lightweight Directory Access Protocol (LDAP), is a networking protocol for querying and modifying directory services that run on TCP/IP and UDP. LDAP is a lightweight mechanism for accessing an x.500-based directory server. RFC 2251 defines LDAP.

ACS 5.2 integrates with an LDAP external database, which is also called an identity store, by using the LDAP protocol. See Creating External LDAP Identity Stores for information about configuring an LDAP identity store.

This section contains the following topics:

Directory Service

Authentication Using LDAP

Multiple LDAP Instances

Failover

LDAP Connection Management

Authenticating a User Using a Bind Connection

Group Membership Information Retrieval

Attributes Retrieval

Certificate Retrieval

Creating External LDAP Identity Stores

Configuring LDAP Groups

Viewing LDAP Attributes

Directory Service

The directory service is a software application, or a set of applications, for storing and organizing information about a computer network's users and network resources. You can use the directory service to manage user access to these resources.

The LDAP directory service is based on a client-server model. A client starts an LDAP session by connecting to an LDAP server, and sends operation requests to the server. The server then sends its responses. One or more LDAP servers contain data from the LDAP directory tree or the LDAP backend database.

The directory service manages the directory, which is the database that holds the information. Directory services use a distributed model for storing information, and that information is usually replicated between directory servers.

An LDAP directory is organized in a simple tree hierarchy and can be distributed among many servers. Each server can have a replicated version of the total directory that is synchronized periodically.

An entry in the tree contains a set of attributes, where each attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema.

Each entry has a unique identifier: its Distinguished Name (DN). This name contains the Relative Distinguished Name (RDN) constructed from attributes in the entry, followed by the parent entry's DN. You can think of the DN as a full filename, and the RDN as a relative filename in a folder.

Authentication Using LDAP

ACS 5.2 can authenticate a principal against an LDAP identity store by performing a bind operation on the directory server to find and authenticate the principal. If authentication succeeds, ACS can retrieve groups and attributes that belong to the principal. The attributes to retrieve can be configured in the ACS web interface (LDAP pages). These groups and attributes can be used by ACS to authorize the principal.

To authenticate a user or query the LDAP identity store, ACS connects to the LDAP server and maintains a connection pool. See LDAP Connection Management.

Multiple LDAP Instances

You can create more than one LDAP instance in ACS 5.2. By creating more than one LDAP instance with different IP address or port settings, you can configure ACS to authenticate by using different LDAP servers or 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 ACS LDAP identity store instance.

ACS 5.2 does not require that each LDAP instance correspond to a unique LDAP database. You can have more than one LDAP instance set to access the same database.

This method is useful when your LDAP database contains more than one subtree for users or groups. Because each LDAP instance 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 ACS should submit authentication requests.

Failover

ACS 5.2 supports failover between a primary LDAP server and secondary LDAP server. In the context of LDAP authentication with ACS, failover applies when an authentication request fails because ACS could not connect to an LDAP server.

For example, as when the server is down or is otherwise unreachable by ACS. To use this feature, you must define primary and secondary LDAP servers, and you must set failover settings.

If you set failover settings and if the first LDAP server that ACS attempts to contact cannot be reached, ACS always attempts to contact the other LDAP server.

The first server ACS attempts to contact might not always be the primary LDAP server. Instead, the first LDAP server that ACS attempts to contact depends on the previous LDAP authentications attempts and on the value that you enter in the Failback Retry Delay box.

LDAP Connection Management

ACS 5.2 supports multiple concurrent LDAP connections. Connections are opened on demand at the time of the first LDAP authentication. The maximum number of connections is configured for each LDAP server. Opening connections in advance shortens the authentication time.

You can set the maximum number of connections to use for concurrent binding connections. The number of opened connections can be different for each LDAP server (primary or secondary) and is determined according to the maximum number of administration connections configured for each server.

ACS retains a list of open LDAP connections (including the bind information) for each LDAP server that is configured in ACS. During the authentication process, the connection manager attempts to find an open connection from the pool. If an open connection does not exist, a new one is opened.

If the LDAP server closed the connection, the connection manager reports an error during the first call to search the directory, and tries to renew the connection.

After the authentication process is complete, the connection manager releases the connection to the connection manager.

Authenticating a User Using a Bind Connection

ACS sends a bind request to authenticate the user against an LDAP server. The bind request contains the user's DN and user password in clear text. A user is authenticated when the user's DN and password matches the username and password in the LDAP directory.

Authentication Errors—ACS logs authentication errors in the ACS log files.

Initialization Errors—Use the LDAP server timeout settings to configure the number of seconds that ACS waits for a response from an LDAP server before determining that the connection or authentication on that server has failed.

Possible reasons for an LDAP server to return an initialization error are:

LDAP is not supported.

The server is down.

The server is out of memory.

The user has no privileges.

Incorrect administrator credentials are configured.

Bind Errors

Possible reasons for an LDAP server to return bind (authentication) errors are:

Filtering errors—A search using filter criteria fails.

Parameter errors—Invalid parameters were entered.

User account is restricted (disabled, locked out, expired, password expired, and so on).

The following errors are logged as external resource errors, indicating a possible problem with the LDAP server:

A connection error occurred.

The timeout expired.

The server is down.

The server is out of memory.

The following error is logged as an Unknown User error:

A user does not exist in the database.

The following error is logged as an Invalid Password error, where the user exists, but the password sent is invalid:

An invalid password was entered.

Group Membership Information Retrieval

For user authentication, user lookup, and MAC address lookup, ACS must retrieve the group membership information from LDAP databases. LDAP servers represent the association between a subject (a user or a host) and a group in one of the following two ways:

Groups Refer to Subjects—The group objects contain an attribute that specifies the subject. Identifiers for subjects can be stored in the group as:

Distinguished Names (DNs)

Plain usernames

Subjects Refer to Groups—The subject objects contain an attribute that specify the group they belong to.

LDAP identity stores contain the following parameters for group membership information retrieval:

Reference Direction—Specifies the method to use when determining group membership (either Groups to Subjects or Subjects to Groups).

Group Map Attribute—Indicates which attribute contains the group membership information.

Group Object Class—Determines that we recognize certain objects as groups.

Group Search Subtree—Indicates the search base for group searches.

Member Type Option—Specifies how members are stored in the group member attribute (either as DNs or plain usernames).

Attributes Retrieval

For user authentication, user lookup, and MAC address lookup, ACS must retrieve the subject attributes from LDAP databases. For each instance of an LDAP identity store, an identity store dictionary is created. These dictionaries support attributes of the following data types:

String

Unsigned Integer 32

IPv4 Address

For unsigned integers and IPv4 attributes, ACS converts the strings that it has retrieved to the corresponding data types. If conversion fails or if no values are retrieved for the attributes, ACS logs a debug message, but does not fail the authentication or the lookup process.

You can optionally configure default values for the attributes that ACS can use when the conversion fails or when ACS does not retrieve any values for the attributes.

Certificate Retrieval

If you have configured certificate retrieval as part of user lookup, then ACS must retrieve the value of the certificate attribute from LDAP. To do this, you must have configured certificate attribute in the List of attributes to fetch while configuring an LDAP identity store.

Creating External LDAP Identity Stores


Note Configuring an LDAP identity store for ACS has no effect on the configuration of the LDAP database. ACS recognizes the LDAP database, enabling the database to be authenticated against. To manage your LDAP database, see your LDAP database documentation.


When you create an LDAP identity store, ACS also creates:

A new dictionary for that store with two attributes, ExternalGroups and IdentityDn.

A custom condition for group mapping from the ExternalGroup attribute; the condition name has the format LDAP:ID_store_name ExternalGroups.

You can edit the predefined condition name, and you can create a custom condition from the IdentityDn attribute in the Custom condition page. See Creating, Duplicating, and Editing a Custom Session Condition.

To create, duplicate, or edit an external LDAP identity store:


Step 1 Select Users and Identity Stores > External Identity Stores > LDAP.

The LDAP Identity Stores page appears.

Step 2 Click Create. You can also:

Check the check box next to the identity store you want to duplicate, then click Duplicate.

Click the identity store name that you want to modify, or check the box next to the name and click Edit.

If you are creating an identity store, the first page of a wizard appears: General.

If you are duplicating an identity store, the External Identity Stores > Duplicate: "<idstore>" page General tab appears, where <idstore> is the name of the external identity store that you chose. (Is this a menu path or a tab? The ">" indicates that it is a menu path)

If you are editing an identity store, the External Identity Stores > Edit: "<idstore>" page General tab appears, where <idstore> is the name of the external identity store that you chose.

Step 3 Complete the Name and Description fields as required.

Step 4 Click Next.

Step 5 Continue with Configuring an External LDAP Server Connection.


Related Topic

Deleting External LDAP Identity Stores

Configuring an External LDAP Server Connection

Use this page to configure an external LDAP identity store.


Step 1 Select Users and Identity Stores > External Identity Stores > LDAP, then click any of the following:

Create and follow the wizard.

Duplicate, then click Next. The Server Connection page appears.

Edit, then click Next. The Server Connection page appears.

Table 8-7 LDAP: Server Connection Page 

Option
Description
Server Connection

Enable Secondary Server

Check to enable the secondary LDAP server, to use as a backup in the event that the primary LDAP server fails. If you check this check box, you must enter configuration parameters for the secondary LDAP server.

Always Access Primary Server First

Click to ensure that the primary LDAP server is accessed first, before the secondary LDAP server is accessed.

Failback to Primary Server After <min.> Minutes

Click to set the number of minutes that ACS authenticates using the secondary LDAP server if the primary server cannot be reached, where <min.> is the number of minutes. After this time period, ACS reattempts authentication using the primary LDAP server. (Default = 5.)

Primary Server

Hostname

Enter the IP address or DNS name of the machine that is running the primary LDAP software. The hostname can contain from 1 to 256 characters or a valid IP address expressed as a string. The only valid characters for hostnames are alphanumeric characters (a to z, A to Z, 0 to 9), the dot (.), and the hyphen (-).

Port

Enter the TCP/IP port number on which the primary LDAP server is listening. Valid values are from 1 to 65,535. The default is 389, as stated in the LDAP specification. If you do not know the port number, you can find this information by referring to the administrator of the LDAP server.

Anonymous Access

Click to ensure that searches on the LDAP directory occur anonymously. The server does not distinguish who the client is and will allow the client read access to any data that is configured accessible to any unauthenticated client.

In the absence of specific policy permitting authentication information to be sent to a server, a client should use an anonymous connection.

Authenticated Access

Click to ensure that searches on the LDAP directory occur with administrative credentials. If so, enter information for the Admin DN and Password fields.

Admin DN

Enter the distinguished name of the administrator; that is, the LDAP account which, if bound to, permits searching all required users under the User Directory Subtree and permits searching groups.

If the administrator specified does not have permission to see the group name attribute in searches, group mapping fails for users that LDAP authenticates.

Password

Enter the LDAP administrator account password.

Use Secure Authentication

Click to use Secure Sockets Layer (SSL) to encrypt communication between ACS and the primary LDAP server. Verify the Port field contains the port number used for SSL on the LDAP server. If you enable this option, you must select a root CA.

Root CA

Select a trusted root certificate authority from the drop-down list box to enable secure authentication with a certificate.

Server Timeout <sec.> Seconds

Enter the number of seconds that ACS waits for a response from the primary LDAP server before determining that the connection or authentication with that server has failed, where <sec.> is the number of seconds. Valid values are 1 to 300. (Default = 10.)

Max Admin Connections

Enter the maximum number of concurrent connections (greater than 0) with LDAP administrator account permissions, that can run for a specific LDAP configuration. These connections are used to search the directory for users and groups under the User Directory Subtree and Group Directory Subtree. Valid values are 1 to 99. (Default = 8.)

Test Bind To Server

Click to test and ensure that the primary LDAP server details and credentials can successfully bind. If the test fails, edit your LDAP server details and retest.

Secondary Server

Hostname

Enter the IP address or DNS name of the machine that is running the secondary LDAP software. The hostname can contain from 1 to 256 characters or a valid IP address expressed as a string. The only valid characters for hostnames are alphanumeric characters (a to z, A to Z, 0 to 9), the dot (.), and the hyphen (-).

Port

Enter the TCP/IP port number on which the secondary LDAP server is listening. Valid values are from 1 to 65,535. 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 DS Properties on the LDAP machine.

Anonymous Access

Click to verify that searches on the LDAP directory occur anonymously. The server does not distinguish who the client is and will allow the client to access (read and update) any data that is configured to be accessible to any unauthenticated client.

In the absence of specific policy permitting authentication information to be sent to a server, a client should use an anonymous connection.

Authenticated Access

Click to ensure that searches on the LDAP directory occur with administrative credentials. If so, enter information for the Admin DN and Password fields.

Admin DN

Enter the domain name of the administrator; that is, the LDAP account which, if bound to, permits searching for all required users under the User Directory Subtree and permits searching groups.

If the administrator specified does not have permission to see the group name attribute in searches, group mapping fails for users that LDAP authenticates.

Password

Type the LDAP administrator account password.

Use Secure Authentication

Click to use Secure Sockets Layer (SSL) to encrypt communication between ACS and the secondary LDAP server. Verify the Port field contains the port number used for SSL on the LDAP server. If you enable this option, you must select a root CA.

Root CA

Select a trusted root certificate authority from the drop-down list box to enable secure authentication with a certificate.

Server Timeout <sec.> Seconds

Type the number of seconds that ACS waits for a response from the secondary LDAP server before determining that the connection or authentication with that server has failed, where <sec.> is the number of seconds. Valid values are 1 to 300. (Default = 10.)

Max Admin Connections

Type the maximum number of concurrent connections (greater than 0) with LDAP administrator account permissions, that can run for a specific LDAP configuration. These connections are used to search the directory for users and groups under the User Directory Subtree and Group Directory Subtree. Valid values are 1 to 99. (Default = 8.)

Test Bind To Server

Click to test and ensure that the secondary LDAP server details and credentials can successfully bind. If the test fails, edit your LDAP server details and retest.


Step 2 Click Next.

Step 3 Continue with Configuring External LDAP Directory Organization.


Configuring External LDAP Directory Organization

Use this page to configure an external LDAP identity store.


Step 1 Select Users and Identity Stores > External Identity Stores > LDAP, then click any of the following:

Create and follow the wizard until you reach the Directory Organization page.

Duplicate, then click Next until the Directory Organization page appears.

Edit, then click Next until the Directory Organization page appears.

Table 8-8 LDAP: Directory Organization Page 

Option
Description
Schema

Subject Object class

The value of the LDAP objectClass attribute that identifies the subject. Often, subject records have several values for the objectClass attribute, some of which are unique to the subject, some of which are shared with other object types.

This box should contain a value that is not shared. Valid values are from 1 to 20 characters and must be a valid LDAP object type. This parameter can contain any UTF-8 characters. (Default = Person.)

Group Object class

Enter the group object class that you want to use in searches that identify objects as groups. (Default = GroupOfUniqueNames.)

Subject Name Attribute

The name of the attribute in the subject record that contains the subject name. You can obtain this attribute name from your directory server. This attribute specifies the subject name in the LDAP schema. You use this attribute to construct queries to search for subject objects.

For more information, refer to the LDAP database documentation. Valid values are from 1 to 20 characters and must be a valid LDAP attribute. This parameter can contain any UTF-8 characters. Common values are uid and CN. (Default = uid.)

Group Map Attribute

For user authentication, user lookup, and MAC address lookup, ACS must retrieve group membership information from LDAP databases. LDAP servers represent an association between a subject (a user or a host) and a group in one of the following two ways:

Groups refer to subjects

Subjects refer to groups

The Group Map Attribute contains the mapping information.

You must enter the attribute that contains the mapping information: an attribute in either the subject or the group, depending on:

If you select the Subject Objects Contain Reference To Groups radio button, enter a subject attribute.

If you select Group Objects Contain Reference To Subjects radio button, enter a group attribute.

Certificate Attribute

Enter the attribute that contains certificate definitions. These definitions can optionally be used to validate certificates presented by clients when defined as part of a certificate authentication profile. In such cases, a binary comparison is performed between the client certificate and the certificate retrieved from the LDAP identity store.

Subject Objects Contain Reference To Groups

Click if the subject objects contain a reference to groups.

Group Objects Contain Reference To Subjects

Click if the group objects contain a reference to subjects.

Subjects In Groups Are Stored In Member Attribute As

Use the drop-down list box to indicate if the subjects in groups are stored in member attributes as either:

Username

Distinguished name

Directory Structure

Subject Search Base

Enter the distinguished name (DN) for the subtree that contains all subjects. For example:

o=corporation.com

If the tree containing subjects is the base DN, enter:

o=corporation.com

or

dc=corporation,dc=com

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

Group Search Base

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

Test Configuration

Click to obtain the expected connection and schema results by counting the number of users and groups that may result from your configuration.

Username Prefix\Suffix Stripping

Strip start of subject name up to the last occurrence of the separator

Enter the appropriate text to remove domain prefixes from usernames.

If, in the username, ACS finds the delimiter character that is specified in the start_string 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 that are specified in the start_string box, ACS strips characters through the last occurrence of the delimiter character. For example, if the delimiter character is the backslash (\) and the username is DOMAIN\echamberlain, ACS submits echamberlain to an LDAP server.

The start_string cannot contain the following special characters: the pound sign (#), the question mark (?), the quote ("), the asterisk (*), the right angle bracket (>), and the left angle bracket (<). ACS does not allow these characters in usernames. If the X box contains any of these characters, stripping fails.

Strip end of subject name from the first occurrence of the separator

Enter the appropriate text to remove domain suffixes from usernames.

If, in the username, ACS finds the delimiter character that is specified in the Y box, it strips all characters from the delimiter character through the end of the username.

If the username contains more than one of the character specified in the Y box, ACS strips characters starting with the first occurrence of the delimiter character. For example, if the delimiter character is the at symbol (@) and the username is jwiedman@domain, then ACS submits jwiedman to an LDAP server.

The end_string box cannot contain the following special characters: the pound sign (#), the question mark (?), the quote ("), the asterisk (*), the right angle bracket (>), and the left angle bracket (<). ACS does not allow these characters in usernames. If the end_string box contains any of these characters, stripping fails.

MAC Address Format

Search for MAC Address in Format <format>

MAC addresses in internal identity stores are stored in the format xx-xx-xx-xx-xx-xx. MAC addresses in LDAP databases can be stored in different formats. However, when ACS receives a host lookup request, ACS converts the MAC address from the internal format to the format that is specified in this field.

Use the drop-down list box to enable search for MAC addresses in a specific format, where <format> can be any one of the following:

xxxxxxxxxxxx

xx-xx-xx-xx-xx-xx

xx:xx:xx:xx:xx:xx

xxxx.xxxx.xxxx

The format you select must match the format of the MAC address stored in the LDAP server.


Step 2 Click Finish.

The external identity store you created is saved.


Related Topics

Configuring LDAP Groups

Deleting External LDAP Identity Stores

Deleting External LDAP Identity Stores

You can delete one or more external LDAP identity stores simultaneously.

To delete an external LDAP identity store:


Step 1 Select Users and Identity Stores > External Identity Stores > LDAP.

The LDAP Identity Stores page appears, with a list of your configured external identity stores.

Step 2 Check one or more check boxes next to the external identity stores you want to delete.

Step 3 Click Delete.

The following error message appears:

Are you sure you want to delete the selected item/items?

Step 4 Click OK.

The External Identity Stores page appears, without the deleted identity stores in the list.


Related Topic

Creating External LDAP Identity Stores

Configuring LDAP Groups

Use this page to configure an external LDAP group.


Step 1 Select Users and Identity Stores > External Identity Stores > LDAP, then click any of the following:

Create and follow the wizard.

Duplicate, then click the Directory Groups tab.

Edit, then click the Directory Groups tab.

The Selected Directory Groups field displays a list of groups that are available as options in rule-table group-mapping conditions.

Step 2 Do one of the following:

Click Select to open the Groups secondary window from which you can select groups and add them to the Selected Directory Groups list.

You can alternatively enter the LDAP groups in the Group Name field and click Add.

To remove a selected group from the Selected Directory Groups list, select that group in the Selected Directory Groups list and Click Deselect.

Step 3 Click Submit to save your changes.


Viewing LDAP Attributes

Use this page to view the external LDAP attributes.


Step 1 Select Users and Identity Stores > External Identity Stores > LDAP.

Step 2 Check the check box next to the LDAP identity store whose attributes you want to view, click Edit, and then click the Directory Attributes tab.

Step 3 In the Name of example Subject to Select Attributes field, enter the name of an example object from which to retrieve attributes, then click Select.

For example, the object can be an user and the name of the object could either be the username or the user's DN.

Step 4 Complete the fields as described in Table 8-9

Table 8-9 LDAP: Attributes Page 

Option
Description

Attribute Name

Type an attribute name that you want included in the list of available attributes for policy conditions.

Type

Select the type you want associated with the attribute name you entered in the Attribute Name field.

Default

Specify the default value you want associated with the attribute name you entered in the Attribute Name field. If you do not specify a default value, no default is used.

When attributes are imported to the Attribute Name/Type/Default box via the Select button, these default values are used:

String—Name of the attribute

Unsigned Integer 32

IPv4 Address

Policy Condition Name

(Optional) Specify the name of the custom condition for this attribute. This condition will be available for selection when customizing conditions in a policy.


Step 5 Click Add and the information you entered is added to the fields on the screen.

The attributes listed here are available for policy conditions.

Step 6 Click Submit to save your changes.


Leveraging Cisco NAC Profiler as an External MAB Database

ACS communicates with Cisco NAC Profiler to enable non-802.1X-capable devices to authenticate in 802.1X-enabled networks. Endpoints that are unable to authenticate through 802.1X use the MAC Authentication Bypass (MAB) feature in switches to connect to an 802.1X-enabled network.

Typically, non-user-attached devices such as printers, fax machines, IP phones, and Uninterruptible Power Supplies (UPSs) are not equipped with an 802.1x supplicant.

This means the switch port to which these devices attach cannot authenticate them using the 802.1X exchange of device or user credentials and must revert to an authentication mechanism other than port-based authentication (typically endpoint MAC address-based) in order for them to connect to the network.

Cisco NAC Profiler provides a solution for identifying and locating the endpoints that are unable to interact with the authentication component of these systems so that these endpoints can be provided an alternative mechanism for admission to the network.

NAC Profiler consists of an LDAP-enabled directory, which can be used for MAC Authentication Bypass (MAB). Thus, the NAC Profiler acts as an external LDAP database for ACS to authenticate non-802.1X-capable devices.


Note You can use the ACS internal host database to define the MAC addresses for non-802.1X-capable devices. However, if you already have a NAC Profiler in your network, you can use it to act as an external MAB database.


To leverage Cisco NAC Profiler as an external MAB database, you must:

Enable the LDAP Interface on Cisco NAC Profiler. See Enabling the LDAP Interface on Cisco NAC Profiler to Communicate with ACS.

Configure NAC Profiler in ACS. See Configuring NAC Profile LDAP Definition in ACS for Use in Identity Policy.

Enabling the LDAP Interface on Cisco NAC Profiler to Communicate with ACS


Note Before you can enable the LDAP interface on the NAC Profiler, ensure that you have set up your NAC Profiler with the NAC Profiler Collector. For more information on configuring Cisco NAC Profiler, refer to the Cisco NAC Profiler Installation and Configuration Guide, available under http://www.cisco.com/en/US/products/ps8464/products_installation_and_configuration_guides_list.html.


To enable the LDAP interface on the NAC Profiler to communicate with ACS:


Step 1 Log in to your Cisco NAC Profiler.

Step 2 Choose Configuration > NAC Profiler Modules > List NAC Profiler Modules.

Step 3 Click Server.

The Configure Server page appears.

Step 4 In the LDAP Configuration area, check the Enable LDAP check box as shown in Figure 8-1.

Figure 8-1 LDAP Interface Configuration in NAC Profiler

Step 5 Click Update Server.

Step 6 Click the Configuration tab and click Apply Changes.

The Update NAC Profiler Modules page appears.

Step 7 Click Update Modules to enable LDAP to be used by ACS.

You must enable the endpoint profiles that you want to authenticate against the Cisco NAC Profiler. For information on how to do this, see Configuring Endpoint Profiles in NAC Profiler for LDAP Authentication.


For proper Active Response Events you need to configure Active Response Delay time from your Cisco NAC Profiler UI. For this, choose Configuration > NAC Profiler Modules > Configure Server > Advanced Options > Active Response Delay.

Configuring Endpoint Profiles in NAC Profiler for LDAP Authentication

For the non-802.1X endpoints that you want to successfully authenticate, you must enable the corresponding endpoint profiles in NAC Profiler for LDAP authentication.


Note If the profile is not enabled for LDAP, the endpoints in the profile will not be authenticated by the Cisco NAC Profiler.


To enable the endpoint profiles for LDAP authentication:


Step 1 Log into your NAC Profiler.

Step 2 Choose Configuration > Endpoint Profiles > View/Edit Profiles List.

A list of profiles in a table appears.

Step 3 Click on the name of a profile to edit it.

Step 4 In the Save Profile page, ensure that the LDAP option is enabled by clicking the Yes radio button next to it, if it is not already done as shown in Figure 8-2.

Figure 8-2 Configuring Endpoint Profiles in NAC Profiler

Step 5 Click Save Profile.


Configuring NAC Profile LDAP Definition in ACS for Use in Identity Policy

After you install ACS, there is a predefined LDAP database definition for NAC Profiler. This predefined database definition for NAC Profiler contains all the required data for establishing an initial connection. The only exception is the host information, which depends on your specific deployment configuration.

The steps below describe how to configure the host information, verify the connection, and use the profile database in policies.


Note Make sure that ACS NAC Profiler is choosen under Access Policies > Access Services > Default Network Access > Identity.



Note The NAC Profiler template in ACS, available under the LDAP external identity store, works with Cisco NAC Profiler version 2.1.8 and later.


To edit the NAC Profiler template in ACS:


Step 1 Choose Users and Identity Stores > External Identity Stores > LDAP.

Step 2 Click on the name of the NAC Profiler template or check the check box next to the NAC Profiler template and click Edit.

The Edit NAC Profiler definition page appears as shown in Figure 8-3.

Figure 8-3 Edit NAC Profiler Definition - General Page

Step 3 Click the Server Connection tab.

The Edit page appears as shown in Figure 8-4.

Figure 8-4 Edit NAC Profiler Definition - Server Connection Page

Step 4 In the Primary Server Hostname field, enter the IP address or fully qualified domain name of the Profiler Server, or the Service IP of the Profiler pair if Profiler is configured for High Availability.

Step 5 Click Test Bind to Server to test the connection and verify ACS can communicate with Profiler through LDAP.

A small popup dialog, similar to the one shown in Figure 8-5 appears.

Figure 8-5 Test Bind to Server Dialog Box

For more information, see Creating External LDAP Identity Stores.


Note The default password for LDAP is GBSbeacon. If you want to change this password, refer to the Cisco NAC Profiler Installation and Configuration Guide at the following location: http://www.cisco.com/en/US/docs/security/nac/profiler/configuration_guide/310/p_ldap31.html#wp1057155


Step 6 If successful, go to the Directory Organization tab.

The Edit page appears as shown in Figure 8-6.

Figure 8-6 Edit NAC Profiler Definition - Directory Organization Page

Step 7 Click Test Configuration.

A dialog box as shown in Figure 8-7 appears that lists data corresponding to the Profiler. For example:

Primary Server

Number of Subjects: 100

Number of Directory Groups: 6

Figure 8-7 Test Configuration Dialog Box

Number of Subjects—This value maps to the actual subject devices already profiled by the Cisco NAC Profiler (actual devices enabled for Profiler).

After the Profiler receives initial SNMP trap information from the switch, Profiler can poll the switch using SNMP to gather MIB (Management Information Base) information about the switch as well as the connecting endpoint.

After the Profiler has learned about the endpoint (e.g. MAC address, switch port), it adds the endpoint to its database. An endpoint added to the Profiler's database is considered 1 subject.

Number of Directory Groups—This value maps to the actual profiles enabled for LDAP on Profiler. When already running Profiler on your network, default profiles for endpoints are pre-configured.

However, all profiles are not enabled for LDAP, and must be configured as described in Configuring Endpoint Profiles in NAC Profiler for LDAP Authentication. Note that if setting up Profiler for the first time, once the Profiler is up and running, you will see zero groups initially.


Note The subjects and directory groups are listed if they are less than 100 in number. If the number of subjects or directory groups exceed 100, the subjects and directory groups are not listed. Instead, you get a message similar to the following one:

More than 100 subjects are found.

Step 8 Click the Directory Attributes tab if you want to use the directory attributes of subject records as policy conditions in policy rules. See Viewing LDAP Attributes for more information.

Step 9 Choose NAC Profiler as the result (Identity Source) of the identity policy. For more information, see Viewing Identity Policies.

As soon as Endpoint is successfully authenticated from ACS server, ACS will do a CoA (Change of Authorization) and change VLAN. For this, you can configure static VLAN mapping in ACS server. For more information, see Specifying Common Attributes in Authorization Profiles.

When Endpoint is successfully authenticated the following message is displayed on the switch.

ACCESS-Switch# #show authentication sessions
Interface MAC Address Method Domain Status Session ID
Fa1/0/1 0014.d11b.aa36 mab DATA Authz Success 505050010000004A0B41FD15
 
   

For more information on features like Event Delivery Method and Active Response, see the Cisco NAC Profiler Installation and Configuration Guide, Release 3.1 at the follwing location: http://www.cisco.com/en/US/docs/security/nac/profiler/configuration_guide/310/p_prof_events31.html

Troubleshooting MAB Authentication with Profiler Integration

Following are the steps to troubleshoot MAB authentication while integrating with NAC Profiler:


Step 1 To verify that the endpoint is successfully authenticated, run the following command on the switch which is conencted to the endpoint devices:

ACCESS-Switch# show authentication sessions
 
   

The following output is displayed:

Interface  MAC Address    Method   Domain  Status         Session ID
Fa1/0/1    0014.d11b.aa36 mab      DATA     Authz Success  505050010000004A0B41FD15 reject
 
   

Step 2 Enable debugging for SNMP, AAA, and 802.1X on the switch.

Step 3 Verify the MAB authentication logs in Monitoring and Reports Viewer > Troubleshooting, for failure and success authentications.


Microsoft AD

ACS uses Microsoft Active Directory (AD) as an external identity store to store resources such as, users, machines, groups, and attributes. ACS authenticates these resources against AD.

Supported Authentication Protocols

EAP-FAST and PEAP—ACS 5.2 supports user and machine authentication and change password against AD using EAP-FAST and PEAP with an inner method of MSCHAPv2 and EAP-GTC.

PAP—ACS 5.2 supports authenticating against AD using PAP and also allows you to change AD users password.

MSCHAPv1—ACS 5.2 supports user and machine authentication against AD using MSCHAPv1. You can change AD users password using MSCHAPv1 version 2. ACS does not support MS-CHAP MPPE-Keys of a user, but does support MPPE-Send-Key and MPPE-Recv-Key.


Note ACS 5.2 does not support changing user password against AD using MSCHAPv1 version 1.


MSCHAPv2—ACS 5.2 supports user and machine authentication against AD using MSCHAPv2. ACS does not support MS-CHAP MPPE-Keys of a user, but does support MPPE-Send-Key and MPPE-Recv-Key.

EAP-GTC—ACS 5.2 supports user and machine authentication against AD using EAP-GTC.

EAP-TLS—ACS uses the certificate retrieval option introduced in 5.2 to support user and machine authentication against AD using EAP-TLS.

Changing the password for EAP-FAST and PEAP with inner MSCHAPv2 is also supported.

ACS supports these AD domains:

Windows Server 2003

Windows Server 2003 R2

Windows Server 2008

Windows Server 2008 R2

AD supports the following functional levels:

Domain functional level

Forest functional level

A mix of domain and forest functional levels

ACS machine access restriction (MAR) features use AD to map machine authentication to user authentication and authorization, and sets a the maximal time allowed between machine authentication and an authentication of a user from the same machine.

Most commonly, MAR fails authentication of users whose host machine does not successfully authenticate or if the time between machine and user authentication is greater than the specified aging time. You can add MAR as a condition in authentication and authorization rules as required.

While trying to join ACS to the AD domain, ACS and AD must be time-synchronized. Time in ACS is set according to the Network Time Protocol (NTP) server. Both AD and ACS should be synchronized by the same NTP server.

If time is not synchronized when you join ACS to the AD domain, ACS displays a clock skew error. Using the command line interface on your appliance, you must configure the NTP client to work with the same NTP server that the AD domain is synchronized with.

Refer to http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.2/command/
reference/acs5_2_cli.html
for more information.

ACS 5.2 supports certificate authorization.

If there is a firewall between ACS and AD, certain ports need to be opened in order to allow ACS to communicate with AD. The following are the default ports to be opened:

Protocol
Port number

LDAP

389/udp

SMB

445/tcp

KDC

88/(tcp/udp)

Global catalog

3268/tcp

KPASS

464/tcp

NTP

123/udp



Note Dial-in users are not supported by AD in ACS.


This section contains the following topics:

Machine Authentication

Attribute Retrieval for Authorization

Group Retrieval for Authorization

Certificate Retrieval for EAP-TLS Authentication

Concurrent Connection Management

User and Machine Account Restrictions

Machine Access Restrictions

Joining ACS to an AD Domain

Configuring an AD Identity Store

Selecting an AD Group

Configuring AD Attributes

Machine Authentication

Machine authentication provides access to network services to only these computers that are listed in Active Directory. This becomes very important for wireless networks because unauthorized users can try to access your wireless access points from outside your office building.

Machine authentication happens while starting up a computer or while logging in to a computer. Supplicants, such as Funk Odyssey perform machine authentication periodically while the supplicant is running.

If you enable machine authentication, ACS authenticates the computer before a user authentication request comes in. ACS checks the credentials provided by the computer against the Windows user database. If the credentials match, the computer is given access to the network.

Attribute Retrieval for Authorization

You can configure ACS to retrieve user or machine AD attributes to be used in authorization and group mapping rules. The attributes are mapped to the ACS policy results and determine the authorization level for the user or machine.

ACS retrieves user and machine AD attributes after a successful user or machine authentication and can also retrieve the attributes for authorization and group mapping purposes independent of authentication.

Group Retrieval for Authorization

ACS can retrieve user or machine groups from Active Directory after a successful authentication and also retrieve the user or machine group independent of authentication for authorization and group mapping purposes. You can use the AD group data in the authorization and group mapping tables and introduce special conditions to match them against the retrieved groups.

Certificate Retrieval for EAP-TLS Authentication

ACS 5.2 supports certificate retrieval for user or machine authentication that uses EAP-TLS protocol. The user or machine record on AD includes a certificate attribute of binary data type. This can contain one or more certificates. ACS refers to this attribute as userCertificate and does not allow you to configure any other name for this attribute.

ACS retrieves this certificate for verifying the identity of the user or machine. The certificate authentication profile determines the field (SAN, CN, or SSN) to be used for retrieving the certificates.

After ACS retrieves the certificate, it performs a binary comparison of this certificate with the client certificate. When multiple certificates are received, ACS compares the certificates to check if one of them match. When a match is found, ACS grants the user or machine access to the network.

Concurrent Connection Management

After ACS connects to the AD domain, at startup, ACS creates a number of threads to be used by the AD identity store for improved performance. Each thread has its own connection.

User and Machine Account Restrictions

While authenticating or querying a user or a machine, ACS checks for the following:

Is the user account disabled?

Is the user locked out?

Has the user's account expired?

Is the query run outside of the specified logon hours?

If the user has one of these limitations, the AD1::IdentityAccessRestricted attribute on the AD dedicated dictionary is set to indicate that the user has restricted access. You can use this attribute in group mapping and authorization rules.

Machine Access Restrictions

MAR helps tying the results of machine authentication to user authentication and authorization process. The most common usage of MAR is to fail authentication of users whose host machine does not successfully authenticate. The MAR is effective for all authentication protocols.

MAR functionality is based on the following points:

As a result of Machine Authentication, the machine's RADIUS Calling-Station-ID attribute (31) is cached as an evidence for later reference.

Administrator can configure the time to live (TTL) of the above cache entries in the AD settings page.

Administrator can configure whether or not MAR is enabled in the AD settings page. However for MAR to work the following limitations must be taken into account:

Machine authentication must be enabled in the authenticating protocol settings

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

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

ACS do not persevere the cache of Calling-Station-Id attribute. So the content is lost in case you restart ACS or if it crashes. The content is not verified for consistency in case the administrator performs configuration changes that may effect machine authentication.

Dialup is not supported for 5.1.

When user authenticates with either PEAP or EAP-FAST, against AD external ID store then ACS performs an additional action. It searches the cache for the users Calling-Station-Id. If it is found then Was-Machine-Authenticated attribute is set to true on the session context, otherwise set to false.

For the above to function correctly, the user authentication request should contain the Calling-Station-Id. In case it does not, the Was-Machine-Authenticated attribute shall be set to false.

The administrator can add rules to authorization policies that are based on AD GM attribute and on Machine authentication required attribute. Any rule that contains these two attributes will only apply if the following conditions are met:

MAR feature is enabled

Machine authentication in the authenticating protocol settings is enabled

External ID store is AD

When a rule such as the one described above is evaluated, the attributes of AD GM and Was-Machine-Authenticated are fetched from the session context and checked against the rule's condition. According to the results of this evaluation an authorization result is set.

Exemption list functionality is supported implicitly (in contrast to ACS 4.x). To exempt a given user group from the MAR the administrator can set a rule such that the column of AD Group consists of the group to exempt and the column of Machine Authentication Required consists of No. See the second rule in the table below for an example.

For example, the administrator will add rules to the authorization policy as follows:

AD Group
Machine Authentication Required
...
ATZ profile

Engineers

Yes

...

VLAN X

Managers

No

...

VLAN B

...

...

...

DENY ACCESS


The Engineers' rule is an example of MAR rule that only allows engineers access if their machine was successfully authenticated against windows DB.

The Managers' rule is an example of an exemption from MAR.

Joining ACS to an AD Domain

After you configure the AD identity store in ACS through the ACS web interface, you must submit the configuration to join ACS to the AD domain. For more information on how to configure an AD identity store, see Configuring an AD Identity Store.


Note The Windows AD account, which joins ACS to the AD domain, can be placed in its own organizational unit (OU). It resides in its own OU either when the account is created or later on, with a restriction that the appliance name must match the name of the AD account.



Note ACS does not support user authentication in AD when a user name is supplied with an alternative UPN suffix configured in OU level. The authentication works fine if the UPN suffix is configured in domain level.


Related Topic

Machine Authentication

Configuring an AD Identity Store

When you configure an AD identity store, ACS also creates:

A new dictionary for that store with two attributes: ExternalGroups and another attribute for any attribute retrieved from the Directory Attributes page.

A new attribute, IdentityAccessRestricted. You can manually create a custom condition for this attribute.

A custom condition for group mapping from the ExternalGroup attribute; the custom condition name is AD1:ExternalGroups and another custom condition for each attribute selected in the Directory Attributes page (for example, AD1:cn).

You can edit the predefined condition name, and you can create a custom condition from the Custom condition page. See Creating, Duplicating, and Editing a Custom Session Condition.

To authenticate users and join ACS with an AD domain:


Step 1 Select Users and Identity Stores > External Identity Stores > Active Directory.

The Active Directory page appears.

Step 2 Modify the fields in the General tab as described in Table 8-10.

Table 8-10 Active Directory: General Page 

Option
Description
Connection Details

Active Directory Domain Name

Name of the AD domain to join ACS to.

Username

Predefined user in AD. AD account required for domain access in ACS should have either of the following:

Add workstations to domain user right in corresponding domain.

Create Computer Objects or Delete Computer Objects permission on corresponding computers container where ACS machine's account is precreated (created before joining ACS machine to the domain).

Password

Enter the user password. The password should have minimum of 8 characters with the combination of atleast one lower case alphabet, one upper case alphabet, one numeral, and one special character. All special characters are supported.

Test Connection

Click to test the ACS connection with the AD domain for the user, domain, and password identified in the previous fields.

A message appears informing you whether the AD server is routable within the network and also authenticates the given AD username and password.

Note To join to the AD domain, ACS first attempts to create a secure connection. If this is unsuccessful, it would then attemp to create an insecure connection.

End User Authentication Settings

Enable password change

Click to allow the password to be changed.

Enable machine authentication

Click to allow machine authentication.

Enable Machine Access Restrictions

Click to ensure that machine authentication results are tied to user authentication and authorization. If you enable this feature, you must set the Aging time.

Aging time (hours) <time>

The time after a machine was authenticated that a user can be authenticated from that machine. If this time elapses, user authentication fails.

You must set this time if you clicked the Enable Machine Access Restrictions check box.

Connectivity Status

Joined to Domain

(Display only.) After you save the configuration (by clicking Save Changes), shows the domain name with which ACS is joined.

Connectivity Status

(Display only.) After you save the configuration (by clicking Save Changes), shows the connection status of the domain name with which ACS is joined.


Step 3 Click:

Save Changes to save the configuration, join the ACS to the specified AD domain with the configured credentials, and start the AD agent.

Discard Changes to discard all changes.

If AD is already configured and you want to delete it, click Clear Configuration after you verify that:

There are no policy rules that use custom conditions based on the AD dictionary.

The AD is not chosen as the identity source in any of the available access services.

There are no identity store sequences with the AD.

The Active Directory configuration is saved. The Active Directory page appears with the new configuration.


Note The Windows AD account, which joins ACS to the AD domain, can be placed in its own Organizational Unit (OU). It resides in its own OU either when the account is created or later on with a restriction that the appliance name must match the name of the AD account.



Note Due to NETBIOS limitations, ACS hostnames must contain less than or equal to 15 characters.



Related Topics

Selecting an AD Group

Configuring AD Attributes

Selecting an AD Group

Use this page to select groups that can then be available for policy conditions.


Note To select groups and attributes from an AD, ACS must be connected to that AD.



Step 1 Select Users and Identity Stores > External Identity Stores > Active Directory, then click the Directory Groups tab.

The Groups page appears. The Selected Directory Groups field lists the AD groups you selected and saved. The AD groups you selected in the External User Groups page are listed and can be available as options in group mapping conditions in rule tables.

If you have more groups in other trusted domain or forest that are not displayed, you can use the search filter to narrow down your search results.

Step 2 Click Select to see the available AD groups on the domain (and other trusted domains in the same forest).

The External User Groups dialog box appears displaying a list of AD groups in the domain, as well as other trusted domains in the same forest.

If you have more groups that are not displayed, use the search filter to refine your search and click Go.

Step 3 Enter the AD groups or select them from the list, then click OK.

To remove an AD group from the list, click an AD group, then click Deselect.

Step 4 Click:

Save Changes to save the configuration.

Discard Changes to discard all changes.

If AD is already configured and you want to delete it, click Clear Configuration after you verify that there are no policy rules that use custom conditions based on the AD dictionary.



Note When configuring the AD Identity Store on ACS 5.x, the security groups defined on Active Directory are enumerated and can be used, but distribution groups are not shown. Active Directory Distribution groups are not security-enabled and can only be used with e-mail applications to send e-mail to collections of users. Please refer to Microsoft documentation for more information on distribution groups.



Note Logon authentication may fail on Active Directory when ACS tries to authenticate Users who belong to more than 1015 groups in external identity stores. This is due to the Local Security Authentication (LSA) limitations in Active Directory.


Configuring AD Attributes

Use this page to select attributes that can then be available for policy conditions.


Step 1 Select Users and Identity Stores > External Identity Stores > Active Directory, then click the Directory Attributes tab.

Step 2 Complete the fields in the Active Directory: Attributes page as described in Table 8-11:

Table 8-11 Active Directory: Attributes Page 

Option
Description

Name of example Subject to Select Attributes

Enter the name of a user or computer found on the joined domain. You can enter the user's or the computer's CN or distinguished name.

The set of attributes that are displayed belong to the subject that you specify. The set of attributes are different for a user and a computer.

Select

Click to access the Attributes secondary window, which displays the attributes of the name you entered in the previous field.

Attribute Name List—Displays the attributes you selected in the secondary Selected Attributes window.

Attribute Name

Do one of the following:

Enter the name of the attribute.

You can also select an attribute from the list, then click Edit to edit the attribute.

Click Add to add an attribute to the Attribute Name list.

Type

Attribute types associated with the attribute names. Valid options are:

String

Unsigned Integer 32

IPv4 Address

Default

Specified attribute default value for the selected attribute:

String—Name of the attribute.

Unsigned Integer 32—0.

IPv4 Address—No default set.

Policy Condition Name

Enter the custom condition name for this attribute. For example, if the custom condition name is AAA, enter AAA in this field and not AD1:att_name.

Select Attributes Secondary Window

Available from the Attributes secondary window only.

Search Filter

Specify a user or machine name.

For user names, you can specify distinguished name, SAM, NetBios, or UPN format.

For machine names, you can specify one of the following formats: MACHINE$, NETBiosDomain\MACHINE$, host/MACHINE, or host/machine.domain. You can specify non-English letters for user and machine names.

Attribute Name

The name of an attribute of the user or machine name you entered in the previous field.

Attribute Type

The type of attribute.

Attribute Value

The value of an attribute for the specified user or machine.


Step 3 Click:

Save Changes to save the configuration.

Discard Changes to discard all changes.

If AD is already configured and you want to delete it, click Clear Configuration after you verify that there are no policy rules that use custom conditions based on the AD dictionary.


RSA SecurID Server

ACS supports the RSA SecurID server as an external database. RSA SecurID two-factor authentication consists of the user's personal identification number (PIN) and an individually registered RSA SecurID token that generates single-use token codes based on a time code algorithm.

A different token code is generated at fixed intervals (usually each at 30 or 60 seconds). The RSA SecurID server validates this dynamic authentication code. Each RSA SecurID token is unique, and it is not possible to predict the value of a future token based on past tokens.

Thus when a correct token code is supplied together with a PIN, there is a high degree of certainty that the person is a valid user. Therefore, RSA SecurID servers provide a more reliable authentication mechanism than conventional reusable passwords.

You can integrate with RSA SecurID authentication technology in any one of the following ways:

Using the RSA SecurID agent—Users are authenticated with username and passcode through the RSA's native protocol.

Using the RADIUS protocol—Users are authenticated with username and passcode through the RADIUS protocol.

RSA SecurID token server in ACS 5.2 integrates with the RSA SecurID authentication technology by using the RSA SecurID Agent.

Configuring RSA SecurID Agents

The RSA SecurID Server administrator can do the following:

Create an Agent Record (sdconf.rec)

Reset the Node Secret (securid)

Override Automatic Load Balancing

Manually Intervene to Remove a Down RSA SecurID Server

Create an Agent Record (sdconf.rec)

To configure an RSA SecurID token server in ACS 5.2, the ACS administrator requires the sdconf.rec file. The sdconf.rec file is a configuration record file that specifies how the RSA agent communicates with the RSA SecurID server realm.

In order to create the sdconf.rec file, the RSA SecurID server administrator should add the ACS host as an Agent host on the RSA SecurID server and generate a configuration file for this agent host.

Reset the Node Secret (securid)

After the agent initially communicates with the RSA SecurID server, the server provides the agent with a node secret file called securid. Subsequent communication between the server and the agent relies on exchanging the node secret to verify the other's authenticity.

At times, you might have to reset the node secret. To reset the node secret:

The RSA SecurID server administrator must uncheck the Node Secret Created check box on the Agent Host record in the RSA SecurID server.

The ACS administrator must remove the securid file from ACS.

Override Automatic Load Balancing

RSA SecurID Agent automatically balances the requested loads on the RSA SecurID servers in the realm. However, you do have the option to manually balance the load. You can specify which server each of the agent hosts must use and assign a priority to each server so that the agent host directs authentication requests to some servers more frequently than others.

You must specify the priority settings in a text file and save it as sdopts.rec, which you can then upload to ACS.

Manually Intervene to Remove a Down RSA SecurID Server

When an RSA SecurID server is down, the automatic exclusion mechanism does not always work quickly. To speed up this process, you can remove the sdstatus.12 file from ACS.

Creating and Editing RSA SecurID Token Servers

ACS 5.2 supports RSA SecurID Token Servers for authenticating users for the increased security that one-time passwords provide. RSA SecurID token servers provide two-factor authentication to ensure the authenticity of users.

To authenticate users against an RSA identity store, you must first create an RSA SecurID Token Server in ACS and configure the realm, ACS instance, and advanced settings.

ACS 5.2 supports only one RSA realm. You can configure the settings for the RSA realm. A single realm can contain many ACS instances.


Note You must obtain the sdconf.rec file from the RSA SecurID server administrator and store it in ACS.


To create or edit an RSA SecurID token server:


Step 1 Select Users and Identity Stores > External Identity Stores > RSA SecurID Token Servers.

The RSA SecurID Token Servers page appears.

Step 2 Click Create.

You can also click the identity store name that you want to modify, or check the box next to the name and click Edit.

Step 3 Complete the fields in the RSA Realm Settings tab as described in Table 8-12.

Table 8-12 RSA Realm Settings Tab

Option
Description
General

Name

Name of the RSA realm.

Description

(Optional) The description of the RSA realm.

Server Connection

Server Timeout n seconds

ACS waits for n seconds to connect to the RSA SecurID token server before timing out.

Reauthenticate on Change PIN

Check this check box to reauthenticate on change PIN.

Realm Configuration File

Import new `sdconf.rec' file

Click Browse to select the sdconf.rec file from your machine.


Step 4 Click the ACS Instance Settings tab. See Configuring ACS Instance Settings for more information.

Step 5 Click the Advanced tab. See Configuring Advanced Options for more information.

Step 6 Click Submit to create an RSA SecurID store.

The RSA SecurID Token Server page appears with the configured servers.


Related Topics:

RSA SecurID Server

Configuring ACS Instance Settings

Configuring Advanced Options

Configuring ACS Instance Settings

The ACS Instance Settings tab appears with the current list of ACS instances that are active in the system. You cannot add or delete these entries. However, you can edit the available RSA Realm settings for each of these ACS instances.

.Table 8-13 describes the fields in the ACS Instance Settings tab.

Table 8-13 ACS Instance Settings Tab

Option
Description

ACS Instance

Name of the ACS instance.

Options File

Name of the options file.

securid Backup Status

Status of SecurID backup. This can be one of the following:

Cached

Not cached


You can edit the settings of the ACS instances that are listed on this page. To do this:


Step 1 Check the check box next to the ACS instance that you want to edit and click Edit.

The ACS instance settings dialog box appears. This dialog box contains the following tabs:

RSA Options File—See Editing ACS Instance Settings for more information.

Reset Agents Files—See Editing ACS Instance Settings for more information.

Step 2 Click OK.


Related Topics

RSA SecurID Server

Creating and Editing RSA SecurID Token Servers

Editing ACS Instance Settings

Editing ACS Instance Settings

Configuring Advanced Options

Editing ACS Instance Settings

You can edit the ACS instance settings to:

Enable the RSA options file

Reset Agent Files

Enable the RSA options file

You can enable the RSA options file (sdopts.rec) on each ACS instance to control routing priorities for connections between the RSA agent and the RSA servers in the realm.

Table 8-14 describes the fields in the RSA Options File tab.

Table 8-14 RSA Options File Tab

Option
Description

The RSA options file (sdopts.rec) may be enabled on each ACS instance to control the routing priorities for connections between the RSA agent and the RSA servers in the realm. For detailed description of the format of the sdopts.rec, please refer to the RSA Documentation.

Use the Automatic Load Balancing status maintained by the RSA Agent

Choose this option to use the automatic load balancing status that the RSA agent maintains.

Override the Automatic Load Balancing status with the sdopts.rec file selected below

Choose this option to use the automatic load balancing status that is specified in the sdopts.rec file.

Current File

Lists the sdopts.rec file that is chosen currently.

Timestamp

The time when sdopts.rec file was last modified.

File Size

The size of the sdopts.rec file.

Import new `sdopts.rec' file

Click Browse to import the new sdopts.rec file from your hard drive.

Note Changes will not take effect until the page which launched this popup is submitted.


Do one of the following:

Click OK to save the configuration.

Click the Reset Agent Files tab to reset the secret key information or the status of active and inactive servers in the realm.

Related Topics

RSA SecurID Server

Creating and Editing RSA SecurID Token Servers

Configuring ACS Instance Settings

Editing ACS Instance Settings

Configuring Advanced Options

Reset Agent Files

Use this page to reset the following:

Node Secret key file, to ensure that communication with the RSA servers is encrypted.

Status of the servers in the realm.


Step 1 Choose either of the following options:

To reset node secret on the agent host, check the Remove securid file on submit check box.

If you reset the node secret on the agent host, you must reset the agent host's node secret in the RSA server.

To reset the status of servers in the realm, check the Remove sdstatus.12 file on submit check box.

Step 2 Click OK.


Related Topics

RSA SecurID Server

Creating and Editing RSA SecurID Token Servers

Configuring ACS Instance Settings

Editing ACS Instance Settings

Configuring Advanced Options

Configuring Advanced Options

Use this page to do the following:

Define what an access reject from an RSA SecurID token server means to you.

Enable identity caching—Caching users in RSA is similar to caching users in Radius Token with the logic and the purpose of the caching being the same. The only difference is that in RSA there is no attribute retrieval for users and therefore no caching of attributes. The user who is authenticated is cached, but without any attributes.

To configure advanced options for the RSA realm:


Step 1 Do one of the following:

Click the Treat Rejects as `authentication failed' radio button—For ACS to interpret an authentication reject from an RSA SecurdID store as an authentication failure.

Click the Treat Rejects as `user not found' radio button—For ACS to interpret an authentication reject from an RSA SecurID store as "user not found."

Step 2 Enable identity caching to allow ACS to process requests that are not authenticated through the RSA server.

The results obtained from the last successful authentication are available in the cache for the specified time period.

Step 3 Check the Enable identity caching check box.

Step 4 Enter the aging time in minutes.

The identity cache stores the results of a successful login only for the time period specified here.

Step 5 Click Submit.


Related Topics

RSA SecurID Server

Creating and Editing RSA SecurID Token Servers

Configuring ACS Instance Settings

Editing ACS Instance Settings

Editing ACS Instance Settings

RADIUS Identity Stores

RADIUS server is a third-party server that supports the RADIUS interface. RADIUS identity store, which is part of ACS, connects to the RADIUS server.

RADIUS servers are servers that come with a standard RADIUS interface built into them and other servers that support the RADUIS interface. ACS 5.2 supports any RADIUS RFC 2865-compliant server as an external identity store. ACS 5.2 supports multiple RADIUS token server identities.

For example, the RSA SecurID server and SafeWord server. RADIUS identity stores can work with any RADIUS Token server that is used to authenticate the user. RADIUS identity stores use the UDP port for authentication sessions. The same UDP port is used for all RADIUS communication.


Note For ACS to successfully send RADIUS messages to a RADIUS-enabled server, you must ensure that the gateway devices between the RADIUS-enabled server and ACS allow communication over the UDP port. You can configure the UDP port through the ACS web interface.


This section contains the following topics:

Supported Authentication Protocols

Failover

Password Prompt

User Group Mapping

Groups and Attributes Mapping

RADIUS Identity Store in Identity Sequence

Authentication Failure Messages

Username Special Format with Safeword Server

User Attribute Cache

Creating, Duplicating, and Editing RADIUS Identity Servers

Supported Authentication Protocols

ACS supports the following authentication protocols for RADIUS identity stores:

RADIUS PAP

TACACS+ ASCII/PAP

PEAP with inner EAP-GTC

EAP-FAST with inner EAP-GTC

Failover

ACS 5.2 allows you to configure multiple RADIUS identity stores. Each RADIUS identity store can have primary and secondary RADIUS servers. When ACS is unable to connect to the primary server, it uses the secondary server.

Password Prompt

RADIUS identity stores allow you to configure the password prompt. You can configure the password prompt through the ACS web interface.

User Group Mapping

To provide the per-user group mapping feature available in ACS 4.x, ACS 5.2 uses the attribute retrieval and authorization mechanism for users that are authenticated with a RADIUS identity store.

For this, you must configure the RADIUS identity store to return authentication responses that contain the [009\001] cisco-av-pair attribute with the following value:

ACS:CiscoSecure-Group-Id=N, where N can be any ACS group number from 0 through 499 that ACS assigns to the user.

Then, this attribute is available in the policy configuration pages of the ACS web interface while creating authorization and group mapping rules.

Groups and Attributes Mapping

You can use the RADIUS attributes retrieved during authentication against the RADIUS identity store in ACS policy conditions for authorization and group mapping. You can select the attributes that you want to use in policy conditions while configuring the RADIUS identity store. These attributes are kept in the RADIUS identity store dedicated dictionary and can be used to define policy conditions.


Note You cannot query the RADIUS server for the requested attributes. You can only configure the RADIUS identity store to return the requested attributes. These attributes are available in the Access-Accept response as part of the attributes list.


You can use the attribute subscription feature of ACS 5.2 to receive RADIUS identity store attributes can on the ACS response to the device. The following RADIUS attributes are returned:

Attributes that are listed in the RADIUS RFS

Vendor-specific attributes

The following attribute types are supported:

String

Unsigned Integer

IPv4 Address

Enumeration

If an attribute with multiple values is returned, the value is ignored, and if a default value has been configured, that value is returned. However, this attribute is reported in the customer log as a problematic attribute.

RADIUS Identity Store in Identity Sequence

You can add the RADIUS identity store for authentication sequence in an identity sequence. However, you cannot add the RADIUS identity store for attribute retrieval sequence because you cannot query the RADIUS identity store without authentication. ACS cannot distinguish between different error cases while authenticating with a RADIUS server.

RADIUS servers return an Access-Reject message for all error cases. For example, when a user is not found in the RADIUS server, instead of returning a User Unknown status, the RADIUS server returns an Access-Reject message.

You can, however, enable the Treat Rejects as Authentication Failure or User Not Found option available in the RADIUS identity store pages of the ACS web interface.

Authentication Failure Messages

When a user is not found in the RADIUS server, the RADIUS server returns an Access-Reject message. ACS provides you the option to configure this message through the ACS web interface as either Authentication Failed or Unknown User.

However, this option returns an Unknown User message not only for cases where the user is not known, but for all failure cases.

Table 8-15 lists the different failure cases that are possible with RADIUS identity servers.

Table 8-15 Error Handling

Cause of Authentication Failure
Failure Cases

Authentication Failed

User is unknown.

User attempts to login with wrong passcode.

User logon hours expired.

Process Failed

RADIUS server is configured incorrectly in ACS.

RADIUS server is unavailable.

RADIUS packet is detected as malformed.

Problem during sending or receiving a packet from the RADIUS server.

Timeout.

Unknown User

Authentication failed and the 'Fail on Reject' option is set to false.


Username Special Format with Safeword Server

Safeword token server supports authentication with the following username format:

Username—Username, OTP

ACS parses the username and converts this to:

Username—Username

Safeword token servers support both the formats. ACS works with various token servers. While configuring a Safeword server, you must check the Safeword Server check box for ACS to parse the username and convert it to the specified format.

This conversion is done in the RADIUS token server identity store before the request is sent to the RADIUS token server.

User Attribute Cache

RADIUS token servers, by default, do not support user lookups. However, the user lookup functionality is essential for the following ACS features:

PEAP session resume—Happens after successful authentication during EAP session establishment

EAP/FAST fast reconnect—Happens after successful authentication during EAP session establishment

T+ Authorization—Happens after successful T+ Authentication

ACS caches the results of successful authentications to process user lookup requests for these features. For every successful authentication, the name of the authenticated user and the retrieved attributes are cached. Failed authentications are not written to the cache.

The cache is available in the memory at runtime and is not replicated between ACS nodes in a distributed deployment. You can configure the time to live (TTL) limit for the cache through the ACS web interface. You must enable the identity caching option and set the aging time in minutes. The cache is available in the memory for the specified amount of time.

Creating, Duplicating, and Editing RADIUS Identity Servers

ACS 5.2 supports the RADIUS identity server as an external identity store for the increased security that one-time passwords provide. RADIUS identity servers provide two-factor authentication to ensure the authenticity of the users.

To authenticate users against a RADIUS identity store, you must first create the RADIUS identity server in ACS and configure the settings for the RADIUS identity store. ACS 5.2 supports the following authentication protocols:

RADIUS PAP

TACACS+ ASCII\PAP

PEAP with inner EAP-GTC

EAP-FAST with inner EAP-GTC

For a successful authentication with a RADIUS identity server, ensure that:

The gateway devices between the RADIUS identity server and ACS allow communication over the UDP port.

The shared secret that you configure for the RADIUS identity server on the ACS web interface is identical to the shared secret configured on the RADIUS identity server.

To create, duplicate, or edit a RADIUS Identity Server:


Step 1 Choose Users and Identity Stores > External Identity Stores > RADIUS Identity Servers.

The RADIUS Identity Servers page appears with a list of RADIUS external identity servers.

Step 2 Click Create. You can also:

Check the check box next to the identity store you want to duplicate, then click Duplicate.

Click the identity store name that you want to modify, or check the box next to the name and click Edit.

Step 3 Complete the fields in the General tab. See Configuring General Settings for a description of the fields in the General tab.

Step 4 You can:

Click Submit to save the RADIUS Identity Server.

Click the Shell Prompts tab. See Configuring Shell Prompts for a description of the fields in the Shell Prompts tab.

Click the Directory Attributes tab. See Configuring Directory Attributes for a description of the fields in the Directory Attributes tab.

Click the Advanced tab. See Configuring Advanced Options for a description of the fields in the Advanced tab.

Step 5 Click Submit to save the changes.


Related Topics

RADIUS Identity Stores

Creating, Duplicating, and Editing RADIUS Identity Servers

Configuring General Settings

Table 8-16 describes the fields in the General tab of the RADIUS Identity Servers page.

Table 8-16 RADIUS Identity Server - General Tab 

Option
Description

Name

Name of the external RADIUS identity server.

Description

(Optional) A brief description of the RADIUS identity server.

SafeWord Server

Check this check box to enable a two-factor authentication using a SafeWord server.

Server Connection

Enable Secondary Server

Check this check box to use a secondary RADIUS identity server as a backup server in case the primary RADIUS identity server fails.

If you enable the secondary server, you must configure the parameters for the secondary RADIUS identity server and must choose one of the following options:

Always Access Primary Server First—Select this option to ensure that ACS always accesses the primary RADIUS identity server first before the secondary server is accessed.

Failback To Primary Server After n Minutes—Select this option to set the number of minutes ACS can use the secondary server for authentication.

After this time expires, ACS should again attempt to authenticate using the primary server. The default value is 5 minutes.

Primary Server

Server IP Address

IP address of the primary RADIUS identity server.

Shared Secret

The shared secret between ACS and the primary RADIUS identity server.

A shared secret is an expected string of text, which a user must provide before the network device authenticates a username and password. The connection is rejected until the user supplies the shared secret.

Authentication Port

Port number on which the RADIUS primary server listens. Valid options are from 1 to 65,535. The default value is 1812.

Server Timeout n Seconds

The number of seconds, n, that ACS waits for a response from the primary RADIUS identity server before it determines that the connection to the primary server has failed. Valid options are from 1 to 300. The default value is 5.

Connection Attempts

Specifies the number of times that ACS should attempt to reconnect before contacting the secondary RADIUS identity server or dropping the connection if no secondary server is configured. Valid options are from 1 to 10. The default value is 3.

Secondary Server

Server IP Address

IP address of the secondary RADIUS identity server.

Shared Secret

The shared secret between ACS and the secondary RADIUS identity server. The shared secret must be identical to the shared secret that is configured on the RADIUS identity server.

A shared secret is an expected string of text, which a user must provide before the network device authenticates a username and password. The connection is rejected until the user supplies the shared secret.

Authentication Port

Port number on which the RADIUS secondary server listens. Valid options are from 1 to 65,535. The default value is 1812.

Server Timeout n Seconds

The number of seconds, n, that ACS waits for a response from the secondary RADIUS identity server before it determines that the connection to the secondary server has failed.

Valid options are from 1 to 300. The default value is 5.

Connection Attempts

Specifies the number of times that ACS should attempt to reconnect before dropping the request. Valid options are from 1 to 10. The default value is 3.


Related Topics

RADIUS Identity Stores

Creating, Duplicating, and Editing RADIUS Identity Servers

Configuring Shell Prompts

Configuring Directory Attributes

Configuring Advanced Options

Configuring Shell Prompts

For TACACS+ ASCII authentication, ACS must return the password prompt to the user. RADIUS identity server supports this functionality by the password prompt option. ACS can use the prompt that you configure in the Shell Prompts page on the ACS web interface. If the prompt is empty, the user receives the default prompt that is configured under TACACS+ global settings.

When establishing a connection with a RADIUS identity server, the initial request packets may not have the password. You must request a password. You can use this page to define the prompt that is used to request the password. To do this:


Step 1 Enter the text for the prompt in the Prompt field.

Step 2 Do one of the following:

Click Submit to configure the prompt for requesting the password.

Click the Directory Attributes tab to define a list of attributes that you want to use in policy rule conditions. See Configuring Directory Attributes for more information.


Related Topics

RADIUS Identity Stores

Creating, Duplicating, and Editing RADIUS Identity Servers

Configuring General Settings

Configuring Directory Attributes

Configuring Advanced Options

Configuring Directory Attributes

When a RADIUS identity server responds to a request, RADIUS attributes are returned along with the response. You can make use of these RADIUS attributes in policy rules.

In the Directory Attributes tab, you can specify the RADIUS attributes that you use in policy rule conditions. ACS maintains a separate list of these attributes.


Step 1 Modify the fields in the Directory Attributes tab as described in Table 8-17.

Table 8-17 RADIUS Identity Servers - Directory Attributes Tab

Option
Description

Attribute List

Use this section to create the attracted list to include in policy conditions. As you include each attribute, its name, type, default value, and policy condition name appear in the table. To:

Add a RADIUS attribute, fill in the fields below the table and click Add.

Edit a RADIUS attribute, select the appropriate row in the table and click Edit. The RADIUS attribute parameters appear in the fields below the table. Edit as required, then click Replace.

Dictionary Type

RADIUS dictionary type. Click the drop-down list box to select a RADIUS dictionary type.

RADIUS Attribute

Name of the RADIUS attribute. Click Select to choose the RADIUS attribute. This name is composed of two parts: The attribute name and an extension to support AV-pairs if the attribute selected is a Cisco AV-Pair.

For example, for an attribute, cisco-av-pair with an AV-pair name some-avpair, ACS displays cisco-av-pair.some-avpair.

IETF and vendor VSA attribute names contain an optional suffix, -nnn, where nnn is the ID of the attribute.

Type

RADIUS attribute type. Valid options are:

String

Unsigned Integer 32

IPv4 Address

Default

(Optional) A default value that can be used if the attribute is not available in the response from the RADIUS identity server. This value must be of the specified RADIUS attribute type.

Policy Condition Name

Specify the name of the custom policy condition that uses this attribute.


Step 2 Do either of the following:

Click Submit to save your changes and return to the RADIUS Identity Servers page.

Click the Advanced tab to configure failure message handling and to enable identity caching. See Configuring Advanced Options for more information.


Related Topics

RADIUS Identity Stores

Creating, Duplicating, and Editing RADIUS Identity Servers

Configuring General Settings

Configuring Shell Prompts

Configuring Advanced Options

Configuring Advanced Options

In the Advanced tab, you can do the following:

Define what an access reject from a RADIUS identity server means to you.

Enable identity caching.

Table 8-18 describes the fields in the Advanced tab of the RADIUS Identity Servers page.

Table 8-18 RADIUS Identity Server - Advanced Tab

Option
Description

This Identity Store does not differentiate between 'authentication failed' and 'user not found' when an authentication attempt is rejected. From the options below, select how such an authentication reject from the Identity Store should be interpreted by ACS for Identity Policy processing and reporting.

Treat Rejects as 'authentication failed'

Click this option to consider all ambiguous access reject attempts as failed authentications.

Treat Rejects as 'user not found'

Click this option to consider all ambiguous access reject attempts as unknown users.

Identity caching is used to allow processing of requests that do not perform authentication against the server. The cache retains the results and attributes retrieved from the last successful authentication for the subject.

Enable identity caching

Check this check box to enable identity caching. If you enable identity caching, you must enter the time in minutes for which you want ACS to retain the identity cache.

Aging Time n Minutes

Enter the time in minutes for which you want ACS to retain the identity cache. Valid options are from 1 to 1440.


Click Submit to save the RADIUS Identity Server.

Related Topics

RADIUS Identity Stores

Creating, Duplicating, and Editing RADIUS Identity Servers

Configuring CA Certificates

When a client uses the EAP-TLS protocol to authenticate itself against the ACS server, it sends a client certificate that identifies itself to the server. To verify the identity and correctness of the client certificate, the server must have a preinstalled certificate from the Certificate Authority (CA) that has digitally signed the client certificate.

If ACS does not trust the client's CA certificate, then you must install in ACS the entire chain of successively signed CA certificates, all the way to the top-level CA certificate that ACS trusts. CA certificates are also known as trust certificates.

You use the CA options to install digital certificates to support EAP-TLS authentication. ACS uses the X.509 v3 digital certificate standard. ACS also supports manual certificate acquisition and provides the means for managing a certificate trust list (CTL) and certificate revocation lists (CRLs).

Digital certificates do not require the sharing of secrets or stored database credentials. They can be scaled and trusted over large deployments. If managed properly, they can serve as a method of authentication that is stronger and more secure than shared secret systems.

Mutual trust requires that ACS have an installed certificate that can be verified by end-user clients. This server certificate may be issued from a CA or, if you choose, may be a self-signed certificate. For more information, see Configuring Local Server Certificates.


Note ACS builds a certificate chain with the CA certificates that you add to it and uses this chain during TLS negotiations. You must add the certificate that signed the server certificate to the CA. You must ensure that the chain is signed correctly and that all the certificates are valid.


If the server certificate and the CA that signed the server certificate are installed on ACS, ACS sends the full certificate chain to the client.

Related Topics

Adding a Certificate Authority

Editing a Certificate Authority and Configuring Certificate Revocation Lists

Deleting a Certificate Authority

Exporting a Certificate Authority

Adding a Certificate Authority

The supported certificate formats are either DER or PEM.

To add a trusted CA (Certificate Authority) certificate:


Step 1 Select Users and Identity Stores > Certificate Authorities.

The Trust Certificate page appears.

Step 2 Click Add.

Step 3 Complete the fields in the Certificate File to Import page as described in Table 8-19:

Table 8-19 Certificate Authority Properties Page   

Option
Description
Certificate File to Import

Certificate File

Enter the name of the certificate file. Click Browse to navigate to the location on the client machine where the trust certificate is located.

Trust for client with EAP-TLS

Check this box so that ACS will use the certificate trust list for the EAP protocol.

Description

Enter a description of the CA certificate.


Step 4 Click Submit.

The new certificate is saved. The Trust Certificate List page appears with the new certificate.


Related Topics

User Certificate Authentication

Overview of EAP-TLS

Editing a Certificate Authority and Configuring Certificate Revocation Lists

Use this page to edit a trusted CA (Certificate Authority) certificate.


Step 1 Select Users and Identity Stores > Certificate Authorities.

The Trust Certificate page appears with a list of configured certificates.

Step 2 Click the name that you want to modify, or check the check box for the Name, and click Edit.

Step 3 Complete the fields in the Edit Trust Certificate List Properties Page as described in Table 8-20:

Table 8-20 Edit Certificate Authority Properties Page  

Option
Description
Issuer

Friendly Name

The name that is associated with the certificate.

Description

(Optional) A brief description of the CA certificate.

Issued To

Display only. The entity to which the certificate is issued. The name that appears is from the certificate subject.

Issued By

Display only. The certification authority that issued the certificate.

Valid from

Display only. The start date of the certificate's validity. An X509 certificate is valid only from the start date to the end date (inclusive).

Valid To (Expiration)

Display only. The last date of the certificate's validity.

Serial Number

Display only. The serial number of the certificate.

Description

Description of the certificate.

Usage

Trust for client with EAP-TLS

Check this box so that ACS will use the trust list for the TLS related EAP protocols.

Certificate Revocation List Configuration

Use this section to configure the CRL.

Download CRL

Check this box to download the CRL.

CRL Distribution URL

Enter the CRL distribution URL. You can specify a URL that uses HTTP.

Retrieve CRL

ACS attempts to download a CRL from the CA. Toggle the time settings for ACS to retrieve a new CRL from the CA.

Automatically —Obtain the next update time from the CRL file. If unsuccessful, ACS tries to retrieve the CRL periodically after the first failure until it succeeds.

Every—Determines the frequency between retrieval attempts. Enter the amount in units of time.

If Download Failed Wait

Enter the amount of time to attempt to retrieve the CRL, if the retrieval initially failed.

Bypass CRL Verification if CRL is not Received

If unchecked, all the client requests that use the certificate that is signed by the selected CA will be rejected until ACS receives the CRL file. When checked, the client request may be accepted before the CRL is received.

Ignore CRL Expiration

Check this box to check a certificate against an outdated CRL.

When checked, ACS continues to use the expired CRL and permits or rejects EAP-TLS authentications according to the contents of the CRL.

When unchecked, ACS examines the expiration date of the CRL in the Next Update field in the CRL file. If the CRL has expired, all authentications that use the certificate that is signed by the selected CA are rejected.


Step 4 Click Submit.

The Trust Certificate page appears with the edited certificate.


Related Topics

User Certificate Authentication

Overview of EAP-TLS

Deleting a Certificate Authority

Use this page to delete a trusted CA (Certificate Authority) certificate:


Step 1 Select Users and Identity Stores > Certificate Authorities.

The Trust Certificate List page appears with a list of configured certificates.

Step 2 Check one or more check boxes next to the certificates that you want to delete.

Step 3 Click Delete.

Step 4 Click Yes to confirm.

The Trust Certificate page appears without the deleted certificate(s).


Related Topic

Overview of EAP-TLS

Exporting a Certificate Authority

To export a trust certificate:


Step 1 Select Users and Identity Stores > Certificate Authorities.

The Trust Certificate List page appears with a list of configured certificates.

Step 2 Check the box next to the certificates that you want to export.

Step 3 Click Export.

This operation exports the trusted certificate to the client machine.

Step 4 Click Yes to confirm.

You are prompted to install the exported certificate on your client machine.


Related Topics

User Certificate Authentication

Overview of EAP-TLS

Configuring Certificate Authentication Profiles

The certificate authentication profile defines the X509 certificate information to be used for a certificate- based access request. You can select an attribute from the certificate to be used as the username.

You can select a subset of the certificate attributes to populate the username field for the context of the request. The username is then used to identify the user for the remainder of the request, including the identification used in the logs.

You can use the certificate authentication profile to retrieve certificate data to further validate a certificate presented by an LDAP or AD client. The username from the certificate authentication profile is used to query the LDAP or AD identity store.

ACS compares the client certificate against all certificates retrieved from the LDAP or AD identity store, one after another, to see if one of them matches. ACS either accepts or rejects the request.


Note For ACS to accept a request, only one certificate from either the LDAP or the AD identity store must match the client certificate.


When ACS processes a certificate-based request for authentication, one of two things happens: the username from the certificate is compared to the username in ACS that is processing the request, or ACS uses the information that is defined in the selected LDAP or AD identity store to validate the certificate information.

You can duplicate a certificate authentication profile to create a new profile that is the same, or similar to, an existing certificate authentication profile. After duplication is complete, you access each profile (original and duplicated) separately, to edit or delete them.

To create, duplicate, or edit a certificate authentication profile:


Step 1 Select Users and Identity Stores > Certificate Authentication Profile.

The Certificate Authentication Profile page appears.

Step 2 Do one of the following:

Click Create.

Check the check box next to the certificate authentication profile that you want to duplicate, then click Duplicate.

Click the certificate authentication profile that you want to modify, or check the check box next to the name and click Edit.

The Certificate Authentication Profile Properties page appears.

Step 3 Complete the fields in the Certificate Authentication Profile Properties page as described in Table 8-21:

Table 8-21 Certificate Authentication Profile Properties Page 

Option
Description
General

Name

Enter the name of the certificate authentication profile.

Description

Enter a description of the certificate authentication profile.

Certificate Definition

Principal Username X509 Attribute

The available set of principal username attributes for x509 authentication. The selection includes:

Common Name

Subject Alternative Name

Subject Serial Number

Subject

Subject Alternative Name - Other Name

Subject Alternative Name - EMail

Subject Alternative Name - DNS

Perform Binary Certificate Comparison with Certificate retrieved from LDAP or Active Directory

Check this check box if you want to validate certificate information for authentication against a selected LDAP or AD identity store.

If you select this option, you must enter the name of the LDAP or AD identity store, or click Select to select the LDAP or AD identity store from the available list.


Step 4 Click Submit.

The Certificate Authentication Profile page reappears.


Related Topics

Viewing Identity Policies

Configuring Identity Store Sequences

Creating External LDAP Identity Stores

Configuring Identity Store Sequences

An access service identity policy determines the identity sources that ACS uses for authentication and attribute retrieval. An identity source consists of a single identity store or multiple identity methods. When you use multiple identity methods, you must first define them in an identity store sequence, and then specify the identity store sequence in the identity policy.

An identity store sequence defines the sequence that is used for authentication and attribute retrieval and an optional additional sequence to retrieve additional attributes.

Authentication Sequence

An identity store sequence can contain a definition for certificate-based authentication or password-based authentication or both.

If you select to perform authentication based on a certificate, you specify a single Certificate Authentication Profile, which you have already defined in ACS.

If you select to perform authentication based on a password, you can define a list of databases to be accessed in sequence.

When authentication succeeds, any defined attributes within the database are retrieved. You must have defined the databases in ACS.

Attribute Retrieval Sequence

You can optionally define a list of databases from which to retrieve additional attributes. These databases can be accessed regardless of whether you use password or certificate-based authentication. When you use certificate-based authentication, ACS populates the username field from a certificate attribute and then uses the username to retrieve attributes.

ACS can retrieve attributes for a user, even when:

The user's password is flagged for a mandatory change.

The user's account is disabled.

When you perform password-based authentication, you can define the same identity database in the authentication list and the attribute retrieval list. However, if the database is used for authentication, it will not be accessed again as part of the attribute retrieval flow.

ACS authenticates a user or host in an identity store only when there is a single match for that user or host. If an external database contains multiple instances of the same user, authentication fails. Similarly, ACS retrieves attributes only when a single match for the user or host exists; otherwise, ACS skips attribute retrieval from that database.

This section contains the following topics:

Creating, Duplicating, and Editing Identity Store Sequences

Deleting Identity Store Sequences

Creating, Duplicating, and Editing Identity Store Sequences

To create, duplicate, or edit an identity store sequence:


Step 1 Select Users and Identity Stores > Identity Store Sequences.

The Identity Store Sequences page appears.

Step 2 Do one of the following:

Click Create.

Check the check box next to the sequence that you want to duplicate, then click Duplicate.

Click the sequence name that you want to modify, or check the check box next to the name and click Edit.

The Identity Store Sequence Properties page appears as described in Table 8-22.

Table 8-22 Identity Store Sequence Properties Page 

Option
Description
General

Name

Enter the name of the identity store sequence.

Description

Enter a description of the identity store sequence.

Authentication Method List

Certificate Based

Check this check box to use the certificate-based authentication method. If you choose this option, you must enter the certificate authentication profile. Click Select to choose the profile from a list of available profiles.

Password Based

Check this check box to use the password-based authentication method. If you choose this option, you must choose the set of identity stores that ACS will access one after another until a match is found.

If you choose this option, you must select a list of identity stores in the Authentication and Attribute Retrieval Search List area for ACS to access the identity stores one after another.

Authentication and Attribute Retrieval Search List

Note This section appears only when you check the Password Based option.

Available

The available set of identity stores to access.

Selected

The selected set of identity stores to access in sequence until first authentication succeeds. Use the Up and Down arrows at the right of the list to define the order of access.

ACS automatically retrieves attributes from identity stores that you selected for authentication. You do not need to select the same identity stores for attribute retrieval.

Additional Attribute Retrieval Search List

Available

The available set of additional identity stores for attribute retrieval.

Selected

(Optional) The selected set of additional identity stores for attribute retrieval. Use the Up and Down arrows at the right of the list to define the order of access.

ACS automatically retrieves attributes from identity stores that you selected for authentication. You do not need to select the same identity stores for attribute retrieval.

Internal User/Host Advanced Option

If internal user/host not found or disabled then exit sequence and treat as "User Not Found"

Check this check box for ACS to treat the failed authentication as User Not Found when a match is not found.


Step 3 Click Submit.

The Identity Store Sequences page reappears.


Related Topics

Performing Bulk Operations for Network Resources and Users

Viewing Identity Policies

Managing Internal Identity Stores

Managing External Identity Stores

Configuring Certificate Authentication Profiles

Deleting Identity Store Sequences

Deleting Identity Store Sequences

To delete an identity store sequence:


Step 1 Select Users and Identity Stores > Identity Store Sequences.

The Identity Store Sequences page appears with a list of your configured identity store sequences.

Step 2 Check one or more check boxes next to the identity store sequences that you want to delete.

Step 3 Click Delete.

The following error message appears:

Are you sure you want to delete the selected item/items?

Step 4 Click OK.

The Identity Store Sequences page appears, without the deleted identity store sequence(s) listed.


Related Topics

Performing Bulk Operations for Network Resources and Users

Viewing Identity Policies

Managing Internal Identity Stores

Managing External Identity Stores

Configuring Certificate Authentication Profiles

Creating, Duplicating, and Editing Identity Store Sequences