User Guide for the Cisco Secure Access Control System 5.0
ACS 5.0 Policy Model
Downloads: This chapterpdf (PDF - 262.0KB) The complete bookPDF (PDF - 12.93MB) | Feedback

ACS 5.0 Policy Model

Table Of Contents

ACS 5.0 Policy Model

Overview of the ACS 5.0 Policy Model

Rule-Based Policy Terminology

First-Match Rule Tables

Policy Conditions

Policy Results

Identity Source and Failure Options

Group Mapping Policy Results for Identity Groups

External Policy Check Results

Authorization Profiles for Network Access

Processing Rules with Multiple Authorization Profiles

Shell Profiles and Command Sets for Device Administration

Processing Rules with Multiple Command Sets

Exception Authorization Policy Rules

Simple Policies

Policies and Identity Attributes

Policies and Network Device Groups

Example of Rule-Based Policy

Access Services

Flows for Configuring Services and Policies

Types of Policies


ACS 5.0 Policy Model


ACS 5.0 is a policy-based access control system. The term policy model in ACS 5.0 refers to the presentation of policy elements, objects, and rules to the policy administrator. ACS 5.0 uses a rule-based policy model instead of the group-based model in previous versions.

This section contains the following topics:

Overview of the ACS 5.0 Policy Model

Rule-Based Policy Terminology

Policies and Identity Attributes

Policies and Network Device Groups

Example of Rule-Based Policy

Access Services

Flows for Configuring Services and Policies

Types of Policies


Note See Functionality Mapping from ACS 4.x to ACS 5.0, page 2-5 for a mapping of ACS 4.x concepts to ACS 5.0.


Overview of the ACS 5.0 Policy Model

The ACS 5.0 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.0 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.0, you define conditions and results as global, shared objects. You define them once and then reference them when you create rules. ACS 5.0 uses the term policy elements for these shared objects, and they are the building blocks for creating rules.

Table 3-1 shows how the various policy elements define all the information that the old group contained.

Table 3-1 Information in Policy Elements 

Information in ACS 4.x Group
Information in ACS 5.0 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


A policy is a set of rules that ACS 5.0 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.0 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.

For more information about policy model terminology, see Rule-Based Policy Terminology.

Related Topics

Policies and Identity Attributes

Flows for Configuring Services and Policies

Rule-Based Policy Terminology

Table 3-2 describes rule-based policy terminology.

Table 3-2 Rule-Based Policy Terminology

Term
Description

Access service

A sequential set of policies used to process access requests. ACS 5.0 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

The 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

The basic "permissions container" for TACACS+ based device administration policy, which 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

A set of rules that are used to reach a specific policy decision (for example, how to authenticate and what authorization to grant). For those 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.0 policy for choosing how to authenticate and acquire identity attributes for a given request. ACS 5.0 allows two types of identity policies: a simple, static policy, or a rules-based policy for more complex situations.

Identity group mapping policy

Optional 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, an identity classification ("everyone like this"). The identity group can be used as a condition in authorization policy, if desired.

External policy check

Optional policy for interacting with external policy systems (such as the Cisco NAC Appliance - Clean Access Manager) to obtain additional attributes needed for authorization policy decisions.

Authorization policy

ACS 5.0 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

A 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

A "catchall" rule in ACS 5.0 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.


First-Match Rule Tables

ACS 5.0 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 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 appears in a cell, it indicates that no operations or comparisons are performed on that attribute.

Figure 3-1 shows a column-based rule table with defined condition types.

Figure 3-1 Example Policy Rule Table

Column
Description

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

A 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

The shell profile is 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.


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 as follows:

1. ACS compares the values of the attributes associated with the current access request with a set of conditions expressed in a rule.

2. If the attribute values do not match the conditions, ACS proceeds to the next rule in the rule table.

3. If the attribute values match the conditions, ACS applies the result that is specified for that rule, and ignores all remaining rules.

4. 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

Rule-Based Policy Terminology

Policy Conditions

Policy Results

Exception Authorization Policy Rules

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

Rule-Based Policy Terminology

Policy Results

Exception Authorization Policy Rules

Policies and Identity Attributes

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 Identity Source and Failure Options.

Identity groups for group mapping. See Group Mapping Policy Results for Identity Groups.

External policy servers for external policy checks. See External Policy Check Results

Authorization Profiles for Network Access.

Shell Profiles and Command Sets for Device Administration.

Security groups and security group access control lists (ACLs) for Cisco TrustSec. See ACS and Cisco TrustSec, page 4-25.

For additional policy results, see Managing Authorizations and Permissions, page 8-6.

Related Topics

Rule-Based Policy Terminology

Policy Conditions

Exception Authorization Policy Rules

Policies and Identity Attributes

Identity Source and Failure Options

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.0, certificate-based authentication occurs when the 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.

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 database to use to verify the revocation status of the certificate. When you select an LDAP database, the certificate data is retrieved from the LDAP 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 attributes only. 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, in which case a single certificate authentication profile is selected, or an identity database, in which case the administrator defines 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.

Attributes can be retrieved for a user even if the user's password is marked that it needs to be changed or if the user 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.

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 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 Results for Identity Groups

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.

External Policy Check Results

The external policy check has two purposes:

Determine whether an external policy check is to be performed.

If an external policy check is to be performed, identify the NAC RADIUS server to be accessed.

