Cisco Acs 5x User Guide

							8-19
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing Internal Identity Stores
Policies and Identity Attributes, page 3-17
Configuring an Identity Group for Host Lookup Network Access Requests, page 4-18
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 18-10 
and Creating, Duplicating, and Editing an Internal Host Identity Attribute, page 18-13.
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 18-10 and Creating, Duplicating, and Editing an 
Internal Host Identity Attribute, page 18-13.
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
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.  
						

							8-20
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing Internal Identity Stores
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 UserIsInManagement Hierarchy Attribute
To configure and use UserIsInManagementHierarchy attribute, complete the following steps:
Step 1Create ManagementHierarchy and UserIsInManagementHierarchy attributes for internal users. See 
Configuring Internal Identity Attributes, page 18-11. 
Step 2Create the Network Device Groups for the network devices and AAA clients with the required 
hierarchies. See Creating, Duplicating, and Editing Network Devices, page 7-10.
Step 3Create Network Devices and AAA clients and associate them with a Network Device Group. See 
Creating, Duplicating, and Editing Network Devices, page 7-10.
Step 4Create Internal Users and configure the ManagementHierarchy attribute. See Creating Internal Users, 
page 8-11. 
Step 5Choose Access Policies > Access Services > Default Network Access > Authorization.
The Authorization page appears.
Step 6Click Customize, add the Compound Condition to the policy conditions, and click OK. 
Step 7Click 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 UserIsInManagementHierarchy attribute from the available attribute list. 
e.Select Static value and enter True 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 10-29 for more information 
on creating a authorization policy for network access. 
Step 8After 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 contained in the AAA clients 
hierarchy. You can view the logs to analyze the authentication results.  
						

							8-21
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing Internal Identity Stores
Related Topics
Configuring and Using HostIsInManagement Hierarchy Attributes, page 8-21.
Configuring and Using HostIsInManagement Hierarchy Attributes
To configure and use HostIsInManagementHierarchy attribute, complete the following steps:
Step 1Create ManagementHierarchy and HostIsInManagementHierarchy attributes for internal hosts. See 
Configuring Internal Identity Attributes, page 18-11. 
Step 2Create the Network Device Groups for the network devices and AAA clients with the required 
hierarchies. See Creating, Duplicating, and Editing Network Device Groups, page 7-2.
Step 3Create Network Devices and AAA clients and associate them with a Network Device Group. See 
Creating, Duplicating, and Editing Network Devices, page 7-10.
Step 4Create Internal Hosts and configure the ManagementHierarchy attribute. See Creating Internal Users, 
page 8-11. 
Step 5Choose Access Policies > Access Services > Default Network Access > Authorization.
The Authorization page appears.
Step 6Click Customize, add the Compound Condition to the policy conditions, and click OK. 
Step 7Click 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 True 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 10-29 for more information 
on creating a authorization policy for network access. 
Step 8After 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 contained in the AAA clients 
hierarchy. You can view the logs to analyze the authentication results. 
Related Topics
Configuring and Using UserIsInManagement Hierarchy Attribute, page 8-20. 
						

							8-22
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing External Identity Stores
Managing External Identity Stores
ACS 5.3 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.
NoteACS 5.3 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.3 supports and then 
describes how you can configure them.
This section contains the following topics:
LDAP Overview, page 8-22
Leveraging Cisco NAC Profiler as an External MAB Database, page 8-34
Microsoft AD, page 8-41
RSA SecurID Server, page 8-54
RADIUS Identity Stores, page 8-60
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.3 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 8-26 for information about 
configuring an LDAP identity store.
This section contains the following topics:
Directory Service, page 8-23
Authentication Using LDAP, page 8-23
Multiple LDAP Instances, page 8-23
Failover, page 8-24
LDAP Connection Management, page 8-24
Authenticating a User Using a Bind Connection, page 8-24
Group Membership Information Retrieval, page 8-25
Attributes Retrieval, page 8-25
Certificate Retrieval, page 8-26
Creating External LDAP Identity Stores, page 8-26 
						

							8-23
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing External Identity Stores
Configuring LDAP Groups, page 8-33
Viewing LDAP Attributes, page 8-34
Directory Service
The directory service is a software application, or a set of applications, for storing and organizing 
information about a computer networks 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 entrys 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.3 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 8-24.
Multiple LDAP Instances
You can create more than one LDAP instance in ACS 5.3. 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.3 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. 
						

							8-24
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing External Identity Stores
Failover
ACS 5.3 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.3 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 
users DN and user password in clear text. A user is authenticated when the users 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 
						

							8-25
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing External Identity Stores
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 
						

							8-26
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing External Identity Stores
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
NoteConfiguring 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, page 9-5.
To create, duplicate, or edit an external LDAP identity store:
Step 1Select Users and Identity Stores > External Identity Stores > LDAP.
The LDAP Identity Stores page appears.
Step 2Click 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: “” page 
General tab appears, where idstore is the name of the external identity store that you chose.
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 3Complete the Name and Description fields as required.
Step 4Click Next.  
						

							8-27
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing External Identity Stores
Step 5Continue with Configuring an External LDAP Server Connection, page 8-27.
NoteNAC guest Server can also be used as an External LDAP Server. For procedure to use NAC guest server 
as an External LDAP Server:
http://www.cisco.com/en/US/docs/security/nac/guestserver/configuration_guide/20/
g_sponsor.html#wp1070105.
Related Topic
Deleting External LDAP Identity Stores, page 8-33
Configuring an External LDAP Server Connection 
Use this page to configure an external LDAP identity store.
Step 1Select 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 FirstClick to ensure that the primary LDAP server is accessed first, before the secondary LDAP 
server is accessed. 
Failback to Primary Server 
After  MinutesClick to set the number of minutes that ACS authenticates using the secondary LDAP server 
if the primary server cannot be reached, where  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. 
						

							8-28
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 8      Managing Users and Identity Stores
  Managing External Identity Stores
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  
SecondsEnter 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 
 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.
Table 8-7 LDAP: Server Connection Page (continued)
Option Description