Cisco Acs 57 User Guide

							5   
Managing Users and Identity Stores
Managing External Identity Stores
AD uses the “Maximum password age is N days” rule to detect password expiry. All other rules are used during attempts to 
change a password. 
ACS supports these AD domains:
Windows Server 2003
Windows Server 2003 R2
Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2.
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.
W h i l e  t r y i n g  t o  j o i n  AC S  t o  t h e  A D  d o m a i n ,  A C S  a n d  A D  m u s t  b e  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. 
The NTP process restarts automatically when it is down. You can check the NTP process status in two ways: 
Use the 
sh app status acs command in CLI interface. 
Choose Monitoring and Reports > Reports > ACS Reports > ACS Instance > ACS_Health_Summary in the ACS web 
interface. 
For more information, see CLI Reference Guide for Cisco Secure Access Control System 5.7.
Note: ACS supports two way trust between Active Directory domains completely.
The ACS appliance uses different levels of caching for AD groups, to optimize performance. AD groups are identified with a 
unique identifier, the Security Identifier (SID). ACS retrieves the SID that belongs to the user, and uses the cached mapping of 
the SID with the full name and path of the group. The AD client component caches the mapping for 24 hours. The run-time 
component of ACS queries the AD client and caches the results, as long as ACS is running.
ACS 5.7 provides AD client troubleshooting tools to troubleshoot AD connectivity issues. You can use the commands adinfo, 
adcheck, and ldapsearch to troubleshoot AD connectivity issues. ACS provides these CLI commands with the exact same 
parameters, flags, and conditions that are required for their operation. ACS also redirects the output of these CLI commands to 
ACSADAgent.log. 
For more information on these commands, see CLI Reference Guide for Cisco Secure Access Control System 5.7. 
Note: To prevent ACS from using the outdated mappings, you should create new AD groups instead of changing or moving the 
existing ones. If you change or move the existing groups, you have to wait for 24 hours and restart the ACS services to refresh 
all the cached data. 
ACS 5.7 supports certificate authorization. 
						

							5
Managing Users and Identity Stores
 
Managing External Identity Stores
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: 
Note: Dial-in users are not supported by AD in ACS.
This section contains the following topics:
Machine Authentication, page 52
Attribute Retrieval for Authorization, page 53
Group Retrieval for Authorization, page 57
Certificate Retrieval for EAP-TLS Authentication, page 57
Concurrent Connection Management, page 57
User and Machine Account Restrictions, page 57
Machine Access Restrictions, page 57
Dial-In Permissions, page 60
Callback Options for Dial-In users, page 60
Joining ACS to an AD Domain, page 62
Selecting an AD Group, page 65
Configuring AD Attributes, page 66
Configuring Machine Access Restrictions, page 68
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.
Note: When you perform Machine Authentication using EAP-TLS protocol, you should enable the “Perform Binary Certificate 
Comparison with Certificate retrieved from LDAP or Active Directory” option and select the appropriate LDAP or Active Directory 
in the Certificate Authentication Profile > CN User Name > Edit Page. Protocol Port number
LDAP  389/(tcp/udp)
SMB  445/tcp
KDC  88/(tcp/udp)
Global catalog   3268/tcp
KPASS  464/tcp
NTP  123/udp
DNS  53/(tcp/udp) 
						

							5   
Managing Users and Identity Stores
Managing External Identity Stores
Attribute Retrieval for Authorization
You can configure ACS to retrieve Active Directory user or machine 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 the user and Active Directory machine attributes after a successful user or machine authentication; ACS can also 
retrieve the attributes for authorization and group-mapping purposes independent of authentication.
msRADIUSFramedIPAddress Attribute
In ACS, you can configure the Framed-IP-Address attribute as a dynamic value so that it takes the value dynamically from the 
AD attribute, msRADIUSFramedIPAddress during authentication. You can use the msRADIUSFramedIPAddress attribute that is 
retrieved from AD only as the IP address in ACS. You cannot convert this attribute type to string, integer, Boolean, and so on. 
In AD, for every dial-in user, the AD administrator assigns a static IP address. When a dial-in user tries to connect to a network, 
the request is routed to ACS. ACS processes that request, authenticates the user against AD, and assigns the static IP address 
that is retrieved from AD to the dial-up client that is trying to connect to the network. In ACS 5.7, the msRADIUSFramedIPAdress 
attribute is of type IP Address. 
You must configure the msRADIUSFramedIPAddress attribute in the Directory Attributes tab of Active Directory configuration in 
ACS and also use this attribute in the network access authorization profile for ACS to assign this value to the dial-up client. For 
more information on the network access authorization profile, see Authorization Profiles for Network Access, page 15.
Boolean Attribute Support in Active Directory or LDAP
ACS 5.7 allows you to configure Boolean attributes in AD or the LDAP Directory Attributes page and retrieves Boolean attributes 
from AD or LDAP during authentication against an AD or LDAP identity store. ACS retrieves the attributes specific to a user who 
is trying to authenticate against an AD or LDAP identity store. 
ACS supports the following values for Boolean attributes:
True—t, T, true, TRUE, True, and 1.
False—f, F, false, FALSE, False, and 0.
You can configure Boolean attributes in AD or the LDAP Directory Attributes page and use them in authorization profiles. ACS 
does not recognize the Boolean attribute if you configure a value other than the supported values listed above.
You can configure the Boolean attribute of AD or LDAP as a string. ACS converts the Boolean value of the specific attribute 
to a string value while retrieving it from AD or LDAP.
For example, consider the Boolean attribute msTSAllowLogon.
In AD or LDAP, the attribute msTSAllowLogon is a Boolean attribute. In ACS, you can configure the msTSAllowLogon 
attribute as string.
If the value of a Boolean attribute in AD or LDAP is 0 or 1, you can convert that attribute to an integer.
The Boolean attribute in AD or LDAP can be retrieved only as an attribute of type Boolean in ACS. 
You can also configure a string or an integer type AD or LDAP attribute as a Boolean attribute in ACS.
For example, consider the attribute displayName.
In AD or LDAP, the attribute displayName is a string or integer type attribute. In ACS, you can configure displayName as 
Boolean only when the value for the displayName attribute is one of the supported Boolean values listed above.
Note: ACS does not support attribute substitution for Boolean attributes in RADIUS and TACACS+ authentications. 
						

							5
Managing Users and Identity Stores
 
Managing External Identity Stores
Multi-Value Attribute Support in AD or LDAP
ACS 5.7 allows you to configure multi-value attributes in AD or the LDAP Directory Attributes page and retrieves multi-value 
attributes from AD or LDAP during authentication against an AD or LDAP identity store. ACS retrieves the attributes specific to 
a user who is trying to authenticate against an AD or LDAP identity store. 
ACS supports the following AD or LDAP attribute types for multi-value attributes:
String 
Integer
IP Address
After you configure these multi-value attributes, you can use them in authorization profiles.
You can construct the following forms of conditions in access policies involving multiple value attributes:
[Multiple value attribute] [operator] [Multiple value attribute]
[Single value attribute] [operator] [Multiple value attribute]
[Multiple value attribute] [operator] [Single value attribute]
[Multiple value attribute] [operator] [Static value]
Operators for String-Type Multi-Value Attributes
ACS supports the following operators for String-type multi-value attributes:
Equals
Not Equals
Starts with
Ends with 
Contains
Not contains
Table 47 on page 55 displays the results of the conditions when you use the above operators among the multi-value, single 
value, and static value attribute operands. 
						

							5   
