Cisco Acs 57 User Guide

							11   
ACS 5.x Policy Model
Service Selection Policy
a.If ACS designated any command set as Commandset-DenyAlways, ACS denies the command.
b.If there is no Commandset-DenyAlways, ACS permits the command if any command set is Commandset-Permit; 
otherwise, ACS denies the command.
Related Topics
Policy Terminology, page 2
Authorization Profiles for Network Access, page 15
Exception Authorization Policy Rules
A common real-world problem is that, in day-to-day operations, you often need to grant policy waivers or policy 
exceptions. A specific user might need special access for a short period of time; or, a user might require some additional 
user permissions to cover for someone else who is on vacation.
In ACS, you can define an exception policy for an authorization policy. The exception policy contains a separate set of 
rules for policy exception and waivers, which are typically ad hoc and temporary. The exception rules override the rules 
in the main rule table. 
The exception rules can use a different set of conditions and results from those in the main policy. For example, the main 
policy might use Identity Group and Location as its conditions, while its related exception policy might use different 
conditions 
By default, exception policies use a compound condition and a time and date condition. The time and date condition is 
particularly valuable if you want to make sure your exception rules have a definite starting and ending time.
An exception policy takes priority over the main policy. The exception policy does not require its own default rule; if there 
is no match in the exception policy, the main policy applies, which has its own default rule.
You can use an exception to address a temporary change to a standard policy. For example, if an administrator, John, in 
one group is on vacation, and an administrator, Bob, from another group is covering for him, you can create an exception 
rule that will give Bob the same access permissions as John for the vacation period.
Related Topics
Policy Terminology, page 2
Policy Conditions, page 15
Policy Results, page 15
Policies and Identity Attributes, page 16
Service Selection Policy
When ACS receives various access requests, it uses a service selection policy to process the request. ACS provides you 
two modes of service selection:
Simple Service Selection, page 11
Rules-Based Service Selection, page 12
Simple Service Selection
In the simple service selection mode, ACS processes all AAA requests with just one access service and does not actually 
select a service. 
						

							12
ACS 5.x Policy Model
 
Service Selection Policy
Rules-Based Service Selection
In the rules-based service selection mode, ACS decides which access service to use based on various configurable 
options. Some of them are:
AAA Protocol—The protocol used for the request, TACACS+ or RADIUS.
Request Attributes—RADIUS or TACACS+ attributes in the request.
Date and Time—The date and time ACS receives the request.
Network Device Group—The network device group that the AAA client belongs to.
ACS Server—The ACS server that receives this request.
AAA Client—The AAA client that sent the request.
Network condition objects—The network conditions can be based on
—End Station—End stations that initiate and terminate connections.
—Device—The AAA client that processes the request.
—Device Port—In addition to the device, this condition also checks for the port to which the end station is 
associated with.
For more information on policy conditions, see Managing Policy Conditions, page 1.
ACS comes preconfigured with two default access services: Default Device Admin and Default Network Access. The 
rules-based service selection mode is configured to use the AAA protocol as the selection criterion and hence when a 
TACACS+ request comes in, the Default Device Admin service is used and when a RADIUS request comes in, the Default 
Network Access service is used.
Access Services and Service Selection Scenarios
ACS allows an organization to manage its identity and access control requirements for multiple scenarios, such as wired, 
wireless, remote VPN, and device administration. The access services play a major role in supporting these different 
scenarios. 
Access services allow the creation of distinct and separate network access policies to address the unique policy 
requirements of different network access scenarios. With distinct policies for different scenarios, you can better manage 
your organization's network.
For example, the default access services for device administration and network access reflect the typical distinction in 
policy that is required for network administrators accessing network devices and an organization's staff accessing the 
company’s network. 
However, you can create multiple access services to distinguish the different administrative domains. For example, 
wireless access in the Asia Pacific regions can be administered by a different team than the one that manages wireless 
access for European users. This situation calls for the following access services:
APAC-wireless—Access service for wireless users in the Asia Pacific region.
Europe-wireless—Access service for wireless users in the European countries.
You can create additional access services to reduce complexity in policies within a single access service by creating the 
complex policy among multiple access services. For example, if a large organization wishes to deploy 802.1x network 
access, it can have the following access services:
802.1x—For machine, user password, and certificate-based authentication for permanent staff.
Agentless Devices—For devices that do not have an EAP supplicant, such as phones and printers. 
						

							13   
