Cisco Acs 57 User Guide

							9   
Managing Users and Identity Stores
Configuring Identity Store Sequences
Authentication Sequence
An identity store sequence can contain a definition for certificate-based authentication or password-based authentication or 
both. 
If you select to perform authentication based on a certificate, you specify a single Certificate Authentication Profile, which 
you have already defined in ACS.
If you select to perform authentication based on a password, you can define a list of databases to be accessed in sequence. 
When authentication succeeds, any defined attributes within the database are retrieved. You must have defined the databases 
in ACS.
Attribute Retrieval Sequence
You can optionally define a list of databases from which to retrieve additional attributes. These databases can be accessed 
regardless of whether you use password or certificate-based authentication. When you use certificate-based authentication, 
ACS populates the username field from a certificate attribute and then uses the username to retrieve attributes.
ACS can retrieve attributes for a user, even when:
The user’s password is flagged for a mandatory change.
The user’s account is disabled. 
When you perform password-based authentication, you can define the same identity database in the authentication list and the 
attribute retrieval list. However, if the database is used for authentication, it will not be accessed again as part of the attribute 
retrieval flow.
ACS authenticates a user or host in an identity store only when there is a single match for that user or host. If an external 
database contains multiple instances of the same user, authentication fails. Similarly, ACS retrieves attributes only when a single 
match for the user or host exists; otherwise, ACS skips attribute retrieval from that database.
This section contains the following topics:
Creating, Duplicating, and Editing Identity Store Sequences, page 91
Deleting Identity Store Sequences, page 93
Creating, Duplicating, and Editing Identity Store Sequences
To create, duplicate, or edit an identity store sequence:
1.Choose Users and Identity Stores > Identity Store Sequences.
The Identity Store Sequences page appears.
2.Do one of the following:
Click Create.
Check the check box next to the sequence that you want to duplicate, then click Duplicate. 
Click the sequence name that you want to modify, or check the check box next to the name and click Edit.
The Identity Store Sequence Properties page appears as described in Table 65 on page 92. 
						

							9
Managing Users and Identity Stores
 
Configuring Identity Store Sequences
3.Click Submit.
Table 65 Identity Store Sequence Properties Page
Option Description
General
Name Enter the name of the identity store sequence.
Description Enter a description of the identity store sequence.
Authentication Method List
Certificate Based Check this check box to use the certificate-based authentication method. If you choose this 
option, you must enter the certificate authentication profile. Click Select to choose the profile 
from a list of available profiles.
Password Based Check this check box to use the password-based authentication method. If you choose this 
option, you must choose the set of identity stores that ACS will access one after another until 
a match is found.
If you choose this option, you must select a list of identity stores in the Authentication and 
Attribute Retrieval Search List area for ACS to access the identity stores one after another.
Authentication and Attribute Retrieval Search List
Note: This section appears only when you check the Password Based option.
Available Available set of identity stores to access.
Selected Selected set of identity stores to access in sequence until first authentication succeeds. Use 
the Up and Down arrows at the right of the list to define the order of access.
ACS automatically retrieves attributes from identity stores that you selected for authentication. 
You do not need to select the same identity stores for attribute retrieval.
Additional Attribute Retrieval Search List
Available Available set of additional identity stores for attribute retrieval.
Selected (Optional) The selected set of additional identity stores for attribute retrieval. Use the Up and 
Down arrows at the right of the list to define the order of access.
ACS automatically retrieves attributes from identity stores that you selected for authentication. 
You do not need to select the same identity stores for attribute retrieval.
Internal User/Host 
If internal user/host is not 
found or disabled then exit 
the sequence and treat as 
User Not FoundThis option is applicable for the attribute phase and when the Internal Identity Store is in the 
Attribute retrieval list. 
ACS exists the sequence and treats it as User Not Found if this option is selected and the user 
not found or is disabled.
Advanced Options
Break  sequence If this option is selected and if an authentication attempt against current Identity Store results in 
process error, the flow breaks the Identity Stores sequence. The flow then continues to the 
Fail-Open option configured in the Identity Policy. 
The same applies to attribute retrieval. 
Continue to next identity 
store in the sequenceIf this is checked and if authentication with the current Identity Store results in a process error, 
the flow tries to authenticate it with the next Identity Store in the authentication list. 
The same applies to attribute retrieval phase.  
						

							9   
