Cisco Acs 57 User Guide

							1
Cisco Systems, Inc.www.cisco.com
 
ACS 5.x Policy Model
ACS 5.x is a policy-based access control system. The term policy model in ACS 5.x refers to the presentation of policy 
elements, objects, and rules to the policy administrator. ACS 5.x uses a rule-based policy model instead of the 
group-based model used in the 4.x versions.
This section contains the following topics:
Overview of the ACS 5.x Policy Model, page 1
Access Services, page 5
Service Selection Policy, page 11
Authorization Profiles for Network Access, page 15
Policies and Identity Attributes, page 16
Policies and Network Device Groups, page 17
Example of a Rule-Based Policy, page 17
Flows for Configuring Services and Policies, page 18
Note: See Functionality Mapping from ACS 4.x to ACS 5.7, page 4 for a mapping of ACS 4.x concepts to ACS 5.7.
Overview of the ACS 5.x Policy Model
The ACS 5.x rule-based policy model provides more powerful and flexible access control than is possible with the older 
group-based approach.
In the older group-based model, a group defines policy because it contains and ties together three types of information:
Identity information—This information can be based on membership in AD or LDAP groups or a static assignment for 
internal ACS users.
Other restrictions or conditions—Time restrictions, device restrictions, and so on.
Permissions—VLANs or Cisco IOS privilege levels.
The ACS 5.x policy model is based on rules of the form:
If condition then result
For example, we use the information described for the group-based model:
If identity-condition, restriction-condition then authorization-profile
In ACS 5.7, you define conditions and results as global, shared objects. You define them once and then reference them 
when you create rules. ACS 5.7 uses the term policy elements for these shared objects, and they are the building blocks 
for creating rules.
Table 2 on page 2 shows how the various policy elements define all the information that the old group contained. 
						

							2
ACS 5.x Policy Model
 
Overview of the ACS 5.x Policy Model
A policy is a set of rules that ACS 5.x uses to evaluate an access request and return a decision. For example, the set of 
rules in an:
Authorization policy return the authorization decision for a given access request. 
Identity policy decide how to authenticate and acquire identity attributes for a given access request. 
ACS 5.x organizes the sequence of independent policies (a policy work flow) into an access service, which it uses to 
process an access request. You can create multiple access services to process different kinds of access requests; for 
example, for device administration or network access. For more information, see Access Services, page 5.
You can define simple policies and rule-based policies. Rule-based policies are complex policies that test various 
conditions. Simple policies apply a single result to all requests without any conditions.
There are various types of policies:
For more information on the different types of policies, see Types of Policies, page 4.
For more information about policy model terminology, see Policy Terminology, page 2.
Related Topics
Policies and Identity Attributes, page 16Policies and Identity Attributes, page 16
Flows for Configuring Services and Policies, page 18
Policy Terminology
Table 3 on page 3 describes the rule-based policy terminology.
Table 2 Information in Policy Elements
Information in ACS 4.x Group Information in ACS 5.7 Policy Element
Identity informationAD group membership and attributes
LDAP group membership and attributes
ACS internal identity groups and attributes
Other policy conditionsTime and date conditions
Custom conditions
Permissions Authorization profiles 
						

							3   
