-
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
Posture Validation in Network Access Control
Posture Validation and Network Access Profiles
The Posture Validation Process
About Posture Credentials and Attributes
Posture Validation Attribute Data Types
About Rules, Rule Elements, and Attributes
External Posture Validation Audit Servers
How an External Audit Gets Triggered
Setting Up Posture Validation Policies
Cloning a Policy or Policy Rule
Deleting a Condition Component or Condition Set
Setting Up an External Policy Server
Editing an External Posture Validation Server
Deleting an External Posture Validation Server
Setting Up an External Audit Posture Validation Server
Adding an External Posture Validation Audit Server
Editing an External Posture Validation Audit Server
Deleting an External Posture Validation Server
Audit Processing with MAC Authentication Bypass
Posture Validation Pages Reference
Posture Validation Components Setup Page
Internal Posture Validation Setup Pages
Posture Validation Policies Page
Posture Validation Policy Page
Posture Validation Rules for <policy_name> Page
Posture Validation Rule - <policy_name> Page
External Posture Validation Setup Pages
External Posture Validation Servers Page
Add/Edit External Posture Validation Server Page
External Posture Validation Audit Setup Pages
External Posture Validation Audit Server Page
External Posture Validation Audit Server Setup Page
Posture Validation
The Cisco Secure Access Control Server Release 4.1, hereafter referred to as ACS, supports posture validation when ACS is deployed as part of a broader Cisco Network Access Control (NAC) solution.
This chapter contains:
•
Posture Validation in Network Access Control
•
•
•
•
•
What is Posture Validation?
The term posture refers to the collection of attributes that play a role in the conduct and "health" of an endpoint device that is seeking access to the network. Some of these attributes relate to the endpoint device-type and operating system; other attributes belong to various security applications that might be present on the endpoint, such as antivirus (AV) scanning software.
Posture validation applies a set of rules to the posture data associated with an endpoint. The result is an assessment of the level of trust associated with the endpoint. A posture token, such as Healthy or Infected, represents the state of the endpoint.
The posture token becomes one of the conditions in the authorization rules for network access. Posture validation, together with the traditional user authentication, provides a complete security assessment of the endpoint and the user.
Posture Validation in Network Access Control
Posture validation can work with Network Access Control (NAC). NAC uses the network infrastructure to enforce-security policy compliance on all devices seeking access to network computing resources.
Security-policy compliance limits damage from emerging security threats. By using NAC, customers can allow network access only to compliant and trusted endpoint devices (such as PCs, servers, and PDAs), and can restrict the access of noncompliant devices. For more information about the NAC solution, see http://www.cisco.com/go/nac.
Figure 13-1 shows the components of a typical NAC deployment, including posture validation.
Figure 13-1 Components of a Typical NAC Deployment
Typical NAC components are:
•
Examples of NAC-compliant applications are the Cisco Security Agent and antivirus programs from Network Associates, Symantec, or Trend Micro. These applications provide the Cisco Trust Agent with attributes about themselves, such as the version number of a virus definition file.
A NAC agentless host (NAH) is an endpoint that is not running the Cisco Trust Agent application.
•
•
•
•
Posture Validation and Network Access Profiles
To understand the profile-based policy paradigm, you should understand network access profiles. (NAPs). A profile is essentially a classification of network access requests for applying a common policy. Profile-based policies include rules for authentication, authorization, and posture validation.
Authorization rules are no longer set in Posture Validation but in the Network Access Profiles tab. By using authorization in NAP, you can provision the same RADIUS attribute to have different values for different users, groups and profiles. The one-user-one-group-one-profile is now more flexible by using profile-based policies instead.
After configuring posture validation rules, you must associate those rules to a network access profile. For detailed instructions, see Setting a Posture-Validation Policy, page 14-27.
For more detailed information on policy-based profiles, see Overview of NAPs, page 14-1.
Posture Tokens
Posture tokens represent the state of an endpoint device or a NAC-compliant application that is installed on the computer. ACS recognizes two types of posture tokens:
•
•
ACS determines the SPT of each request by comparing the APTs from all policies that are applied to the request. The most severe APT becomes the SPT.
Table 13-1 describes the six predefined, non-configurable posture tokens, used for system and application posture tokens. They are listed in order from least to most severe.
From the perspective of ACS, the actions that you set in your authorization rule determine the meaning of an SPT. These actions associate a token with RADIUS authorization components (RACs), DACLs, or both. The authorization rule may also specify a user group as part of the condition. For details on configuring RACs, see Adding RADIUS Authorization Components, page 4-10. For details on setting up your authorization rules as part of network access profiles, see Classification of Access Requests, page 14-2.
Posture validation requests resulting in an SPT for which access is not strictly denied are logged in the Passed Authentications log. Posture validation requests resulting in an SPT for which access is denied are logged in the Failed Attempts log. For more information on logging and reports, see Update Packets in Accounting Logs, page 10-28.
ACS only uses APTs to determine the SPT; but the endpoint device receiving the results of the posture validation can use them based on their meanings to the relevant NAC-compliant application.
The Posture Validation Process
ACS evaluates the posture attributes that it receives from an endpoint computer. The following overview describes the steps and systems involved in posture validation. Details about various concepts, such as posture tokens and policies, are provided in topics that follow.
1.
2.
3.
4.
5.
6.
You can set up many types of restrictions in authorization rules by using various RADIUS attributes in the RAC (which might be combined with the user's group), downloadable ACL, and url-redirect or
status-query-timeout.7.
cisco-av-pair.8.
The endpoint handles the results of the posture validation request according to its configuration. The AAA client enforces network access as dictated by ACS in its RADIUS response. By configuring profiles, you define authorizations and, therefore, network access control, based on the system posture token that is determined as a result of posture validation.
Policy Overview
This section contains:
•
•
You can use ACS to set up internal or external posture validation policies that return a posture token and an action after checking the rules that you (or the external server) set for the policy.
Policies are reusable; that is, you can associate a single policy with more than one network access profile. For example, if your NAC implementation requires two profiles, one for endpoints using NAI software and one for endpoints using Symantec software, you may need to apply the same rules about the operating system of the endpoint; regardless of which antivirus application is installed. You can create a single policy that enforces rules about the operating system and associate it with the Symantec and the NAI server information.
The results of applying a policy are:
•
•
•
About Posture Credentials and Attributes
For posture validation, credentials are the sets of attributes sent from the endpoint to ACS. Also known as inbound attributes, these attributes contain data that is used during posture validation to determine the posture of the computer. ACS considers attributes from each NAC-compliant application and from the Cisco Trust Agent to be different types of credentials.
With policies that ACS creates for validation, the rules that you create use the content of inbound attributes to determine the APT returned by applying the policy. With policies that are created for validation by an external server, ACS forwards the credential types that you specify to the external NAC server. In either case, the contents of inbound attributes provide the information that is used to determine posture and, thus, to control network admission for the computer.
ACS uses NAC attributes in its response to the endpoint. These attributes are called outbound attributes. For example, APTs and the SPT are sent to the endpoint in attributes.
Credential types are uniquely identified by two identifiers: vendor ID and application ID. The vendor ID is the number that is assigned to the vendor in the IANA Assigned Numbers RFC. For example, vendor ID 9 corresponds to Cisco Systems, Inc. Vendors assign numbers to the NAC applications that they provide. For example, with Cisco applications, application ID 1 corresponds to the Cisco Trust Agent. In the web interface, when you specify result credential types for a policy, the names that you assign to the vendor and application identify the credential types for the Cisco Trust Agent. For example, the credential type for the Cisco Trust Agent is Cisco:PA (where PA refers to posture agent, another term for the Cisco Trust Agent). In a posture validation response, ACS would use the numeric identifiers 9 and 1, which are the identifiers for Cisco and the Cisco Trust Agent, respectively.
Attributes are uniquely identified by three identifiers: vendor ID, application ID, and attribute ID. For each unique combination of vendor and application, there are set of attributes that each have numbers as well. When ACS communicates with an endpoint, the identifiers are numerical. In the web interface, when you define rules for internal policies, attributes are identified by the names that are assigned to vendor, application, and attribute. For example, the Cisco Trust Agent attribute for the version of the operating system is Cisco:PA:OS-Version. The data that ACS receives identifies the attribute with the numeric identifiers 9, 1, and 6, which are the identifiers for Cisco, the Cisco Trust Agent, and the sixth attribute of the Cisco Trust Agent, respectively.
For more information about attributes, including data types and operators that are used in rules for internal policies, see Posture Validation Attribute Data Types. You can use CSUtil.exe to add and configure custom RADIUS vendor and VSA configurations. For information about using CSUtil.exe to export, add, or delete posture validation attributes, see User-Defined RADIUS Vendors and VSA Sets, page D-17.
Extended Attributes
You use extended attributes to configure conditions that support Linux clients, and are specific for different Linux packages. For example, you can configure a condition for the version of the openssl package.
You input values for these Linux packages in the Entity field. When you input an extended attribute from the attribute drop-down list, the entity field is enabled. You can then select an entity from the drop-down list.
For example, if you select the Cisco:Host:Package:Version attribute, which is an extended attribute, the Entity drop-down list displays all the Linux packages that are configured in the system (ACS).
You can add or delete extended attributes. ACS for Windows: You use the CSUtil.exe command. For details, see Posture-Validation Attributes, page D-28. ACS Solution Engine: You use the NAC Attributes Management page in the web interface. For detailed instructions, see NAC Attribute Management (ACS Solution Engine Only), page 8-37.
Posture Validation Attribute Data Types
Posture validation attributes can be one of the following data types:
•
falseandtrueare valid input. Valid operators are=(equal to) and!=(not equal to). When a rule element using a Boolean attribute is evaluated,falsecorresponds to a value of 0 (zero) andtruecorresponds to 1.For example, if a rule element for a Boolean attribute requires that the attribute is not equal to
falseand the attribute in a specific posture validation request was 1, ACS would evaluate the rule element to be true; however, to avoid confusion, you can express the rule element more clearly by requiring that the attribute is equal totrue.•
=(equal to),!=(not equal to),contains,starts-with, andregular-expression.•
=(equal to),!=(not equal to),>(greater than),<(less than),<=(less than or equal to),>=(greater than or equal to). Valid input in rule elements is an integer between -65535 and 65535.•
=(equal to),!=(not equal to),>(greater than),<(less than),<=(less than or equal to), and >= (greater than or equal to). Valid input in rule elements is a whole number between 0 and 4294967295.•
=(equal to),!=(not equal to), andmask. Valid format in rule elements is dotted decimal format. If the operator ismask, the format is themask/IP. For more information, see Configuring Policies.•
=(equal to),!=(not equal to),>(greater than),<(less than),<=(less than or equal to),>=(greater than or equal to), anddays-since-last-update. Valid format in rule elements:mm/dd/yyyy hh:mm:ss•
=(equal to),!=(not equal to),>(greater than),<(less than),<=(less than or equal to), and>=(greater than or equal to). Valid format in rule elements:n.n.n.nwhere each n can be an integer from 0 to 65535.
•
=(equal to) and!=(not equal to). Valid input in rule elements is any hexadecimal number, such as 7E (the hexadecimal equivalent of 126).Internal Policies
This section contains:
•
About Internal Policies
Internal policies comprise one or more rules that you define in ACS. When ACS applies an internal policy, it uses the policy rules to evaluate credentials that are received with the posture validation request. Each rule is associated with an APT, a credential type, and an action. The credential type determines which NAC-compliant application with which the APT and action are associated.
ACS applies each rule in the order they appear on the Posture Validation Policies page (from top to bottom), resulting in one of the following two possibilities:
•
•
Note
When you specify the order of rules in a policy, determine the likelihood of each rule to be true and then order the rules so that the rule most likely to be true is first and the rule least likely to be true is last. Doing so makes rule processing more efficient; however, determining how likely a rule is to be true can be challenging. For example, one rule may be true for the posture of twice as many endpoints as a second rule, but posture validation may occur more than twice as often for endpoints whose posture matches the second rule; therefore, the second rule should be listed first.
About Rules, Rule Elements, and Attributes
A rule is a set of one or more rule elements. A rule element is a logical statement which comprises:
•
•
•
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.
For detailed descriptions of rules, see Classification of Access Requests, page 14-2.
For information on configuration, see Creating an Internal Policy, and Internal Posture Validation Setup Pages
External Policies
External policies are policies that an external NAC server defines, usually from an antivirus vendor and a set of credential types to be forwarded to the external database. You also have the option of defining a secondary external NAC server. The presence of a secondary server allows the secondary or failover server to evaluate any policies from the primary server.
ACS does not determine the result of applying an external policy; instead, it forwards the selected credentials to the external NAC server and expects to receive the results of the policy evaluation: an APT, a result credential type, and an action.
Each external policy that is associated with a external server must return a result; otherwise, ACS rejects policy validation requests that are evaluated with a profile whose external policies do not return a result. For example, if ACS evaluates a posture validation request by using a profile that has 10 internal policies and one external policy, but the external NAC servers associated with the external policy are not online, it is irrelevant that the 10 internal policies all return SPTs. The failure of the single external policy causes ACS to reject the posture validation request.
For information on external policy configuration options see Editing an External Posture Validation Server, and External Posture Validation Setup Pages.
External Posture Validation Audit Servers
This section contains:
About External Audit Servers
Audit servers are Cisco and third-party servers that determine posture information about a host without relying on the presence of a Posture Agent (PA). The Cisco PA is also known as the Cisco Trust Agent. Audit servers are used to assess posture validation with an organization's security policy. You can also define a secondary external audit server. The presence of a secondary audit server allows the second or failover server to evaluate any policies from the primary server when the primary server rejects a policy.
An audit policy is a set of processing rules for evaluating the posture of a Agentless Host through an audit server. Audit policies are used to retrieve posture decisions for hosts that do not have an EAP supplicant. When a host accesses the network through a NAD that is acting as a NAC enforcement point, the NAD sends information to ACS so that ACS can trigger auditing. If ACS is configured correctly, it queries the audit server for the result (posture token) of the audit and then determines the authorization based on the audit result.
Your network-management security strategy may include external audit servers that work with ACS to control access to your network.
ACS will use the GAME protocol to communicate with audit servers. In each audit request, ACS forwards the following information to the audit server:
•
host id•
ip-address•
mac-address(optional)The name of the System-Posture-Token is dynamically sent (without requiring any configuration) to the device.
Table 13-2 defines the details required in applying the results of an audit.
How an External Audit Gets Triggered
An endpoint failure triggers an external audit. This failure occurs when the enforcement point detects that the endpoint is not responding as required. The enforcement point sends the aaa:event failure message to indicate that a device failure has occurred.
The current release of ACS supports this event type and provides configuration in the out-of-band posture policy about which event should activate the policy (may be more than one).
ACS must be able to recognize the following events that may or may not trigger an audit, depending on policy configuration:
•
aaa:eventattribute•
•
Once ACS recognizes that an audit will occur, the audit server is queried. The audit server responds with results or an audit-in-progress message, which may contain a polling timeout hint to pass on to the NAD. At this point, ACS evaluates the enforcement policy for the given host based on the default APT that is associated with the posture validation policies. Part of the enforcement policy must be a session-timeout value that is used to trigger the NAD to reauthenticate the host. ACS receives the request and queries the audit server. This process repeats itself until the audit server responds with an APT. Once the audit response is received, enforcement policies are reevaluated and returned to the NAD.
The NAD caches the posture token that will be sent along with any subsequent access requests occurring during the host's session; for instance, as a result of session timeout (reauthentication). ACS uses this token for default policy evaluation during the audit for these subsequent authentications, thereby avoiding session downgrade for the connected host.
Exemption List Support
ACS supports exemption lists of groups and hosts. The exemption list contains a list of IP or MAC addresses to include or exclude from the audit. When a host is exempted, it is assigned an exemption token that determines its posture status. The exemption list is defined in the out-of-band audit policy. The IP list may contain single IP addresses or IP mask ranges. The MAC lists may be MAC ranges in the form of partial MAC strings that are matched with the hosts MAC address by using the begins with operator.
Auditing Device Types
As an extra security check on MAC authentication, you can configure an audit policy that checks for device type and handles assignment of the device to an appropriate destination user group. For example, a questionable device might be assigned to a user group called Mismatch; or, if the process does not assign a group, the device might be assigned to a user group called Quarantine. In the case where MAC authentication and the audit policy return the same device type, such as printer, your audit policy can assign the device to the printer group.
Policy Formation
You use options on the External Posture Validation Audit Server Setup page to define the audit policy. These options can enable a request for device-type from the audit server or assign a group in the absence of the device-type. The options on this page also provide for construction of rules that can specifically manage group assignment based on logical comparisons.
The complete audit policy also depends on the elements that you have previously configured on the External Posture Validation Server Setup page, which include setup of the host(s), audit server(s), and audit flow. In addition, the policy includes an option for configuration of a secondary audit server that can function in a failover scenario.
ACS uses the GAME protocol in a conversation with an audit server. The conversation includes a request for device type, which the audit server determines by scanning the device. If the protocol or audit policy flows return errors, the system displays an error message.
When configuring policy, remember that:
•
•
•
User Groups and Device Types
MAC authentication returns a device type in the form of a user group, such as Printer or PC. Audit policy relies on a list of NAC attribute device definitions, which include Printer and PC, for comparison with the MAC user group. Alternatively, the audit policy can rely on a user-defined device-type string.
When looking at the MAC user group, the policy supports a user group of Any, which ACS interprets to mean that the group returned can be any group or no group. When looking at the device type, the policy supports Match-all when interpreting the device type returned by the audit.
Group Assignment
Group assignment depends on the configuration of your network. Your network might support multiple devices or only certain devices. To support the audit policy, you should add a destination device group such as Mismatch or Quarantine. Your particular configuration might require additional groups.
Assignment to a destination user group is based on the following conditions:
•
•
•
•
Group Mapping Rules
Each group-mapping rule uses an operator, which compares the device user group that MAC authentication returns with the device type that an audit server returned. Any one of the following operators can be defined in a comparison:
•
•
•
•
•
•
For example:
•
•
•
•
•
Policy List
Each rule definition appears on a list of policies that is orderable by priority.
Configuring NAC in ACS
This section provides an overview of the steps to configure posture validation in ACS, with references to more detailed procedures for each step.
Note
Before You Begin
Before ACS can perform posture validation, you must complete several configuration steps. An overview of the steps follows. For information on finding detailed instructions on Cisco.com, see Posture Validation in Network Access Control.
To implement posture validation:
Step 1
For detailed steps about installing a server certificate, see Installing an ACS Server Certificate, page 9-21. For detailed steps about generating and installing a self-signed certificate, see Generating a Self-Signed Certificate, page 9-33.
Note
Step 2
You must add your audit vendor to the ACS internal dictionary. ACS for Windows: You use the CSUtil.exe command before configuring an external posture validation audit server. For detailed instructions, see Importing External Audit Posture-Validation Servers, page D-33. ACS Solution Engine: You use the NAC Attributes Management page in the web interface. For detailed instructions, see NAC Attribute Management (ACS Solution Engine Only), page 8-37.
Note
ACS authenticates the audit servers and posture validation servers by using certificates. You must choose the certificate from ACS or configure the Certificate Trust List (CTL). If the external servers use a different CA than the CA that issued the ACS server certificate, then you must configure the CTL. For detailed steps, see Editing the Certificate Trust List, page 9-26.
If your external server uses a self-signed certificate, you do not need to alter the CTL.
Step 3
For detailed steps about configuring this type of log, see Configuring a CSV Log, page 10-14.
Step 4
For detailed steps about configuring this type of log, see Configuring a CSV Log, page 10-14.
Step 5
For detailed steps, see Configuring Authentication Options, page 9-19.
Step 6
For detailed steps, see Adding AAA Clients, page 3-11.
Step 7
Step 8
Tip
Step 9
For detailed steps on creating rules, see Creating an Internal Policy. For detailed steps, see Adding a Downloadable IP ACL, page 4-15 (and Adding RADIUS Authorization Components, page 4-10.) To associate posture rules to profiles, see Posture-Validation Policy Configuration for NAPs, page 14-26.
Step 10
•
For detailed steps, see Configuring Policies.
•
For detailed steps, see Posture-Validation Policy Configuration for NAPs, page 14-26.
Configuring Policies
If you plan to use NAC in your network, you will need to define the manner in which posture validation will be performed. Policies are sets of rules that are used to determine a posture token for a posture validation request.
This section contains:
•
•
•
•
Posture Validation Options
You can configure the following posture validation options:
•
•
•
Table 13-3 describes the setup options for posture validation.
Table 13-3 Posture Validation Options
Policy requirements for the network are internally (or locally) validated in ACS.
NAC policies for the Cisco Trust Agent, Windows, the Cisco Security Agent, and antivirus software applications are among recommended internal policies. See Creating an Internal Policy
An outside posture validation server validates policies.
Externalizing the posture validation to an AV server allows you to handle proprietary AV posture credentials and antivirus policy administration by an AV administrator separate from the ACS administrator.
Cisco and third-party servers that determine posture information about a host without relying on the presence of a PA. These types of hosts are also referred to as agentless. Audit servers are used to assess posture validation with an organization's security policy.
The Cisco PA is also known as the Cisco Trust Agent. If no Cisco Trust Agent is on the host, then an audit server can be used.
Note
To configure a policy for internal or external posture validation:
Step 1
Step 2
•
•
•
Step 3
Setting Up Posture Validation Policies
This section contains:
•
•
Creating an Internal Policy
Use internal posture validation to write your own policies for access in your network. After you have created policies, you can then profile rules to use these policies.
You can select internal policies for more than one profile. To add the policy to a profile, use the Network Access Profiles page.
For descriptions of the options available on the Internal Posture Validation Setup page, see Configuring Policies.
For details on how to set up your third-party component policies, see the related documentation on the Go NAC website on Cisco.com. For information on adding internal policies to your profiles, see Posture-Validation Policy Configuration for NAPs, page 14-26.
Once you have set up at least one policy, you can use the clone rule option to save time by copying a policy and customizing it. For details on how to use cloning, see Cloning a Policy or Policy Rule.
To create your internal posture validation policy:
Step 1
a.
b.
ACS displays a list of posture validation policies, if available.
c.
Step 2
Step 3
Step 4
Step 5
Step 6
a.
b.
c.
d.
e.
For example, if you create a policy for the Cisco Security Agent, you might create the following condition sets:
•
•
•
For more information about operators, see Configuring Policies.
For information on the Cisco Trust Agent posture plug-in attributes and values, see the Cisco Trust Agent documentation.
The condition set appears in the Conditions Sets table.
Step 7
•
•
Step 8
Tip
Step 9
a.
b.
c.
For more information about tokens, see Posture Tokens.
If the rule matches the posture validation request, ACS associates with the policy the result credential type, token, and action that you specify.
Tip
Step 10
The Policy Validation Rules page appears again. The new condition set appears at the bottom of the Condition Sets table.
Tip
Step 11
a.
b.
Step 12
a.
b.
c.
When ACS applies this policy to a posture-validation request and none of the configurable rules matches the request, ACS associates the default credential type, token, and action that you specify with the policy.
Step 13
The Posture Validation Rules page displays the new rule.
Step 14
The current configuration has been changed.
Step 15
Editing a Policy
You can only edit a policy by accessing it through the Posture Validation pages.
To edit a policy or posture validation rule:
Step 1
Step 2
Step 3
The applicable policy rules page appears.
Step 4
a.
b.
i.
ii.
iii.
c.
i.
ii.
iii.
d.
e.
f.
i.
ii.
g.
•
•
h.
ACS creates a new policy. ACS stores the new policy and does not change the configuration of the old policy. The old policy remains in the Posture Validation Policies table.
Step 5
Step 6
Cloning a Policy or Policy Rule
This option creates a policy or rule that is identical to the selected one. You can then easily modify the settings.
To clone an internal posture validation policy or policy rule:
Step 1
a.
b.
ACS displays a list of posture validation policies.
c.
Tip
Step 2
For example, if you selected VPNmgt1 as the policy, the copy would be Copy-of-VPNmgt1.
Step 3
The Policy Validation Rule page appears again. The new condition set appears in the Condition Sets table.
Step 4
ACS creates a new policy and does not change the configuration of the old policy. The old policy remains in the Posture Validation Policies table.
Step 5
Step 6
Step 7
Renaming a Policy
Use the renaming feature to change the name or description of an existing or cloned policy to something more meaningful.
To rename a policy:
Step 1
a.
b.
ACS displays a list of posture validation policies.
c.
Step 2
Step 3
ACS creates a new policy. ACS stores the new policy and does not change the configuration of the old policy. The old policy remains in the Posture Validation Policies table.
Step 4
The renamed policy appears at the bottom of the Posture Validation Policies page.
Step 5
Deleting a Policy or Rule
To delete a policy or rule:
Step 1
a.
b.
ACS displays a list of posture validation policies.
Step 2
The Posture Validation Rules page appears.
Step 3
This deletes the policy from the policy validation list; but does not remove the policy from any profiles with which it may be associated. A warning message prompts you to cancel or click OK.
Step 4
ACS deletes the policy rule. The policies page reappears and the policies table no longer lists the deleted policy. All profiles that were configured to use the policy no longer include the deleted policy.
Deleting a Condition Component or Condition Set
A condition component is the list of elements that a condition set comprises. To delete a condition component from a condition set or an entire condition set:
Step 1
a.
b.
ACS displays a list of posture validation policies.
Step 2
The Posture Validation Rules page appears.
Step 3
Step 4
Step 5
ACS deletes the condition set or condition component.
Step 6
Setting Up an External Policy Server
This procedure describes how you can create an external policy.
Before You Begin
You can select external policies for more than one profile. To create external policies, use the External Posture Validation Setup pages. To add the policy to a profile, use the Network Access Profiles page. See Classification of Access Requests, page 14-2.
The external server that you use to access the External Policy Validation page does not limit which profiles can select the new external policy.
For descriptions of the options available on the External Policy Configuration page, see Configuring Policies.
Step 1
Step 2
The Add/Edit External Posture Validation Server page appears.
Step 3
Step 4
a.
Note
b.
Step 5
a.
b.
Step 6
Step 7
Step 8
Editing an External Posture Validation Server
You can edit an external posture validation server by accessing it through the Posture Validation pages.
To edit an external posture validation server:
Step 1
Step 2
Step 3
The Add/Edit External Posture Validation Server page appears.
Step 4
Deleting an External Posture Validation Server
You can remove an external posture validation server by accessing it through the Posture Validation pages.
To delete an external posture validation server:
Step 1
Step 2
Step 3
The Add/Edit External Posture Validation Server page appears.
Step 4
Setting Up an External Audit Posture Validation Server
Use External Posture Validation Audit Server Setup page to add, edit, and delete external posture validation audit servers. Policies are reusable; you can associate an audit policy with more than one network access profile.
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. You can use the attributes that you add to create conditions for internal policies.
NAC introduces the ability to authorize network hosts not only based on user or machine identity; but also on a host's posture validation. The posture validation is determined by comparing the host's credentials to a posture-validation policy that you create from attribute-value pairs (AVPs), which Cisco and other vendors who are NAC partners define. Since the range of NAC attributes extends across many vendors and applications, you must import the non-Cisco attributes.
Before You Begin
Before you begin, you must:
•
•
•
Adding an External Posture Validation Audit Server
To add an audit server for external posture validation:
Step 1
The Posture Validation Components Setup page appears.
Step 2
The External Posture Validation Audit Server page appears.
Step 3
The External Posture Validation Audit Server Setup page appears.
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
If your audit vendor does not appear, you must define an audit APT for the vendor in the internal ACS dictionary. ACS for Windows: You use the CSUtil.exe command. For detailed instructions, see Posture-Validation Attributes, page D-28. ACS Solution Engine: You use the NAC Attributes Management page in the web interface. For detailed instructions, see NAC Attribute Management (ACS Solution Engine Only), page 8-37.
Step 11
Step 12
Step 13
Step 14
Step 15
Step 16
Step 17
Step 18
If this check box is not available (greyed out), define an audit device type attribute for the vendor in the internal ACS dictionary. ACS for Windows: You use the CSUtil.exe command. See Posture-Validation Attributes, page D-28 for information. ACS Solution Engine: You use the NAC Attributes Management page in the web interface. See NAC Attribute Management (ACS Solution Engine Only), page 8-37 for more information.
Step 19
Step 20
Step 21
Step 22
Step 23
Step 24
Step 25
Editing an External Posture Validation Audit Server
You can edit an external posture validation audit server by accessing it through the Posture Validation pages.
To edit an external posture validation server:
Step 1
Step 2
Step 3
The External Posture Validation Audit Server page appears.
Step 4
Deleting an External Posture Validation Server
You can remove an external posture validation audit server by accessing it through the Posture Validation pages.
To delete an external posture validation audit server:
Step 1
Step 2
Step 3
The External Posture Validation Audit Server page appears.
Step 4
Audit Processing with MAC Authentication Bypass
An audit request can include a check against Agentless Host authentication. Audit server processing can double-check an audit request against a MAB authentication policy and an audit policy, and then combine the evaluation of the two policies.
Evaluating the combined policies is only possible in Layer 2 IP and Layer 3 NAC deployments because the audit request must contain the MAC address and IP address of an endpoint.
ACS requires the following key attributes for MAB and audit interoperability:
•
•
•
•
•
Workflow
This feature requires the following configuration options:
•
•
•
–
–
•
Processing
When the request is processed:
1.
2.
3.
4.
5.
Policy Configurations
ACS supports a number of configurations and capabilities for authenticating and authorizing agentless hosts. Table 13-4 summarizes the policy combinations, capabilities, and configurations.
You use the following procedure to configure Agentless Hosts and Audit interoperability.
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Posture Validation Pages Reference
The following topics describe the pages that you access from the Posture Validation button on the navigation bar:
•
•
•
•
Posture Validation Components Setup Page
Use this page to access the posture validation pages.
To display the Posture Validation Components Setup page, click Posture Validation on the navigation bar.
Internal Posture Validation Setup Pages
The following topics describe the Internal Validation Setup pages:
•
•
•
•
Posture Validation Policies Page
Use this page to add policies or to access existing policies for editing.
To display the Posture Validation Policies page, click Posture Validation on the navigation bar, then choose Internal Posture Validation Setup.
Posture Validation Policy Page
Use this page to specify the name and description for a new policy.
To display the Posture Validation Policy page, choose Posture Validation > Internal Posture Validation Setup > Add Policy.
Posture Validation Rules for <policy_name> Page
Use this page to display and order rules.
To display the Posture Validation Rules for <policy_name> page when editing a rule, choose Posture Validation > Internal Posture Validation Setup > <policy_name>.
Posture Validation Rule - <policy_name> Page
Use this page to view and edit rules.
To display the Posture Validation Rules for <policy_name> page when adding a rule, choose Posture Validation > Internal Posture Validation Setup > <policy_name> > <condition>.
Table 13-9 Posture Validation Rule - <policy_name> Page
Lists the condition sets that are associated with a rule. A <condition_name> opens the Add/Edit Condition page.
When adding or editing a rule, a compound Boolean expression determines the logical treatment of the conditions that are associated with a rule.
•
•
Add Condition Set
Opens the Add/Edit Condition page.
Posture Token
Specifies the vendor and application, and a token (an APT). If the rule is true, the Token list determines the APT that is associated with the vendor and application that is selected in the corresponding Posture Assessment list. For more information about tokens, see Posture Tokens.
Notification String
Specifies a text message that is sent to the application that the Result Credential Type list indicates. The vendor determines use of the text message. Some NAC-compliant applications do not implement the use of the Notification String box.
Add/Edit Condition Page
Use this page to add or edit conditions.
To display the Posture Validation Rules for <policy_name> page when adding a rule, choose Posture Validation > Internal Posture Validation Setup > <policy_name> > <condition> > <condition_set>.
Table 13-10 Add/Edit Condition Page
Condition Elements Table
Lists each condition. Specifies a vendor and application; the credential type. If the rule is true, the credential type determines the application to which the token in the corresponding Token list is associated. For example, the Cisco Trust Agent appears on the list as
Cisco:PA. For more information about credential types, see About Posture Credentials and Attributes.Attribute
Lists the available attributes.
Entity
Lists the available entities for attributes that require entities.
Operator
Lists the appropriate operators for this attribute.
Value
Specifies an appropriate value for the attribute.
External Posture Validation Setup Pages
The following topics describe the External Posture Validation Setup pages:
•
•
External Posture Validation Servers Page
Use this page to view existing external posture validation servers.
To display the External Posture Validation Servers page, choose Posture Validation > External Posture Validation Setup.
Add/Edit External Posture Validation Server Page
Use this page to add or edit external posture validation servers.
To display the Add/Edit External Posture Validation Server page, choose Posture Validation > External Posture Validation Setup. Then click Add Server to add a server or click <server_name> to edit a server.
Table 13-12 Add/Edit External Posture Validation Server Page
Name
Specifies the name by which to identify the server.
The name can contain up to 32 characters. Leading and trailing spaces are not allowed. Names cannot contain the left bracket ([), the right bracket (]), the comma (,), or the slash (/).
Description
Specifies a text description of the server, up to 255 characters. For each profile using the policy, the text you type in the Description box appears beside the policy. In the Description box you can add the details that you could not convey in the name of the policy. For example, you could describe its purpose or summarize its rules.
Because you can apply the same policy to more than one profile, a useful description could also help prevent accidental configuration errors when someone modifies a policy without understanding which profiles use it.
Primary Server Configuration
Secondary Server ConfigurationEnables a primary NAC server (and an optional secondary NAC server). ACS relies on these servers to apply the policy and configure the set of credential types that ACS forwards.
For each posture validation request to which an external policy is applied, ACS attempts to use the first enabled server configuration in the policy that is enabled. If the first enabled server is the primary server and ACS cannot reach the primary server or the primary server fails to respond to the request, ACS will use the secondary server, if it is configured and enabled.
URL
Specifies the HTTP or HTTPS URL for the server. The format for URLs is:
[http[s]://]host[:port]/resourcewhere host is the hostname or IP address of the NAC server, port is the port number used, and resource is the rest of the URL, as required by the NAC server itself. The URL varies depending on the server vendor and configuration. For the URL that your NAC server requires, refer to your NAC server documentation.
The default protocol is HTTP. URLs beginning with the hostname are assumed to be using HTTP. To use HTTPS, you must specify the URL beginning with
https://and import a self-generated CA certificate into ACS for this policy server. See ACS Certificate Setup, page 9-20.If the port is omitted, the default port is used. The default port for HTTP is port 80. The default port for HTTPS is port 443.
If the NAC server hostname is antivirus1, which uses port 8080 to respond to HTTP requests for the service provided policy.asp, a script kept in a web directory called cnac, valid URLs would be:
http://antivirus1:8080/cnac/policy.asp antivirus1:8080/cnac/policy.aspIf the same server used the default HTTP port, valid URLs would be:
http://antivirus1/cnac/policy.asp http://antivirus1:80/cnac/policy.asp antivirus1/cnac/policy.asp antivirus1:80/cnac/policy.aspIf the same server used HTTPS on the default port, valid URLs would be:
https://antivirus1/cnac/policy.asp https://antivirus1:443/cnac/policy.aspUsername
Specifies the username required for access to the server. The server ignores the values in the Username and Password fields if the server is not password protected.
Password
Specifies the password required for access to the server. The server ignores the values in the Username and Password fields if the server is not password protected.
Timeout (Sec)
The number of seconds that ACS waits for a result from the external server, including domain name resolution. The Timeout value must be greater than zero (0). The default is 10.
ACS forwards requests to the secondary server (if configured) when the primary server times out. If no secondary server is configured or if a request to the secondary server also times out, ACS cannot apply the external policy and therefore rejects the posture validation request.
For each posture validation request, ACS always tries the primary server first, regardless of whether previous requests timed out.
Trusted Root CA
The certificate authority (CA) that issued the server certificate, which the server uses. If the protocol is HTTPS, ACS forwards credentials to a server only if the CA that is specified on this list issued the certificate that it presents. If ACS cannot forward the request to the primary or secondary NAC server because the trusted root CAs did not issue the server certificates, the external policy cannot be applied and, therefore, the posture validation request is rejected.
The Trusted Root CA list does must contain the CA that issued a NAC server certificate. For information, see Adding a Certificate Authority Certificate, page 9-24.
ACS does not check NAC server certificates against Certificate Revocation Lists (CRLs), even if a configured CRL issuer for the CA of the NAC server certificate is present.
The certificate name and type must match. For example, if the server presents a VeriSign Class 1 Primary CA certificate and VeriSign Class 1 Public Primary CA is selected on the Trusted Root CA list, ACS does not forward the credentials to the server when HTTPS is in use.
Forwarding Credential Types
The Available Credentials list specifies the credential types that are not sent to the external server. The Selected Credentials list contains the credential types that are sent to the external server.
See the following information to add credential types to the Available Credentials list. ACS for Windows: You use the CSUtil.exe command. For detailed instructions, see Importing External Audit Posture-Validation Servers, page D-33.ACS Solution Engine: You use the NAC Attributes Management page in the web interface. For detailed instructions, see NAC Attribute Management (ACS Solution Engine Only), page 8-37.
External Posture Validation Audit Setup Pages
The following topics describe the External Posture Validation Audit Setup pages:
•
•
External Posture Validation Audit Server Page
Use the External Posture Audit Server page view the name, description, server details, and current posture tokens for each configured server.
To display the Add/Edit External Posture Validation Server page, choose Posture Validation > External Posture Validation Audit Setup.
External Posture Validation Audit Server Setup Page
Use this page to add or edit external posture validation audit servers.
Add Server Page
To display this page, choose Posture Validation > External Posture Validation Audit Setup > Add Server.
Edit Server Page
To display this page, choose Posture Validation > External Posture Validation Audit Setup, then click the <server_name>. You can edit the Audit Server settings as needed, but:
•
•
Table 13-13 External Posture Validation Audit Server Setup Options
Name
The name for the audit policy.
The name can contain up to 32 characters. Leading and trailing spaces are not allowed. Names cannot contain the left bracket ([), the right bracket (]), the comma (,), or the slash (/).
Description
Describes the audit policy (up to 255 characters).
Audit all user groups
Audit these user groups
Do not audit these user groupsThe user group options determine the auditing of the groups in the Selected Groups list.
Audit all hosts
Audit these hosts
Do not audit these hostsAudit all hosts that do not contain a posture agent.
Audit only certain hosts or exclude certain hosts as defined in the Host IP Addresses and Ranges (IP/MASK) (comma separated values) field.
For Host MAC Address (comma separated values), ACS accepts two MAC address formats, 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.
Select a Posture Token for the hosts that will not be audited
A posture token that ACS will apply to hosts that are not audited.
Audit Server Vendor
Vendors that have an audit Application Posture Token (APT) defined in the internal ACS dictionary appear in the drop-down list.
If no audit servers appear in the drop-down list, see Posture-Validation Attributes, page D-28 (ACS for Windows) or NAC Attribute Management (ACS Solution Engine Only), page 8-37. for information on setting up audit servers.
Primary Server Configuration, Secondary Server Configuration
Each option enables configuration of audit servers. ACS requires a primary server. The secondary server provides failover capability (not required). The options for a Secondary Server Configuration are identical to the options for a Primary Server Configuration.
URL
The URL of the audit server. Specify the HTTP or HTTPS protocol.
URLs must conform to the following format:
[http[s]://]host[:port]/resourcewhere host is the hostname or IP address of the external server, port is the port number used, and resource is the rest of the URL, as required by the external server. The URL varies depending on the server vendor and configuration.
The audit server documentation contains specific format guidelines.
Username
The username that the audit server requires.
Password
The password that the audit server requires.
Timeout (sec)
The number of seconds that ACS waits for a result from the audit server, including domain name resolution. The Timeout value must be greater than zero (0).
Trusted Root CA
A certification authority that is required if the URL of the audit server specifies the HTTPS protocol. This option should match the certification authority that issued the audit server certificate installed on the primary server.
Validate Certificate Common Name
When checked (enabled), this option shows the host name within the URL for purposes of comparison with the common name in the certificate. If the names do not match, ACS closes the SSL connection, posture validation fails, and user access is denied.
Use this Posture Token while Audit Server does not yet have a posture validation result
Interim posture token sent from ACS to the NAD while waiting for a result. ACS uses the In Progress token before the Audit Server determines the actual posture of the nonresponsive host.
Polling Intervals and Session-Timeout
Either the timeout values that are sent by the audit server or that are set in the authorization policy. ACS requires a polling interval if the configuration uses the values that are set in the authorization policy. The authorization policy must include the necessary RACs in order to assign specific timeout values in the final resulting tokens. See Configuring an Authorization Rule, page 14-31.
Maximum amount of times the Audit Server should be polled
The maximum number of times that ACS will query the audit server for a result (posture token). Range of 1-10 times.
Policy string to be sent to the Audit Server
The name of the policy, if the audit server supports named policy invocation.
Request Device Type from Audit Server
Enables the audit policy configuration options. When enabled, the Audit feature can request a device type from the audit server and then check the device type against the device type that MAC authentication returns.
If this check box is not available, define an audit device type attribute for the vendor in the internal ACS dictionary. ACS for Windows: Use the CSUtil.exe command. See Posture-Validation Attributes, page D-28 for information. ACS Solution Engine: Use the NAC Attributes Management page in the web interface. See NAC Attribute Management (ACS Solution Engine Only), page 8-37 for more information.
Assign This Group if Audit Server Did not Return a Device Type
Enables assignment of a device to any administrator-defined group when the audit server does not return a device type.
User Group
Lists all user groups, including Any. The device type that MAC authentication returns is initially compared with this list of device types.
Device Type
Defines the comparison criteria for the User Group, using an operator and device type.
Valid values for the operator are:
match-all
=
!=
contains
starts-with
regular-expressionValid values for the device type drop-down are not editable. They include:
Printer
IP Phone
Network Infrastructure
Wireless Access Point
Windows
Unix
Mac
Integrated Device
PDA
UnknownType a device type in the text box if the device type drop-down does not contain a particular device.
Assign User Group
A drop-down list of administrator-defined user groups. If the comparison of the initial User Group with the Device Type succeeds, ACS will assign this user group.
Add, Delete, Up, Down
Controls that affect the user groups.
Submit, Delete, Cancel
Controls that affect the whole policy.
An audit policy can be in use with more than one NAC Network Access Profile. Before deleting a policy, you must identify the NAC Network Access Profiles that the deletion will affect.
