Cisco Acs 5x User Guide

							3-19
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      ACS 5.x Policy Model
  Flows for Configuring Services and Policies
Figure 3-2 illustrates what this policy rule table could look like.
Figure 3-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 3-3
Types of Policies, page 3-5
Access Services, page 3-6
Flows for Configuring Services and Policies, page 3-19
Flows for Configuring Services and Policies
Ta b l e 3 - 8 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 7-2 and Network Devices and AAA Clients, page 7-5. 
						

							3-20
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      ACS 5.x Policy Model
  Flows for Configuring Services and Policies
Added users to the internal ACS identity store or add external identity stores. See Creating Internal 
Users, page 8-11, Managing Identity Attributes, page 8-7, or Creating External LDAP Identity 
Stores, page 8-26.
Table 3-8 Steps to Configure Services and Policies
Step Action Drawer in Web Interface
Step 1Define 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 9-23
Creating, Duplicating, and Editing Command Sets for Device 
Administration, page 9-28
Creating, Duplicating, and Editing Authorization Profiles for Network 
Access, page 9-18Policy Elements
Step 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 9-5.—
Step 3Create 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 10-12.Access Policies
Step 4Add rules to Service Selection Policy to determine which access service to 
use for requests. See: 
Customizing a Policy, page 10-4
Creating, Duplicating, and Editing Service Selection Rules, page 10-8Access Policies
Step 5Define 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.Users and Identity Stores
Step 6Create authorization rules:
Device administration—Shell/command authorization policy.
Network access—Session authorization policy.
See: 
Customizing a Policy, page 10-4
Configuring Access Service Policies, page 10-21Access Policies 
						

							3-21
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      ACS 5.x Policy Model
  Flows for Configuring Services and Policies
Related Topics
Policy Terminology, page 3-3
Policy Conditions, page 3-16
Policy Results, page 3-16
Policies and Identity Attributes, page 3-17 
						

							3-22
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 3      ACS 5.x Policy Model
  Flows for Configuring Services and Policies 
						

							CH A P T E R