ACS 5.x Policy Model
Overview of the ACS 5.x Policy Model
Simple Policies
You can configure all of your ACS policies as rule-based policies. However, in some cases, you can choose to configure 
a simple policy, which selects a single result to apply to all requests without conditions. 
For example, you can define a rule-based authentication policy with a set of rules for different conditions; or, if you want 
to use the internal database for all authentications, you can define a simple policy. 
Table 3  Rule-Based Policy Terminology
Term Description
Access service Sequential set of policies used to process access requests. ACS 5.x allows you to define multiple 
access services to support multiple, independent, and isolated sets of policies on a single ACS 
system. 
There are two default access services: one for device administration (TACACS+ based access to 
the device shell or CLI) and one for network access (RADIUS-based access to network 
connectivity).
Policy element Global, shared object that defines policy conditions (for example, time and date, or custom 
conditions based on user-selected attributes) and permissions (for example, authorization profiles). 
The policy elements are referenced when you create policy rules.
Authorization  profile Basic permissions container for a RADIUS-based network access service, which is where you define 
all permissions to be granted for a network access request. 
VLANs, ACLs, URL redirects, session timeout or reauthorization timers, or any other RADIUS 
attributes to be returned in a response, are defined in the authorization profile.
Shell profile Basic permissions container for TACACS+ based device administration policy. This is where you 
define permissions to be granted for a shell access request. 
IOS privilege level, session timeout, and so on are defined in the shell profile.
Command set Contains the set of permitted commands for TACACS+ based, per-command authorization.
Policy Set of rules that are used to reach a specific policy decision. For example, how to authenticate and 
what authorization to grant. For any policies that have a default rule, a policy is a first-match rules 
table with a default rule for any request which does not match any user-created rules. 
Identity policy ACS 5.7 policy for choosing how to authenticate and acquire identity attributes for a given request. 
ACS 5.7 allows two types of identity policies: a simple, static policy, or a rules-based policy for more 
complex situations.
Identity group mapping 
policyOptional policy for mapping identity information collected from identity stores (for example, group 
memberships and user attributes) to a single ACS identity group. 
This can help you normalize identity information and map requests to a single identity group, which 
is just a tag or an identity classification. The identity group can be used as a condition in 
authorization policy, if desired. 
Authorization policy ACS 5.7 policy for assigning authorization attributes for access requests. Authorization policy 
selects a single rule and populates the response with the contents of the authorization profiles 
referenced as the result of the rule. 
Exception policy  Special option for authorization policy, which allows you to define separately the set of conditions 
and authorization results for authorization policy exceptions and waivers. If defined, the exception 
policy is checked before the main (standard) authorization policy. 
Default rule Catchall rule in ACS 5.7 policies. You can edit this rule to specify a default result or authorization 
action, and it serves as the policy decision in cases where a given request fails to match the 
conditions specified in any user-created rule.  
						

							4
ACS 5.x Policy Model
 
Overview of the ACS 5.x Policy Model
Table 4 on page 5 helps you determine whether each policy type can be configured as a simple policy. 
If you create and save a simple policy, and then change to a rule-based policy, the simple policy becomes the default 
rule of the rule-based policy. 
If you have saved a rule-based policy and then change to a simple policy, ACS automatically uses the default rule 
as the simple policy. 
Related Topic
Types of Policies, page 4
Rule-Based Policies
Rule-based policies have been introduced to overcome the challenges of identity-based policies. In earlier versions of 
ACS, although membership in a user group gives members access permissions, it also places certain restrictions on 
them. 
When a user requests access, the user's credentials are authenticated using an identity store, and the user is associated 
with the appropriate user group. Because authorization is tied to user group, all members of a user group have the same 
access restrictions and permissions at all times. 
With this type of policy (the simple policy), permissions are granted based on a user’s association with a particular user 
group. This is useful if the user’s identity is the only dominant condition. However, for users who need different 
permissions under different conditions, this policy does not work.
In ACS 5.x, you can create rules based on various conditions apart from identity. The user group no longer contains all 
of the information. 
For example, if you want to grant an employee full access while working on campus, and restricted access while working 
remotely, you can do so using the rule-based policies in ACS 5.7. 
You can base permissions on various conditions besides identity, and permissions are no longer associated with user 
groups. You can use session and environment attributes, such as access location, access type, health of the end station, 
date, time, and so on, to determine the type of access to be granted.
Authorization is now based on a set of rules:
If conditions then apply the respective permissions
With rule-based policies, conditions can consist of any combination of available session attributes, and permissions are 
defined in authorization profiles. You define these authorization profiles to include VLAN, downloadable ACLs, QoS 
settings, and RADIUS attributes.
Types of Policies
Table 4 on page 5 describes the types of policies that you can configure in ACS. 
The policies are listed in the order of their evaluation; any attributes that a policy retrieves can be used in any policy listed 
subsequently. The only exception is the Identity group mapping policy, which uses only attributes from identity stores. 
						

							5   