Managing Users and Identity Stores
Configuring Identity Store Sequences
The Identity Store Sequences page reappears. 
Related Topics
Performing Bulk Operations for Network Resources and Users, page 7
Viewing Identity Policies, page 23
Managing Internal Identity Stores, page 4
Managing External Identity Stores, page 29
Configuring Certificate Authentication Profiles, page 89
Deleting Identity Store Sequences, page 93
Deleting Identity Store Sequences
To delete an identity store sequence:
1.Choose Users and Identity Stores > Identity Store Sequences.
The Identity Store Sequences page appears with a list of your configured identity store sequences.
2.Check one or more check boxes next to the identity store sequences that you want to delete.
3.Click Delete.
The following error message appears:
Are you sure you want to delete the selected item/items?
4.Click OK.
The Identity Store Sequences page appears, without the deleted identity store sequence(s) listed.
Related Topics
Performing Bulk Operations for Network Resources and Users, page 7
Viewing Identity Policies, page 23
Managing Internal Identity Stores, page 4
Managing External Identity Stores, page 29
Configuring Certificate Authentication Profiles, page 89
Creating, Duplicating, and Editing Identity Store Sequences, page 91 
						

							9
Managing Users and Identity Stores
 
Configuring Identity Store Sequences 
						

							1
Cisco Systems, Inc.www.cisco.com
 
Managing Policy Elements
A policy defines the authentication and authorization processing of clients that attempt to access the ACS network. A 
client can be a user, a network device, or a user associated with a network device.
Policies are sets of rules. Rules contain policy elements, which are sets of conditions and results that are organized in 
rule tables. See ACS 5.x Policy Model, page 1 for more information on policy design and how it is implemented in ACS. 
Before you configure your policy rules, you must create the policy elements, which are the conditions and results to use 
in those policies. After you create the policy elements, you can use them in policy rules. See Managing Access Policies, 
page 1 for more information on managing services, policies, and policy rules.
These topics contain.
Managing Policy Conditions, page 1
Managing Authorizations and Permissions, page 16
Creating, Duplicating, and Editing Downloadable ACLs, page 30
Note: When Cisco Security Group Access license is installed, you can also configure Security Groups and Security Group 
Access Control Lists (SGACLs), which you can then use in Security Group Access authorization policies. For information 
about configuring security groups for Security Group Access, see Creating Security Groups, page 23. 
Managing Policy Conditions
You can configure the following items as conditions in a rule table:
Request/Protocol Attributes—ACS retrieves these attributes from the authentication request that the user issues. 
Identity Attributes—These attributes are related to the identity of the user performing a request. These attributes can 
be retrieved from the user definition in the internal identity store or from user definitions that are stored in external 
identity stores, such as LDAP and AD.
Identity Groups—ACS maintains a single identity group hierarchy that is used for all types of users and hosts. Each 
internal user or host definition can include an association to a single identity group within the hierarchy. 
You can map users and hosts to identity groups by using the group mapping policy. You can include identity groups 
in conditions to configure common policy conditions for all users in the group. For more information about creating 
identity groups, see Managing Identity Attributes, page 7.
Network Device Groups (NDGs)—Devices issuing requests are included in one or more of up to 12 device hierarchies. 
You can include hierarchy elements in policy conditions. For more information about creating NDGs, see Network 
Device Groups, page 1.
Date and Time Conditions—You can create named conditions that define specific time intervals across specific days 
of the week. You can also associate expiry dates with date and time conditions.
A date and time condition is a condition that takes the current date and time and effectively returns either true or 
false to indicate whether or not the condition is met. There are two components within the date and time condition: 
						

							2
Managing Policy Elements
 
