Cisco Acs 57 User Guide

							2   
Managing Users and Identity Stores
Managing Internal Identity Stores
Viewing and Performing Bulk Operations for Internal Identity Store Users
To view and perform bulk operations to internal identity store users:
1.Choose 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.
2.Do one of the following:
Click Create. For more information on creating internal users, see Creating Internal Users, page 13.
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, page 13.
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, page 13.
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, page 7 for a detailed description of the bulk operations.
Related Topics
Creating Internal Users, page 13
Viewing and Performing Bulk Operations for Internal Identity Store Users, page 21
Deleting Users from Internal Identity Stores, page 17
Configuring Authentication Settings for Hosts
ACS 5.7 introduces a new section “Authentication Settings” under “System Administration” for Configuring Authentication 
Settings for Hosts. Using this section, you can disable and delete host accounts based on their inactivity.
This section describes the following:
Disabling and Deleting Host Accounts After N and N+x Days of Inactivity, page 21
Disabling and Deleting Host Accounts After N and N+x Days of Inactivity 
Before you Begin: 
This feature is applicable only for the internal hosts that sends MAB authentication requests. 
						

							2
Managing Users and Identity Stores
 
Managing Internal Identity Stores
ACS must be configured to send passed authentication messages to the log collector server.
The log collector server must be running and receiving syslog messages from all ACS nodes in the deployment. 
The log recovery feature must be enabled.
ACS 5.7 allows the administrator to configure the maximum number of days from ACS web interface during which the internal 
hosts’ accounts are enabled despite the hosts not having logged in to the network. Once the configured period is exceeded, 
the host’s account is disabled if the host has not logged in to the network. Also, the administrator can configure the number of 
days in such a way that ACS can delete the host account from the database if the host has not logged in to the network after 
the host account is disabled. 
The default value for disabling the host account is 30 days of inactivity. The default value for deleting the host account is 60 
days of inactivity after the host account is disabled. For this feature to work properly, the log collector server should be running 
and receiving the syslog messages from all ACS nodes in the deployment. 
ACS calculates the inactivity based on the last login date of MAB entry. Every day at 10 PM, ACS View runs a job to provide the 
list of active MAB entries to the primary management. An active host is one which has made at least one successful 
authentication for the configured period of time. You can observe the last active time of a host from the passed authentication 
reports in ACS Reports web interface. Based on this list, the primary management identifies the inactive MAB entries list, 
disables them, and sends an audit log message to the log collector server. The administrator can enable the disabled host 
account. After enabling the host account, the subsequent calculation for inactivity will be calculated from the last enabled date.
Note: When you change the log collector server, it is mandatory to restore the back up taken from the old log collector server 
in the new log collector server.
Note: When you restore the ACS backup from one ACS instance to another ACS instance, the view back up also should be 
restored along with the ACS backup.
To disable host accounts after n days of inactivity:
1.Choose System Administration > Hosts > Authentication Settings.
The Host Authentication Settings page appears.
2.Check the Disable host account after n days of inactivity check box.
3.Enter the number of days in the text box.
ACS disables the host account if it is not active for the configured number of days.
To delete host accounts after n days of disablement:
1.Choose System Administration > Hosts > Authentication Settings.
The Host Authentication Settings page appears.
2.Check the Delete host account after n days of disablement/inactivity check box.
3.Enter the number of days in the text box. 
ACS deletes the host account if it is not active for the configured number of days after that account is disabled.
Creating Hosts in Identity Stores
To create, duplicate, or edit a MAC address and assign identity groups to internal hosts:
1.Choose Users and Identity Stores > Internal Identity Stores > Hosts. 
						

							2   
Managing Users and Identity Stores
Managing Internal Identity Stores
The Internal Hosts page appears, listing any configured internal hosts.
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, page 25 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.
3.Complete the fields in the Internal MAC Address Properties page as described in Table 42 on page 24: 
						

							2
Managing Users and Identity Stores
 
Managing Internal Identity Stores
4.Click Submit to save changes.
Table 42 Internal Hosts Properties Page
Option Description
General
MAC Address ACS 5.7 support wildcards while adding new hosts to the internal identity store. Enter a valid MAC 
address, using any of the following formats:
01-23-45-67-89-AB/01-23-45-*
01:23:45:67:89:AB/01:23:45:*
0123.4567.89AB/0123.45*
0123456789AB/012345*
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 InformationDisplay only. Contains MAC host identity attribute information.
Creation/Modification Information
This section of the page appears only after you have created or modified a MAC address.
Date CreatedDisplay 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 ModifiedDisplay 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 
						

							2   