ACS 5.x Policy Model
Access Services
Access Services
Access services are fundamental constructs in ACS 5.x that allow you to configure access policies for users and devices 
that connect to the network and for network administrators who administer network devices. 
In ACS 5.x, authentication and authorization requests are processed by access services. An access service consists of 
the following elements:
Identity Policy—Specifies how the user should be authenticated and includes the allowed authentication protocols 
and the user repository to use for password validation.
Group Mapping Policy—Specifies if the user's ACS identity group should be dynamically established based on user 
attributes or group membership in external identity stores. The user's identity group can be used as part of their 
authorization.
Authorization Policy—Specifies the authorization rules for the user.
The access service is an independent set of policies used to process an access request.
The ACS administrator might choose to create multiple access services to allow clean separation and isolation for 
processing different kinds of access requests. ACS provides two default access services:
Default Device Admin—Used for TACACS+ based access to device CLI
Default Network Access—Used for RADIUS-based access to network connectivity
Table 4 ACS Policy Types
Policy Can Contain 
Exception 
Policy?Simple1 and 
Rule-Based?Available 
Dictionaries for 
ConditionsAvailable Result 
TypesAttributes Retrieved
Service Selection
Determines the access 
service to apply to an 
incoming request.No Yes All except 
identity store 
relatedAccess Service —
Identity 
Determines the identity 
source for authentication.No Yes All except 
identity store 
relatedIdentity Source, 
Failure optionsIdentity Attributes; 
Identity Group for 
internal ID stores
Identity Group Mapping
Defines mapping attributes 
and groups from external 
identity stores to ACS 
identity groups.No Yes Only identity 
store 
dictionariesIdentity Group Identity Group for 
external ID stores
Network Access 
Authorization
Determines authorization 
and permissions for 
network access.Yes Rule-based 
onlyAll dictionaries Authorization 
Profile, Security 
Group Access—
Device Administration 
Authorization
Determines authorization 
and permissions for device 
administration.Yes Rule-based 
onlyAll dictionaries Shell Profile, 
Command Set—
1. A simple policy specifies a single set of results that ACS applies to all requests; it is in effect a one-rule policy. 
						

							6
ACS 5.x Policy Model
 
Access Services
You can use the access services as is, modify them, or delete them as needed. You can also create additional access 
services.
The TACACS+ protocol separates authentication from authorization; ACS processes TACACS+ authentication and 
authorization requests separately. Table 5 on page 6 describes additional differences between RADIUS and TACACS+ 
access services.
For TACACS+, all policy types are optional; however, you must choose at least one policy type in a service. If you do not 
define an identity policy for TACACS+, ACS returns authentication failed for an authentication request.
Similarly, if you do not define an authorization policy and if ACS receives a session or command authorization request, it 
fails. For both RADIUS and TACACS+ access services, you can modify the service to add policies after creation. 
Note: Access services do not contain the service selection policy. Service selection rules are defined independently.
You can maintain and manage multiple access services; for example, for different use cases, networks, regions, or 
administrative domains. You configure a service selection policy, which is a set of service selection rules to direct each 
new access request to the appropriate access service.
Table 6 on page 6 describes an example of a set of access services.
Table 7 on page 6 describes a service selection policy.
If ACS 5.7 receives a TACACS+ access request, it applies Access Service A, which authenticates the request according 
to Identity Policy A. It then applies authorizations and permissions according to the shell/command authorization policy. 
This service handles all TACACS+ requests.
Table 5 Differences Between RADIUS and TACACS+ Access Services
Policy Type TACACS+ RADIUS
Identity Optional
1
1. For TACACS+, you must select either Identity or Authorization. 
Required
Group Mapping Optional Optional
Authorization Optional1.For TACACS+, you must select either 
Identity or Authorization., page 6Required
Ta b l e 6 A c c e s s  S e r v i c e  L i s t
Access Service A
for Device AdministrationAccess Service B
for Access to 802.1X Agentless HostsAccess Service C
for Access from 802.1X Wired and 
Wireless Devices
Identity Policy A Identity Policy B Identity Policy C
Shell/Command Authorization 
Policy ASession Authorization Policy B Session Authorization Policy C
Table 7 Service Selection Policy
Rule Name Condition Result
DevAdmin protocol = TACACS+ Access Service A
Agentless Host Lookup = True Access Service C
Default  — Access Service B 
						

							7   