Managing Policy Conditions
—Enable Duration—You have the option to limit the duration during which the condition is enabled by specifying an 
optional start time, end time, or both. This component allows you to create rules with limited time durations that 
effectively expire.
If the condition is not enabled, then this component of the date and time condition returns false.
—Time Intervals—On the ACS web interface, you see a grid of time that shows the days of the week and the hours 
within each day. Each cell in the grid represents one hour. You can either set or clear the cells.
If the date and time when a request is processed falls at a time when the corresponding time interval is set, then this 
component of the date and time condition returns true.
Both components of the date and time condition are considered while processing a request. The date and time 
condition is evaluated as true only if both components return a true value.
Network Conditions—You can create filters of the following types to restrict access to the network:
—End Station Filters—Based on end stations that initiate and terminate the connection. End stations may be 
identified by IP address, MAC address, calling line identification (CLI), or dialed number identification service 
(DNIS) fields obtained from the request.
—Network Device Filters—Based on the AAA client that processes the request. A network device can be identified 
by its IP address, by the device name that is defined in the network device repository, or by the NDG.
—Device Port Filters—Network device definition might be supplemented by the device port that the end station is 
associated with.
Each network device condition defines a list of objects that can then be included in policy conditions, resulting in a 
set of definitions that are matched against those presented in the request. 
The operator that you use in the condition can be either match, in which case the value presented must match at 
least one entry within the network condition, or no matches, in which case it should not match any entry in the set 
of objects that is present in the filter. 
You can include Protocol and Identity attributes in a condition by defining them in custom conditions or in compound 
conditions.
UserIsInManagementHierarchy—This attribute returns true as a result when the management hierarchy defined for 
the user equals or contained in the network device’s hierarchy. The type of the attribute is Boolean and the default 
value is False. 
You define compound conditions in the policy rule properties page and not as a separate named condition. See 
Configuring Compound Conditions, page 40.
Custom conditions and Date and Time conditions are called session conditions. 
This section contains the following topics: 
Creating, Duplicating, and Editing a Date and Time Condition, page 3
Creating, Duplicating, and Editing a Custom Session Condition, page 5
Deleting a Session Condition, page 6
Managing Network Conditions, page 6
See ACS 5.x Policy Model, page 1 for information about additional conditions that you can use in policy rules, although 
they are not configurable. 
						

							3   
Managing Policy Elements
Managing Policy Conditions
Creating, Duplicating, and Editing a Date and Time Condition
Create date and time conditions to specify time intervals and durations. For example, you can define shifts over a specific 
holiday period. When ACS processes a rule with a date and time condition, the condition is compared to the date and 
time information of the ACS instance that is processing the request. Clients that are associated with this condition are 
subject to it for the duration of their session.
The time on the ACS server is used when making policy decisions. Therefore, ensure that you configure date and time 
conditions that correspond to the time zone in which your ACS server resides. Your time zone may be different from that 
of the ACS server. 
You can duplicate a session condition to create a new session condition that is the same, or similar to, an existing session 
condition. After duplication is complete, you access each session condition (original and duplicated) separately to edit 
or delete them.
To create, duplicate, or edit a date and time condition:
1.Choose Policy Elements > Session Conditions > Date and Time.
The Date and Time Conditions page appears.
2.Do one of the following:
Click Create.
Check the check box the condition you want to duplicate and click Duplicate.
Click the name that you want to modify; or, check the check box the condition that you want to modify and click Edit.
The Date and Time Properties page appears.
3.Enter valid configuration data in the required fields as described in Table 66 on page 3:
Table 66 Date and Time Properties Page
Option Description
General
Name Enter a name for the date and time condition.
Description Enter a description, such as specific days and times of the date and time condition. 
						

							4
Managing Policy Elements
 
Managing Policy Conditions
To add date and time conditions to a policy, you must first customize the rule table. See Customizing a Policy, page 4.
4.Click Submit.
The date and time condition is saved. The Date and Time Conditions page appears with the new date and time 
condition that you created or duplicated. 
Note: ACS has services and resources that are time sensitive. So, it is advised to restart all services after performing 
operations such as changing the clock, time zone, or NTP. If you do not restart after these operations, there are 
possibilities that it may break the functionalities such as AD, database connections, and cryptographic materials. 
Related Topics
Creating, Duplicating, and Editing a Custom Session Condition, page 5
Deleting a Session Condition, page 6 Duration
Start Click one of the following options: 
Start Immediately—Specifies that the rules associated with this condition are valid, starting at the 
current date.
Start On—Specify a start date by clicking the calendar icon the associated field to choose a specific 
start date, at which the condition becomes active (at the beginning of the day, indicated by the time 
00:00:00 on a 24-hour clock).
You can specify time in the hh:mm format.
End Click one of the following options: 
No End Date—Specifies that the rules associated with this date and time condition are always active, 
after the indicated start date.
End By—Specify an end date by clicking the calendar icon the associated field to choose a specific 
end date, at which the date and time condition becomes inactive (at the end of the day, indicated by 
the time 23:59:59 on a 24-hour clock)
You can specify time in the hh:mm format.
Days and Time
Days and Time 
section gridEach square in the Days and Time grid is equal to one hour. Select a grid square to make the 
corresponding time active; rules associated with this condition are valid during this time. 
A green (or darkened) grid square indicates an active hour.
Ensure that you configure date and time conditions that correspond to the time zone in which your ACS 
server resides. Your time zone may be different from that of the ACS server. 
For example, you may receive an error message if you configure a date and time condition that is an hour 
ahead of your current time, but that is already in the past with respect to the time zone of your ACS server.
Select  All Click to set all squares in the grid to the active state. Rules associated with this condition are always valid.
Clear All Click to set all squares in the grid to the inactive state. Rules associated with this condition are always 
invalid.
Undo All Click to remove your latest changes for the active and inactive day and time selections for the date and 
time group.
Table 66 Date and Time Properties Page (continued)
Option Description 
						

							5   