Managing Users and Identity Stores
Managing Internal Identity Stores
The MAC address configuration is saved. The Internal MAC list page appears with the new configuration.
Note: Hosts with wildcards (supported formats) for MAC addresses are migrated from 4.x to 5.x. 
Note: You can add wildcard for MAC address which allows the entire range of Organization Unique Identifier (OUI) clients. 
For example: If you add Cisco's MAC address 00-00-0C-*, the entire range of Cisco devices will be added to the host.
Related Topics
Host Lookup, page 12
Deleting Internal Hosts, page 25
Viewing and Performing Bulk Operations for Internal Identity Store Hosts, page 25
Policies and Identity Attributes, page 16
Configuring an Identity Group for Host Lookup Network Access Requests, page 17
Deleting Internal Hosts
To delete a MAC address:
1.Choose Users and Identity Stores > Internal Identity Stores > Hosts.
The Internal MAC List page appears, with any configured MAC addresses listed.
2.Check one or more of the check boxes next to the internal hosts you want to delete.
3.Click Delete.
The following message appears:
Are you sure you want to delete the selected item/items?
4.Click OK.
The Internal MAC List page appears without the deleted MAC addresses.
Related Topics
Host Lookup, page 12
Viewing and Performing Bulk Operations for Internal Identity Store Hosts, page 25
Creating Hosts in Identity Stores, page 22
Policies and Identity Attributes, page 16
Configuring an Identity Group for Host Lookup Network Access Requests, page 17
Viewing and Performing Bulk Operations for Internal Identity Store Hosts
To view and perform bulk operations for internal identity stores:
1.Choose Users and Identity Stores > Internal Identity Stores > Hosts.
The Internal Hosts page appears, with any configured internal hosts listed. 
						

							2
Managing Users and Identity Stores
 
Managing Internal Identity Stores
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, page 7 for a detailed description of the bulk operations.
Related Topics
Host Lookup, page 12
Creating Hosts in Identity Stores, page 22
Deleting Internal Hosts, page 25
Policies and Identity Attributes, page 16
Configuring an Identity Group for Host Lookup Network Access Requests, page 17
Management Hierarchy 
Management Hierarchy enables the administrator to give access permission to the internal users or internal hosts according to 
their level of hierarchy in the organizations management hierarchy. A hierarchical label is assigned to each device that 
represents the administrative location of that particular device within the organizations management hierarchy. 
For example, the hierarchical label All:US:NY:MyMgmtCenter indicates that the device is in a MyMgmtcenter under NY city which 
is in U.S. The administrator can give access permission to the users based on their assigned level of hierarchy. For instance, if 
a user has an assigned level as All:US:NY, then that user is given permission when the user accesses the network through any 
device with a hierarchy that starts with All:US:NY. The same examples are applicable for internal hosts. 
Attributes of Management Hierarchy
To use the Management Hierarchy feature, administrator needs to create the following attributes in the Internal Users Dictionary: 
ManagementHierarchy attribute—allows the administrator to define one or more hierarchies for each internal users or 
internal hosts. This attribute is of type string and the maximum character length is 256. See Creating, Duplicating, and 
Editing an Internal User Identity Attribute, page 12 and Creating, Duplicating, and Editing an Internal Host Identity Attribute, 
page 15.
UserIsInManagementHierarchy or HostIsInManagementHierarchy attribute—the value of this attribute is set to true when the 
hierarchy defined for the user or host equals or contained in the hierarchy defined for the network device and AAA clients. 
This attribute is of type Boolean and the default value is false. It is not displayed in the users or hosts page in ACS web 
interface. You can view this attribute only in the identity attributes dictionary list. See Creating, Duplicating, and Editing an 
Internal User Identity Attribute, page 12 and Creating, Duplicating, and Editing an Internal Host Identity Attribute, page 15.
Configuring AAA Devices for Management Hierarchy
The management centers and the correlated customer names should be configured within a Management Hierarchy for each 
AAA client. Any Network Device Group can be used as a Management Hierarchy for a AAA client. The Network Device Group 
used for this is known as the Management Hierarchy Attribute. The administrator can create a new Network Device Group which 
will be used as Management Hierarchy. The Location hierarchy is an example of a Management Hierarchy attribute.
Example: 
Location:All Locations:ManagementCenter1:Customer1 
						

							2   