ACS 5.x Policy Model
Access Services
If ACS 5.7 receives a RADIUS request that it determines is a host lookup (for example, the RADIUS service-type attribute 
is equal to call-check), it applies Access Service C, which authenticates according to Identity Policy C. It then applies a 
session authorization profile according to Session Authorization Policy C. This service handles all host lookup requests 
(also known as MAC Auth Bypass requests). 
Access Service B handles other RADIUS requests. This access service authenticates according to Identity Policy B and 
applies Session Authorization Policy B. This service handles all RADIUS requests except for host lookups, which are 
handled by the previous rule.
Access Service Templates
ACS contains predefined access services that you can use as a template when creating a new service. When you choose 
an access service template, ACS creates an access service that contains a set of policies, each with a customized set 
of conditions. 
You can change the structure of the access service by adding or removing a policy from the service, and you can change 
the structure of a policy by modifying the set of policy conditions. See Configuring Access Services Templates, page 21, 
for a list of the access service templates and descriptions.
RADIUS and TACACS+ Proxy Services
ACS 5.7 can function as a RADIUS, RADIUS proxy or TACACS+ proxy server. 
As a RADIUS proxy server, ACS receives authentication and accounting requests from the NAS and forwards the 
requests to the external RADIUS server. 
As a TACACS+ proxy server, ACS receives authentication, authorization and accounting requests from the NAS and 
forwards the requests to the external TACACS+ server.
ACS accepts the results of the requests and returns them to the NAS. You must configure the external RADIUS and 
TACACS+ servers in ACS for ACS to forward requests to them. You can define the timeout period and the number of 
connection attempts.
The ACS proxy remote target is a list of remote RADIUS and TACACS+ servers that contain the following parameters:
IP
Authentication port
Accounting port
Shared secret
Reply timeout
Number of retries
Connection port
Network timeout
The following information is available in the proxy service:
Remote RADIUS or TACACS+ servers list
Accounting proxy local/remote/both
Strip username prefix/suffix
When a RADIUS proxy server receives a request, it forwards it to the first remote RADIUS or TACACS+ server in the list. 
If the proxy server does not receive a response within the specified timeout interval and the specified number of retries, 
it forwards the request to the next RADIUS or TACACS+ server in the list.  
						

							8
ACS 5.x Policy Model
 
Access Services
When the first response arrives from any of the remote RADIUS or TACACS+ servers in the list, the proxy service 
processes it. If the response is valid, ACS sends the response back to the NAS.
Table 8 on page 8 lists the differences in RADIUS proxy service between ACS 4.2 and 5.7 releases.
ACS can simultaneously act as a proxy server to multiple external RADIUS and TACACS+ servers. For ACS to act as a 
proxy server, you must configure a RADIUS or TACACS+ proxy service in ACS. See Configuring General Access Service 
Properties, page 13 for information on how to configure a RADIUS proxy service.
For more information on proxying RADIUS and TACACS+ requests, see RADIUS and TACACS+ Proxy Requests, page 26.
Related Topics
Policy Terminology, page 2
Types of Policies, page 4
Flows for Configuring Services and Policies, page 18
Identity Policy
Two primary mechanisms define the mechanism and source used to authenticate requests: 
Password-based—Authentication is performed against databases after the user enters a username and password. 
Hosts can bypass this authentication by specifying a MAC address. However, for identity policy authentication, host 
lookup is also considered to be password-based. 
Certificate-based—A client presents a certificate for authentication of the session. In ACS 5.7, certificate-based 
authentication occurs when the PEAP-TLS or EAP-TLS protocol is selected.
In addition, databases can be used to retrieve attributes for the principal in the request.
The identity source is one result of the identity policy and can be one of the following types:
Deny Access—Access to the user is denied and no authentication is performed. 
Identity Database—Single identity database. When a single identity database is selected as the result of the identity 
policy, either an external database (LDAP or AD) or an internal database (users or hosts) is selected as the result. 
The database selected is used to authenticate the user/host and to retrieve any defined attributes stored for the 
user/host in the database. 
Table 8 Differences in RADIUS and TACACS+ Proxy Service Between ACS 4.2 and 5.7
Feature ACS 5.7 ACS 4.2
Configurable timeout (RADIUS) Yes No
Configurable retry count (RADIUS) Yes No
Network timeout (TACACS+) Yes No
Authentication and accounting ports (RADIUS) Yes Yes
Connection port (TACACS+) Yes No
Proxy cycles detection Yes (For RADIUS only) No
Username stripping Yes Yes
Accounting proxy (local, remote, or both) Yes Yes
Account delay timeout support (RADIUS) No No 
						

							9   