Managing Policy Elements
Managing Policy Conditions
Configuring Access Service Policies, page 22
Creating, Duplicating, and Editing a Custom Session Condition
The protocol and identity dictionaries contain a large number of attributes. To use any of these attributes as a condition 
in a policy rule, you must first create a custom condition for the attribute. In this way, you define a smaller subset of 
attributes to use in policy conditions, and present a smaller focused list from which to choose condition types for rule 
tables. 
You can also include protocol and identity attributes within compound conditions. See Configuring Compound 
Conditions, page 40 for more information on compound conditions.
To create a custom condition, you must select a specific protocol (RADIUS or TACACS+) or identity attribute from one 
of the dictionaries, and name the custom condition. See Configuring Global System Options, page 1 for more information 
on protocol and identity dictionaries.
When you create a custom condition that includes identity or RADIUS attributes, you can also include the definition of the 
attributes. You can thus easily view any existing custom conditions associated with a particular attribute.
To create, duplicate, or edit a custom session condition:
1.Choose Policy Elements > Session Conditions > Custom.
The Custom Conditions page appears.
2.Do one of the following:
Click Create.
Check the check box the condition you want to duplicate and click Duplicate.
Click the name that you want to modify; or, check the check box the condition that you want to modify and click Edit.
The Custom Condition Properties page appears.
3.Enter valid configuration data in the required fields as shown in Table 67 on page 5:
To add custom conditions to a policy, you must first customize the rule table. See Customizing a Policy, page 4.
4.Click Submit.
Table 67 Policy Custom Condition Properties Page
Option Description
General
Name Name of the custom condition.
Description Description of the custom condition.
Condition
Dictionary Choose a specific protocol or identity dictionary from the drop-down list box. 
Attribute Click Select to display the list of external identity store dictionaries based on the selection you made in the 
Dictionary field. Select the attribute that you want to associate with the custom condition, then click OK. If 
you are editing a custom condition that is in use in a policy, you cannot edit the attribute that it references. 
						

							6
Managing Policy Elements
 
Managing Policy Conditions
The new custom session condition is saved. The Custom Condition page appears with the new custom session 
condition. Clients that are associated with this condition are subject to it for the duration of their session.
Related Topics
Creating, Duplicating, and Editing a Date and Time Condition, page 3
Deleting a Session Condition, page 6
Configuring Access Service Policies, page 22
Deleting a Session Condition
To delete a session condition:
1.Choose Policy Elements > Session Conditions > session condition, where session condition is Date and Time or 
Custom.
The Session Condition page appears.
2.Check one or more check boxes the session conditions that you want to delete and click Delete.
The following message appears:
Are you sure you want to delete the selected item/items?
3.Click OK.
The Session Condition page appears without the deleted custom session conditions.
Related Topics
Creating, Duplicating, and Editing a Date and Time Condition, page 3
Creating, Duplicating, and Editing a Custom Session Condition, page 5
Managing Network Conditions
Filters are reusable network conditions that you create for end stations, network devices, and network device ports. 
Filters enable ACS 5.7 to do the following: 
Decide whether or not to grant network access to users and devices. 
Decide on the identity store, service, and so on to be used in policies.
After you create a filter with a name, you can reuse this filter multiple times across various rules and policies by referring 
to its name.
Note: The filters in ACS 5.7 are similar to the NARs in ACS 4.x. In ACS 4.x, the NARs were based on either the user or 
user group. In 5.7, the filters are independent conditions that you can reuse across various rules and policies.
ACS offers three types of filters:
End Station Filter—Filters end stations, such as a laptop or printer that initiates a connection based on the end 
station’s IP address, MAC address, CLID number, or DNIS number.
The end station identifier can be the IP address, MAC address, or any other string that uniquely identifies the end 
station. It is a protocol-agnostic attribute of type string that contains a copy of the end station identifier:
—In a RADIUS request, this identifier is available in Attribute 31 (Calling-Station-Id).