Requests sent to the external server include a fixed set of attributes, one of which is the identity group. Interaction with the external server, from the policy perspective, results in the following NAC-related system attributes being populated, which can then be used as conditions in the authorization policy:

NAC RADIUS user name

NAC RADIUS policy status (enumerated value)

NAC RADIUS role (string)

NAC RADIUS user authentication (Boolean)

If there are problems retrieving these attributes from the server, each external policy check contains default values for these parameters. The default values ar e overwritten when actual values are retrieved from the server.

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.

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

Rule-Based Policy Terminology

Shell Profiles and Command Sets for Device Administration

Shell Profiles and Command Sets 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:

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

Rule-Based Policy Terminology

Authorization Profiles for Network Access

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

Rule-Based Policy Terminology

Policy Conditions

Policy Results

Policies and Identity Attributes

Simple Policies

You can configure rule-based policies for all policies in ACS. However, in some policies 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-7 describes whether you can configure a simple policy for each 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

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 7-1

Rule-Based Policy Terminology

Types of Policies

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 7-1

Rule-Based Policy Terminology

Types of Policies

Example of 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.0 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 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

Rule-Based Policy Terminology

Types of Policies

Access Services

Access Services

Flows for Configuring Services and Policies

Access Services

Because it is often necessary to have a sequence of policies (for example, Identity Policy, Authorization Policy), ACS 5.0 collects the sequence of policies (a policy workflow) into an access service. 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. Table 3-3 describes additional differences between RADIUS and TACACS+ access services.

Table 3-3 Differences Between RADIUS and TACACS+ Access Services

Policy Type
TACACS+
RADIUS

Identity

Optional1

Required

Group Mapping

Optional

Optional

External Posture Check

Not Applicable

Optional

Authorization

Optional2

Required

1 For TACACS+, you must select either Identity or Authorization.

2 For TACACS+, you must select either Identity or Authorization.


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, 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 3-4 describes an example of a set of access services.

Table 3-4 Access Service List

Access Service A
for Device Administration
Access Service B
for Access for 802.1X Agentless Hosts
Access Service C
for Access from 802.1X Wired and Wireless Devices

Identity Policy A

Identity Policy B

Identity Policy C

Shell/Command Authorization Policy A

Session Authorization Policy B

Session Authorization Policy C


Table 3-5 describes a service selection policy.

Table 3-5 Service Selection Policy

Rule Name
Condition
Result

DevAdmin

protocol = TACACS+

Access Service A

Agentless

Host Lookup = True

Access Service C

Default

Access Service B


If ACS 5.0 receives a TACACS+ access request, it applies Access Service A, which authenticates the request according to Identity Policy A, and then applies authorizations and permissions according to the shell/command authorization policy. This handles all TACACS+ requests.

If ACS 5.0 receives a RADIUS request that it detects 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, and applies a session authorization profile according to Session Authorization Policy C. This 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 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 9-17, for a list of the access service templates and descriptions.

Related Topics

Rule-Based Policy Terminology

Types of Policies

Flows for Configuring Services and Policies

Flows for Configuring Services and Policies

Table 3-6 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 6-2 and Network Devices and AAA Clients, page 6-4.

Added users to the internal ACS identity store or add external identity stores. See Creating Internal Users, page 7-6, Creating Identity Groups, page 7-2, or Creating External LDAP Identity Stores, page 7-16.

Table 3-6 Steps to Configure Services and Policies 

Step
Action
Drawer in Web Interface

Step 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 8-12

Creating, Duplicating, and Editing Command Sets for Device Administration, page 8-16

Creating, Duplicating, and Editing Authorization Profiles for Network Access, page 8-6

Policy 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 8-4.

Step 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 9-11.

Access Policies

Step 4 

Add rules to Service Selection Policy to determine which access service to use for requests. See:

Customizing a Policy, page 9-4

Creating, Duplicating, and Editing Service Selection Rules, page 9-8

Access Policies

Step 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.

Users and Identity Stores

Step 6 

Create authorization rules:

Device administration—Shell/command authorization policy.

Network access—Session authorization policy.

See:

Customizing a Policy, page 9-4

Configuring Access Service Policies, page 9-20

Access Policies

Related Topics

Rule-Based Policy Terminology

Policy Conditions

Policy Results

Policies and Identity Attributes

Types of Policies

Table 3-7 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.

Table 3-7 ACS Policy Types 

Policy
Can Contain Exception Policy?
Simple 1 and Rule-Based?
Available Dictionaries for Conditions
Available Result Types
Attributes Retrieved
Service Selection

Determines the access service to apply to an incoming request.

No

Yes

All except identity store related

Access Service

Identity

Determines the identity source for authentication.

No

Yes

All except identity store related

Identity Source, Failure options

Identity 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 dictionaries

Identity Group

Identity Group for external ID stores

External Policy Check

Determines whether to perform posture check, and the server that performs the check.

No

Yes

All dictionaries

External Policy Server (NAC RADIUS)

External policy attributes (NAC RADIUS attributes)

Network Access Authorization

Determines authorization and permissions for network access.

Yes

Rule-based only

All dictionaries

Authorization Profile, Security Group for TrustSec

Device Administration Authorization

Determines authorization and permissions for device administration.

Yes

Rule-based only

All 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.