Cisco Acs 5x User Guide

							2-9
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 2      Migrating from ACS 4.x to ACS 5.3
  Common Scenarios in Migration
Step 3Perform bulk import of data into ACS 5.3.
For more information on performing bulk import of ACS objects, see 
http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_system/5.3/sdk/
cli_imp_exp.html#wp1056244.
The data from your other AAA servers is now available in ACS 5.3. 
						

							2-10
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 2      Migrating from ACS 4.x to ACS 5.3
  Common Scenarios in Migration 
						

							CH A P T E R
3-1
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
3
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 3-1
Access Services, page 3-6
Service Selection Policy, page 3-12
Authorization Profiles for Network Access, page 3-16
Policies and Identity Attributes, page 3-17
Policies and Network Device Groups, page 3-18
Example of a Rule-Based Policy, page 3-18
Flows for Configuring Services and Policies, page 3-19
NoteSee Functionality Mapping from ACS 4.x to ACS 5.3, page 2-5 for a mapping of ACS 4.x concepts to 
ACS 5.3.
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 
						

							3-2
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      ACS 5.x Policy Model
  Overview of the ACS 5.x Policy Model
For example, we use the information described for the group-based model:
If identity-condition, restriction-condition then authorization-profile
In ACS 5.3, you define conditions and results as global, shared objects. You define them once and then 
reference them when you create rules. ACS 5.3 uses the term policy elements for these shared objects, 
and they are the building blocks for creating rules.
Ta b l e 3 - 1 shows how the various policy elements define all the information that the old group contained.
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 workflow) 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 3-6.
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 3-5.
For more information about policy model terminology, see Policy Terminology, page 3-3.
Related Topics
Policies and Identity Attributes, page 3-17
Flows for Configuring Services and Policies, page 3-19
Table 3-1 Information in Policy Elements
Information in ACS 4.x Group Information in ACS 5.3 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-3
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      ACS 5.x Policy Model
  Overview of the ACS 5.x Policy Model
Policy Terminology
Ta b l e 3 - 2 describes the rule-based policy terminology.
Table 3-2  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.3 policy for choosing how to authenticate and acquire identity attributes for a given request. 
ACS 5.3 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.3 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.3 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.  
						

							3-4
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 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. 
Ta b l e 3 - 3 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 3-5
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 users 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.3. 
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. 
						

							3-5
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      ACS 5.x Policy Model
  Overview of the ACS 5.x Policy Model
Types of Policies
Ta b l e 3 - 3 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.
Ta b l e 3 - 3 A C S  P o l i c y  Ty p e s
PolicyCan Contain 
Exception 
Policy?Simple
1 and 
Rule-Based?
1. A simple policy specifies a single set of results that ACS applies to all requests; it is in effect a one-rule policy.
Available 
Dictionaries for 
ConditionsAvailable Result 
Types Attributes 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— 
						

							3-6
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      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 users ACS identity group should be dynamically 
established based on user attributes or group membership in external identity stores. The users 
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
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. Ta b l e 3 - 4 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. 
NoteAccess 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 3-4 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 Optional
1Required 
						

							3-7
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      ACS 5.x Policy Model
  Access Services
Ta b l e 3 - 5 describes an example of a set of access services.
Ta b l e 3 - 6 describes a service selection policy.
If ACS 5.3 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.
If ACS 5.3 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 10-19, for a list of the access service templates and descriptions.
RADIUS and TACACS+ Proxy Services
ACS 5.3 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.
Table 3-5 Access Service List
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 3-6 Service Selection Policy
Rule Name Condition Result
DevAdmin protocol = TACACS+ Access Service A
Agentless Host Lookup = True Access Service C
Default  — Access Service B 
						

							3-8
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      ACS 5.x Policy Model
  Access Services
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. 
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.
Ta b l e 3 - 7 lists the differences in RADIUS proxy service between ACS 4.2 and 5.3 releases.
Table 3-7 Differences in RADIUS and TACACS+ Proxy Service Between ACS 4.2 and 5.3
Feature ACS 5.3 ACS 4.2
Configurable timeout (RADIUS) Yes No
Configurable retry count (RADIUS) Yes No
Network timeout (TACACS+) Yes No
Authentication and accounting ports 
(RADIUS)Ye s Ye s
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