Managing Users and Identity Stores
Managing External Identity Stores
Examples
Left attribute value = 11 Equals Right attribute value = {22,11,33}
Result = True
Left attribute value = 11 Equals Right attribute value = {22,44}
Result =False
Left attribute value = 11 Not Equals Right attribute value = {22,33,44}
Result = True
Left attribute value = 11 Not Contains Right attribute value = {22,11,33}
Result = False
Left attribute value = 123 Contains Right attribute value = {12,23}
Result = True
Operators for Integer-Type Multi-Value Attributes
ACS supports the following operators for Integer-type multi-value attributes:
= 
!= 
>
>=
<

						

							5
Managing Users and Identity Stores
 
Managing External Identity Stores
Table 48 on page 56 displays the results of the conditions when you use the above operators among the multi-value, single 
value, and static value attribute operands. 
Examples
Left attribute value = {11,22,33} = Right attribute value = 11
Result = True
Left attribute value = {11,22,33} != Right attribute value = 11
Result = False
Left attribute value = {11,22,33} > Right attribute value = 11
Result = True
Left attribute value = {11,22,33} < Right attribute value = 11
Result = False
Operators for IP-Address-Type Multi-Value Attributes
ACS supports the following operators for IP-Address type multi-value attributes:
Equals
Not Equals
Table 49 on page 57 displays the results of the conditions when you use the above operators among the multi-value, single 
value, and static value attribute operands. 
Table 48 Results of the Operators Used Between the Integer-Type Multi-Value Attributes
Left 
OperandRight 
Operand= != > >= < 
						

							5   
Managing Users and Identity Stores
Managing External Identity Stores
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 authorization and group mapping tables and introduce special conditions to match them against the retrieved groups.
Certificate Retrieval for EAP-TLS Authentication
ACS 5.7 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, SSN, SAN-Email, SAN-DNS, or SAN-other name) 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 whether:
The user account disabled
The user locked out
The user’s account has expired
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:
Table 49 Results of the Operators Used Between the IP-Address Type Multi-Value Attributes
Left Operand Right Operand Equals Not Equals
Multi-value attribute Multi-value attribute True if at least one 
value in the left 
operand is equal to 
one value in the right 
operand.True if no value in the left 
operand is equal to any 
value in the right operand.  Single value attribute Multi-value attribute
Multi-value attribute Single value attribute
Multi-value attribute Static value 
						

							5
Managing Users and Identity Stores
 
Managing External Identity Stores
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 enable or disable MAR from 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 when ACS crashes 
unexpectedly. The content is not verified for consistency in case the administrator performs configuration changes that 
may effect machine authentication. 
When the 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 i t 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:
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. AD Group Machine Authentication 
Required…ATZ profile
Engineers Yes … VLAN X
Managers No … VLAN B
… … … DENY ACCESS 
						

							5   
