User Guide for Cisco Secure ACS Solution Engine 4.0
Network Access Profiles

Table Of Contents

Network Access Profiles

Overview of NAPs

Profile-based Policies

Configuring Profile-Based Policies

Setting Up a Profile

Defining User Access Requests

NAFs

Protocol Types

Advanced Filtering

About Rules, Rule Elements, and Attributes

Configuring Advanced Filtering

NAP Administrative Tasks

Adding a Profile

Ordering Profiles

Editing a Profile

Cloning a Profile

Deleting a Profile

Processing Unmatched User Requests

NAP Administration Pages

Using Profile Templates

Shared-profile Components

Prerequisites for Using Profile Templates

Selecting a Profile Template

NAC L3 IP

Downloadable ACLs

NAC L2 IP

ACS and AV Pairs

Default ACLs

NAC Layer 2 802.1x

Microsoft IEEE 802.1x

Wireless (NAC L2 802.1x)

Authentication Bypass

NAC Agentless Host

Configuring Policies for Profiles

Configuring Authentication Policies

Populate from Global

Authentication Protocols

MAC-Authentication Bypass

EAP Configuration

EAP-FAST

Posture Validation Settings

Credential Validation Databases

Setting Authentication Policies

Configuring MAC Authentication Bypass

Configuring Posture-Validation Policies

URL Redirect Policy

Import Vendor Attribute-Value Pairs (AVPs)

Setting a Posture-Validation Policy

Deleting a Posture Validation Rule

Audit Server Functionality

System Posture Token Configuration

Mapping an Audit Server to a Profile

Posture Validation for Agentless Hosts

Configuring Fail Open

Runtime Behavior

Configuring Authorization Policies

Authorization Rules

Configuring an Authorization Rule

Configuring a Default Authorization Rule

Ordering the Authorization Rules

Deleting an Authorization Rule

Shared RACs

RAC and Groups

Merging Attributes

Troubleshooting Profiles

Migrating from Groups to RACs

Policy Replication and Backup


Network Access Profiles


The Cisco Secure Access Control Server Release 4.0 Solution Engine, hereafter referred to as ACS, includes Network Access Profile (NAP) support. This chapter describes NAPs and contains the following topics:

Overview of NAPs

Profile-based Policies

Configuring Profile-Based Policies

Setting Up a Profile

NAP Administrative Tasks

Using Profile Templates

Configuring Policies for Profiles

Policy Replication and Backup

Overview of NAPs

A NAP, also known as a profile, is a means to classify access requests for each deployed network service, according to the Authentication, Authorization, and Accounting (AAA) clients' IP addresses, membership in a NDG, protocol types, or other specific Remote Access Dial-In User Service (RADIUS) attribute values sent by the network device through which the user connects.

Typical organizations have various kinds of users who access the network in different ways and for different purposes. Correspondingly, you must apply different security policies to the different use cases. For example, you might have to apply a tighter and more limiting security policy to the wireless access points of your building's lobby area, versus the physically secured production plant. Or, you might have to treat remote access users who use a virtual private network (VPN) differently from users that log in from behind a firewall. Users who connect through certain subnetworks might be authenticated differently from other users. Wireless access is often treated more strictly than wired access, as is any form of remote access (dial, VPN, home wireless).

A profile is essentially a classification of network-access requests for applying a common policy. One example of use of a profile is to aggregate all policies that should be activated for a certain location in the network. The policies will be selected every time an access request is initiated from that network location. Another method is to aggregate all policies that handle the same device type, for example, VPNs or Access Points (APs).

ACS traverses the ordered list of active profiles and maps a RADIUS transaction to a profile by using a first-match strategy on the first access request of the transaction. If no matching profile is found, ACS reverts to the global configuration settings.

You use profiles to classify access requests by defining filters on the access-request payload (the RADIUS attributes that are sent in an access request). Each profile is associated with a set of policies to be applied.

When a packet is received, ACS evaluates the profile filters to classify the packet. When a profile matches, ACS applies the configuration and policies that are associated with the profile during packet processing.

In their simplest form, you use NAPs to identify each of your network services (wireless LAN (WLAN), VPN, dial-up). On a per-service basis you can configure:

Supported authentication protocols (Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), Extensible Authentication Protocol (EAP)).

Databases (ACS, Active Directory (AD), or others).

How each type of service is provisioned (session keys, timeouts, access control lists (ACLs)).

Profile-based Policies

After you set up a profile, you associate a set of rules or policies with it to reflect your organization's security policies. These associations are called profile-based policies. Profile-based policies include rules for authentication, authorization, and posture validation.

By defining profile-based policies, can redirect authentication to different directories (for example, wireless users need to authenticate to AD while the same users who access the network through VPN might need to authenticate to an Rivest, Shamir, and Adelman (RSA) One-Time Password (OTP) directory).

To configure policies for a profile:


Step 1 Use the Authentication link to set policies based on password protocols or identity storage.

Step 2 Use the Posture Validation link to identify the kind of application that you expect to install.

Step 3 Use the Authorization link to design the network result for each combination of user and posture assessment that is used.

ACS associates attributes according to the profile that was requested. The attributes that are returned in an Access-Accept message are a consolidation of attributes that are associated with a profile (such as Tunnel-Type for a VPN profile request) and session-specific attributes that are bound to the end-user (such as Idle-Timeout for example). The profile mapping is independent of the user identity, therefore each user can use multiple profiles, and has only one entry in the validating database.


See Configuring Policies for Profiles, for a description on how to configure profile-based policies in detail.

Configuring Profile-Based Policies

To create profile-based policies:


Step 1 Identify the network services that you want to control by using ACS (for example, VPN, Dial, WLAN, ip-admission).

Step 2 Set up a profile for each network service. Setting up a profile defines how ACS will recognize or identify requests for example, device IP, NDG, NAF, advanced filtering). For more information, see Setting Up a Profile.

Step 3 Define the authentication protocols and external databases that are required for the service. For more information, see Configuring Authentication Policies.

Step 4 Define the posture-validation policies or rules (optional-if network admission control (NAC) is part of the deployment). See Configuring Posture-Validation Policies for more information.

Step 5 Define per-service provisioning components (Shared RADIUS authorization components (RACs) and downloadable access control lists (DACLs)). If required for a given service, create custom RACs and DACLS for those groups of users that require specific settings.

Step 6 Define the authorization mappings from group to RAC and DACL. Also include the system posture token (SPT) if NAC is in use. For more information, see Configuring an Authorization Rule

Step 7 Check the Network Access Restriction (NAR) policies for the selected user group. Accept or reject will be applied, depending on the result of the NAR evaluation. For more information, see Network Access Restrictions, page 5-17.

If access is granted (access-accept) ACS merges between user, user-group RAC and ACLs, and provisions a result to the AAA client. For more information, see Merging Attributes.


Setting Up a Profile

This section describes how to configure network-access profiles. Profiles are associated with RADIUS attributes. Each profile has a unique name and can be active or inactive.

This section describes the following topics:

Defining User Access Requests

NAFs

Protocol Types

Advanced Filtering

Defining User Access Requests

You use the Profile Setup Page to define how ACS classifies access requests. You can use one or all of the following classification methods:

NAFs

Protocol Types

Advanced Filtering

You use these three conditions to determine how ACS classifies an access request and maps it to a profile. The profile is selected when all the selected conditions match. For each condition, the value Any always matches the condition. For example, if you create a NAF for wireless and then select the Aironet Protocol type, only devices with the protocol types in the wireless NAF will be selected for filtering.

You create a profile from scratch, or you can use one of the supplied s to populate some default values. See Using Profile Templates, for more information. The templates that are provided are particularly useful for NAC-enabled networks.

NAFs

NAFs provide a flexible way of applying network-access restrictions, and downloadable ACLs on network device names, NDGs, or their IP addresses. NAFs that are applied by IP address can use IP address ranges and wildcards. NAFs introduce a granular application of NARs and downloadable ACLs, both of which previously supported only the use of the same access restrictions or ACLs to all devices. You can use NAFs to define flexible network device restriction policies, a requirement common in large environments.

NAFs are groupings of AAA client configurations (which might represent multiple network devices), NDGs, or IP addresses of specific AAA client devices. For more information, see About Network Access Filters, page 5-3.

You can use a NAF to group (and name) a disparate set of devices; for example: these devices comprise the abc network service.

You can also use NAFs to differentiate user requests on the same type of device. For example, while you undertake an IOS upgrade of Aironet wireless APs is undertaken (perhaps to enable some new encryption protocol) you might require a separate NAP for upgraded and nonupgraded APs.

Therefore, you can use NAFs with greater flexibility when you define which devices in a given network service or NAP.


Note If you want to aggregate NDGs and use them as a filter to assign users to a profile, you must configure NAFs before you set up a profile.


Protocol Types

You use Protocol Types to classify a user request based on the type of protocol that is used to request access to the network. Protocol Types are a subset of the vendor specific attributes (VSAs) that RADIUS supports.


Note The Terminal Access Controller Access Control System (TACACS+) protocol for NAPs is not supported in ACS Release 4.0.


You can select the AAA client vendor types from the access requests that are allowed. See AAA Client Configuration Options, page 4-8.

Advanced Filtering

You can use Advanced Filtering to create rules based on specific RADIUS attributes and values (including Cisco-AV- pairs). It is based on a Boolean AND expression of RADIUS attributes.

You can enter multiple rule-elements, which are treated as an AND Boolean expression. Operators contains, start with, and regular expression only apply to string-type attribute values.


Note ACS supports Cisco IOS RADIUS AV pairs. Before you select an AV pair, confirm that your AAA client supports it. If you enter an AV pair that the AAA client does not support, the condition will always fail.


Use the Rule Elements Table to specify the rule elements that comprises a rule based on a RADIUS attribute. For more information about rules, see About Rules, Rule Elements, and Attributes, page 14-10.

The components of the Rule Elements Table are:

Attribute—Lists all RADIUS attributes that you can use to specify rules. A number uniquely identifies each RADIUS attribute; for example, 001 is the number for User-Name, except for vendor-specific attributes. Vendor Specific Attributes (VSAs) use the number 026 as an identifier. The format is:

Cisco AV-pair 026 / <vendor type> / <vendor attribute>, for example, 026/009/001 is a Cisco AV-pair attribute.