4-1
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
4
Common Scenarios Using ACS
Network control refers to the process of controlling access to a network. Traditionally a username and 
password was used to authenticate a user to a network. Now a days with the rapid technological 
advancements, the traditional method of managing network access with a username and a password is 
no longer sufficient. 
The ways in which the users can access the network and what they can access have changed considerably. 
Hence, you must define complex and dynamic policies to control access to your network.
For example, earlier, a user was granted access to a network and authorized to perform certain actions 
based on the group that the user belonged to. Now, in addition to the group that the user belongs to, you 
must also consider other factors, such as whether:
The user is trying to gain access within or outside of work hours.
The user is attempting to gain access remotely.
The user has full or restricted access to the services and resources.
Apart from users, you also have devices that attempt to connect to your network.
When users and devices try to connect to your network through network access servers, such as wireless 
access points, 802.1x switches, and VPN servers, ACS authenticates and authorizes the request before a 
connection is established.
Authentication is the process of verifying the identity of the user or device that attempts to connect to a 
network. ACS receives identity proof from the user or device in the form of credentials. There are two 
different authentication methods:
Password-based authentication—A simpler and easier way of authenticating users. The user enters 
a username and password. The server checks for the username and password in its internal or 
external databases and if found, grants access to the user. The level of access (authorization) is 
defined by the rules and conditions that you have created.
Certificate-based authentication—ACS supports certificate-based authentication with the use of the 
Extensible Authentication Protocol-Transport Level Security (EAP-TLS), which uses certificates 
for server authentication by the client and for client authentication by the server. 
Certificate-based authentication methods provide stronger security and are recommended when 
compared to password-based authentication methods.
Authorization determines the level of access that is granted to the user or device. The rule-based policy 
model in ACS 5.x allows you to define complex conditions in rules. ACS uses a set of rules (policy) to 
evaluate an access request and to return a decision. 
ACS organizes a sequence of independent policies into an access service, which is used 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. 
						

							4-2
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Overview of Device Administration
Cisco Secure Access Control System (ACS) allows you to centrally manage access to your network 
services and resources (including devices, such as IP phones, printers, and so on). ACS 5.3 is a 
policy-based access control system that allows you to create complex policy conditions and helps you to 
comply with the various Governmental regulations.
When you deploy ACS in your network, you must choose an appropriate authentication method that 
determines access to your network.
This chapter provides guidelines for some of the common scenarios. This chapter contains:
Overview of Device Administration, page 4-2
Password-Based Network Access, page 4-5 
Certificate-Based Network Access, page 4-9 
Agentless Network Access, page 4-12
VPN Remote Network Access, page 4-20
ACS and Cisco Security Group Access, page 4-23
RADIUS and TACACS+ Proxy Requests, page 4-29
Overview of Device Administration
Device administration allows ACS to control and audit the administration operations performed on 
network devices, by using these methods:
Session administration—A session authorization request to a network device elicits an ACS 
response. The response includes a token that is interpreted by the network device which limits the 
commands that may be executed for the duration of a session. See Session Administration, page 4-3.
Command authorization—When an administrator issues operational commands on a network 
device, ACS is queried to determine whether the administrator is authorized to issue the command. 
See Command Authorization, page 4-4.
Device administration results can be shell profiles or command sets.
Shell profiles allow a selection of attributes to be returned in the response to the authorization request 
for a session, with privilege level as the most commonly used attribute. Shell profiles contain common 
attributes that are used for shell access sessions and user-defined attributes that are used for other types 
of sessions.
ACS 5.3 allows you to create custom TACACS+ authorization services and attributes. You can define:
Any A-V pairs for these attributes.
The attributes as either optional or mandatory.
Multiple A-V pairs with the same name (multipart attributes).
ACS also supports task-specific predefined shell attributes. Using the TACACS+ shell profile, you can 
specify custom attributes to be returned in the shell authorization response. See TACACS+ Custom 
Services and Attributes, page 4-5.
Command sets define the set of commands, and command arguments, that are permitted or denied. The 
received command, for which authorization is requested, is compared against commands in the available 
command sets that are contained in the authorization results. 
						

							4-3
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Overview of Device Administration
If a command is matched to a command set, the corresponding permit or deny setting for the command 
is retrieved. If multiple results are found in the rules that are matched, they are consolidated and a single 
permit or deny result for the command is returned, as described in these conditions:
If an explicit deny-always setting exists in any command set, the command is denied.
If no explicit deny-always setting exists in a command set, and any command set returns a permit 
result, the command is permitted.
If either of the previous two conditions are not met, the command is denied.
You configure the permit and deny settings in the device administration rule table. You configure policy 
elements within a device administration rule table as conditions that are or not met. The rule table maps 
specific request conditions to device administration results through a matching process. The result of 
rule table processing is a shell profile or a command set, dependent on the type of request.
Session administration requests have a shell profile result, which contains values of attributes that are 
used in session provisioning. Command authorization requests have a command authorization result, 
which contains a list of command sets that are used to validate commands and arguments.
This model allows you to configure the administrator levels to have specific device administration 
capabilities. For example, you can assign a user the Network Device Administrator role which provides 
full access to device administration functions, while a Read Only Admin cannot perform administrative 
functions.
Session Administration
The following steps describe the flow for an administrator to establish a session (the ability to 
communicate) with a network device:
1.An administrator accesses a network device.
2.The network device sends a RADIUS or TACACS+ access request to ACS.
3.ACS uses an identity store (external LDAP, Active Directory, RSA, RADIUS Identity Server, or 
internal ACS identity store) to validate the administrator’s credentials.
4.The RADIUS or TACACS+ response (accept or reject) is sent to the network device. The accept 
response also contains the administrator’s maximum privilege level, which determines the level of 
administrator access for the duration of the session.
To configure a session administration policy (device administration rule table) to permit communication:
Step 1Configure the TACACS+ protocol global settings and user authentication option. See Configuring 
TACACS+ Settings, page 18-1.
Step 2Configure network resources. See Network Devices and AAA Clients, page 7-5.
Step 3Configure the users and identity stores. See Managing Internal Identity Stores, page 8-4 or Managing 
External Identity Stores, page 8-22.
Step 4Configure shell profiles according to your needs. See Creating, Duplicating, and Editing a Shell Profile 
for Device Administration, page 9-23. 
						

							4-4
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Overview of Device Administration
Step 5Configure an access service policy. See Access Service Policy Creation, page 10-4.
Step 6Configure a service selection policy. See Service Selection Policy Creation, page 10-4.
Step 7Configure an authorization policy (rule table). See Configuring a Session Authorization Policy for 
Network Access, page 10-29.
Command Authorization
This topic describes the flow for an administrator to issue a command to a network device.
NoteThe device administration command flow is available for the TACACS+ protocol only.
1.An administrator issues a command to a network device.
2.The network device sends an access request to ACS.
3.ACS optionally uses an identity store (external Lightweight Directory Access Protocol [LDAP], 
Active Directory, RADIUS Identity Server, or internal ACS identity store) to retrieve user attributes 
which are included in policy processing.
4.The response indicates whether the administrator is authorized to issue the command.
To configure a command authorization policy (device administration rule table) to allow an 
administrator to issue commands to a network device:
Step 1Configure the TACACS+ protocol global settings and user authentication option. See Configuring 
TACACS+ Settings, page 18-1.
Step 2Configure network resources. See Network Devices and AAA Clients, page 7-5.
Step 3Configure the users and identity stores. See Managing Internal Identity Stores, page 8-4 or Managing 
External Identity Stores, page 8-22.
Step 4Configure command sets according to your needs. See Creating, Duplicating, and Editing Command 
Sets for Device Administration, page 9-28.
Step 5Configure an access service policy. See Access Service Policy Creation, page 10-4.
Step 6Configure a service selection policy. See Service Selection Policy Creation, page 10-4.
Step 7Configure an authorization policy (rule table). See Configuring Shell/Command Authorization Policies 
for Device Administration, page 10-34.
Related Topics
Network Devices and AAA Clients, page 7-5
Configuring System Administrators and Accounts, page 16-3
Managing Users and Identity Stores, page 8-1
Managing External Identity Stores, page 8-22
Managing Policy Conditions, page 9-1
Managing Access Policies, page 10-1 
						

							4-5
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Password-Based Network Access
TACACS+ Custom Services and Attributes
This topic describes the configuration flow to define TACACS+ custom attributes and services.
Step 1Create a custom TACACS+ condition to move to TACACS+ service on request. To do this:
a.Go to Policy Elements > Session Conditions > Custom and click Create.
b.Create a custom TACACS+ condition. See Creating, Duplicating, and Editing a Custom Session 
Condition, page 9-5.
Step 2Create an access service for Device Administration with the TACACS+ shell profile as the result. See 
Configuring Shell/Command Authorization Policies for Device Administration, page 10-34.
Step 3Create custom TACACS+ attributes. See Creating, Duplicating, and Editing a Shell Profile for Device 
Administration, page 9-23.
Password-Based Network Access
This section contains the following topics:
Overview of Password-Based Network Access, page 4-5
Password-Based Network Access Configuration Flow, page 4-7
For more information about password-based protocols, see Appendix B, “Authentication in ACS 5.3.”
Overview of Password-Based Network Access
The use of a simple, unencrypted username and password is not considered a strong authentication 
mechanism but can be sufficient for low authorization or privilege levels such as Internet access.
Encryption reduces the risk of password capture on the network. Client and server access-control 
protocols, such as RADIUS encrypt passwords to prevent them from being captured within a network. 
However, RADIUS operates only between the AAA client and ACS. Before this point in the 
authentication process, unauthorized persons can obtain clear-text passwords, in these scenarios:
The communication between an end-user client dialing up over a phone line
An ISDN line terminating at a network-access server
Over a Telnet session between an end-user client and the hosting device
ACS supports various authentication methods for authentication against the various identity stores that 
ACS supports. For more information about authentication protocol identity store compatibility, see 
Authentication Protocol and Identity Store Compatibility, page B-35.
Passwords can be processed by using these password-authentication protocols based on the version and 
type of security-control protocol used (for example, RADIUS), and the configuration of the AAA client 
and end-user client.
You can use different levels of security with ACS concurrently, for different requirements. Password 
Authentication Protocol (PAP) provides a basic security level. PAP provides a very basic level of 
security, but is simple and convenient for the client. MSCHAPv2 allows a higher level of security for 
encrypting passwords when communicating from an end-user client to the AAA client.  
						

							4-6