ACS 5.x Policy Model
Service Selection Policy
Guest Access—For users accessing guest wireless networks.
In this example, instead of creating the network access policy for 802.1x, agentless devices, and guest access in one 
access service, the policy is divided into three access services.
First-Match Rule Tables
ACS 5.7 provides policy decisions by using first-match rule tables to evaluate a set of rules. Rule tables contain 
conditions and results. Conditions can be either simple or compound. Simple conditions consist of attribute operator 
value and are either True or False. Compound conditions contain more complex conditions combined with AND or OR 
operators. See Policy Conditions, page 15 for more information.
The administrator selects simple conditions to be included in a policy. The conditions are displayed as columns in a rule 
table where the column headings are the condition name, which is usually the name of the attribute. 
The rules are displayed under the column headings, and each cell indicates the operator and value that are combined 
with the attribute to form the condition. If ANY Figure 1 on page 13 shows a column-based rule table with defined 
condition types.
Figure 1 Example Policy Rule Table 
						

							14
ACS 5.x Policy Model
 
Service Selection Policy
The default rule specifies the policy result that ACS uses when no other rules exist, or when the attribute values in the 
access request do not match any rules.
ACS evaluates a set of rules in the first-match rule table by comparing the values of the attributes associated with the 
current access request with a set of conditions expressed in a rule. 
If the attribute values do not match the conditions, ACS proceeds to the next rule in the rule table. 
If the attribute values match the conditions, ACS applies the result that is specified for that rule, and ignores all 
remaining rules. 
If the attribute values do not match any of the conditions, ACS applies the result that is specified for the policy default 
rule.
Related Topics
Policy Terminology, page 2
Policy Conditions, page 15
Policy Results, page 15
Table 9 Example Policy Rule
ColumnDescription
Status You can define the status of a rule as enabled, disabled, or monitored:
Enabled—ACS evaluates an enabled rule, and when the rule conditions match the access request, 
ACS applies the rule result.
Disabled—The rule appears in the rule table, but ACS skips this rule and does not evaluate it. 
Monitor Only—ACS evaluates a monitored rule. If the rule conditions match the access request, ACS 
creates a log record with information relating to the match.
ACS does not apply the result, and the processing continues to the following rules. Use this status 
during a running-in period for a rule to see whether it is needed.
Name Descriptive name. You can specify any name that describes the rule’s purpose. By default, ACS generates 
rule name strings rule-number.
Conditions
Identity Group In this example, this is matching against one of the internal identity groups.
NDG: Location  Location network device group. The two predefined NDGs are Location and Device Type.
Results 
Shell Profile Used for device administration-type policies and contains permissions for TACACS+ shell access 
request, such as Cisco IOS privilege level.
Hit Counts Displays the number of times a rule matched an incoming request since the last reset of the policy’s hit 
counters. ACS counts hits for any monitored or enabled rule whose conditions all matched an incoming 
request. Hit counts for:
Enabled rules reflect the matches that occur when ACS processes requests.
Monitored rules reflect the counts that would result for these rules if they were enabled when ACS 
processed the requests.
The primary server in an ACS deployment displays the hit counts, which represent the total matches for 
each rule across all servers in the deployment. On a secondary server, all hit counts in policy tables appear 
as zeroes. 
						

							15   
