-
User Guide for Cisco Secure Access Control Server 4.1
-
Preface
-
Overview
-
Using the Web Interface
-
Network Configuration
-
Shared Profile Components
-
User Group Management
-
User Management
-
System Configuration: Basic
-
System Configuration: Advanced
-
System Configuration: Authentication and Certificates
-
Logs and Reports
-
Administrators and Administrative Policy
-
User Databases
-
Posture Validation
-
Network Access Profiles
-
Unknown User Policy
-
User Group Mapping and Specification
-
Troubleshooting
-
TACACS+ Attribute-Value Pairs
-
RADIUS Attributes
-
CSUtil Database Utility
-
VPDN Processing
-
RDBMS Synchronization Import Definitions
-
Internal Architecture
-
Index
-
Feedback
Table Of Contents
Classification of Access Requests
Workflow for Configuring NAPs and Profile-based Policies
Processing Unmatched User Requests
Prerequisites for Using Profile Templates
Creating a Profile with a Profile Template
Agentless Host for L2 (802.1x Fallback)
Configuring Policies for Profiles
Protocol Configuration for NAPs
EAP-FAST with Posture Validation
EAP-TLS Authentication with RADIUS Key Wrap
Authentication Policy Configuration for NAPs
Credential Validation Databases
Configuring Authentication Policies
Posture-Validation Policy Configuration for NAPs
About Posture Validation Rules
Setting a Posture-Validation Policy
Deleting a Posture Validation Rule
Configuring Posture Validation for Agentless Hosts
Authorization Policy Configuration for NAPs
Configuring an Authorization Rule
Configuring a Default Authorization Rule
Ordering the Authorization Rules
Deleting an Authorization Rule
Network Access Profiles Pages Reference
Create Profile from Template Page
Protocols Settings for profile_name Page
Authentication for profile_name Page
Posture Validation Rule for profile_name Page
Select External Posture Validation Audit for profile_name Page
Authorization Rules for profile_name
Network Access Profiles
The Cisco Secure Access Control Server Release 4.1, hereafter referred to as ACS, supports Network Access Profiles (NAP). This chapter describes NAPs and contains the following topics:
•
Configuring Policies for Profiles
•
•
Overview of NAPs
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 who 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 (for example, dial, VPN, home wireless).
A NAP, also known as a profile, is essentially a classification of network-access requests for applying a common policy. You can use NAPs to aggregate all policies that should be activated for a certain location in the network. Alternatively, you can aggregate all policies that handle the same device type, for example, VPNs or Access Points (APs).
Note
The following topics describe NAPs and their associated policies:
•
•
•
Classification of Access Requests
You can classify access requests according to the AAA clients' IP addresses, membership in a network device group (NDG), protocol types, or other specific RADIUS attribute values sent by the network device through which the user connects.
You can use one or all of the following classification methods to classify access requests:
•
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 network access filter (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.
NAFs
NAFs are groupings of AAA client configurations (which might represent multiple network devices), NDGs, or IP addresses of specific AAA client devices. 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.
Note
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.
Advanced Filtering
You can create rules based on specific RADIUS attributes and values (including Cisco AV pairs). Each rule contains one or more rule elements, and each rule element 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. For more information about advanced filtering options, see Profile Setup Page.
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 profile-based policies include rules for authentication, authorization, and posture validation.
By defining profile-based policies, you 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 RSA One-Time Password (OTP) directory.
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. ACS uses 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.
Workflow for Configuring NAPs and Profile-based Policies
You can create a profile from scratch, or you can use one of the supplied templates to populate some default values. The templates that are provided are particularly useful for NAC-enabled networks. See Using Profile Templates, for more information.
The following is the order of work for creating NAPs and their associated policies:
1.
ip_admission).2.
3.
4.
5.
6.
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.Processing Unmatched User Requests
In ACS you can configure global configuration settings as well as NAP-specific settings. The global configuration settings serve two purposes:
•
•
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 deny access when no profile matches and the access request cannot be classified.
The only case where ACS fallback behavior and NAPs should be used is with TACACS+. NAPs does not currently support TACACS+. Granting access using the global configuration 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.
Managing NAPs
These topics describe how to set up and manage NAPs:
Adding a Profile
This topic describes how to set up a profile from scratch. For information about creating a profile from a profile template, see Using Profile Templates.
To add a profile:
Step 1
The Network Access Profiles Page appears.
Step 2
The Profile Setup page appears.
Step 3
Step 4
Step 5
Step 6
Step 7
The Network Access Profile page reappears. The Network Access Profile's first match is implemented to authenticate or authorize a client request, or both.
Step 8
Step 9
Step 10
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
Step 2
Step 3
Editing a Profile
To edit the profile configuration:
Step 1
The Network Access Profiles page appears.
Step 2
a.
The Profile Setup page appears.
b.
Step 3
a.
The relevant policy configuration page appears.
b.
Step 4
Cloning a Profile
Cloning replicates all the following relevant components for a NAP:
•
•
•
•
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
The Network Access Profiles page appears.
Step 2
The Profile Setup page appears.
Step 3
A copy of the cloned profile appears in the Network Access Profiles page.
Step 4
Step 5
Deleting a Profile
To delete a profile:
Step 1
The Network Access Profiles page appears.
Step 2
The Profile Setup page appears.
Step 3
A warning message appears.
Step 4
Step 5
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. For a list of templates, see Profile Templates. The templates include a preconfigured set of NAC samples that you can use as the basis for building NAC policies. After you have set up a new profile based on a template, you can customize the profile settings to the specific needs of your security policy.
Note
When you select a predefined template, ACS creates a full-scale NAP, including profile authentication, posture validation, and authorization policies.
The following topics describe profile templates and how to use them:
•
•
Prerequisites for Using Profile Templates
Before you can use a profile template, you must configure:
•
•
•
•
•
•
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 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
Creating a Profile with a Profile Template
To select a profile template:
Step 1
The Network Access Profiles page appears.
Step 2
The Create Profile from Template Page, appears.
Step 3
Step 4
Step 5
Step 6
A window appears showing the new objects that have been created for the profile.
Step 7
The Network Access Profiles page reappears showing the new profile.
Step 8
Profile Templates
These topics describe the profile templates that ACS provides:
•
•
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, ensure that you have checked the following options in the Global Authentication Setup page:
•
•
•
•
Downloadable ACLs
Downloadable per-user ACL support is available for Layer 3 network devices that support downloadable ACLs. These include 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 you use this feature 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.
Table 14-1 describes the Profile Sample in the NAC Layer 3 IP Sample Profile Template.
Table 14-3 describes the posture-validation policies in the NAC Layer 3 IP Sample Profile Template.
Table 14-4 describes the Shared Profile Components in the NAC Layer 3 IP Sample Profile Template.
NAC L2 IP
Before you use this template, ensure that you have checked the Enable EAP Configuration > Allow Posture Validation option in the Global Authentication Setup page.
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.
This template sets Advanced Filtering and Authentication properties with NAC-L2-IP Configuration automatically.
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).
•
#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 = <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 a 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. The Authentication Bypass (802.1x fallback) template is used for access requests to bypass the nonclient authentication process. Users are mapped to a User Group based on their identity.
Note
Table 14-5 describes the content of the Profile in the NAC Layer 2 IP Sample Profile Template.
Table 14-6 describes the content of the Authorization Rules in the NAC Layer 2 IP Sample Profile Template.
Table 14-7 describes the content of the posture-validation policies in the NAC Layer 2 IP Sample Profile Template.
NAC Layer 2 802.1x
Before you use this template, ensure that you have checked the following options in the Global Authentication Setup page:
•
•
•
•
Table 14-8 describes the content of the NAC L2 802.1x Sample Profile Template.
Table 14-9 describes the content of the Authorization Rules in the NAC Layer 802.1x Sample Profile Template.
Table 14-10 describes the content of the posture-validation policies in the NAC Layer 802.1x Sample Profile Template.
Table 14-11 describes the content of the Shared Profile Components in the NAC Layer 802.1x Sample Profile Template.
Microsoft IEEE 802.1x
Before you use this template, ensure that you have checked the Allow EAP-MS-CHAPv2 option in the Global Authentication Setup page.
Table 14-12 describes the Profile Sample in the Microsoft IEEE 802.1x Sample Profile Template.
Table 14-13 describes the Authorization Rules in the Microsoft IEEE 802.1x Sample Profile Template.
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.
Agentless Host for L2 (802.1x Fallback)
You can use the Agentless Host for L2 (802.1x Fallback) profile template 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.
Table 14-14 describes the content of the Profile Sample in the Agentless Host for L2 (802.1x Fallback) Sample Profile Template.
Table 14-15 describes the content of the Authorization Rules in the Authentication Bypass Sample Profile Template.
Agentless Host for L3
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 14-16 describes the Profile Sample in the Agentless Host for L3 Sample Profile Template.
Table 14-17 describes the Shared Profile Components in the Agentless Host for L3 Sample Profile Template.
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. You can configure policies for:
•
•
•
•
ACS associates attributes according to the profile that was requested. The attributes that are returned in an
Access-Acceptmessage are a consolidation of attributes that are associated with a profile (such asTunnel-Typefor a VPN profile request) and session-specific attributes that are bound to the end-user (such asIdle-Timeoutfor 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.These topics describe how to configure and manage policies for NAPs:
•
•
•
•
Protocol Configuration for NAPs
These topics describe how to configure authentication protocols for NAPs:
•
•
Authentication Protocols
You can configure all relevant parameters for authentication protocols for your NAPs. These parameters are applied during access request processing.
The following authentication protocols, listed from weakest to most secure, can be configured:
•
–
–
–
–
–
–
•
–
–
–
–
The protocols that you select determine the flexibility of negotiation. The final result is to determine which protocol to use to authenticate. For more information about protocols, see About Certification and EAP Protocols, page 9-1.
Note
Populating Protocol setting with ACS Global Settings
You can populate the protocol settings with the ACS global settings, and then customize them. This method facilitates configuring the protocol settings each time you set up a new profile.
Global Authentication Setup 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 automatically be unchecked in all ACS (active and inactive) profiles. Options that are not available in the Global Authentication Setup page, are unchecked in the Protocol Settings page after populating from the Global Authentication Setup page.
To apply global settings: Click Populate from Global to apply authentication settings that were set in the System Configuration > Global Authentication Setup window. For more information, see Configuring Authentication Options, page 9-19.
Note
Agentless Request Processing
Agentless Request Processing 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 (Media Access Control) address of the endhost connecting to the switch. Agentless 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. You can use a configured LDAP server or the internal ACS Database to authenticate MAC address user requests. ACS uses the LDAP server to look up MAC addresses and to retrieve LDAP group attributes for MAC addresses. If the MAC addresses exist in the LDAP Server, ACS maps the LDAP Group to the ACS Groups configured in the configured ACS External LDAP Database. ACS accepts any of the MAC address standard formats. 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.
For information about configuring the LDAP external database for agentless requests see Configuration Guide for Cisco Secure ACS Release 4.1.
The MAC address is sent in the Calling-Station-ID RADIUS attribute. ACS identifies an Agentless Request in this manner:
Service-Type = 10 (Call Check)
If the Agentless Request Processing option is not enabled, MAC address authentication is not applied and the access request is rejected.
ACS supports the following three standard formats for representing MAC-48 addresses in human-readable form:
•
•
•
An Error alert appears for invalid MAC addresses. MAC addresses are presented in one format regardless of the format in which they were entered into ACS.
To process agentless requests, Agentless Request Processing must be enabled in the Protocols Settings for profile_name Page. You must also define settings in the Authentication for profile_name Page. You choose which configured database to use to authenticate a MAC address user request, and define the default mapping for MAC addresses that do not match.
EAP Configuration for NAPs
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:
•
•
•
•
•
The following extended EAP methods are available for NAC:
•
•
•
EAP-FAST with Posture Validation
Several organizations might be in the process of supplying their hosts with the Cisco Trust Agent and some hosts might or might not have the Cisco Trust Agent installed. Cases might arise where you might want to enforce posture validation on machines with the Cisco Trust Agent; however, you do not want to fail authentication on those machines that are temporarily without the Cisco Trust Agent. 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 13-3.
Note
EAP-TLS Authentication with RADIUS Key Wrap
You can configure ACS to use EAP-TLS authentication with RADIUS Key Wrap. ACS can then authenticate RADIUS messages and distribute the EAP-TLS session key to the network access server (NAS). The EAP-TLS session key is encrypted by using Advanced Encryption Standard (AES), and the RADIUS message is authenticated by using HMAC-SHA-1.
Because RADIUS is used to transport EAP messages (in the EAP-Message attribute), securely authenticating RADIUS messages ensures securely authenticated EAP message exchanges. You can use RADIUS Key Wrap when EAP-TLS authentication is enabled as an external authentication method. Key Wrap is not supported for EAP-TLS as an inner method (for example, for EAP-FAST or PEAP).
RADIUS Key Wrap support in ACS uses three new AVPs for the Cisco-AV-pair RADIUS Vendor-Specific-Attribute (VSA); the TLV value of Cisco VSA is [26/9/1]):
•
•
•
When using RADIUS Key Wrap, ACS enforces the use of these three RADIUS Key Wrap AVPs for message exchanges and key delivery. ACS will reject all RADIUS (EAP) requests that contain RADIUS Key Wrap AVPs and the standard RADIUS Message-Authenticator attribute.
To use RADIUS Key Wrap in EAP-TLS authentications, you must enable EAP-TLS authentication with RADIUS Key Wrap in the Protocol Settings page for the NAP. You must also define two shared secret keys for each AAA Client, or for an NDG. Each key must be unique, and must also be distinct from the RADIUS shared key. RADIUS Key Wrap does not support proxy functionality, and should not be used with a proxy configuration.
Configuring Protocols
To configure protocols for NAPs:
Step 1
The Network Access Profiles page appears.
Step 2
The Protocols and EAP Configuration page appears.
Step 3
Note
Step 4
Step 5
Step 6
The Network Access Profiles page reappears.
Step 7
Authentication Policy Configuration for NAPs
Authentication settings define which databases are used to validate the credentials of the user for authentication. Before you configure authentication policies configure the External User Databases that you mapped to ACS user groups by the mapping rules that are defined in Database Group Mapping.
Note
You can also configure Agentless Request Processing settings as part of your authentication policy. For more information, see Agentless Request Processing.
These topics describe how to configure authentication settings:
•
•
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
Configuring Authentication Policies
To configure authentication policies for NAPs:
Step 1
Step 2
The Authentication Settings page appears.
Step 3
Step 4
Step 5
a.
b.
For information about options, see Authentication for profile_name Page.
Step 6
The Network Access Profiles page reappears.
Step 7
Posture-Validation Policy Configuration for NAPs
These topics contain information about configuring posture-validation policies:
•
•
•
•
About Posture Validation Rules
Posture validation rules are used to select the posture validation components. A posture validation rule is comprised of a condition and actions. The condition is a set of required credential types. The actions are to determine which internal policies or external servers should be used for posture validation. Posture validation rules return a posture token and action for a posture request. See Chapter 13, "Posture Validation," 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 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.
Each rule contains:
•
•
•
•
•
Note
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.
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.
For more information about setting up audit servers, see Setting Up an External Audit Posture Validation Server, page 13-23.
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.
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:
•
•
The ACL name for the host policy, the redirect URL, and the URL redirect ACL are conveyed by using RADIUS Attribute-Value objects.
Fail Open for Errors
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.
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.
You can select whether to enable fail open for profiles that are associated with an:
•
•
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 determine 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.
Before you begin:
•
•
To add an internal posture-validation policy, external posture-validation server, or both, to a profile:
Step 1
Step 2
The Posture Validation page appears.
Step 3
The Posture Validation Rule Page appears. For details of options on this page, see Posture Validation Rule for profile_name Page.
Step 4
Step 5
Step 6
Step 7
•
•
–
–
Step 8
Step 9
Step 10
The Network Access Profiles page reappears.
Step 11
Step 12
Deleting a Posture Validation Rule
To delete an internal posture-validation policy rule:
Step 1
Step 2
The Posture Validation page appears.
Step 3
Step 4
A warning message appears.
Step 5
Configuring 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 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.
To configure a posture validation policy for a NAH:
Step 1
Step 2
The Posture Validation Page appears.
Step 3
The Select External Posture Validation Audit for profile_name Page appears.
Step 4
Step 5
a.
b.
c.
d.
Step 6
Step 7
Authorization Policy Configuration for NAPs
These topics provide information on configuring authorization rules:
•
•
•
•
About Authorization Rules
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 RACs and ACLs.
For more information about configuring RACs, see RADIUS Authorization Components, page 4-6. For more information about downloadable ACLs, see Downloadable IP ACLs, page 4-13.
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 if:
•
•
•
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.
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.
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 might be 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.
You can also use authorization rules to explicitly deny (send an access-reject) as an action.
After you have configured your authorization rules, check that the Network Access Restriction (NAR) policies for the selected user group do not override the NAP policies. Accept or reject will be applied, depending on the result of the NAR evaluation. For more information, see Network Access Restrictions, page 4-18.
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. 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. For more information about configuring RACs for NAPs, see Understanding RACs and NAPs, page 4-7
Merging Attributes
You can use RADIUS attribute overrides for group or user attributes. When you choose these options, ACS merges 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.
Attribute merging is performed by a process of repeated overriding whatever is listed in priority order, highest first. The order is:
•
•
•
•
•
•
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.
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.
Configuring an Authorization Rule
Before You Begin
Define per-service provisioning components (Shared RACs and DACLs). If required for a given service, create custom RACs and DACLS for those groups of users that require specific settings.
To configure an authorization rule:
Step 1
Step 2
The Authorization Rule page appears.
Step 3
A new rule row appears.
Step 4
•
•
For more information about condition options, see Authorization Rules for profile_name.
Step 5
You can deny access or you can choose one or both authorization actions to implement when the authorization rules match:
•
•
•
For more information about action options, see Authorization Rules for profile_name.
Step 6
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:
•
•
Step 7
Related Topics
•
•
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
Step 2
The Authorization Rules for profile_name appears.
Step 3
Step 4
Step 5
You may select an authorization action to implement for the default rule:
•
•
•
Step 6
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:
•
•
Step 7
Ordering the Authorization Rules
The authorization policy first match is implemented to authorize a client request.
Note
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
Step 2
Deleting an Authorization Rule
To delete an authorization rule:
Step 1
Step 2
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
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:
•
•
•
•
•
•
•
•
•
EAP-FAST uses a different mechanism for replication and, therefore, should also be checked.
Note
For more information about replication, see ACS Internal Database Replication, page 8-1.
Network Access Profiles Pages Reference
These topics describe the pages in the Network Access Profile section of the ACS web interface:
•
•
•
•
•
•
Network Access Profiles Page
The Network Access Profiles page is the starting point for configuring profile-based policies.
To open this page, click Network Access Profiles on the navigation bar.
Table 14-18 Network Access Profiles Page
Name
Activates the configuration for the profile. Opens the Profile Setup Page.
Policies
Contains links to protocols, authentication, posture validation, and authorization policies.
•
•
•
•
Add Profile
Opens the Profile Setup Page to configure NAPs.
Add Template Profile
Creates a profile from a selection of templates including NAC L3 IP, NAC L2 IP, and Agentless Host. Use the templates to facilitate the construction of a profile. Opens the Create Profile from Template Page.
Up and Down buttons
Changes the order of the profiles. Click the Up or Down buttons to change the sort order.
Deny access when no profile matches
When enabled, and the access request does not match any profile, authentication fails and ACS denies the access request. This is the recommended option for handling unmatched access requests.
Grant access using global configuration, when no profile matches
When enabled, and the access request does not match any profile, authentication fails and ACS grants the access request based on the default configuration. The Unknown User policy then determines packet processing. Use this option for TACACS+ with NAPs.
Apply and Restart
Restarts ACS and applies the modifications.
Related Topics
Profile Setup Page
Use this page to add, edit, clone, or delete a Network Access Profile.
To open this page, choose Network Access Profiles > Add Profile or highlight the profile Name.
Table 14-19 Profile Setup Page
Name
The profile name.
Description
The profile description.
Active
Activates or deactivates the profile.
The list of available NAFS for use with this profile (Default = Any).
The list of client vendor types from which ACS allows access requests.
•
•
Attribute
A list of all RADIUS attributes. 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.
Note
Operator
The list of operators appropriate to each attribute. Defines the comparison method by which ACS evaluates whether the rule element is true.
•
•
•
•
•
•
•
•
•
–
–
Note
Value
A value appropriate to the attribute.
Cisco-av-pair
For the {026/009/001} cisco-av-pair attribute, the operator and values for the av-pair-key and av-pair-value.
Submit
Submits modifications. Returns to the Profile Setup Page.
Clone
Creates a copy of the NAP.
Delete
Deletes a profile, after warning.
Cancel
Returns to the Profile Setup Page without implementing changes.
Related Topics
•
Create Profile from Template Page
Use to this page to create a new profile from a template.
To open this page, choose Network Access Profiles > Add Profile from Template.
Table 14-20 Create Profile from Template Page
Name
A name for the profile.
Description
A description for the profile.
Template
The list of available templates.
Note
Active
Activates or deactivates the profile.
Submit
Submits modifications. Returns to the Profile Setup Page.
Cancel
Returns to the Profile Setup Page without implementing changes.
Related Topics
Protocols Settings for profile_name Page
Use this page to set password protocols and EAP configuration.
To open this page, choose Network Access Profiles > Protocols (appears for each profile).
Table 14-21 Protocols and EAP Configuration Page
Populate from Global
Populates the Protocol Settings with the ACS Global Authentication settings. This method facilitates configuration of the authentication settings for new profiles.
Allow PAP
Enables PAP. PAP uses clear-text passwords (that is, unencrypted passwords) and is the least secure authentication protocol.
Allow CHAP
Enables CHAP. CHAP uses a challenge-response mechanism with password encryption. CHAP does not work with the Windows user database.
Allow MS-CHAPv1
Enables MS-CHAPv1.
Allow MS-CHAPv2
Enables MS-CHAPv2.
Allow Agentless Request Processing
Enable to configure the authentication process for a profile that receives a MAC address request.
The PEAP types. Check at least one box to enable authentication with PEAP. In most cases, check all boxes.
Note
•
•
•
•
Allow EAP-FAST
Enables 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.
•
•
Allow Stateless session resume
When enabled, ACS provisions authorization PACs for EAP-FAST clients and always perform phase 2 of EAP-FAST (default = enabled).
•
Allowed inner methods
When enabled, determines 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
•
•
•
Posture Validation
Determines the EAP-FAST posture-validation mode. Select one of the following posture-validation modes:
•
•
•
•
•
EAP-TLS
Enables EAP-TLS authentication.
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
Enables EAP-based Message Digest 5 hashed authentication.
Related Topics
Protocol Configuration for NAPs
Authentication for profile_name Page
Use this page to specify the databases that the profile uses for authentication rules, and to setup the Agentless Request Processing configuration.
To display this page, choose Network Access Profiles > Authentication (appears for each profile).
Table 14-22 Authentication Settings Page
Credential Validation Databases
The lists of Available Databases and Selected Databases that can validate users. The lists of databases include the ACS Internal Database and all databases configured in External User Databases > Unknown User Policy. If the Unknown User Policy configures a database to fail, the database cannot become a validation database and fails with an error message.
Populate from Global
Populates the Authentication Settings from the System Configuration > Global Authentication Setup page. Facilitates configuration of the authentication settings.
ACS can authenticate MAC addresses with an LDAP server or the ACS Internal Database.
ACS supports the following three standard formats for representing MAC-48 addresses in human-readable form:
•
•
•
LDAP Server
If chosen, configures an LDAP server from the available servers on the External User Databases > External User Database Configuration page.
ACS uses the LDAP server to look up MAC addresses and to retrieve LDAP group attributes for MAC addresses. If the MAC addresses exist in the LDAP Server, ACS maps the LDAP Group to the ACS Groups configured in the configured ACS External LDAP Database.
Internal ACS Database
If chosen, provides fields for MAC Addresses, each with an associated User Group.
Each NAP can hold up to 10,000 MAC addresses in the Authentication 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.
Default Action (If Agentless request was not assigned to a user group)
If the MAC addresses were not found in the LDAP Server or the ACS Internal Database, or if the LDAP Server is not reachable, provides a group to which to assign the MAC addresses.
Submit
Submits changes to the ACS internal database.
Cancel
Returns to the Network Access Profiles Page without submitting new changes.
Related Topics
•
Posture Validation Page
Use this page to order and associate Posture Validation rules.
To display this page, click Posture Validation in the Network Access Profiles Page.
Table 14-23 Posture Validation Page for profile_name Page
Rule Name
The name of the posture-validation rule.
Required Credential Types
The Available Credentials list displays the credential types that ACS does not require.
The Selected Credentials list displays the credential types that ACS requires in a posture-validation request in order to use this posture-validation rule to evaluate the posture-validation request.
Associate With
The policies that are associated with a rule.
Up/Down
Sets the order of evaluation.
Add Rule
Opens the Posture Validation Rule for profile_name Page on which you create a new posture-validation rule.
Select Audit
Opens the Select External Posture Validation Audit for profile_name Page to configure an audit server for NAH. NAC-compliant AAA clients can handle NAC for computers that do not respond to attempts to start a posture-validation session with the Cisco Trust Agent by querying an audit server. If the Cisco Trust Agent 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 that an audit server returns is a posture token.
Related Topics
•
•
Posture Validation Rule for profile_name Page
Use this page to define a Posture Validation rule.
To display this page, click Add Rule in the Posture Validation Page.
Related Topics
•
•
•
Select External Posture Validation Audit for profile_name Page
Use this page to select an external posture validation audit server for posture validation.
To display this page, click Select Audit in the Posture Validation Page.
Related Topics
•
•
Authorization Rules for profile_name
Use this page to list the set of authorization rules for a Network Access Profile.
To display this page, click Authorization in the Network Access Profiles Page.
Table 14-25 Authorization Rules for profile_name
User Group
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
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.
Deny Access
Denies access for requests that do not match any configured policy.
Shared RAC
The list of RACs defined in the Shared Profile Components > RADIUS Authorization Components option.
Note
Downloadable ACL
The list of downloadable ACLs defined in Shared Profile Components > Downloadable IP ACLs.
If a condition is not defined or there is no matched condition:
A default action when a matched condition is not found.
Include RADIUS attributes from user's group
Enable to use RADIUS attributes per user's group.
Include RADIUS attributes from user record
Enable to use RADIUS attributes per user record.
Related Topics
•
