Cisco Acs 57 User Guide

							1
Cisco Systems, Inc.www.cisco.com
 
Managing Users and Identity Stores
This chapter describes the following topics:
Overview, page 1
Managing Internal Identity Stores, page 4
Managing External Identity Stores, page 29
Configuring CA Certificates, page 83
Configuring Certificate Authentication Profiles, page 89
Configuring Identity Store Sequences, page 90
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. 
						

							2
Managing Users and Identity Stores
 
Overview
Fixed components are:
Name
Description
Password
Enabled or disabled status
Email Address
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
Disable Account if Date Exceeds
Disable account after n successive failed attempts
Enable Password Hash
Password Never Expired/Disabled
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, 
page 4.
External Identity Stores
External identity stores are external databases on which ACS performs authentications for internal and external users. ACS 5.7 
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, page 29. 
						

							3   
Managing Users and Identity Stores
Overview
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, page 83
Configuring Certificate Authentication Profiles, page 89
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. 
						

							4
Managing Users and Identity Stores
 
Managing Internal Identity Stores
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, page 83. 
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, page 90.
This chapter contains the following sections:
Managing Internal Identity Stores, page 4
Managing External Identity Stores, page 29
Configuring CA Certificates, page 83
Configuring Certificate Authentication Profiles, page 89
Configuring Identity Store Sequences, page 90
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.7 supports authentication for internal users against the internal identity store only.
This section contains the following topics:
Authentication Information, page 5
Identity Groups, page 5
Managing Identity Attributes, page 7
Configuring Authentication Settings for Users, page 9
Disabling User Account After N Days of Inactivity, page 12 
						

							5   
Managing Users and Identity Stores
Managing Internal Identity Stores
Creating Internal Users, page 13
Enable and Disable Password Hashing for Internal Users, page 18
Configuring Password Expiry Notification Emails to Users and Administrators, page 19
Viewing and Performing Bulk Operations for Internal Identity Store Users, page 21
Configuring Authentication Settings for Hosts, page 21
Creating Hosts in Identity Stores, page 22
Viewing and Performing Bulk Operations for Internal Identity Store Hosts, page 25
Management Hierarchy, page 26
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.  
						

							6
Managing Users and Identity Stores
 
Managing Internal Identity Stores
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:
1.Choose Users and Identity Stores > Identity Groups.
The Identity Groups page appears.
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, 
page 7.
The Create page or the Edit page appears when you choose the Create, Duplicate, or Edit option.
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.
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, page 1
Managing Internal Identity Stores, page 4
Performing Bulk Operations for Network Resources and Users, page 7
Identity Groups, page 3
Creating Identity Groups, page 6 
						

							7   
Managing Users and Identity Stores
Managing Internal Identity Stores
Deleting an Identity Group, page 7
Deleting an Identity Group
To delete an identity group:
1.Choose Users and Identity Stores > Identity Groups.
The Identity Groups page appears.
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?
3.Click OK.
The Identity Groups page appears without the deleted identity groups.
Related Topic
Managing Identity Attributes, page 7
Managing Identity Attributes
Administrators can define sets of identity attributes that become elements in policy conditions. For information about the ACS 
5.7 policy model, see ACS 5.x Policy Model, page 1 During authentication, identity attributes are taken from the internal data 
store when they are part of a policy condition. 
ACS 5.7 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.7 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, page 7
User Attributes, page 8
Host Attributes, page 9
Standard Attributes
Table 37 on page 8 describes the standard attributes in the internal user record. 
						

							8
Managing Users and Identity Stores
 
Managing Internal Identity Stores
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.7, 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.
Ta b l e 3 7 S t a n d a r d  A t t r i b u t e s
Attribute Description
Username ACS compares the username against the username in the authentication request. 
The comparison is case-insensitive.
StatusEnabled status indicates that the account is active. 
Disabled status indicates that authentications for the username will fail. 
Description Text description of the attribute.
Identity Group ACS associates each user to an identity group. See Managing Identity Attributes, 
page 7 for information. 
						

							9   
Managing Users and Identity Stores
Managing Internal Identity Stores
4.Define rules based on this condition.
As you become more familiar with ACS 5.7 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, page 12 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, page 15 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:
1.Choose System Administration > Users > Authentication Settings.
The User Authentication Settings page appears with the Password Complexity and Advanced tabs.
2.In the Password Complexity tab, check each check box that you want to use to configure your user password. 
Table 38 on page 10 describes the fields in the Password Complexity tab. 
						

							1
Managing Users and Identity Stores
 
Managing Internal Identity Stores
3.In the Advanced tab, enter the values for the criteria that you want to configure for your user authentication process. The 
following table describes the fields in the Advanced tab.
Ta b l e 3 8 P a s s w o r d  C o m p l e x i t y  Ta b
Option Description
Applies to all ACS internal identity store user accounts
Minimum length Required minimum length; the valid options are 4 to 127.
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 
consecutivelyCheck to specify that the password cannot repeat characters four or more times 
consecutively.
Change password failed reason message 
(for TACACS+ only)Enter the error message that is displayed when a user enters a password that 
does not meet the password policy while trying to change the existing 
password. 
This option is applicable only for internal user TACACS+ authentication. The 
maximum length of this field is 50 characters. Using this option, you can display 
an appropriate error message for the internal users if their new password does 
not match the criteria that you have specified.
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.
Uppercase 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 non-alphanumeric character.