User Guide for Cisco Secure Access Control System 5.3
OL-24201-01
Chapter 4      Common Scenarios Using ACS
  Password-Based Network Access
NoteDuring password-based access (or certificate-based access), the user is not only authenticated but also 
authorized according to the ACS configuration. And if NAS sends accounting requests, the user is also 
accounted.
ACS supports the following password-based authentication methods:
Plain RADIUS password authentication methods
–RADIUS-PAP
–RADIUS-CHAP
–RADIUS-MSCHAPv1
–RADIUS-MSCHAPv2
RADIUS EAP-based password authentication methods
–PEAP-MSCHAPv2
–PEAP-GTC
–EAP-FAST-MSCHAPv2
–EAP-FAST-GTC
–EAP-MD5
–LEAP
You must choose the authentication method based on the following factors:
The network access server—Wireless access points, 802.1X authenticating switches, VPN servers, 
and so on.
The client computer and software—EAP supplicant, VPN client, and so on.
The identity store that is used to authenticate the user—Internal or External (AD, LDAP, RSA token 
server, or RADIUS identity server).
Related Topics
Authentication in ACS 5.3, page B-1
Password-Based Network Access Configuration Flow, page 4-7
Network Devices and AAA Clients, page 7-5
Managing Access Policies, page 10-1