ACS 5.x Policy Model
Authorization Profiles for Network Access
Exception Authorization Policy Rules, page 11
Policy Conditions
You can define simple conditions in rule tables based on attributes in: 
Customizable conditions—You can create custom conditions based on protocol dictionaries and identity dictionaries 
that ACS knows about. You define custom conditions in a policy rule page; you cannot define them as separate 
condition objects.
Standard conditions—You can use standard conditions, which are based on attributes that are always available, such 
as device IP address, protocol, and username-related fields.
Related Topics
Policy Terminology, page 2
Policy Results, page 15
Exception Authorization Policy Rules, page 11
Policies and Identity Attributes, page 16
Policy Results
Policy rules include result information depending on the type of policy. You define policy results as independent shared 
objects; they are not related to user or user group definitions. 
For example, the policy elements that define authorization and permission results for authorization policies include:
Identity source and failure options as results for identity policies. See Authorization Profiles for Network Access, 
page 15.
Identity groups for group mapping. See Group Mapping Policy, page 10.
Authorization Profiles for Network Access, page 15.
Authorization Policy for Device Administration, page 10.
Security groups and security group access control lists (ACLs) for Cisco Security Group Access. See ACS and Cisco 
Security Group Access, page 21.
For additional policy results, see Managing Authorizations and Permissions, page 16.
Related Topics
Policy Terminology, page 2
Policy Conditions, page 15
Exception Authorization Policy Rules, page 11
Policies and Identity Attributes, page 16
Authorization Profiles for Network Access
Authorization profiles define the set of RADIUS attributes that ACS returns to a user after successful authorization. The 
access authorization information includes authorization privileges and permissions, and other information such as 
downloadable ACLs.  
						

							16
ACS 5.x Policy Model
 
Policies and Identity Attributes
You can define multiple authorization profiles as a network access policy result. In this way, you maintain a smaller 
number of authorization profiles, because you can use the authorization profiles in combination as rule results, rather than 
maintaining all the combinations themselves in individual profiles.
Processing Rules with Multiple Authorization Profiles
A session authorization policy can contain rules with multiple authorization profiles. The authorization profile contains 
general information (name and description) and RADIUS attributes only. When you use multiple authorization profiles, 
ACS merges these profiles into a single set of attributes. If a specific attribute appears:
In only one of the resulting authorization profiles, it is included in the authorization result. 
Multiple times in the result profiles, ACS determines the attribute value for the authorization result based on the 
attribute value in the profile that appears first in the result set.
For example, if a VLAN appears in the first profile, that takes precedence over a VLAN that appears in a 2nd or 3rd 
profile in the list.
Note: If you are using multiple authorization profiles, make sure you order them in priority order.
The RADIUS attribute definitions in the protocol dictionary specify whether the attribute can appear only once in the 
response, or multiple times. In either case, ACS takes the values for any attribute from only one profile, irrespective of 
the number of times the values appear in the response. The only exception is the Cisco attribute value (AV) pair, which 
ACS takes from all profiles included in the result.
Related Topics
Policy Terminology, page 2
Authorization Policy for Device Administration, page 10
Policies and Identity Attributes
The identity stores contain identity attributes that you can use as part of policy conditions and in authorization results. 
When you create a policy, you can reference the identity attributes and user attributes. 
This gives you more flexibility in mapping groups directly to permissions in authorization rules. When ACS processes a 
request for a user or host, the identity attributes are retrieved and can then be used in authorization policy conditions. 
For example, if you are using the ACS internal users identity store, you can reference the identity group of the internal 
user or you can reference attributes of the internal user. (Note that ACS allows you to create additional custom attributes 
for the internal identity store records.)
If you are using an external Active Directory (AD), you can reference AD groups directly in authorization rules, and you 
can also reference AD user attributes directly in authorization rules. User attributes might include a user’s department or 
manager attribute.
Related Topics
Managing Users and Identity Stores, page 1
Policy Terminology, page 2
Types of Policies, page 4 
						

							17   