Operator—Defines the comparison method by which ACS evaluates whether the rule element is true. The operators that are available in the Operator list vary depending on the type of attribute selected from the Attribute list. In addition to common operators, such as the right angle bracket (>), the left angle bracket (<), and the equal sign (=), the Operator list supports a few special operators. For information about special operators, see About Rules, Rule Elements, and Attributes.

Value—Specifies the value to which ACS compares the contents of the attribute.

AV-pair Key—This option is enabled when you select the Cisco AV-pair attribute and ACS compares the contents of the AV-pair key attribute from the access request.

AV-pair Value—This option is enabled when you select the Cisco AV-pair attribute and ACS compares the contents of the AV-pair value attribute from the access request.

Enter button—Adds the rule element that is defined in the Attribute, Operator, and Value options to the Rule Elements Table.

About Rules, Rule Elements, and Attributes

A rule is a set of one or more rule elements. A rule element is a logical statement that contains:

A RADIUS attribute

An operator

A value

ACS uses the operator to compare the contents of an attribute to the value. Each rule element of a rule must be true for the whole rule to be true. In other words, all rule elements of a rule are joined with a Boolean AND.


Note The {026/009/001Cisco AV-pair attribute field is unique. When it is selected, the AV-pair key and an AV-pair value are activated. Enter values for the two fields. For example, AV-pair key is the name of AV-pair attribute (aaa:service) and AV-pair value is the attribute contents to be compared to (for example. ip-admission).


Rule Operators

When you construct a rule in ACS, you can only select an operator that is applicable to the type of attribute that you select.

ACS supports these operators:

= (equal to)—The rule element is true if the value in the attribute is exactly equal to the value that you specify.

!= (not equal to)—Evaluates to FALSE when the input request does not contain an attribute.


Tip Use of the != operator can lead to confusion, especially with Boolean attributes. For example, if a rule element for a Boolean attribute requires that the attribute is not equal to false and the attribute in a specific posture-validation request was 1, ACS would evaluate the rule element to be true. To avoid confusion, you can express the rule element more clearly by requiring that the attribute is equal to true.


> (greater than)—The rule element is true if the value in the attribute is greater than the value that you specify.

< (less than)—The rule element is true if the value in the attribute is less than the value that you specify.

<= (less than or equal to)—The rule element is true if the value in the attribute is less than or equal to the value that you specify.

>= (greater than or equal to)—The rule element is true if the value in the attribute is greater than or equal to the value that you specify.

contains—The rule element is true if a substring of the string type attribute matches the string that you specify. For example, the contains operator and a value of sc would match an attribute that contains the string Cisco, the string scsi, or the string disc.

starts-with—The rule element is true if the beginning of the attribute value matches the string that you specify. For example, the starts-with operator and a value of Ci would match an attribute that contains the string Cisco or the string Ciena.

regular-expression—The rule element is true if the attribute matches the regular expression that you specify. ACS supports the following regular expression operators:

^ (caret)—The ^ operator matches the start of a string. For example ^Ci would match the string Cisco or the string Ciena but not docile.

$ (dollar)—The $ operator matches the end of a string. For example, co$ would match the string Cisco or the string Tibco but not the string console.

Configuring Advanced Filtering

To configure advanced filtering:


Step 1 Select an Attribute from the drop-down list.

Step 2 Select an Operator from the drop-down list.

Step 3 Select an Entity from the drop-down list (optional for Linux packages).

Step 4 Enter a Value for the Attribute.

Step 5 Click Enter.


Note The Rule Elements Table is populated with conditions when you select a profile template. See Using Profile Templates.



NAP Administrative Tasks

This section describes the following tasks:

Adding a Profile

Ordering Profiles

Editing a Profile

Cloning a Profile

Deleting a Profile

Processing Unmatched User Requests

NAP Administration Pages

Adding a Profile

On the Profile Setup page, you can configure:

Name of the profile

Description

Activation flag (determines whether this profile is active or inactive)

Clone an existing profile

The Network Access Profiles Page page is initially empty. Once populated, you must set the list of profiles into an order with a priority sequence from top to bottom.

Use the Profile Setup Page to configure the profile name, description, add the classification, and all other parameters that are required to set up the profile.

To add a profile:


Step 1 In the navigation bar, click Network Access Profiles.

The Network Access Profiles Page appears.

Step 2 Click Add Profile.

The Profile Setup Page appears.

Step 3 In the Name box, type the name of the new profile.

Step 4 In the Description box, type a description of the new profile.

Step 5 To enable the profile, check the Active check box.

Step 6 Set the configuration parameters for the profile:

a. Classify (filter), a user request by choosing a NAF from the list of existing NAFs. Configure NAF objects in Shared Profile Components. See About Network Access Filters, page 5-3.

b. Use Protocol Types to choose one or more protocol types as a filter. The Protocol Types are a subset of the VSAs that NAS supports. See AAA Client Configuration Options, page 4-8

c. Choose Advance Filtering to create a specific rule that contains one or more RADIUS attributes and values. See Configuring Advanced Filtering

Step 7 Click Submit.

The Network Access Profiles Page appears. The Network Access Profile's first match is implemented to authenticate or authorize a client request, or both.

Step 8 Click the radio buttons to change the order of the profiles. Click the Up or Down to move the profile to the correct position.


Note You also click the Up and Down buttons to submit the information to ACS.


Step 9 Select Deny access when no profile selected, when no profile matches the request. The default selection, Grant access using global configuration, when no profile matches, reverts to the global ACS configuration settings of authorizing by user-groups.

Step 10 Click Apply and Restart for your changes to take effect.


Ordering Profiles

Since ACS applies a first-match principle when trying to match an access request with a profile, the order of the profiles in the list is significant.

To set the order of the profile:


Step 1 In the Network Access Profiles Page, click the radio buttons to select a profile.

Step 2 Click the Up or Down to move the profile to the position you want.


Note Click Apply and Restart for your changes to take effect.



Editing a Profile

To edit the profile configuration:


Step 1 In the navigation bar, click Network Access Profiles.

The Network Access Profiles Page appears.

Step 2 Click the Name to modify the filtering methods for the profile.

The Profile Setup Page appears,

or

Select the configuration policy to edit. The relevant policy configuration page appears.

Step 3 To save your profile configuration settings, return to the Network Access Profiles Page and click Apply and Restart.


Cloning a Profile

Cloning replicates all the following relevant components for a NAP:

Authentication references—External databases.

Posture references—Internal or external posture validation, and external audit server. For more information about posture references, see Setting Up Posture Validation Policies, page 14-18.

Authorization references—RACs and DACLs.

Cloning a NAP does not copy the shared-profile components, or the internal and external posture-validation policies, that the profile references. The newly cloned profile references the same shared-profile components as the original profile. For example, components that are referenced by name (RACs, DACLs, NAFs) remain the same.

When you clone a NAP, it is initially inactive by default. This inactive state avoids ambiguity when ACS tries to match an access request to a profile. After you modify the cloned profile, you can change the status to the active state.

The Profile description, Active Flag, Protocol Selection, Advanced Filter, Authentication, and Authorization policies are all cloned (copied). Posture-validation policies (Internal/External/Audit Servers) are not copied, but are referenced by the newly created Profile.

The naming pattern for cloning is Copy-of-. For multiple cloning (cloning the cloned element) the prefix Copy-(2)-of- is given.

If the new name length exceeds 32 characters, it is truncated to 32 characters.

To clone a profile:


Step 1 In the navigation bar, click Network Access Profiles.

The Network Access Profiles Page appears.

Step 2 Click the Name.

The Profile Setup Page appears.

Step 3 Click Clone.

Step 4 A copy of the cloned profile appears in the Network Access Profiles Page.

Step 5 Modify the cloned profile.

Step 6 Click Apply and Restart for your changes to take effect.


Deleting a Profile

To delete a profile:


Step 1 In the navigation bar, click Network Access Profiles.

The Network Access Profiles Page appears.

Step 2 Click the Name.

The Profile Setup Page appears.

Step 3 Click Delete.

Step 4 A warning message appears.

Step 5 Click OK to delete the profile configuration.

Step 6 Click Apply and Restart for your changes to take effect.


Processing Unmatched User Requests

ACS global configuration settings serve two purposes:

Defining the fallback behavior for a request that does not match a profile.

Defining the baseline for NAPs (if you want to enable a protocol in the NAP authentication page, you must first enable it in the Global Authentication Settings page).

Although legacy global settings and NAPs are supported and are interoperable, we do not recommend both of them, except for the case that is described in this section.

We recommend that you use the Deny access when no profile selected option whenever the access request cannot be classified it is rejected.

We recommend that you use to use Grant access using global configuration when no profile matches, since ACS will revert to the configuration settings in the Global Authentication Page. The Unknown User policy determine how to proceed with the packet processing.

The only case where ACS fallback behavior and NAPs should be used is with TACACS+. NAPs does not currently support TACACS+. Using Grant access using global configuration option is the only way to use TACACS+ and NAP configuration with RADIUS.

When you use both, you must ensure that the fallback behavior using global configuration will not create a security flaw in the network.

NAP Administration Pages

This section describes the fields in the web pages that you use for NAP administration:

Network Access Profiles Page

Profile Setup Page

Advanced Filtering-Rule Elements Table

Network Access Profiles Page

This page contains:

Field
Description

Name

Click to activate the configuration for the profile. Opens the Profile Setup Page.

Policies

Contains links to set up authentication, posture validation, and authorization policies. Choose the appropriate link in this column to set the policy for the profile.

Authentication

Controls the profile's authentication policy. Opens the Authentication Settings Page where you can select which protocols are permitted and the database that is used to validate user credentials.

Posture Validation

Use to configure posture-validation policies. Opens the Posture Validation Page.

Authorization

Use to map between a user-group and system posture token result, to a radius-profile tag and Access Control List (ACL) name. Opens the Authorization Rules for Profile Page.

Deny access when no profile matches

When this option is enabled and the access request does not match any profile, authentication fails and the access request is denied. If this option is not enabled, ACS reverts to the global configuration settings of authorizing by user-groups.

Grant access using global configuration, when no profile matches

When this option is enabled and the access request does not match any profile, authentication fails and the access request is granted based on the default configuration.

Add Profile

Click to open the Profile Setup Page to configure NAPs.

Add Template Profile

Click to create a profile from a selection of templates. You can use the templates to facilitate the construction of a profile. Opens the Create Profile from Template Page.

Up/Down

Use to change the order of the profiles. Click the Up or Down buttons submit and save the sort order to the database.

Radio Button

Use to sort the order of profiles. Click to activate the profile to reorder.

Apply and Restart

Restarts ACS and applies the modifications.


Profile Setup Page

This page contains:

Field
Description

Name

Enter the profile name.

Description

Displays the profile description

Active

Displays the profile status.

Network Access Filter

Use to create a filter for configuring a profile. based on NAFs. The default for the NAF is Any.

Protocol Types

The Protocol Types are a subset of the VSAs that NAS supports. Click Allow Any Protocol Type to allow any protocol type or click Allow Selected Protocol Types to select protocols. Click the arrows to move the available Protocol Types to the Selected list. The default for the Protocol Types is Allow Any.

Advanced Filtering

Use to set rules for advanced filtering. See Advanced Filtering-Rule Elements Table. If you do not specify values for advanced filtering, the default is Any.

Submit

Click to submit your modifications. Returns you to the Network Access Profiles Page.

Clone

Click to clone and create a copy of the NAP. See Cloning a Profile for more information.

Delete

Click to delete a profile. A warning message appears.

Cancel

Returns you to the Network Access Profiles Page without implementing any changes that you have made.


Advanced Filtering-Rule Elements Table

This table contains:

Field
Description

Attribute

Select the RADIUS Attribute from the drop-down list.

Operator

When you construct a rule for advanced filtering, in ACS you can only select an operator that is applicable to the type of attribute that you select. Operators include:

= (equal to)—The rule element is true if the value in the attribute is exactly equal to the value that you specify.

!= (not equal to)—The rule element is true if the value in the attribute does not equal to the value that you specify.

contains — The rule element is true if the attribute contains a string and if any part of that string matches the string that you specify.

starts with —The rule element is true if the attribute contains a string and if the beginning of that string matches the string that you specify.

regular expression — The rule element is true if the attribute contains a string and if the string matches the regular expression that you specify.

Value

Enter a value for the attribute.

Cisco-av-pair

When you select the {026/009/001} cisco-av-pair attribute, enter an operator and values for the av-pair-key and av-pair-value.


Using Profile Templates

You use a profile template to construct a new profile. Instead of setting up a new profile from scratch, you can select a profile from a predefined set of profile templates. The templates include a preconfigured set of NAC samples that you can use as the basis for building NAC policies. After you name the new profile and select a profile template, default values are populated into the Profile Setup page. You can then customize the profile settings to the specific needs of your security policy.

When you select a predefined template, ACS creates a full-scale NAP, including profile authentication, posture validation, and authorization policies.

The following templates are available for creating a profile:

NAC L3 IP

NAC L2 IP

NAC Layer 2 802.1x

Microsoft IEEE 802.1x

Wireless (NAC L2 802.1x)

Authentication Bypass (802.1x fallback)

NAC Agentless Host (EAP over User Datagram Protocol (UDP) fallback)

Shared-profile Components

Each template references a set of shared-profile components. Before creating a template, ACS verifies that the appropriate shared-profile components exist. If the shared-profile components were not configured, ACS uses a set of shared-profile components that were created for the selected template.

Prerequisites for Using Profile Templates

Before you can use a profile template, you must configure:

At least one AAA client by using the RADIUS Internet Engineering Task Force (IETF) protocol.

Certificate setup.

Administrator accounts (if needed).

Logging settings.

Global Authentication Setup for templates, depending on the template.

User-Level or Group-Level Downloadable ACLs in the Interface Configuration > Advanced Options, depending on the template.

ACS rules are constructed from attributes that reside in the ACS dictionaries. During installation, the ACS posture dictionary is initialized to include attributes that belong to the cisco:pa. (It is mandatory that this default set of attributes be supported by every Cisco Trust Agent (CTA) implementation.)

The internal posture-validation polices that the templates create are based on these sets of attributes.

In ACS, each template that is created references a set of reusable objects. Before creating the template, ACS verifies that the relevant reusable objects already exist. If they do not, ACS automatically creates the required objects for the template. Creation of profiles from templates will not fail if these objects do not exist beforehand. If the reusable objects exist for the selected template, ACS uses the relevant reusable objects.


Note You cannot delete an attribute if it is being used in a posture-validation policy.


Selecting a Profile Template

To select a profile template:


Step 1 In the navigation bar, click Network Access Profiles.

The Network Access Profiles Page appears.

Step 2 Click Add Template Profile.

The Create Profile from Template Page appears.

Select a template from the drop-down list.

Step 3 Enter and Name and Description for the Profile.

Step 4 Check the Active check box to activate the profile.

Step 5 To save your profile configuration settings, return to the Network Access Profiles Page and click Apply and Restart.


Create Profile from Template Page

This page contains:

Field
Description

Name

Enter a name for the profile template.

Description

Enter a description for the template profile.

Template

Select one of the templates from the drop-down list.

Active

Check to activate the profile.


NAC L3 IP

This template is used for access requests from a LAN Port IP by using Layer 3 posture validation.

Before you use this template enable:

1. Allow Posture Validation in Global Authentication Setup.

2. Extensible Authentication Protocol-Flexible Authentication via Secure Tunnelling (EAP-FAST) authenticated in-band PAC provisioning in Global Authentication Setup.

3. EAP-FAST MS-CHAPv2 in Global Authentication Setup.

4. EAP-FAST Generic Token Card (GTC) in Global Authentication Setup.

Downloadable ACLs

Downloadable per-user ACL support is available for Layer 3 network devices that support downloadable ACLs. These includes Cisco PIX security appliances, Cisco VPN solutions, and Cisco IOS routers. You can define sets of ACLs that you can apply per user or per group. This feature complements NAC support by enabling the enforcement of the correct ACL policy. When used in conjunction with NAFs, you can apply downloadable ACLs can differently per device, allowing you to tailor ACLs uniquely per user or per access device.

To create Layer 3 NAC profile from a template:


Step 1 Choose Network Access Profiles.

Step 2 Choose Add Template Profile.

Step 3 Select NAC L3 IP from the template drop-down list.

Step 4 Enter and Name and Description for the Profile.

Step 5 Check the Active check box to activate the profile.

Step 6 Click Submit.


Table 15-1 describes the Profile Sample in the NAC Layer 3 IP Sample Profile Template.

Table 15-1 NAC Layer 3 IP Profile Sample 

Section
Property
Value

NAP

Name

User configurable

Description

User configurable

Profile

NAF

N/A

Protocol

N/A

Advance filter

([[26/9/1]Cisco av-pair]aaa:service = ip-admission) AND ([006]Service-Type != 10)

Authentication

Protected Extensible Authentication Protocol (PEAP)

Allow Posture Only is checked

Credential Validation Database

N/A

Posture Validation

Posture Validation Rule

Name

NAC-EXAMPLE-POSTURE-EXAMPLE

Required credential types

Cisco:PA

Selected internal posture policies

NAC-SAMPLE-CTA-POLICY

Selected external posture policies

N/A

System Posture Token configuration

System Posture Token

PA message

URL Redirect

Healthy

Healthy

N/A

Checkup

Checkup

N/A

Transition

Transition

N/A

Quarantine

Quarantine

N/A

Infected

Infected

N/A

Unknown

Unknown

N/A


Table 15-2 Authorization Rules for NAC Layer 3 IP Profile Template 

Authorization Rules
User Group
System Posture Token
Shared RAC
DACL

Rule 1

N/A

Healthy

NAC-SAMPLE-
HEALTHY-L3-RAC

NAC-SAMPLE-
HEALTHY-ACL

Rule 2

N/A

Quarantine

NAC-SAMPLE-
QUARANTINE-L3-RAC

NAC-SAMPLE-
QUARANTINE-ACL

Default

Deny = unchecked

NAC-SAMPLE-QUARANTINE-L3-RAC

NAC_SAMPLE_
QUARANTINE_ACL

Include RADIUS attributes from user's group

Unchecked

Include RADIUS attributes from user record

Unchecked


Table 15-3 describes the posture-validation policies in the NAC Layer 3 IP Sample Profile Template.

Table 15-3 Posture Validation for NAC Layer 3 IP Sample 

Section
Object
Value

Internal posture policy

NAC-SAMPLE-CTA-POLICY

 

Condition

System Posture Token

Notification String

Rule 1

Cisco:PA:PA-Name contains CTA and Cisco:PA:PA-Version >=1.0

Cisco:PA:Healthy

N/A

Default

N/A

Cisco:PA:Quarantine

N/A


Table 15-4 describes the Shared Profile Components in the NAC Layer 3 IP Sample Profile Template.

Table 15-4 Shared Profile Components for NAC Layer 3 IP Sample 

Type
Object
Value

RADIUS Authorization Components

NAC-SAMPLE-HEALTHY-L3-RAC

[027]Session-Timeout = 36,000

[26/9/1]cisc-av-pair status-query-timeout=300

[029] Termination-Action RADIUS-Request (1)

NAC-SAMPLE-QUARANTINE-L3-RAC

[027]Session-Timeout = 3,600

[26/9/1]cisc-av-pair status-query-timeout=30

[029] Termination-Action RADIUS-Request (1)

Downloadable IP ACLs

NAC-SAMPLE-HEALTHY-ACL

ACL Content Name

Content

NAF

NAC-SAMPLE-QUARANTINE-ACL

L3-EXAMPLE

permit ip any any

(All-AAA-Clients)


NAC L2 IP

Before you use this template, choose Enable EAP Configuration > Allow Posture Validation in Global Authentication Setup.

You can use NAC Layer 2 IP on an access port on an edge switch to which an endpoint system or client is connected. The device (host or client) can be a PC, a workstation, or a server that is connected to the switch access port through a direct connection, an IP phone, a hub, or a wireless access point.

When NAC Layer 2 IP is enabled, UDP only works with IPv4 traffic. The switch checks the antivirus condition of the endpoint devices or clients and enforces access-control policies.

Advanced Filtering and Authentication properties are filled out with NAC-L2-IP Configuration automatically.

Table 15-5 describes the content of the Profile in the NAC Layer 2 IP Sample Profile Template.

Table 15-5 NAC Layer 2 IP Profile Sample 

Section
Property
Value

NAP

Name

User configurable

Description

User configurable

Profile

NAF

N/A

Protocol

N/A

Advance filter

([[26/9/1]Cisco av-pair]aaa:service = ip-admission) AND ([006]Service-Type != 10)

Authentication

PEAP

Allow Posture Only is checked

Credential Validation Database

N/A

Posture Validation

Posture Validation Rule

Name

NAC-EXAMPLE-POSTURE-EXAMPLE

Required credential types

Cisco:PA

Selected internal posture policies

NAC-SAMPLE-CTA-POLICY

Selected external posture policies

N/A

System Posture Token configuration

System Posture Token

PA message

URL Redirect

Healthy

Healthy

N/A

Checkup

Checkup

N/A

Transition

Transition

N/A

Quarantine

Quarantine

N/A

Infected

Infected

N/A

Unknown

Unknown

N/A


Table 15-6 describes the content of the Authorization Rules in the NAC Layer 2 IP Sample Profile Template.

Table 15-6 Authorization Rules for NAC Layer 2 IP Profile Template 

Authorization Rules
User-Group
System Posture Token
RAC
DACL

Rule 1

N/A

Healthy

NAC-SAMPLE-HEALTHY-L3-RAC

NAC-SAMPLE-HEALTHY-ACL

Rule 2

N/A

Quarantine

NAC-SAMPLE-QUARANTINE-L3-RAC

NAC-SAMPLE-QUARANTINE-ACL

Default

NAC-SAMPLE-QUARANTINE-L3-RAC

NAC_SAMPLE_QUARANTINE_ACL

Include RADIUS attributes from user's group

Unchecked

Include RADIUS attributes from user record

Unchecked


Table 15-7 describes the content of the posture-validation policies in the NAC Layer 2 IP Sample Profile Template.

Table 15-7 Posture Validation for NAC Layer 2 IP Sample 

Section
Object
Value

Internal posture policy

NAC-SAMPLE-POSTURE-RULE

 

Condition

System Posture Token

Notification String

Rule 1

Cisco:PA:PA-Name contains CTA and Cisco:PA:PA-Version >=1.0

Cisco:PA:Healthy

N/A

Default

N/A

Cisco:PA:Quarantine

N/A


ACS and AV Pairs

When you enable NAC Layer 2 IP validation, ACS provides NAC AAA services by using RADIUS. ACS gets information about the antivirus credentials of the endpoint system and validates the antivirus condition of the endpoint.

You can set these Attribute-Value (AV) pairs on ACS by using the RADIUS cisco-av-pair vendor- specific attributes (VSAs).

Cisco Secure-Defined-ACL—Specifies the names of the downloadable ACLs on the ACS. The switch gets the ACL name through the Cisco Secure-Defined-ACL AV pair in this format:

#ACL#-IP-name-number

where name is the ACL name and number is the version number, such as 3f783768.

The Auth-Proxy posture code checks if the access-control entries (ACEs) of the specified downloadable ACL were previously downloaded. If it was not, the Auth-Proxy posture code sends an AAA request with the downloadable ACL name as the username so that the ACEs are downloaded. The downloadable ACL is then created as a named ACL on the switch. This ACL has ACEs with a source address of Any and does not have an implicit Deny statement at the end. When the downloadable ACL is applied to an interface after posture validation is complete, the source address is changed from any to the host source IP address. The ACEs are prepended to the downloadable ACL that is applied to the switch interface to which the endpoint device is connected.

If traffic matches the Cisco Secure-Defined-ACL ACEs, the appropriate NAC actions are taken.

url redirect and url-redirect-acl—Specifies the local URL policy on the switch. The switches use these cisco-av-pair VSAs:

url-redirect = <HTTP or HTTPS URL>

url-redirect-acl = switch ACL name

These AV pairs enable the switch to intercept an HyperText Transfer Protocol (HTTP) or Secure HyperText Transfer Protocol (HTTPS) request from the endpoint device and forward the client web browser to the specified redirect address from which the latest antivirus files can be downloaded. The url-redirect AV pair on the ACS contains the URL to which the web browser will be redirected. The url-redirect-acl AV pair contains the name of an ACL which specifies the HTTP or HTTPS traffic to be redirected. The ACL must be defined on the switch. Traffic which matches a permit entry in the redirect ACL will be redirected.

These AV pairs might be sent if the host's posture is not healthy.

For more information about AV pairs that Cisco IOS software supports, see the documentation about the software releases that run on the AAA clients.

Default ACLs

If you configure NAC Layer 2 IP validation on a switch port, you must also configure a default port ACL on a switch port. You should also apply the default ACL to IP traffic for hosts that have not completed posture validation.

If you configure the default ACL on the switch and the ACS sends a host access policy to the switch, the switch applies the policy to traffic from the host that is connected to a switch port. If the policy applies to the traffic, the switch forwards the traffic. If the policy does not apply, the switch applies the default ACL. However, if the switch gets a host access policy from the ACS, but the default ACL is not configured, the NAC Layer 2 IP configuration does not take effect.

When ACS sends the switch an downloadable ACL that specifies a redirect URL as a policy-map action, this ACL takes precedence over the default ACL that is already configured on the switch port. The default ACL also takes precedence over the policy that is already configured on the host. If the default port ACL is not configured on the switch, the switch can still apply the downloadable ACL from ACS.

You use this template for access requests from Layer 2 devices that do not have the 802.1x client installed. Media Access Control (MAC) Authentication Bypass is used for access requests to bypass the nonclient authentication process. Users are mapped to a User Group based on their identity.


Note Do not use the Populate from Global button; otherwise: this authentication field will be inherited from the Global Authentication Setup in System Configuration.


NAC Layer 2 802.1x

Before you use this template, enable:

1. EAP-FAST in Global Authentication Setup

2. EAP-FAST Authenticated in-band PAC Provisioning in Global Authentication Settings

3. EAP-FAST MS-CHAPv2 in Global Authentication Setup

4. EAP-FAST GTC in Global Authentication Setup

Table 15-8 describes the content of the NAC L2 802.1x Sample Profile Template.

Table 15-8 NAC L2 802.1x Profile Sample 

Section
Property
Value

NAP

Name

User configured

Description

User configured

Profile

NAF

N/A

Protocol

N/A

Advance filter

([006]Service-Type != 10) and (not exist [26/9/1]cisco-av-pair aaa:service)

Authentication

EAP-FAST

Allow EAP-FAST is checked.

Allow authenticated in-band PAC provisioning is checked.

Allow inner methods EAP-GTC is checked.

Allow inner methods EAP-MS-CHAPv2 is checked.

Allow Stateless Session Resume is checked.

Accept client on authenticated provisioning is checked.

Posture Validation required is checked.

Credential Validation Database

ACS Internal user database

Posture Validation

Posture validation Rule

Name

NAC-SAMPLE-POSTURE-RULE

Required credential types

Cisco:PA

Selected internal posture policies

NAC-SAMPLE-CTA-POLICY

Selected external posture policies

N/A

System Posture Token configuration

System Posture Token

PA message

URL

Healthy

Healthy

N/A

Checkup

Checkup

N/A

Transition

Transition

N/A

Quarantine

Quarantine

N/A

Infected

Infected

N/A

Unknown

Unknown

N/A


Table 15-9 describes the content of the Authorization Rules in the NAC Layer 802.1x Sample Profile Template.

Table 15-9 Authorization Rules for NAC Layer 2 801.x Profile Sample 

Authorization Rules
User group
System Posture Token
RAC
DACL

Rule 1

N/A

Healthy

NAC-SAMPLE-
HEALTHY-L2-RAC

N/A

Rule 2

N/A

Quarantine

NAC-SAMPLE-
QUARANTINE-L2-RAC

N/A

Default

NAC-SAMPLE-
QUARANTINE-L3-RAC

NAC_SAMPLE_
QUARANTINE_ACL

Include RADIUS attributes from user's group

Unchecked

Include RADIUS attributes from user record

Unchecked


Table 15-10 describes the content of the posture-validation policies in the NAC Layer 802.1x Sample Profile Template.

Table 15-10 Posture Validation for NAC Layer 2 802.1x Profile Sample 

Section
Object
Value

Internal posture policy

NAC-SAMPLE-CTA-POLICY

 

Condition

System Posture Token

Notification String

Rule 1

Cisco:PA:PA-Name contains CTA and Cisco:PA:PA-
Version >=1.0

Cisco:PA:Healthy

N/A

Default

N/A

Cisco:PA:Quarantine

N/A


Table 15-11 describes the content of the Shared Profile Components in the NAC Layer 802.1x Sample Profile Template.

Table 15-11 Shared Profile Components for NAC Layer 2 802.1x Profile Template 

Type
Object
Value

RADIUS Authorization Components

NAC-SAMPLE-HEALTHY-L2-RAC

[027] Session-Timeout = 36,000

[26/9/1] cisco-av-pair sec:pg=healthy_hosts

[029] Termination-Action RADIUS-Request (1)

[064] Tunnel-Type [T1] VLAN (13)

[065] Tunnel-Medium-Type [T1] 802 (6)

[081] Tunnel-Private-Group-ID = healthy

NAC-SAMPLE-
QUARANTINE-L2-RAC

[027] Session-Timeout = 3,600

[26/9/1]cisco-av-pair sec:pg=quarantine_hosts

[029] Termination-Action RADIUS-Request (1)

[064] Tunnel-Type [T1] VLAN (13)

[065] Tunnel-Medium-Type [T1] 802 (6)

[081] Tunnel-Private-Group-ID = quarantine


Microsoft IEEE 802.1x

Before you use this template, choose Enable EAP Configuration > Allow EAP-MS-CHAPv2 in the Global Authentication Setup page.

Table 15-12 describes the Profile Sample in the Microsoft IEEE 802.1x Sample Profile Template.

Table 15-12 Microsoft IEEE 802.1x Profile Sample 

Section
Property
Value

NAP

Name

User configurable

Description

User configurable

Profile

NAF

N/A

Protocol

N/A

Advance filter

([006]Service-Type != 10) and (not exist [26/9/1]cisco-av-pair aaa:service)

Authentication

PEAP

Allow EAP MS-CHAPv2 is checked

Credential Validation Database

ACS Internal Users Database

Posture Validation

N/A


Table 15-13 describes the Authorization Rules in the Microsoft IEEE 802.1x Sample Profile Template.

Table 15-13 Authorization Rules for Microsoft IEEE 802.1x Profile Sample 

Authorization Rules
User Group
System Posture Token
RAC
DACL

Default

Deny = unchecked

Include RADIUS attributes from user's group

Checked

Include RADIUS attributes from user record

Checked


Wireless (NAC L2 802.1x)

The templates for wireless (NAC L2 802.1x) are the same as the NAC L2 802.1x templates. See NAC Layer 2 802.1x for more information.

Authentication Bypass

You can use the profile template that ACS provides to create a profile that matches a RADIUS request that will come from a switch. Once the profile is created an analysis of the RADIUS packet that comes from the Catalyst 6500 must be done to create an accurate match for the profile. The RADIUS request from the switch has a Service Type value of 10, just like NAC-L2-IP; but does not have a Cisco Attribute Value Pair (AVP) that contains the keywords service. Therefore, two entries are created in the Advanced Filtering box.


Note MAC-Authentication-Bypass is only supported on the Cisco Catalyst 6500 Cat OS in this release.


Table 15-14 describes the content of the Profile Sample in the Authentication Bypass Sample Profile Template.

Table 15-14 Authentication Bypass Sample Profile 

Section
Property
Value

NAP

Name

User configurable

Description

User configurable

Profile

NAF

N/A

Protocol

N/A

Advance filter

(not exist [26/9/1]cisco-av-pair aaa:service)

AND ([006]Service-Type = 10)

Credential Validation Database

N/A

Authentication

Protocols

MAC authentication bypass will be checked

Default user-group will be set to default group

Posture Validation

N/A


Table 15-15 describes the content of the Authorization Rules in the Authentication Bypass Sample Profile Template.

Table 15-15 Authorization Rules for Authentication Bypass Sample Profile 

Authorization Rules
User Group
System Posture Token
RAC
DACL

Rule 1

Default-group

N/A

NAC-SAMPLE-
QUARANTINE-L2-RAC

N/A

Default

Deny = checked

Include RADIUS attributes from user's group

Unchecked

Include RADIUS attributes from user record

Unchecked


NAC Agentless Host

This template is used for access requests for NAC Agentless Hosts (NAH), also known as agentless hosts. These requests use EAP over UDP (EoU).

Table 15-16 describes the Profile Sample in the NAH Sample Profile Template.

Table 15-16 NAH Sample Profile Template 

Section
Property
Value

NAP

Name

User configurable

Description

User configurable

Profile

NAF

N/A

Protocol

N/A

Advance filter

([[26/9/1]Cisco av-pair]aaa:service =
ip-admission) AND ([006]Service-Type = 10)

Credential Validation Database

N/A

Posture Validation

N/A

Authorization

Rules

User-group

System Posture Token

RAC

DACL

N/A

Healthy

NAC-SAMPLE-HEALTHY-L3-RAC

NAC_SAMPLE_HEALTHY_ACL

N/A

Quarantine

NAC-SAMPLE-
QUARANTINE-L3-RAC

NAC_SAMPLE_
QUARANTINE_ACL

N/A

Transition

NAC-SAMPLE-
TRANSITION-L3-RAC

NAC_SAMPLE_
TRANSITION_ACL

Default

Deny = unchecked

NAC-SAMPLE-
QUARANTINE-L3-RAC

NAC_SAMPLE_
QUARANTINE_ACL

Include RADIUS attributes from user's group

Unchecked

Include RADIUS attributes from user record

Unchecked


Table 15-17 describes the Shared Profile Components in the NAH Sample Profile Template.

Table 15-17 Shared Profile Components for NAH Sample 

Type
Object
Value

RADIUS Authorization Components

NAC-SAMPLE-TRANSITION-L3-RAC

[027] Session-Timeout = 60

[029] Termination-Action RADIUS-Request (1)

A Session-Timeout can be overwritten if hinted by an audit server

NAC-SAMPLE-HEALTHY-L3-RAC

[027]Session-Timeout = 36,000

[029] Termination-Action RADIUS-Request (1)

NAC-SAMPLE-QUARANTINE-L3-RAC

[027]Session-Timeout = 3,600

[029] Termination-Action RADIUS-Request (1)

Downloadable IP ACLs

 

ACL Content Name

Content

NAF

NAC-_SAMPLE-_TRANSITION-_ACL

L3-EXAMPLE

permit ip any any

(All-AAA-Clients)

NAC-_SAMPLE-_HEALTHY-_ACL

L3-EXAMPLE

permit ip any any

(All-AAA-Clients)

NAC_-SAMPLE-_QUARANTINE-_ACL

L3-EXAMPLE

permit ip any any

(All-AAA-Clients)


Configuring Policies for Profiles

After you set up a profile, you associate a set of rules or policies with it, to reflect your organization's security policies. These associations are called profile-based policies. Configuration of a profile-based policy includes the creation of rules for:

Authentication—A set of configuration policies that are related to authentication mechanisms.

Posture validation—Define the manner in which posture validation will be performed (only if you plan to deploy NAC in your network).

Authorization—Configure a set of authorization rules (optional).

A profile acts as a way to segment network access-requests and apply a common policy to those user requests.

Configuration of profile-based policies includes:

1. Configuring Authentication Policies

2. Configuring Posture-Validation Policies

3. Configuring Authorization Policies

Configuring Authentication Policies

Before you configure authentication policies:

Set up the authentication protocols in the System Configuration section by using the Global Authentication Setup option. For more information, see Global Authentication Setup Page, page 10-20.


Note We recommend that you check all authentication protocols in the Global Authentication Setup for NAC.


Configure the External User Databases that you mapped to ACS user groups by the mapping rules that are defined in Database Group Mapping.


Note The ACS internal database is the default selected database.


Authentication settings define what types of authentication protocols are allowed, the configuration for these protocols, and which databases are used to validate the credentials of the user for authentication. The authentication protocols are listed from weakest to most secure. The protocols that you select determine the flexibility of negotiation. The final result is to determine which protocol to use to authenticate.


Note For simple posture validation, you must check the Allow Posture Validation check box in the EAP Configuration section.


Populate from Global

You can populate the authenticating settings with the ACS global settings, and can then be customized. This method facilitates configuring the authentication settings each time you set up a new profile.

You should first configure the Global Authentication Setup, which serves as a central location for all of the EAP configuration settings in the active or inactive profiles.

EAP types, which are disabled in the Global Authentication Page, cannot be enabled in any of the ACS profiles. Every EAP type that is unchecked in the Global Authentication Page, will be automatically unchecked in all ACS (active and inactive) profiles.

To apply global settings:

Click Populate from Global to apply authentication settings that were set in the System Configuration > Global Authentication Setup window.

Authentication Protocols

You can configure all relevant parameters for authentication in the Authentication Settings Page. These parameters are applied during access request processing.

The following authentication protocols can be configured in the Authentication Settings Page:

RADIUS Authentication protocols:

An option to allow or disallow authentication by using Password Authentication Protocol (PAP) protocol.

An option to allow or disallow authentication by using CHAP password protocol.

An option to allow or disallow authentication by using MS-CHAPv1 password protocol.

An option to allow or disallow authentication by using MS-CHAPv2 password protocol.

An option to allow or disallow authentication by using MAC-Authentication Bypass. For more information, see MAC-Authentication Bypass.

An option to allow or disallow a set of EAP types (outer and inner) to be used for EAP authentication, including the relevant setting for each EAP-type. See EAP Configuration, for more information.

You can configure the following EAP protocols:

PEAP

EAP-FAST

EAP-Transport Layer Security (TLS)

EAP-Message Digest 5 (MD5)

An ordered list of external database instances that you can use for authentication and user-group mapping.

If the password protocol is not enabled, then ACS rejects the access request.

If ACS and a client do not share any commonly enabled EAP-Type, then ACS rejects the access request.

When authentication is requested, ACS uses the ordered list of external databases that are defined for a specific profile.

MAC-Authentication Bypass

MAC Authentication Bypass is an identity-based network security feature that is configured on a port basis. A switch makes a RADIUS request to ACS with the MAC address of the endhost connecting to the switch. MAC authentication happens on the switch or device as a fallback that results from a 802.1x failure or an EAPoUDP failure, and hence bypasses these mechanisms. This feature is useful for allowing network access for hosts without 802.1x or EAPoUDP support. For example, devices such as printers or terminals that do not have an 802.1x client can use this feature to access to the network.

You can use this feature to map MAC addresses to user groups. If the list of defined addresses does not contain a MAC address, you can associate a fallback user group with the access request. Groups can be included in the profile's authorization policy and then be evaluated for network admission based on authorization rules.

The MAC address is sent in the Calling-Station-ID RADIUS attribute. The following defines how ACS identifies a mac-authentication request:

Service-Type = 10 (Call Check)

If the MAC-Authentication Bypass option is not selected, MAC authentication is not applied and the access request is rejected.

For more information on how to configure MAC Authentication Bypass, see Configuring MAC Authentication Bypass.

EAP Configuration

EAP is a flexible request-response protocol for arbitrary authentication information (RFC 2284). EAP is layered on top of another protocol such as UDP, 802.1x, or RADIUS and supports multiple authentication types:

PEAP (Protected EAP)

EAP-FAST

EAP-TLS (based on X.509 certificates)

EAP-MD5: Plain Password Hash (CHAP over EAP)

EAP-GTC: OTP Tokens

New extended EAP methods have been added to EAP for NAC:

EAP-TLV: Carry posture credentials, adding posture AVPs, posture notifications.

Status Query: You can use this new EAP method for securely querying the status of a peer without a full credential validation.

EAPoUDP: use of EAP over UDP for Layer 3 transport.


Note LEAP (EAP-Cisco Wireless) is not supported when working with Network Access Profiles.


EAP-FAST

EAP-FAST is a new, publicly accessible IEEE 802.1X EAP type that Cisco developed to support customers that cannot enforce a strong password policy and want to deploy an 802.1X EAP type that does not require digital certificates. EAP-FAST supports a variety of user and password database types, password change and expiration; and is flexible, easy to deploy, and easy to manage. For more information about EAP-FAST and comparison with other EAP types, see: http://www.cisco.com/en/US/products/hw/wireless/ps430/products_qanda_item09186a00802030dc.shtml

You can set the following inner methods for EAP- FAST;

EAP-GTC: OTP Tokens

EAP MS-CHAPv2

EAP-TLS

Posture Validation Settings

Several organizations might be transitional to supply their hosts with CTA and some hosts might or might not have CTA installed. Cases might arise where you might want to enforce posture validation on machines with CTA; however, you do not want to fail authentication on those machines that are temporarily without CTA. When EAP-FAST is enabled with Required Posture Validation, you can select the Optional selection and supply a resulting SPT. You can use the SPT that is set here for setting Authorization settings. For a description of the tokens that are used in ACS, see Posture Tokens, page 14-3.


Note If posture-validation rules are not defined, the posture token returned is Unknown.


Credential Validation Databases

The Credential Validation Databases are databases that you use to validate users. The Available Databases are the configured External User Databases that are mapped to ACS user groups by the mapping rules defined in Databases Group Mapping. The ACS internal database appears, by default, as a selected database.


Note If you specify multiple databases for authentication, ACS will query each directory server in the order specified until it receives an authoritative response. You should put the most likely directory servers higher in the list to improve response times and user experience.


Setting Authentication Policies

To set authentication policies:


Step 1 Choose Network Access Profiles.

Step 2 Choose the relevant Authentication policy.

The Authentication Settings Page appears.

Step 3 Select Populate from Global to populate authentication settings from the ACS Global Authentication Settings. For more information, see Global Authentication Setup, page 10-19.

If you are not using the Global Authentication Setup settings:

Step 4 Configure the Authentication Protocols for the profile.

Step 5 Select the EAP Configuration. See EAP Configuration.

Step 6 Select the EAP-FAST Configuration. See EAP-FAST

Step 7 Select the Credential Validation Databases. See Credential Validation Databases.

Step 8 Click Submit.

The Network Access Profiles Page appears.

Step 9 Click Apply and Restart for your changes to take effect.


Configuring MAC Authentication Bypass

To configure the MAC authentication bypass:


Step 1 Choose Network Access Profiles.

Step 2 Choose the relevant Authentication policy.

Step 3 In the Authentication Settings Page, enable Allow MAC-Authentication-Bypass.

Step 4 Click Submit.

The Network Access Profiles Page appears.

Step 5 Choose the relevant Authentication policy.

Step 6 Select the MAC Authentication Bypass Configuration link.

The MAC Authentication Mapping Page appears.

Step 7 Click Add.

Step 8 Enter the MAC Addresses for the access requests that you want to group.

Step 9 Select a User Group from the drop-down list.

Step 10 Continue Adding MAC addresses and mappings to the list. (optional)

Step 11 Define the default mapping for MAC addresses that do not match by selecting a group from the drop-down list.

Step 12 Click Submit.

The Network Access Profiles Page appears.

Step 13 Click Apply and Restart for your changes to take effect.


Note Each NAP can hold up to 10,000 MAC addresses in the MAB page. Each NAP can hold up to 100 mappings (a map between list of one or more MAC addresses to a group), meaning you can have up to 100 lines of mappings from lists of MACs to user-groups. You can map up to 10,000 MAC Addresses to the same user-group in one NAP.



Authentication Settings Page

The Authentication Settings page contains:

Field
Description

Populate from Global

Use this option to populate the Authentication Settings with the ACS global Authentication settings. This method facilitates configuration of the authentication settings each time you set up a new profile.

Authentication Protocols

Select from PAP, CHAP, MS-CHAPv1,MS-CHAPv2

Allow PAP

Select to enable PAP. PAP uses clear-text passwords (that is, unencrypted passwords) and is the least secure authentication protocol.

Allow CHAP

Select to enable CHAP. CHAP uses a challenge-response mechanism with password encryption. CHAP does not work with the Windows user database.

Allow MS-CHAPv1

Select to enable MS-CHAPv1.

Allow MS-CHAPv2

Select to enable MS-CHAPv2

Allow MAC-Authentication Bypass

Enable to configure the authentication process for a profile that receives a MAC address request.

MAC Authentication Bypass Configuration

Opens the MAC Authentication Mapping Page

EAP Configuration

Note: PEAP is a certificate-based authentication protocol. Authentication can occur only after you have completed the required steps on the ACS Certificate Setup page.

Select he PEAP types. In most cases, all three boxes should be checked. When none is selected, PEAP will not be allowed for authentication.

Allow EAP-GTC (Cisco PEAP)

Select to enable EAP-GTC within PEAP authentication. Use for RSA Secure ID authentication.

Allow EAP-MS-CHAPv2 (MS PEAP)

Select to enable EAP-MS-CHAPv2 within PEAP authentication. Use for AD authentication.

Allow Posture validation

Select to enable the collection of posture data when using PEAP. This options uses EAP over UDP.

Note This EAP configuration must be checked to use the Layer 3 NAC Profile Template.

Allow EAP-FAST

Select to enable EAP-FAST authentication, All other EAP-FAST-related options are irrelevant if unchecked. Some of the following settings must have corresponding settings on the PC based authentication agent (the EAP-FAST client).

Allow anonymous in-band PAC provisioning

If this check box is checked, ACS establishes a secure anonymous TLS handshake with the client to provision it with a so-called PAC by using phase zero of EAP-FAST, and using EAP-MS-CHAP as the inner method.

Allow authenticated in-band PAC provisioning

ACS uses secure sockets layer (SSL) server-side authentication to provision the client with a PAC during phase zero of EAP-FAST. This option is more secure than anonymous provisioning; but requires that a server certificate and a trusted root CA are installed on ACS.

Accept client on authenticated provisioning

This option is only available when the Allow authenticated in-band PAC provisioning option is selected. This option should be checked to slightly shorten the protocol.

Require client certificate for provisioning

Select this option if the clients are configured with public key infrastructure' (PKI) certificates, which will be used to provision PACs

Allow Stateless session resume

Should normally be checked. Uncheck if you do not want ACS to provision authorization PACs for EAP-FAST clients, and always perform phase 2 of EAP-FAST.

Authorization PAC TTL minutes hours

You can use this setting to determine the expiration time of the user authorization PAC. When ACS receives an expired authorization PAC, it performs phase 2 EAP-FAST authentication. Enter a time in minutes or hours.

Allowed inner methods

These options determine which inner EAP methods run inside the EAP-FAST tunnel. For anonymous in-band provisioning, EAP-GTC and EAP-MS-CHAPv2 must be enabled for backward compatibility. In most cases, all the inner methods should be checked.

Note ACS always starts the authentication process by using the first enabled EAP method. For example, if you select EAP-GTC and EAP-MS-CHAPv2, then the first enabled EAP method is EAP-GTC.

ACS always runs the first enabled EAP method. For example, if you select EAP-GTC and EAP-MS-CHAPv2, then the first enabled EAP method is EAP-GTC.

EAP-GTC

This option uses a two-factor authentication; for example, OTP.

EAP-MS-CHAPv2

This option is used for AD authentication.

EAP-TLS

This option uses certificates for authentication.

Posture Validation

Determines the EAP-FAST posture-validation mode. Select one of the following posture-validation modes:

None—Authentication is performed; however, no posture-validation data is requested from the client and no SPT is returned.

Required—Authentication and posture validation are performed in the same authentication session. As a result, an SPT is returned. If this option is selected and posture credentials that are requested from the client are not received, authentication fails. If you are implementing NAC, this option should be enabled.

Optional—Client may not supply posture data. Sets a default SPT when a client cannot supply posture data to ACS.

Use Token—Select an SPT from the drop-down list to use as the default posture token.

Posture Only—Perform posture validation without running authentication inner methods within the authentication session. This option returns an SPT for posture validation.

EAP-TLS

Check this check box to enable EAP-TLS authentication.

Note: EAP-TLS is a certificate-based authentication protocol. EAP-TLS authentication can occur only after you have completed the required steps on the ACS Certificate Setup page.

EAP-MD5

Select to enable EAP-based Message Digest 5 hashed authentication.

Credential Validation Databases

Select the databases that you want to use to validate users. Select from the Available Databases list and use the arrows to move them into the Selected Databases list.


MAC Authentication Mapping Page

The MAC Authentication Mapping page contains:

Field
Description

MAC Addresses

Enter the MAC Addresses to map to a user group. These values should be comma-separated values (CSVs).

Two MAC address formats are accepted: 00-0D-60-FB-16-D3 or 000D.60FB.16D3. MAC prefixes that serve as ranges are acceptable. For example, 00-0D-60-FB-16 or 000D.60 would match any MAC address that begins with these bytes. MAC prefixes must contain an even number of hexadecimal digits. MAC address matching is case sensitive.

User-Group

Select the group from the ACS-defined groups to which to apply the MAC Authentication policy.

If a MAC address is not defined or there is no matched mapping.

If the MAC addresses entered in the provided fields do not match any of the MAC addresses entered, select a group to which to assign the MAC address.

Add

Adds a MAC Address mapping field.

Delete

Deletes a MAC Address mapping field.

Submit

Click to submit your changes to the ACS database.

Cancel

Returns you to the Network Access Profiles Page.


Configuring Posture-Validation Policies

Use the Posture Validation Page to configure and delete posture-validation rules. Posture-validation rules define the way that ACS performs posture validation.

Each rule comprises a condition and actions. The condition contains a set of required credential types; while the action contains a list of internal posture-validation policies or external posture-validation servers that you can use for posture validation, or both. See Chapter 14, "Network Access Control Overview," for more information.

ACS interprets a posture-validation rule as:

If posture credentials contain data that was sent from the following plug-ins <required credential types>, then perform posture validation by using the following internal, external, or both internal and external posture validation methods <list of internal policies and external servers>.

ACS applies all the policies that associated with the selected posture-validation rule to derive application posture tokens (APT), which represent the state of the client (also known as the endpoint). ACS compares all derived APTs and uses the worst case posture token as the SPT, which symbolizes the overall posture of the client.

Audit servers are Cisco and third-party servers that determine posture information about a client without relying on the presence of a NAC-compliant Posture Agent (PA). These types of clients are also referred to as NAC Agentless Hosts (NAH). Audit servers are used to assess posture validation with an organization's security policy. For more information, see Setting a Posture-Validation Policy.

The Cisco PA is also known as the Cisco Trust Agent (CTA).

Each rule contains:

Name (posture-validation policy) for identification.

Required credential types that define the credential types that activate this rule.

Internal policies and external servers that execute to calculate the posture token.

Posture Agent (PA) messages that return to the client for each SPT.

URL redirect that is sent to the AAA client for each SPT.


Note ACS supports up to 100 rules per policy.


The posture rules are evaluated in a first-match strategy. A posture-validation policy can have zero or more ordered posture-validation rules and is selected by using the first rule that matches.

This section contains the following information about configuring posture-validation policies:

URL Redirect Policy

Import Vendor Attribute-Value Pairs (AVPs)

Setting a Posture-Validation Policy

Deleting a Posture Validation Rule

Audit Server Functionality

System Posture Token Configuration

Mapping an Audit Server to a Profile

Posture Validation for Agentless Hosts

Configuring Fail Open

Runtime Behavior

URL Redirect Policy

The URL Redirect policy provides a mechanism to redirect all HTTP or HTTPS traffic to a remediation server that allows a noncompliant host to perform the necessary upgrade actions to become compliant. The policy comprises:

A URL that points to the remediation server.

An ACL on the switch that causes all HTTP or HTTPS packets from the host other than those destined to the remediation server address to be captured and redirected to the switch software for the necessary HTTP redirection.

The ACL name for the host policy, the redirect URL and the URL redirect ACL are conveyed by using RADIUS Attribute-Value objects.

Import Vendor Attribute-Value Pairs (AVPs)

ACS does not include any non-Cisco attributes by default. Therefore, you must import a NAC Attribute Definition File (ADF) from each vendor application that you would like to validate in your NAC posture-validation policies. The attributes that are added can be used to create conditions for internal policies.

NAC introduces the ability to authorize network hosts not only based upon user or machine identity; but also upon a host's posture validation. The posture validation is determined by comparing the host's credentials to a posture-validation policy which you create from attribute-value pairs (AVPs), which are defined by Cisco and other vendors who are NAC partners. Since the range of NAC attributes extends across many vendors and applications, you must import the non-Cisco attributes.

To import a NAC attribute definition file:


Step 1 Obtain one or more ADFs for the NAC-compatible applications that you want to validate with ACS.

Step 2 Place the ADFs on an FTP server that is accessible by the appliance.

Step 3 Add the AVPs through the NAC Attributes Management page.

Step 4 After successfully adding the AVPs, restart CSAdmin, CSLog, and CSAuth.


Setting a Posture-Validation Policy

A posture-validation policy can have one or more posture-validation rules. When ACS uses a posture-validation policy to evaluate a posture-validation request, the first match is implemented. The selected rules determines which internal and external policies will be activated for the request.

You can configure posture-validation policies that might be associated with a rule in Internal or External Posture Validation Setup, as applicable.

To add an internal posture-validation policy, external posture-validation server, or both, to a profile:


Step 1 Choose Network Access Profiles.

Step 2 Choose Posture Validation for the selected profile.

Step 3 The Posture Validation page appears. See Posture Validation Page.

Step 4 Click Add Rule. The Posture Validation Rule Page appears, see Posture Validation Rule Page.

Step 5 Enter a Name for the rule.

Step 6 Choose the Required Credential Types.

Use the arrows to move the Required Credential Types from the from the Available Credentials to the Selected Credentials.

Step 7 Check the appropriate check boxes to enable Internal Posture Validation Policies and External Posture Validation Servers.

Step 8 Use the System Posture Token Configuration Table to set PA Messages and URL Redirects for the System Posture Token. (optional)

Step 9 Click Submit.

Step 10 In the Posture Validation Page click Done.

The Network Access Profiles Page appears.

Step 11 Select Apply and Restart for your changes to take effect.

Step 12 Click Cancel to return to the posture-validation policy.


Posture Validation Page

Use this page to add or modify a posture-validation rule.

Field
Description

Rule Name

Displays the name for the posture-validation rule. Highlight the name to modify the rule.

Required Credential Types

A posture-validation rule can have one or more required credential types. ACS determines whether to use the rule to evaluate a posture-validation request by comparing the credentials that it received in the request to the required credential types that are associated with the rule. If the request includes each of the credential types specified, ACS uses the rule to evaluate the request. If the required credentials do not match, ACS successively tries to match the next sequential rule. If no rule matches, the user request fails and access is denied.

Required Credential Types are those that appear in the Selected Credentials list. Use the left and right arrow buttons to move highlighted credentials from one list to the other. The lists are:

The Available Credentials list displays the credential types that ACS does not require in a posture-validation request in order to use this posture-validation rule to evaluate the posture-validation request.

The Selected Credentials list displays the credential types that ACS does require in a posture-validation request in order to use this posture-validation rule to evaluate the posture-validation request.

Associate With

A posture-validation policy can have one or more posture-validation rules that are associated with it. When ACS evaluates a posture-validation request, it applies each of the internal policies and external server's policies that are associated with the rule to the attributes that are received in the request.

The policies that are associated with a rule are selected in the Posture Validation Rule configuration page.

Up/Down

Click the radio button to select the rule you want to reorder. Click the Up and Down buttons to set the order.

Add Rule

Opens the Posture Validation Rule Page on which you create a new posture-validation rule.

Select Audit

NAC-compliant AAA clients can handle NAC for computers that do not respond to attempts to start a posture-validation session with CTA by querying an audit server. If CTA is not installed on the computer or is unreachable for other reasons, NAC-compliant AAA clients will attempt to perform posture validation on an audit server. The result returned by an audit server is a posture token.

Posture-validation policies for external audit servers that may be associated with a rule are configured in Posture Validation External Posture Validation Audit Setup.


Posture Validation Rule Page

This page contains:

Field
Description

Rule Name

Displays the rule name for identification.

Add Rule

Click to add a posture-validation rule. The Posture Validation Rule configuration page appears.

Edit Rule

Highlight the Rule Name. The Posture Validation Rule configuration page for the specific profile appears for editing.

Action

Select Internal Posture Validation Policies

See Chapter 14, "Posture Validation" for more information.

Select External Posture Validation Server

See Chapter 14, "Posture Validation" for more information.

Failure Action

Check to configure the Fail Open feature.

Failure Posture Token

Select the credential type (AV pair) that is returned to the supplicant.

Select the Posture Token for the credential type.

System Posture Token Configuration

User this table to configure the SPT to return to the AAA client. There are six predefined, nonconfigurable SPTs. The SPT results are listed in order from best to worst.

System Posture Token

Enter a Posture Agent Message and URL Redirect for each posture token that you use.

PA Message

Enter a message that will appear for each posture agent.

Healthy-Host is compliant; no restrictions on network access.

Checkup-Host is within policy but an update is available. Used to proactively remediate a host to the Healthy state.

Transition-Host posturing is in process; give interim access pending full posture validation. Applicable during host boot when all services might not be running or audits are not yet available.

Quarantine-Host is out of compliance; restrict network access to a quarantined network for remediation. The host is not an active threat; but is vulnerable to a known attack or infection.

Infected-Host is an active threat to other endpoint devices; network access should be severely restricted or totally denied all network access.

Unknown-Host posture cannot be determined. Quarantine the host, and audit or remediate until a definitive posture can be determined.

URL Redirect-

Enter the URL redirect that will be sent to the AAA client for each posture token.


Deleting a Posture Validation Rule

To delete an internal posture-validation policy rule:


Step 1 Choose Network Access Profiles.

Step 2 Choose the Posture Validation for the selected profile.

Step 3 The Posture Validation Page appears.

Step 4 Click on Rule Name. The Posture Validation Rule Page appears.

Step 5 Click Delete.

A warning message appears.

Step 6 Click OK.


Audit Server Functionality

The audit server scans the host and returns the token to ACS.

The audit server may use asynchronous port scans, HTTP redirection, a proprietary client, and table lookups to provide posture-validation information.

ACS polls for the audit result, so the audit server must hold its results until the next poll.

System Posture Token Configuration

A system posture token is associated with the state of the computer and a posture token is associated with the state of a NAC-compliant application.

Actions are the result of applying a policy to the credentials received in a posture-validation request. ACS determines the posture token of each request by comparing the actions from all policies applied to the request. The worst posture token becomes the system posture token.

Mapping an Audit Server to a Profile

To add an external posture validation audit server to a profile:


Step 1 Choose Network Access Profiles.

Step 2 Choose Posture Validation for the relevant profile.

Step 3 Click Select Audit.

Step 4 Select the relevant audit server.

Step 5 Click Submit.

Step 6 Click Back for the posture-validation policy.

Step 7 Select Apply and Restart for your changes to take effect.


Posture Validation for Agentless Hosts

Posture-validation rules define what the returned posture token for posture validation will be. The posture-validation table includes posture-validation rules and audit configuration settings.

Posture-validation rules contain:

A required credential that defines the mandatory credential types that activate the rule.

The local policies and external servers that will execute to calculate the posture token.

PA (posture agent) Messages that will return to the client for each posture token.

A URL redirect that will be sent to the AAA client for each posture token.

A posture-validation policy can have 0-n ordered posture rules.

The posture validation selected is the first that match of the mandatory credential types.

The posture token that will return is the worst assessment that returned from the selected local policies and external posture servers.

If the client is an agentless host, the selected Audit server will audit the client.

Configuring Fail Open

You can configure fail open for errors that can prevent the retrieval of posture token from an upstream NAC server. If fail open is not configured, the user request is rejected.

You can select whether to enable fail open for:

Audit Server—for profiles that are associated with an audit server

External Posture Validation Server—for profiles that are associated with an External Posture Validation Server

If you enable fail open, you will need to select the posture token to be granted when an error occurs in the initial authentication.

To configure fail open for an audit server:


Step 1 Choose Network Access Profiles.

Step 2 Choose Posture Validation for the selected profile.

The Posture Validation Page appears.

Step 3 Choose Select Audit.

The Select External Posture Validation Audit for Profile Page appears.

Step 4 To enable fail open, check the Do Not reject when Audit failed check box.

Step 5 Select the posture token to be used in the event of a failure.

Step 6 Enter a value for session-timeout for the audit server.

Step 7 Click Submit.


To configure fail open for an external posture validation server:


Step 1 Choose Network Access Profiles.

Step 2 Choose Posture Validation for the selected profile.

The Posture Validation Page appears.

Step 3 Select the Rule Name. To configure a rule, see Configuring Posture-Validation Policies.

Step 4 On the Posture Validation Rule for Profile page, check the check box in the Select column for the external posture validation server that you want to configure.

Step 5 Do one:

Check Reject User to deny access for fail open.

In the Failure Posture Assessment field, select:

Credential Type—The namespace for the APT which replaces the APT that should have been returned from the failed server.

Posture Token—The posture token to be used in the event of a failure.

Step 6 Click Submit.


Select External Posture Validation Audit for Profile Page

This page contains:

Field
Description

Select

Click the radio button to select the external posture-validation audit server. Click Do Not Use Audit Server radio button if you do not want to use an audit server for posture validation.

Fail Open Configuration

Configure this option for any errors that might occur that prevent the retrieval of posture token from an upstream NAC server. If fail open is not configured, the user request is rejected.

Do not reject when Audit failed

Check this check box to enable fail open. The default is checked.

Use this token when unable to retrieve posture data

Select a token from the drop-down list.

Timeout

Set the timeout for the session granted.


Runtime Behavior

When fail open is configured, and an error occurs when communicating with an upstream posture-validation server, the policy results will be as if posture validation was successful. The SPT for the given policy will be a static, preconfigured value.

For an audit server, the configuration of fail open results in the SPT being set to the statically configured posture token. For External Posture Validation Servers, if more than one server is configured for a profile, each server that fails contributes an APT to the final SPT. The worst case token is used as the SPT, which symbolizes the overall posture of the NAC-client computer

Configuring Authorization Policies

Authorization policies comprise rules that are applied to a NAP. Authorization policies are used for authorizing an authenticated user. Authorization rules can be based on group membership, posture validation, or both. Authorization actions are built from the RADIUS Authorization Components and ACLs.

Credentials are used in identity and posture authorization. Each application's posture credentials are evaluated separately. Credentials are compared against the posture-validation policies.

When you configure authorization policies consider the result of:

User authentication is assignment to a User Group.

Posture validation is a System Posture Token.

EAP-FAST authentication and posture validation in the same session results in assignment to a user group and a posture token.

Authorization policies are a conversion of an ACS user group and a posture token to a set of RADIUS attributes that will be sent to the device. You may deny access for a specific user group, or deny access based on a returned token.


Note When you deny access for a specific condition, you do not need to select RAC or downloadable ACLs.


Authorization Rules

Authorization rules allow for variation of device provisioning within the NAP based on group membership and posture token.

The set of possible mappings is theoretically quite high-for each NAP-for each group and for each posture. However, in practice most users will be caught by a default case; for example, normal healthy users.

Exceptions to the norm would be corner cases, such as groups that require specialized access rights (for example, administrators) or users with Infected or Quarantined postures.

Therefore, when you design the authorization rules, it is useful to define the normal condition first; then the set of exception cases that require more specific mappings.

In a non-NAC network, leave the System Posture Token as Any.

An authorization rule can be defined as:

If the user-group = selected-user-group or the posture-assessment = selected-posture-assessment, then provision the profile with the selected-RAC or the selected DACL.

You can also use authorization rules to explicitly deny (send an access-reject) as an action.

This section contains the following information on configuring authorization rules:

Configuring an Authorization Rule

Configuring a Default Authorization Rule

Ordering the Authorization Rules

Deleting an Authorization Rule

Shared RACs

RAC and Groups

Merging Attributes

Troubleshooting Profiles

Migrating from Groups to RACs

Configuring an Authorization Rule

To configure an authorization rule:


Step 1 Choose Network Access Profiles.

Step 2 Choose the relevant profile Authorization policy.

Step 3 The Authorization Rules for Profile Page appears.

Step 4 Click Add Rule. The Authorization Rules for Profile Page appears.

Step 5 Select a User Group from the drop-down list.

Step 6 Select the System Posture Token

Step 7 Select Authentication Actions

You may select to deny access or one or both authorization actions to implement when the authorization rules match:

Deny Access—Check this option to deny access for users that have matching conditions.

Shared RAC—Select a Shared RAC from the drop-down list. See Shared RACs.

Downloadable ACL—Select a downloadable ACL from the drop-down list. See Downloadable ACLs.

Step 8 Set RADIUS attribute overrides.

The following options are enabled by default. Uncheck them if you do not want to use RADIUS attributes per user record or per user's group:

Include RADIUS attributes from user's group

Include RADIUS attributes from user's record

Step 9 Click Submit.


Authorization Rules for Profile Page

This page contains:

Field
Description

Condition

User Group

Select the ACS group to which the user was mapped. This field defines the group of users for this rule. If you are not basing authorization rules on authentication, select Any.

System Posture Token

Select the posture token that was returned as a result of posture validation. ACS checks the token status before proceeding to follow the configured actions. You can use posture tokens to validate user groups. If you are not using posture validation, select Any.

Action

Deny Access

Enable this option to deny access for requests that do not match any configured policy.

Shared RAC

Select Shared RAC from the drop-down list. RAC are defined in Shared Profile Components > RADIUS Authorization Components option. For more information, see RADIUS Authorization Components, page 5-6.

Note If you configure an external posture validation audit server to use session-timeout settings in the Authorization policy, you must select a shared RAC. See External Audit Server Configuration Options, page 14-16.

DACL

Select Interface Configuration > Advanced Options and then select User or Group Level Downloadable ACLs or both. Proceed to Shared Profile Components and then select Downloadable IP ACLs. For more information, see Downloadable IP ACLs, page 5-13.


Configuring a Default Authorization Rule

You can set a default authorization rule if a condition is not defined or no matched condition is found. You can deny or grant access based on Shared RACs and DACLs selections.

To configure a default authorization rule:


Step 1 Choose Network Access Profiles.

Step 2 Choose the relevant profile Authorization policy.

Step 3 The Authorization Rules for Profile Page appears.

Step 4 Click Add Rule. The Authorization Rules for Profile Page appears.

Step 5 Select Authentication Action for the line that contains the text If a condition is not defined or there is no matched condition.

Step 6 Select Authentication Actions.

You may select an authorization action to implement for the default rule:

Deny Access-Check this option to deny access for users that have matching conditions.You do not have to select any shared RACs or DACLs for this option.

Shared RAC-Select a Shared RAC from the drop-down list. For more information, see Shared RACs.

Downloadable ACL-Select a downloadable ACL from the drop-down list. See Downloadable IP ACLs, page 5-13 for more information.

Step 7 Set RADIUS attribute overrides.

The following options are enabled by default. Uncheck them if you do not want to use RADIUS attributes per user record or per user's group:

Include RADIUS attributes from user's group

Include RADIUS attributes from user record

Step 8 Click Submit.


Ordering the Authorization Rules

The authorization policy first match is implemented to authorize a client request.


Note You must place your highest priority authorization policies at the top of the list. If you select Any Group for the User Group or Any Assessment for the posture token first match, the underlying policies will not be effective because authorization accepts the first match.


When you specify the order of conditions in a policy, determine the likelihood of each condition to be true and then order the policies so that the condition most likely to be true is first and the least likely to be true is last.

To order authorization rules:


Step 1 Click the radio button to select the authorization rule that you want to reorder.

Step 2 Click Up or Down to set the order.


Deleting an Authorization Rule

To delete an authorization rule:


Step 1 Click Internal Posture Validation Policies, External Posture Validation Servers to select an authorization policy.

Step 2 Click Delete to remove the selected rule.

By default, RADIUS attribute rules from user or group records are enabled.


Shared RACs

You can use NAPs to provision the same RADIUS attribute to have different values for different users, groups and NAPs. The one-user-one-group-one-profile is now more flexible by using profile based policies instead. For each NAP, you can configure what policies will authenticate and authorize based on RADIUS attribute values.

For a particular group (for example, Admins) who require distinct authorization profiles for the Corporate LAN, VPN, and WLAN NAPs, you can assign them a specific set of RADIUS attributes to allow them special access. If your user is in a group named contractors, they may get the same set of attributes with different values that may specify more stringent security measures.

RAC and Groups

ACS groups hold attributes that are related to the user group (for example admins, contractors, and so on) and do not cater to the same groups of users that require authorization for different network services (WLAN, VPN, and so on).

RACs hold attributes that can be specific to a single network profile by using authorization policies. You can map from various groups and postures to a set of RACs and ACLs.

You should use RACs when the customer requires profile-differentiated RADIUS authorization. For example, if the session-timeout must be several days for VPN and several hours for WLAN.

Merging Attributes

You can merge RADIUS attributes, downloadable ACLs, and other attributes that are created dynamically. RADIUS attributes can be at a user record level, group level and shared RAC level.

When group or user attributes are enabled, attribute merging is performed by a process of repeated overriding whatever is listed in priority order, highest first. The order is:

User overrides

Dynamic session (for example, posture token)

Authentication protocol (for example, session timeout, wireless session keys)

Downloadable ACL (assignment)

Shared RACs

Static group

The attributes in the assigned Shared RAC override those that are defined in a static ACS group. That attribute set is then overridden with attributes from downloadable ACL and so on. Be cautious when you use NAP authorization policies.

By default, RADIUS attribute rules from user or group records are enabled.

Troubleshooting Profiles

If the profile that is sent to the device is not what you expected, the authorization policy has probably been changed to disable group or user attributes. These attributes are being merged with the RAC that the policy assigns. Other possibilities are that ACS automatically adds certain attributes as part of the authentication protocol or an external audit server might sometimes dictate a specific Session-Timeout.

Ensure that attribute merging is not selected.


Note The Session-Timeout values for NAC deployments can have a significant impact on ACS performance. You should adjust it for the scale of your network and ACS transaction capacity.


Migrating from Groups to RACs

To set up a plan to migrate from groups to RACs:


Step 1 Define the appropriate network access policies and define rules.

Step 2 Create a matrix that shows the level of authorization for each user group and posture.

Step 3 Group all the similar cases and create RACs for them.

Step 4 Remove any previously defined attributes from the users groups if desired.

Step 5 You can use group attributes (if the authorization policy check box is selected) so that you can apply profile-independent attributes to all users of the group without having to duplicate each RAC for each profile.

When you merge between group, RAC, and user attributes, remember that attributes set at a group level are not guaranteed to make the final profile. Depending on your selections, RAC might override them.

You can create a base template authorization at group level and then supply the profile-specific attributes by using RACs. For example, setting a different Session-Timeout for VPN and WLAN.


Policy Replication and Backup

All NAP policies are entirely replicated when you select NAPs for replication. Profiles contain a collaboration of configuration settings. The profile replication components include:

Network Access Profiles

Posture-validation settings

AAA clients and hosts

External database configuration

Global authentication configuration

NDGs

Dictionaries

Shared-profile components (RAC, NAF, and downloadable ACLs)

Additional logging attributes.

EAP-FAST uses a different mechanism for replication and, therefore, should also be checked.


Note Replication of profiles contradicts with replication of Network Configuration Device tables, therefore do not check both of these components at the same time. Replication in ACS only works between the same versions of ACS. Replication does not include external databases and all other global ACS configuration parameters.


To replicate policies:


Step 1 In the navigation bar, click System Configuration.

Step 2 In the Database Replication Setup page select Network Access Profiles.

Step 3 Select whether this ACS is to receive or send the information.