Managing Users and Identity Stores
Managing Internal Identity Stores
Configuring Users or Hosts for Management Hierarchy
A specific level of access is defined to represent the top-most node in the Management Hierarchy assigned for each user or a 
host. This level is defined in the user’s “ManagementHierarchy” attribute. Total value length is limited to 256 characters. 
The administrator can configure any level of hierarchy while defining management centers or AAA client locations. The syntax 
for ManagementHierarchy attribute is:
: :
Examples: 
1.Location:All Locations:ManagementCenter1
2.Location:All Locations:ManagementCenter1:Customer 1
The administrator can configure multiple values for management hierarchy. The syntax for multiple value attribute is:
: :||…
Example:
Location:All Locations:ManagementCenter1:Customer1|ManagementCenter1:Customer2
Configuring and Using the UserIsInManagement Hierarchy Attribute
To configure and use the UserIsInManagementHierarchy attribute, complete the following steps:
1.Create the ManagementHierarchy and UserIsInManagementHierarchy attributes for internal users. See Configuring Internal 
Identity Attributes, page 13. 
2.Create the network device groups for the network devices and AAA clients with the required hierarchies. See Creating, 
Duplicating, and Editing Network Device Groups, page 2.
3.Create network devices and AAA clients and associate them with a network device group. See Creating, Duplicating, and 
Editing Network Devices, page 9.
4.Create internal users and configure the ManagementHierarchy attribute. See Creating Internal Users, page 13. 
5.Choose Access Policies > Access Services > Default Network Access > Authorization.
The Authorization page appears.
6.Click Customize, add the compound condition to the policy conditions, and click OK. 
7.Click Create to create a new policy, and do the following: 
a.Enter an appropriate name for the policy, and set the status. 
b.In the Conditions section, check the Compound Condition check box. 
c.Select Internal users from the dictionary drop-down list. 
d.Select the UserIsInManagementHierarchy attribute from the available attribute list. 
e.Select Static value and enter Tr u e  as a condition for the rule to be matched. 
f.Click Add to add this compound condition to the policy. 
g.Choose the policy result for the rule and click OK. 
						

							2
Managing Users and Identity Stores
 
Managing Internal Identity Stores
See Configuring a Session Authorization Policy for Network Access, page 30, for more information on creating an 
authorization policy for network access. 
8.After successfully creating the policy, try authenticating the user using the created policy. The user will be authenticated 
only if the hierarchy defined for the user equals or is contained in the AAA clients hierarchy. You can view the logs to analyze 
the authentication results. 
Related Topics
Configuring and Using the HostIsInManagement Hierarchy Attribute, page 28.
Configuring and Using the HostIsInManagement Hierarchy Attribute
To configure and use the HostIsInManagementHierarchy attribute, complete the following steps:
1.Create the ManagementHierarchy and HostIsInManagementHierarchy attributes for internal hosts. See Configuring Internal 
Identity Attributes, page 13. 
2.Create the network device groups for the network devices and AAA clients with the required hierarchies. See Creating, 
Duplicating, and Editing Network Device Groups, page 2.
3.Create network devices and AAA clients and associate them with a network device group. See Creating, Duplicating, and 
Editing Network Devices, page 9.
4.Create internal hosts and configure the ManagementHierarchy attribute. See Creating Internal Users, page 13. 
5.Choose Access Policies > Access Services > Default Network Access > Authorization.
The Authorization page appears.
6.Click Customize, add the compound condition to the policy conditions, and click OK. 
7.Click Create to create a new policy, and do the following: 
a.Enter an appropriate name for the policy, and set the status. 
b.In the Conditions section, check the Compound Condition check box. 
c.Select Internal hosts from the dictionary drop-down list. 
d.Select HostIsInManagementHierarchy attribute from the available attribute list. 
e.Select Static value and enter Tr u e as a condition for the rule to be matched. 
f.Click Add to add this compound condition to the policy. 
g.Choose the policy result for the rule and click OK.
See Configuring a Session Authorization Policy for Network Access, page 30, for more information on creating an 
authorization policy for network access. 
8.After successfully creating the policy, try authenticating the user using the created policy. The user will be authenticated 
only if the hierarchy defined for the user equals or is contained in the AAA clients hierarchy. You can view the logs to analyze 
the authentication results. 
Related Topics
Configuring and Using the UserIsInManagement Hierarchy Attribute, page 27. 
						

							2   
Managing Users and Identity Stores
Managing External Identity Stores
Managing External Identity Stores
ACS 5.7 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.7 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.7 supports and then describes how you can 
configure them.
This section contains the following topics:
LDAP Overview, page 29
Leveraging Cisco NAC Profiler as an External MAB Database, page 44
Microsoft AD, page 50
RSA SecurID Server, page 69
RADIUS Identity Stores, page 75
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.7 integrates with an LDAP external database, which is also called an identity store, by using the LDAP protocol. See 
Creating External LDAP Identity Stores, page 33 for information about configuring an LDAP identity store.
This section contains the following topics:
Directory Service, page 30
Authentication Using LDAP, page 30
Multiple LDAP Instances, page 30
Failover, page 30
LDAP Connection Management, page 31
Authenticating a User Using a Bind Connection, page 31
Group Membership Information Retrieval, page 32
Attributes Retrieval, page 32
Certificate Retrieval, page 33
Creating External LDAP Identity Stores, page 33
Configuring LDAP Groups, page 42 
						

							3
Managing Users and Identity Stores
 
Managing External Identity Stores
Viewing LDAP Attributes, page 42
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.7 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, page 31.
Multiple LDAP Instances
You can create more than one LDAP instance in ACS 5.7. 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.7 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.7 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.