ACS 5.x Policy Model
Policies and Network Device Groups
Policies and Network Device Groups
You can reference Network device groups (NDGs) as policy conditions. When the ACS receives a request for a device, 
the NDGs associated with that device are retrieved and compared against those in the policy table. With this method, 
you can group multiple devices and assign them the same policies. For example, you can group all devices in a specific 
location together and assign to them the same policy.
When ACS receives a request from a network device to access the network, it searches the network device repository 
to find an entry with a matching IP address. When a request arrives from a device that ACS identified using the IP address, 
ACS retrieves all NDGs associated with the device.
Related Topics
Managing Users and Identity Stores, page 1
Policy Terminology, page 2
Types of Policies, page 4
Example of a Rule-Based Policy
The following example illustrates how you can use policy elements to create policy rules. 
A company divides its network into two regions, East and West, with network operations engineers at each site. They 
want to create an access policy that allows engineers:
Full access to the network devices in their region.
Read-only access to devices outside their region. 
You can use the ACS 5.7 policy model to:
Define East and West network device groups, and map network devices to the appropriate group.
Define East and West identity groups, and map users (network engineers) to the appropriate group. 
Define Full Access and Read Only authorization profiles. 
Define Rules that allow each identity group full access or read-only access, depending on the network device group 
location. 
Previously, you had to create two user groups, one for each location of engineers, each with separate definitions for 
permissions, and so on. This definition would not provide the same amount of flexibility and granularity as in the 
rule-based model. 
Figure 2 on page 18 illustrates what this policy rule table could look like. 
						

							18
ACS 5.x Policy Model
 
Flows for Configuring Services and Policies
Figure 2 Sample Rule-Based Policy
Each row in the policy table represents a single rule. 
Each rule, except for the last Default rule, contains two conditions, ID Group and Location, and a result, Authorization 
Profile. ID Group is an identity-based classification and Location is a nonidentity condition. The authorization profiles 
contain permissions for a session.
The ID Group, Location, and Authorization Profile are the policy elements.
Related Topics
Policy Terminology, page 2
Types of Policies, page 4
Access Services, page 5
Flows for Configuring Services and Policies, page 18
Flows for Configuring Services and Policies
Table 10Steps to Configure Services and Policies, page 19 describes the recommended basic flow for configuring 
services and policies; this flow does not include user-defined conditions and attribute configurations. With this flow, you 
can use NDGs, identity groups, and compound conditions in rules.
Prerequisites
Before you configure services and policies, it is assumed you have done the following:
Added network resources to ACS and create network device groups. See Creating, Duplicating, and Editing Network 
Device Groups, page 2 and Network Devices and AAA Clients, page 5.
Added users to the internal ACS identity store or add external identity stores. See Creating Internal Users, page 13, 
Managing Identity Attributes, page 7, or Creating External LDAP Identity Stores, page 33. 
						

							19   
ACS 5.x Policy Model
Flows for Configuring Services and Policies
Related Topics
Policy Terminology, page 2
Policy Conditions, page 15
Policy Results, page 15
Policies and Identity Attributes, page 16
Table 10 Steps to Configure Services and Policies
Step ActionDrawer in Web Interface
1.Define policy results:
Authorizations and permissions for device administration—Shell profiles 
or command sets.
Authorizations and permissions for network access—Authorization profile.
See: 
Creating, Duplicating, and Editing a Shell Profile for Device 
Administration, page 22
Creating, Duplicating, and Editing Command Sets for Device 
Administration, page 27
Creating, Duplicating, and Editing Authorization Profiles for Network 
Access, page 17Policy Elements
2.(Optional) Define custom conditions to policy rules. You can complete this 
step before defining policy rules in Step 6, or you can define custom 
conditions while in the process of creating a rule. SeeCreating, Duplicating, 
and Editing a Custom Session Condition, page 5.—
3.Create Access Services—Define only the structure and allowed protocols; you 
do not need to define the policies yet. See Creating, Duplicating, and Editing 
Access Services, page 11.Access Policies
4.Add rules to Service Selection Policy to determine which access service to 
use for requests. See: 
Customizing a Policy, page 4
Creating, Duplicating, and Editing Service Selection Rules, page 7Access Policies
5.Define identity policy. Select the identity store or sequence you want to use 
to authenticate requests and obtain identity attributes. See Managing Users 
and Identity Stores, page 1.Users and Identity Stores
6.Create authorization rules:
Device administration—Shell/command authorization policy.
Network access—Session authorization policy.
See: 
Customizing a Policy, page 4
Configuring Access Service Policies, page 22Access Policies 
						

							20
ACS 5.x Policy Model
 
Flows for Configuring Services and Policies