Managing Users and Identity Stores
Managing External Identity Stores
Distributed MAR Cache
ACS 5.7 supports the Machine Access Restriction cache per ACS deployment. That is, machine authentication results can be 
cached among the nodes within a deployment. 
MAR Cache Distribution Groups
ACS 5.7 has the option to group ACS nodes in MAR cache distribution group s. This opti on i s u sed to cont rol  the impact of MAR 
cache distribution operations on ACS performance and memory usage. 
A text label is assigned to each ACS node, which is called the MAR cache distribution group value. ACS nodes are grouped 
based on the MAR cache distribution group value. You can perform MAR cache distribution operations only between the ACS 
nodes that are assigned to the same MAR cache distribution group. 
If the group value of an ACS node is empty, then it is considered as not assigned to any MAR cache distribution group. Such 
ACS nodes are not part of any MAR cache distribution operations. 
Distributed MAR Cache Operation
The ACS runtime component combines two operations to implement a distributed MAR cache:
MAR cache replication with no guaranteed delivery
MAR cache distributed search
MAR Cache Replication
The ACS runtime component stores a MAR entry, 
authenticated Calling-Station-ID, in a MAR cache during machine 
authentication. Initially, ACS saves the MAR entry in the local MAR cache. Then, the ACS runtime component replicates the MAR 
entry to the ACS nodes that belong to the same MAR cache distribution group. 
The replication is performed based on the cache entry replication attempts and the cache entry replication time-outs that are 
configured in the ACS web interface.
The replication operation is performed in the background and does not interrupt or delay the user authentication that triggered 
this replication. 
MAR Cache Distributed Search
When an authentication request comes in, ACS searches for the MAR entry in the local MAR cache. If a MAR entry is not found 
in the local MAR cache, then ACS queries the ACS nodes that are assigned to the same MAR cache distribution group. 
The distributed search is performed based on the cache entry query attempts and cache entry query time-outs that are 
configured in the ACS web interface. The MAR entry search is also delayed until the first successful response from any of the 
queried ACS nodes, up to the maximum of the configured cache entry query timeout period. You can see any of the following 
messages in ACS View for an authentication that involves querying the MAR Cache: 
24422 - ACS has confirmed previous successful machine authentication for user in Active Directory.
24423 - ACS has not been able to confirm previous successful machine authentication for user in Active Directory.
24701 - ACS peer has confirmed previous successful machine authentication for user in Active Directory.
24702 - ACS peers have not confirmed previous successful machine authentication for user in Active Directory. 
Distributed MAR Cache Reliability
The ACS runtime component provides a reliable mechanism to implement the distributed MAR cache operation. 
						

							6
Managing Users and Identity Stores
 
Managing External Identity Stores
The distributed search option provides a fallback facility when the replication messages for some reason are not delivered. In 
this case, you can find the MAR cache entry on the ACS node that performs the machine authentication or on any one of the 
ACS nodes from the same MAR cache distribution group. The distributed search option also provides a fallback facility when 
the ACS node that performs the machine authentication is restarted. In this case, also, you can find the MAR cache entry in any 
one of the ACS nodes from the same MAR cache distribution group. 
Distributed MAR Cache Persistency
ACS 5.7 stores the MAR cache content, calling-station-ID list, and the corresponding time stamps to a file on its local disk when 
you manually stop the ACS run-time services. The other ACS instances in the MAR cache distribution group cannot access the 
MAR cache of an ACS instance when the run-time services of this ACS instance are down. ACS does not store the MAR cache 
entries of an instance when there is an accidental restart of its run-time services.
ACS reads the MAR cache entries from the file on its local disk based on the cache entry time to live when the ACS run-time 
services get restarted. When the run-time services of an ACS instance come up after a restart, ACS compares the current time 
of that instance with the MAR cache entry time. If the difference between the current time and the MAR entry time is greater 
than the MAR cache entry time to live, then ACS does not retrieve that entry from disk. Otherwise, ACS retrieves that MAR cache 
entry and updates its MAR cache entry time to live.
Dial-In Permissions
The dial-in permissions of a user are checked during authentications or queries from Active Directory. The dial-in check is 
supported only for user authentications and not for machines, in the following authentication protocols: 
PA P
MSCHAPv2
EAP-FAST
PEAP
EAP-TLS. 
The following results are possible:
Allow Access
Deny Access
Control Access through Remote Access Policy. This option is only available for Windows 2000 native domain, Windows 
server 2003 domain. 
Control Access through NPS Network Policy. This is the default result. This option is only available for Windows server 2008, 
Windows 2008 R2, and Windows 2012 domains.
Callback Options for Dial-In users
If the callback option is enabled, the server calls the caller back during the connection process. The phone number that is used 
by the server is set either by the caller or the network administrator. 
The possible callback options are:
No callback
Set by Caller (routing and remote access service only). This option can be used to define a series of static IP routes that 
are added to the routing table of the server running the Routing and Remote Access service when a connection is made.
Always callback to (with an option to set a number). This option can be used to assign a specific IP address to a user when 
a connection is made
The callback attributes should be returned on the RADIUS response to the device.