ACS 5.x Policy Model
Access Services
Certificate Authentication Profile—Contains information about the structure and content of the certificate, and 
specifically maps certificate attribute to internal username. For certificate-based authentication, you must select a 
certificate authentication profile.
For certificate based requests, the entity which identifies itself with a certificate holds the private key that correlates 
to the public key stored in the certificate. The certificate authentication profile extends the basic PKI processing by 
defining the following:
—The certificate attribute used to define the username. You can select a subset of the certificate attributes to 
populate the username field for the context of the request. The username is then used to identify the user for 
the remainder of the request, including the identification used in the logs. 
—The LDAP or AD database to use to verify the revocation status of the certificate. When you select an LDAP or 
AD database, the certificate data is retrieved from the LDAP or AD database and compared against the data 
entered by the client in order to provide additional verification of the client certificate.
Identity Sequence—Sequences of the identity databases. The sequence is used for authentication and, if specified, 
an additional sequence is used to retrieve only attributes. You can select multiple identity methods as the result of the 
identity policy. You define the identity methods in an identity sequence object, and the methods included within the 
sequence may be of any type. 
There are two components to an identity sequence: one for authentication, and one for attribute retrieval. The 
administrator can select to perform authentication based on a certificate or an identity database or both. 
—If you choose to perform authentication based on a certificate, ACS selects a single certificate authentication 
profile. 
—If you choose to perform authentication based on an identity database, you must define a list of databases to 
be accessed in sequence until authentication succeeds. When authentication succeeds, any defined attributes 
within the database are retrieved.
In addition, you can define an optional list of databases from which additional attributes are retrieved. These 
additional databases can be accessed irrespective of whether password- or certificate-based authentication was 
used. 
When certificate-based authentication is used, the username field is populated from a certificate attribute and is 
used to retrieve attributes. All databases defined in the list are accessed and, in cases where a matching record for the user is 
found, the corresponding attributes, are retrieved.
A t t r i b u t es  c a n b e re t r i eve d  f o r  a  u s er  even  i f  t h e  u s e r ’s  p a ss wo rd  i s m a r ke d  t h at  i t  n e ed s t o  b e  c h an g e d  o r  i f  t h e  u s e r  
account is disabled. Even when you disable a user’s account, the user’s attributes are still available as a source of 
attributes, but not for authentication. 
Failure Options
If a failure occurs while processing the identity policy, the failure can be one of three main types:
Authentication failed—ACS received an explicit response that the authentication failed. For example, the wrong 
username or password was entered, or the user was disabled. 
User/host not found—No such user/host was found in any of the authentication databases. 
Process failed—There was a failure while accessing the defined databases.
All failures returned from an identity database are placed into one of the types above. For each type of failure, you can 
configure the following options:
Reject—ACS sends a reject reply.
Drop—No reply is returned.  
						

							10
ACS 5.x Policy Model
 
Access Services
Continue—ACS continues processing to the next defined policy in the service.
The Authentication Status system attribute retains the result of the identity policy processing. If you select to continue 
policy processing in the case of a failure, this attribute can be referred to as a condition in subsequent policy processing 
to distinguish cases in which identity policy processing did not succeed.
Because of restrictions on the underlying protocol being used, there are cases in which it is not possible to continue 
processing even if you select the Continue option. This is the case for PEAP, LEAP, and EAP-FAST; even if you select the 
Continue option, the request is rejected.
The following default values are used for the failure options when you create rules:
Authentication failed—The default is reject.
User/host not found—The default is reject.
Process failure—The default is drop.
Group Mapping Policy
The identity group mapping policy is a standard policy. Conditions can be based on attributes or groups retrieved from 
the external attribute stores only, or from certificates, and the result is an identity group within the identity group 
hierarchy.
If the identity policy accesses the internal user or host identity store, then the identity group is set directly from the 
corresponding user or host record. This processing is an implicit part of the group mapping policy. 
Therefore, as part of processing in the group mapping policy, the default rule is only applied if both of the following 
conditions are true:
None of the rules in the group mapping table match.
The identity group is not set from the internal user or host record.
The results of the group mapping policy are stored in the IdentityGroup attribute in the System Dictionary and you can 
include this attribute in policies by selecting the Identity Group condition.
Authorization Policy for Device Administration
Shell profiles determine access to the device CLI; command sets determine TACACS+ per command authorization. The 
authorization policy for a device administration access service can contain a single shell profile and multiple command 
sets.
Processing Rules with Multiple Command Sets
It is important to understand how ACS processes the command in the access request when the authorization policy 
includes rules with multiple command sets. When a rule result contains multiple command sets, and the rule conditions 
match the access request, ACS processes the command in the access request against each command set in the rule:
1.If a command set contains a match for the command and its arguments, and the match has Deny Always, ACS 
designates the command set as Commandset-DenyAlways.
2.If there is no Deny Always for a command match in a command set, ACS checks all the commands in the command 
set sequentially for the first match. 
If the first match has Permit, ACS designates the command set as Commandset-Permit.
If the first match has Deny, ACS designates the command set as Commandset-Deny.
3.After ACS has analyzed all the command sets, it authorizes the command: