Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide, Release 4.1(2)
Configuring Clean Access Agent Requirements
Downloads: This chapterpdf (PDF - 3.52MB) The complete bookPDF (PDF - 14.3MB) | Feedback

Configuring Clean Access Agent Requirements

Table Of Contents

Configuring Clean Access Agent Requirements

Overview

Configuration Steps for Clean Access Agent Requirements

Create Clean Access Agent Requirements

Configuring Windows Update Requirement

Create Windows Update Requirement

Map Windows Update Requirement to Windows Rules

Configuring Windows Server Update Services Requirement

Create Windows Server Update Service Requirement

Map Windows Server Update Service Requirement to Windows Rules

Configuring AV/AS Definition Update Requirements

AV Rules and AS Rules

Verify AV/AS Support Info

Create AV Rule

Create AV Definition Update Requirement

Create AS Rule

Create AS Definition Update Requirement

Configure Launch Programs Requirement

Configure Custom Checks, Rules, and Requirements

Custom Requirements

Custom Rules

Cisco Pre-Configured Rules ("pr_")

Custom Checks

Cisco Pre-Configured Checks ("pc_")

Using Pre-Configured Rules to Check for CSA

Copying Checks and Rules

Configuration Summary

Create Custom Check

Create Custom Rule

Validate Rules

Create Custom Requirement

Map Requirement to Rules

Apply Requirements to Role

Validate Requirements

Configure an Optional/Audit Requirement

Launch Programs Example

Viewing Clean Access Agent Reports

Limiting the Number of Reports

Clean Access Agent User Dialogs

Windows Agent Dialogs

Mac OS X Agent Dialogs (Authentication Only)

RADIUS Challenge-Response Agent Dialogs

Example Windows RADIUS Challenge-Response User Login Session Dialogs

Example Mac OS X RADIUS Challenge-Response User Login Session Dialogs

Troubleshooting the Agent

Client Cannot Connect/Login

No Agent Pop-Up/Login Disabled

Client Cannot Connect (Traffic Policy Related)

AV/AS Rule Troubleshooting

Known Issue for Windows Script 5.6

Known Issue for MS Update Scanning Tool (KB873333)

Workaround


Configuring Clean Access Agent Requirements


This chapter describes how to configure the Clean Access Agent to be used for vulnerability assessment and remediation of client machines.

Overview

Configuration Steps for Clean Access Agent Requirements

Create Clean Access Agent Requirements

Launch Programs Example

Viewing Clean Access Agent Reports

Clean Access Agent User Dialogs

Troubleshooting the Agent

Overview

The Clean Access Agent provides local-machine agent-based vulnerability assessment and remediation for client machines. Users download and install the Clean Access Agent (read-only client software), which can check the host registry, processes, applications, and services. The Clean Access Agent can be used to perform Windows updates or antivirus/antispyware definition updates, launch qualified remediation programs, distribute files uploaded to the Clean Access Manager, distribute website links to websites in order for users to download files to fix their systems, or simply distribute information/instructions.

After users log into the Clean Access Agent, the Agent gets the requirements configured for the user role/OS from the Clean Access Server, checks for the required packages and sends a report back to the CAM (via the CAS). If requirements are met on the client, the user is allowed network access. If requirements are not met, the Agent presents a dialog to the user for each unmet requirement. The dialog (configured in the New Requirement form) provides the user with instructions and the action to take for the client machine to meet the requirement.

Clean Access Agent vulnerability assessment is configured in the CAM by creating requirements based on rules and (optionally) checks, then applying the requirements to user roles/client OSes. This chapter describes how to configure these requirements.


Note For an illustrated overview, see Clean Access Agent Client Assessment Process, page 9-3.


Configuration Steps for Clean Access Agent Requirements

The basic steps needed to configure the Clean Access Agent are as follows:


Step 1 Make sure to follow the steps in Chapter 10, "Distributing the Clean Access Agent" to enable distribution and download of the Clean Access Agent.

Step 2 Create Clean Access Agent Requirements

Configuring Windows Update Requirement

Configuring Windows Server Update Services Requirement

Configuring AV/AS Definition Update Requirements

Configure Launch Programs Requirement

Configure Custom Checks, Rules, and Requirements

Step 3 Map Requirement to Rules

Step 4 Apply Requirements to Role

Step 5 Validate Requirements

Step 6 Configure an Optional/Audit Requirement

Step 7 Clean Access Agent User Dialogs

Step 8 Troubleshooting the Agent


Create Clean Access Agent Requirements

To implement Clean Access Agent system requirements, you configure and map together the following elements:

Requirements

Rules (AV/AS rules, pr_ rules, or custom rules)

Checks (pc_ checks or custom checks)—only needed if creating custom rules

User roles and operating systems

Requirements are used to implement business-level decisions about what users must (or must not) have running on their systems to be able to access the network. The requirement mechanism maps one or more rules that you want clients in a user role to meet to the action you want those users to take if the client fails the rules. When you create a New Requirement, you choose from one of several different requirement types (e.g. AV Definition Update) to configure options and remediation instructions the Clean Access Agent dialogs present to the user when the client fails the requirement.

A rule is the unit used by the Clean Access Agent to assess whether a requirement is met on a particular operating system. A rule can be an AV/AS rule, Cisco pre-configured rule (pr_rule) or a custom rule made up of a check or a combination of checks. You must map rules to requirements.

A check is a single registry, file, service, or application check for a selected operating system, and is used to create a custom rule. A check can be a Cisco pre-configured check (pc_ check) or a custom check you create yourself.

Once a requirement is associated with rules, the final configuration step is to associate the requirement to a normal login user role. Users who attempt to authenticate into the normal user role are put into the Temporary role until they pass requirements associated with the normal login role:

If they successfully meet the requirements, the users are allowed on the network in the normal login role.

If they fail to meet the requirements, users stay in the Temporary role for the session timeout until they take the steps described in the Agent dialogs and successfully meet the requirements.

For out-of-band users, successfully authenticating and meeting requirements allows the users to leave the in-band network (on the Auth VLAN) and access the out-of-band network on the Access VLAN.

To map a requirement to a normal login user role, the role must already be created as described in Create User Roles, page 6-1.

Configuring Windows Update Requirement

The Clean Access Agent "Windows Update" Requirement type configuration page allows administrators to check and modify Windows Update setting, and launch Windows Updater (Automatic Updates or WSUS Agent for the Local Windows Server Update Services (WSUS)) on Clean Access Agent user machines.

When this requirement is configured, the administrator can turn on Automatic Updates on Windows Vista, Windows 2000, or Windows XP clients which have this option disabled on the machine. If Automatic Updates are already enabled on the user machine, the administrator can override the user-specified update option with the administrator-specified option. In addition, administrator-specified Windows Update settings can be applied temporarily on the user machine or can be set to permanently override user preferences to ensure updates are always performed.

The "Windows Update" requirement (set to Optional) provides an Update button on the Clean Access Agent for remediation. When the end user clicks the Update button, the CCA Agent will launch the AU/WSUS Agent and force it to get the update software from the WSUS Server. The software download from WSUS may take some time. Cisco recommends setting the Windows Update requirement to Optional (default) for WSUS remediation to occur as a background process.

You can also configure specific WSUS update requirements separate from standard Windows updates. For more information, see Configuring Windows Server Update Services Requirement.


NoteThe network administrator must ensure the Automatic Updates Agent is updated to support the local WSUS server for the auto-launch to work. For details, refer to:

http://www.microsoft.com/windowsserversystem/updateservices/evaluation/faqs.mspx

The Windows Update requirement type is only for Windows Vista, Windows XP, and Windows 2000. It supports checking of Automatic Updates (AU) Options, changing of AU Options and one-button Update launch of AU/WSUS Agent

The Agent launches WindowsUpdater as follows:

One-button Update that launches Automatic Updates/ WSUS Agent

Forces update from local WSUS Server (if Automatically Download and Install is selected)

The Windows Update requirement is set to optional by default.

WSUS forced update may take a while. It will be launched and run in the background.

If there are update errors, see C:\Windows\Windows Update.log or C:\Windows\WindowsUpdate.log

In order to support Windows Server Update Services operations, client machines must have version 5.4.3790.1000 (or a more recent version) of the WUAUENG.dll file installed.


The steps to create a Windows Update Requirements are as follows:


Step 1 Create Windows Update Requirement

Step 2 Map Windows Update Requirement to Windows Rules

Step 3 Apply Requirements to Role

Step 4 Validate Requirements


Create Windows Update Requirement

The following steps show how to configure a Windows Update requirement:

1. Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement.

Figure 11-1 New Windows Update Requirement

2. From the Requirement Type dropdown menu, choose Windows Update.

3. Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement. The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Optional—Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking "Next"). The client system does not have to meet the requirement for the user to proceed or have network access.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.


Note Because the Windows Update process runs in the background, this requirement type is set by default to "do not enforce" to optimize the user experience. Cisco recommends leaving this requirement as Optional, if selecting the "Automatically download and install option." A WSUS forced update may take a while, and is launched and run in the background.


4. Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Agent dialogs in that order). Note that if a Mandatory requirement fails, the Agent does not continue past that point until that requirement succeeds.

5. From the Windows Update Setting dropdown, choose one of the following options:

Do not change setting

Notify to download and install

Automatically download and notify to install

Automatically download and install

These settings correspond to the Automatic Updates dialog settings on the Windows client (Figure 11-2)

6. Click the checkbox for Permanently override user setting with administrator Windows Update Setting, if you want to enforce your administrator-specified setting for Automatic Updates on all client machines during and after Windows Update. If left unchecked, the admin setting will only apply when Automatic Updates are disabled on the client; otherwise the user setting applies when Automatic Updates are enabled.

7. For the Requirement Name, type a unique name to identify this requirement in the Agent. The name will be visible to users on the Clean Access Agent dialogs.

8. In the Description field, type a description of the requirement and instructions to guide users who fail to meet the requirement, including instructions for users to click the Update button to update their systems. Note that Windows Update displays the Update button on the Agent.

9. Click one or more of the following checkboxes to set the Operating System(s) for the requirement:

Windows 2000

Windows XP (All) or one or more of the specific Windows XP operating systems

Windows Vista (All) or one or more of the specific Windows Vista operating systems

10. Click Add Requirement.

Figure 11-2 Windows XP Automatic Updates

Map Windows Update Requirement to Windows Rules

1. Go to Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules

Figure 11-3 Map Windows Update Requirement to Rules

2. From the Requirement Name dropdown menu, choose the Windows Update requirement you configured.

3. From the Operating System dropdown menu, select Windows Vista, Windows XP, or Windows 2000. Once you have configured the requirement-rule mapping for one OS, you can select settings for the other OS and update the mapping accordingly.

4. Choose one of the following options for Requirement met if:

All selected rules succeed (default)

Any selected rule succeeds

No selected rule succeeds

5. Ignore the AV Virus/AS Spyware Definition rule options.

6. The Rules for Selected Operating System list will display all rules that exist in the system for the chosen OS (pr_ rules or rules that you have configured). Click the checkbox for each rule you want to enable for this requirement. Typical rules that are associated to this requirement are:

pr_AutoUpdateCheck_Rule (Win XP (All), 2000)

pr_XP_Hotfixes (Win XP Pro/Home)

pr_2K_Hotfixes (Win 2000)

Note that all rules are listed under Device Management > Clean Access > Clean Access Agent > Rules > Rule List.

7. Click Update to complete the mapping.

8. Continue to the next steps—Apply Requirements to Role and Validate Requirements—to complete the configuration.

Configuring Windows Server Update Services Requirement

The Clean Access Agent "Windows Server Update Services" requirement type configuration page allows administrators to launch Windows Server Update Services (WSUS) on Clean Access Agent user machines.

You can use WSUS severity checks instead of, or in addition to, Cisco preconfigured hotfix rules. If Automatic Updates are already enabled on the user machine, the administrator can override the user-specified update option with the administrator-specified option. In addition, administrator-specified Windows Update settings can be applied temporarily on the user machine or can be set to permanently override user preferences to ensure updates are always performed.

The "Windows Server Update Services" requirement provides an Update button on the Clean Access Agent for remediation. When the end user clicks the Update button, the CCA Agent launches the AU/WSUS Agent and forces it to get the update software from a Microsoft- managed or local/third-party-managed WSUS server. The software download from WSUS may take some time. Cisco recommended setting the Windows Update requirement to Optional (default) for WSUS remediation to occur as a background process.

You can also configure Standard Windows update requirements separate from specific WSUS updates. For more information, see Configuring Windows Update Requirement.


NoteThe network administrator must ensure the Automatic Updates Agent is updated to support a local WSUS server to support auto-launch capabilities. For details, refer to:

http://www.microsoft.com/windowsserversystem/updateservices/evaluation/faqs.mspx

The "Windows Server Update Services" requirement type is also only for Windows 2000, Windows XP, and Windows Vista. It supports checking Cisco- and Windows-based client operating system verification and customized update installation options based on update severity.

In order to support Windows Server Update Services operations, client machines must have version 5.4.3790.1000 (or a more recent version) of the WUAUENG.dll file installed.

Some Microsoft Windows components (like Internet Explorer 7, for example) require admin privileges in order to successfully update. If the user does not have admin privileges on the client machine, the Windows update process returns a "WU_E_NO_INTERACTIVE_USER" error. Therefore, Cisco recommends making any Windows updates requiring admin privileges "Optional" to minimize update failures. For details, refer to:

http://msdn2.microsoft.com/en-us/library/aa387289.aspx

WSUS forced update may take a while. It will be launched and run in the background.

If there are update errors, see C:\Windows\Windows Update.log or C:\Windows\WindowsUpdate.log.


The steps to create a Windows Server Update Service Requirements are:


Step 1 Create Windows Server Update Service Requirement

Step 2 Map Windows Server Update Service Requirement to Windows Rules

Step 3 Apply Requirements to Role

Step 4 Validate Requirements


Create Windows Server Update Service Requirement

The following steps show how to configure a Windows Server Update Service (WSUS) requirement:

1. Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement.

Figure 11-4 New Windows Server Update Service Requirement

2. From the Requirement Type dropdown menu, choose Windows Server Update Services.

3. Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement. The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Optional—Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking "Next"). The client system does not have to meet the requirement for the user to proceed or have network access.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.


Note Because the Windows Update process runs in the background, this requirement type is set by default to "do not enforce" to optimize the user experience. Cisco recommends leaving this requirement as Optional, if selecting the "Automatically download and install option." A WSUS forced update may take a while, and is launched and run in the background.


4. Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Agent dialogs in that order). Note that if a Mandatory requirement fails, the Agent does not continue past that point until that requirement succeeds.

5. Under Windows Updates Validation by, specify the method by which Cisco Clean Access validates the Windows operating system running on the client machine:

Cisco Rules—Use preset Cisco validation criteria to ensure the Windows operating system on the client meets minimum standard security guidelines.


Note If you choose this option, you also need to map the requirement to existing Windows rules, as described in Map Windows Update Requirement to Windows Rules.


Severity—Use a local (managed) or hosted (Microsoft) Windows validation server to ensure the Windows operating system on the client meets minimum standard security guidelines.


Note You set the validation method to coincide with the Severity option using the Windows Updates Installation Sources setting, below.


6. Under Windows Updates to be Installed, specify the method by which Cisco Clean Access initiates the Windows update:

Express—This option installs the same Windows updates as would be available from the Windows Update application "Express" option. (For example, the Windows "Express" option may include just Critical and Important security updates or could call for installing an entire service pack update.)

Custom—Use this setting and the associated dropdown menu to install updates based on their severity by choosing Critical, Medium, or All from the associated dropdown menu. If you select Critical only the most severe/critical Windows updates are installed; selecting Medium means all updates (except for those classified as "low severity" by Microsoft) are installed; selecting All means that all of the currently available Windows Updates are installed, regardless of severity.

7. Click Upgrade to Latest OS Service Pack to automatically install the latest service pack available for the user's operating system.


Note This option is automatically included in the install process when you specify either Medium or All Custom updates, above, and cannot be "left out." If you specified Critical Custom updates, you can choose to enable or disable this option.

Cisco rules enforce all "Critical" Windows updates and verify whether or not minimum Windows 2000 Service Pack and Windows XP Service Pack updates are installed on the client machine. If you choose to require only "Critical" Windows Updates to be Installed, Windows 2000 Service Pack 4 and Windows XP Service Pack 2 may not be present on the client machine, hence, the client machine will not pass posture assessment via "Cisco rules." To address this potential problem, Cisco recommends that if you choose to validate client machines using "Cisco rules" and require only "Critical" updates, that you also require Service Pack Updates to ensure any clients validated using "Cisco rules" pass posture assessment. (If you choose to validate client machines according to "Severity" rather than "Cisco rules", this is not an issue.)



Note Windows Service Pack updates traditionally take a long time to download and install. Before you require users to update their Windows operating system with a full service pack installation, be sure you extend the session timeout period for Temporary Role users to accommodate the long install and update process. (See Configure Session Timeout for the Temporary Role, page 8-19.)


8. For Windows Updates Installation Sources, specify the source for the Windows update(s):

Windows Servers—Updates the Windows operating system using Microsoft-managed resources.

Managed WSUS Servers—Updates the Windows operating system using resources managed by the Windows server administrator or other trusted third-party source.

9. For Installation Wizard Interface Setting, specify whether or not the user sees the Installation Wizard user interface during Windows Update installation:

Show UI—The Installation Wizard progress is visible to the user during the update process so they can tell what components are being updated and when the update completes. (Users must have Administrator privileges on the client machine in order to see the Installation Wizard user interface during Windows Update.)

No UI—The Windows Update takes place in the background once the update process has begun and the user is only notified when the update is complete.

10. For the Requirement Name, type a unique name to identify this requirement in the Agent. The name will be visible to users on the Clean Access Agent dialogs.

11. In the Description field, type a description of the requirement and instructions to guide users who fail to meet the requirement, including instructions for users to click the Update button to update their systems. Note that Windows Update displays the Update button on the Agent.

12. Click one or more of the following checkboxes to set the Operating System(s) for the requirement:

Windows 2000

Windows XP (All) or one or more of the specific Windows XP operating systems

Windows Vista (All) or one or more of the specific Windows Vista operating systems

13. Click Add Requirement.

Map Windows Server Update Service Requirement to Windows Rules

Perform the steps in this section if you configured a Windows Server Update Service requirement for Windows Updates Validation by Cisco Rules. (See Create Windows Server Update Service Requirement.)

If you specified Windows Updates Validation by Severity, you do not need to map the Windows Server Update Service to an existing Windows Rule and you can skip this section.

To map a Windows Server Update Service requirement to a Windows rule:

1. Go to Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules

Figure 11-5 Map Windows Update Requirement to Rules

2. From the Requirement Name dropdown menu, choose the Windows Server Update Service (WSUS) requirement you configured.

3. From the Operating System dropdown menu, select one of the available Windows Vista, Windows XP, or Windows 2000 operating system options. Once you have configured the requirement-rule mapping for one OS, you can select settings for the other OS and update the mapping accordingly.

4. Choose one of the following options for Requirement met if:

All selected rules succeed (default)

Any selected rule succeeds

No selected rule succeeds

5. Ignore the AV Virus/AS Spyware Definition rule options.

6. The Rules for Selected Operating System list will display all rules that exist in the system for the chosen OS (pr_ rules or rules that you have configured). Click the checkbox for each rule you want to enable for this requirement. Typical rules that are associated to this requirement are:

pr_AutoUpdateCheck_Rule (Win XP (All), 2000)

pr_XP_Hotfixes (Win XP Pro/Home)

pr_2K_Hotfixes (Win 2000)

Note that all rules are listed under Device Management > Clean Access > Clean Access Agent > Rules > Rule List.

7. Click Update to complete the mapping.

Continue to the next steps—Apply Requirements to Role and Validate Requirements—to complete the configuration.

Configuring AV/AS Definition Update Requirements

The AV Definition Update and AS Definition Update requirement type can be used to update the definition files on a client for supported antivirus or antispyware products. If the client fails to meet the AV/AS requirement, the Clean Access Agent communicates directly with the installed antivirus or antispyware software on the client and automatically updates the definition files when the user clicks the Update button on the Agent dialog.

AV Rules incorporate extensive logic for antivirus vendors and are associated with AV Definition Update requirements. AS Rules incorporate logic for most antispyware vendors and are associated with AS Definition Update requirements. For AV or AS Definition Update requirements, there is no need to configure checks. You associate:

AV Definition Update requirement with AV Rule(s) and user roles and operating systems

AS Definition Update requirement with AS Rule(s) and user roles and operating systems

and configure the Clean Access Agent dialog instructions you want the user to see if the AV or AS requirement fails.


Note Where possible, Cisco recommends using AV Rules mapped to AV Definition Update Requirements to check antivirus software on clients. In the case of a non-supported AV product, or if an AV product/version is not available through AV Rules, administrators always have the option of using Cisco provided pc_ checks and pr_rules for the AntiVirus vendor or of creating their own custom checks, rules, and requirements through Device Management > Clean Access > Clean Access Agent (use New Check, New Rule, and New File/Link/Local Check Requirement), as described in Configure Custom Checks, Rules, and Requirements.
Note that Clean Access works in tandem with the installation schemes and mechanisms provided by supported Antivirus vendors. In the case of unforeseen changes to underlying mechanisms for AV products by AV vendors, the Clean Access team will upgrade the Supported AV/AS Product List and/or Clean Access Agent in the timeliest manner possible in order to support the new AV product changes. In the meantime, administrators can always use the "custom" rule workaround for the AV product (such as pc_checks/pr_ rules) and configure the requirement for "Any selected rule succeeds."


Figure 11-6 shows the Clean Access Agent dialog that appears when a client fails to meet an AV Definition Update requirement.

Figure 11-6 Required AV Definition Update (User Dialog)

AV Rules and AS Rules

Antivirus rules (AV Rule) and anti-spyware rules (AS Rule) are preconfigured rule types that are mapped to the matrix of vendors and products sourced in the Supported AV/AS Product List. There is no need to configure checks with this type of rule.

There are two basic types of AV Rules:

Installation AV Rules check whether the selected antivirus software is installed for the client OS.

Virus Definition AV Rules check whether the virus definition files are up-to-date on the client. Virus Definition AV Rules can be mapped into AV Definition Update requirements so that a user that fails the requirement can automatically execute the update by clicking the Update button in the Agent.

There are two basic types of AS Rules:

Installation AS Rules check whether the selected anti-spyware software is installed for the client OS.

Spyware Definition AS Rules check whether the spyware definition files are up-to-date on the client. Spyware Definition AS Rules can be mapped into AS Definition Update requirements so that a user that fails the requirement can automatically execute the update by clicking the Update button in the Agent.

AV Rules are typically associated with AV Definition Update requirements, and AS Rules are typically associated with AS Definition Update requirements.

The steps to create AV Definition Update Requirements are as follows:


Step 1 Verify AV/AS Support Info

Step 2 Create AV Rule

Step 3 Create AV Definition Update Requirement

Step 4 Map Requirement to Rules

Step 5 Apply Requirements to Role

Step 6 Validate Requirements


The steps to create AS Definition Update Requirements are as follows:


Step 1 Verify AV/AS Support Info

Step 2 Create AS Rule

Step 3 Create AS Definition Update Requirement

Step 4 Map Requirement to Rules

Step 5 Apply Requirements to Role

Step 6 Validate Requirements



Note In some cases it may be advantageous to configure AV or AS rules/requirements in different ways. For example:

Not all product versions of a particular vendor may support the Agent launching the automatic update of the product. In this case, you can provide instructions (via the Description field of the AV or AS Definition Update requirement) to have users update their AV or AS definition files from the interface of their installed AV or AS product.

You can associate the AV or AS rules with a different requirement type, such as Link Distribution or Local Check, to change the Agent buttons and user action required from "Update" to "Go to Link", or to disable the action button and provide instructions only. This allows you flexibility in configuring the actions you want your users to take.

You can also configure different Enforce Types. You can generate reports for clients and optionally provide users extra time to meet a requirement without blocking them from the network. See Configure an Optional/Audit Requirement for details.


Verify AV/AS Support Info

Cisco NAC Appliance allows multiple versions of the Clean Access Agent to be used on the network. New updates to the Agent will add support for the latest antivirus or antispyware products as they are released. The system picks the best method (either Def Date or Def Version) to execute AV/AS definition checks based on the AV/AS products available and the version of the Agent. The AV/AS Support Info page provides details on Agent compatibility with the latest Supported AV/AS Product List downloaded to the CAM. This page lists the latest version and date of definition files for each AV and AS product as well the baseline version of the Agent needed for product support. You can compare the client's AV or AS information against the AV/AS Support Info page to verify if a client's definition file is the latest. If running multiple versions of the Agent on your network, this page can help troubleshoot which version must be run to support a particular product.

To View Agent Support Details:

1. Go to Device Management > Clean Access > Clean Access Agent > Rules > AV/AS Support Info

2. Choose either Antivirus (Figure 11-7) or Anti-Spyware (Figure 11-8) from the Category dropdown.

Figure 11-7 AV/AS Support Info — AV Vendor Example

Figure 11-8 AV/AS Support Info — AS Vendor Example

3. Choose a corresponding vendor (Antivirus Vendor or Anti-Spyware Vendor) from the dropdown menu.

4. For Antispyware products, only the Windows Vista/XP/2K operating system is supported. Check the Minimum Agent Version Required to Support AS Products table for product details.


Note Regular updates for Anti-Spyware definition date/version will be made available via Cisco Updates. Until update service is available, the system enforces definition files to be x days older than the current system date for AS Spyware Definition rules (under Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules).


5. For Antivirus products, choose Windows Vista/XP/2K or Windows 9x/ME from the Operating System dropdown menu to view the support information for those client systems. This populates the following tables:

Minimum Agent Version Required to Support AV Products: shows the minimum Agent version required to support each AV product. For example, a 4.1.2.0 Agent can log into a role that requires Aluria Security Center AntiVirus 1.x, but for any lower Agent version, this check will fail. Note that if a version of the Agent supports both Def Date and Def Version checks, the Def Version check will be used.

Latest Virus Definition Version/Date for Selected Vendor: displays the latest version and date information for the AV product. The AV software for an up-to-date client should display the same values.


Note The Agent sends its version information to the CAM, and the CAM always attempts to first use the virus definition version for AV checks. If the version is not available, the CAM uses the virus definition date instead.



Tip You can also view the latest def file version when selecting an AV vendor from the New AV Rule form.


Create AV Rule

1. Make sure you have the latest version of the Supported AV/AS Product List, as described in Retrieving Updates, page 9-10.

2. Go to Device Management > Clean Access > Clean Access Agent > Rules > New AV Rule.

Figure 11-9 New AV Rule

3. Type a Rule Name. You can use digits and underscores, but no spaces in the name.

4. Choose a specific Antivirus Vendor, or choose ANY vendor, from the dropdown menu. Along with the Operating System chosen, this populates the Checks for Selected Operating Systems table at the bottom of the page for the ANY vendor option or with the supported products and product versions for the specified vendor.

5. From the Type dropdown menu, choose either Installation or Virus Definition. This enables the checkboxes for the corresponding Installation or Virus Definition column in the table below.

6. Choose one of the following Operating Systems from the dropdown menu:

Windows Vista/XP/2K

Windows ME/98

This populates the product versions supported for this client OS in the table below.

7. Type an optional Rule Description.

8. In the Checks for Selected Operating Systems table, choose the product versions you want to check for on the client by clicking the checkbox(es) in the corresponding Installation or Virus Definition column:

ANY means you want to check for any product and any version from this AV vendor.

Installation checks whether the product is installed.

Virus Definition checks whether the virus definition files are up to date on the client for the specified product.


Note In a definition rule, the Agent first confirms whether or not the product is installed, then checks whether or not the definition file is up-to-date.


9. Click Add Rule. The new AV rule will be added at the bottom of the Rule List with the name you provided.


Note When configuring AV Rules, the "ANY" Antivirus vendor option and the vendor-specific "ANY Product/ANY Version" option work differently:

For ANY vendor, the Agent needs to query the server to verify whether the installed products is from a supported vendor. Because the Agent only queries once at the beginning of each login session, the user must click Cancel or restart the Agent to repeat the login process in order to refresh the server's response.

For "ANY Product/ANY Version" for a specific vendor, the Agent only needs to match the required vendor against what is installed on the client machine. No query is needed.


Create AV Definition Update Requirement

The following steps show how to create a new AV Definition Update requirement to check the client system for the specified AV product(s) and version(s) using an associated AV Rule. If the client's AV definition files are not up-to-date, the user can simply click the Update button on the Clean Access Agent, and the Agent causes the resident AV software launch its own update mechanism. Note that the actual mechanism differs for different AV products (e.g. live update vs.command line parameter).

1. In the Clean Access Agent tab, click the Requirements submenu link and then New Requirement.

Figure 11-10 New Requirement

2. For Requirement Type choose AV Definition Update

3. Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement.The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Optional— Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking "Next"). The client system does not have to meet the requirement for the user to proceed or have network access.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.

4. Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Agent dialogs in that order). Note that if a Mandatory requirement fails, the Agent does not continue past that point until that requirement succeeds.

5. Choose an Antivirus Product Name from the dropdown menu or choose ANY. The Products table lists all the virus definition product versions supported per client OS.

6. For the Requirement Name, type a unique name to identify this AV virus definition file requirement in the Agent. The name will be visible to users on the Clean Access Agent dialogs.

7. In the Description field, type a description of the requirement and instructions to guide users who fail to meet the requirement. For an AV Definition Update requirement, you should include instructions for users to click the Update button to update their systems. Note the following:

AV Definition Update displays Update button on the Agent.

AS Definition Update displays Update button on the Agent.

Windows Update displays Update button on the Agent.

8. Click the checkbox for at least one client Operating System (at least one must be chosen).

9. Click Add Requirement to add the requirement to the Requirement List.

Create AS Rule

1. Make sure you have the latest version of the Supported AV/AS Product List, as described in Retrieving Updates, page 9-10.

2. Go to Device Management > Clean Access > Clean Access Agent > Rules > New AS Rule.

Figure 11-11 New AS Rule

3. Type a Rule Name. You can use digits and underscores, but no spaces in the name.

4. Choose an Anti Spyware Vendor from the dropdown menu, or choose ANY to select any supported AS vendor or product. This correspondingly populates the Checks for Selected Operating Systems table at the bottom of the page with the supported products and product versions from this vendor (for the Operating System chosen).

5. From the Type dropdown menu, choose either Installation or Spyware Definition. This enables the checkboxes for the corresponding Installation or Spyware Definition column in the table below.

6. The Operating System field displays Windows Vista/XP/2K by default.

7. Type an optional Rule Description.

8. In the Checks for Selected Operating Systems table, choose the product versions you want to check for on the client by clicking the checkbox(es) in the corresponding Installation or Spyware Definition column:

ANY means you want to check for any product and any version from this AS vendor.

Installation checks whether the product is installed.

Spyware Definition checks whether the spyware definition files are up-to-date on the client for the specified product.


Note In a definition rule, the Agent first confirms whether or not the product is installed, then checks whether or not the definition file is up-to-date.


9. Click Add Rule. The new AS rule will be added at the bottom of the Rule List with the name you provided.

Create AS Definition Update Requirement

1. Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement.

Figure 11-12 New AS Definition Update Requirement

2. For Requirement Type choose AS Definition Update

3. Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement.

Optional—Do not enforce requirement.

Audit—Silently audit.

4. Choose the Priority of execution for this requirement on the client.

5. Choose an Anti-Spyware Vendor Name from the dropdown menu or choose ANY. The Products table lists all the spyware definition product versions currently supported per client OS.

6. For the Requirement Name, type a unique name to identify this AS definition file requirement in the Agent. The name will be visible to users on the Clean Access Agent dialogs.

7. In the Description field, type a description of the requirement and instructions to guide users who fail to meet the requirement. For an AS Definition Update requirement, you should include an instruction for users to click the Update button to update their systems. Note the following:

File Distribution displays Download button on the Agent.

Link Distribution displays Go To Link button on the Agent.

Local Check displays Download button (disabled) on the Agent.

AV Definition Update displays Update button on the Agent.

AS Definition Update displays Update button on the Agent.

Windows Update displays Update button on the Agent.

8. Click the checkbox for at least one client Operating System (at least one must be chosen).

9. Click Add Requirement to add the requirement to the Requirement List

Configure Launch Programs Requirement

Cisco CLean Access features a Launch Programs Requirement Type that allows administrators to launch a qualified remediation program from the Clean Access Agent. The administrator can create a check/rule condition; upon its failure, the administrator can configure to launch any remediation program to fix the machine. Multiple programs are permitted, and they are launched in the same sequence as specified by the administrator.

The Clean Access Agent launches the programs in two ways, depending on user privileges for the device:

If the user has admin privileges on the client machine, the program is launched directly and digital signing and verification of the application are not required

If the user does not have administrative privileges, the Clean Access stub must be installed to launch the target executable. In this case, the Clean Access stub will verify that the program is signed by a trusted certificate authority before launching the program.

Note that it is the administrator's responsibility to populate the required Registry Keys for the programs to be trusted by Cisco Clean Access Agent and Cisco Clean Access Stub.


Note Version 4.1.0.0 or above of the Clean Access Agent is required to use this feature. This feature is applicable to Windows Vista, Windows 2000, and Windows XP machines only.


1. Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement.

Figure 11-13 New Launch Program Requirement

2. For Requirement Type choose Launch Programs

3. Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement.The user is informed of this requirement and cannot proceed or have network access unless the client system meets it.

Optional—Do not enforce requirement. The user is informed of the requirement but can bypass it if desired (by clicking "Next"). The client system does not have to meet the requirement for the user to proceed or have network access.

Audit—Silently audit. The client system is checked "silently" for the requirement without notifying the user, and a report is generated. The report results (pass or fail) do not affect user network access.

4. Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Agent dialogs in that order). Note that if a Mandatory requirement fails, the Agent does not continue past that point until that requirement succeeds.

5. Configure the program to be launched as follows:

For the Program Name, choose the root location from which to launch the program from the dropdown: SYSTEM_DRIVE, SYSTEM_ROOT, SYSTEM_32, SYSTEM_PROGRAMS, or None, and type the name of the program executable in the adjoining text field.

If a more specific path or program parameters are needed, type them in the Program Parameters text field.

Click Add Program. This adds the Program Name and Program Parameters to the sublist of programs to launch for the requirement.

Configure more programs to add, or click the Delete checkbox to remove programs from the list.

6. When done configuring the program or list of programs to added, type the Requirement Name.

7. Type a Description to be displayed to users.

8. Click the checkbox for the Windows Operating System for which this requirement applies.

9. Click Add Requirement.


Note See Launch Programs Example for additional details.


Configure Custom Checks, Rules, and Requirements

A check is a condition statement used to examine the client system. In the simplest case, a requirement can be a single rule made up of a single check. If the condition statement yields a true result, the system is considered in compliance with the Clean Access Agent requirement and no remediation is called for.

To create a check, first find an identifying feature of the requirement. The feature (such as a registry key or process name) should indicate whether the client meets the requirement. The best way to find such an indicator is to examine a system that meets the requirement. If necessary, refer to the documentation provided with the software to determine what identifying feature to use for the Clean Access check. Once you have determined the indicator for the requirement, use the following procedure to create the check.

Custom Requirements

You can create custom requirements to maps rules to the mechanism that allows users to meet the rule condition. The mechanism may be an installation file, a link to an external resource, or simply instructions. If a rule check is not satisfied (for example, required software is not found on the client system), users can be warned or required to fix their systems, depending on your configuration. As shown in Figure 11-14, a rule can combine several checks with Boolean operators, "&" (and), "|" (or), and "!" (not). A requirement can rely on more than one rule, specifying that any selected rule, all rules, or no rule must be satisfied for the client to be considered in compliance with the requirement.

Figure 11-14 Custom Checks, Rules, and Requirements

Custom Rules

A rule is a condition statement made up of one or more checks. A rule combines checks with logical operators to form a Boolean statement that can test multiple features of the client system.

Cisco Pre-Configured Rules ("pr_")

Cisco NAC Appliance provides a set of pre-configured rules and checks that are downloaded to the CAM via the Updates page on the CAM web console (under Device Management > Clean Access > Updates).

Pre-configured rules have a prefix of "pr" in their names (e.g. "pr_XP_Hotfixes"), and can be copied (for use as a template), but cannot be edited or removed. You can click the Edit button for any "pr_" rule to view the rule expression that defines it. The rule expression for a pre-configured rule will be composed of pre-configured checks (e.g. "pc_Hotfix835732") and boolean operators. The rule expression for pre-configured rules is updated via Cisco Updates. For example, when new Critical Windows OS hotfixes are released for Windows XP, the pr_XP_Hotfixes rule will be updated with the corresponding hotfix checks.

Pre-configured rules are listed under Device Management > Clean Access > Clean Access Agent > Rules > Rule List.


Note Cisco pre-configured rules are intended to provide support for Critical Windows OS hotfixes only.


Custom Checks

A check is a condition statement that examines a feature of the client system, such as a file, registry key, service, or application. Table 11-1 lists the types of custom checks available and what they test.

Table 11-1 Checks

Check Category
Check Type

Registry check

whether or not a registry key exists

registry key value

File Check

whether or not a file exists

date of modification or creation

file version

Service check

whether or not a service is running

Application check

whether or not an application is running


Cisco Pre-Configured Checks ("pc_")

Pre-configured checks have a prefix of "pc" in their names (for example, pc_Hotfix828035) and are listed under Device Management > Clean Access > Clean Access Agent > Rules > Check List.

Using Pre-Configured Rules to Check for CSA

You can use Cisco pre-configured rules to create a Clean Access Agent requirement that checks if the Cisco Security Agent (CSA) is already installed and/or running on a client (from version 14663 and above of the Cisco Updates ruleset). To do this:

1. Create a new Link Distribution or File Distribution requirement (for Windows Vista/XP/2000).

2. Associate the requirement to one or both of the following rules (for Windows Vista/XP/2000):

pr_CSA_Agent_Version_5_0

pr_CSA_Agent_Service_Running

3. Associate the requirement to the user role(s) for which it will apply.


Note See the following section for further details on creating custom requirements (using either pre-configured or custom rules).


Copying Checks and Rules

Note that pre-configured rules and checks are not editable, but can serve as templates. To modify a non-editable check or a rule, make a copy of it first by clicking the corresponding Copy button. Copies of checks are added to the bottom of the Check List, in the form copy_of_checkname. Copies of rules are added to the bottom of the Rules List, in the form copy_of_rulename. Click the corresponding Edit button to bring up the Edit form to modify the check or rule. The edited checks and rules can then be configured and associated to requirements and roles as described in the following sections.

Configuration Summary

The steps to create custom requirements are as follows:


Step 1 Create Custom Check

Step 2 Create Custom Rule

Step 3 Validate Rules

Step 4 Create Custom Requirement

Step 5 Map Requirement to Rules

Step 6 Apply Requirements to Role

Step 7 Validate Requirements


Create Custom Check

1. In the Clean Access Agent tab, click the Rules submenu and then open the New Check form

Figure 11-15 New Check

For all custom checks, follow steps 2. to 7., refer to the specifics for each check type—Registry Check Types, File Check Types, Service Check Type, Application Check Type—then perform step 5.

2. Select a Check Category: Registry Check, File Check, Service Check, or Application Check.

3. Type a descriptive Check Name. The rules created from this check will reference the check by this name, so be sure to give the check a unique, self-descriptive name. The name is case-sensitive and should be less than 255 characters and without spaces or special characters.

4. Type an optional Check Description.

5. Click one or more of the following checkboxes to set the Operating System(s) for the requirement:

Windows All

Windows 2000

Windows ME

Windows 98

Windows XP (All) or one or more of the specific Windows XP operating systems

Windows Vista (All) or one or more of the specific Windows Vista operating systems

6. If desired, select "Automatically create rule based on this check". In this case, the rule is automatically populated with the check when added and is named "checkname-rule".

7. Select a Check Type for the Category and fill in specific form fields as described below. Specify the parameters, operator, and (if the check type is a value comparison) the value and data type of the statement, and click Add Check to create the evaluation statement. If the condition statement evaluates to false, the required software is considered missing.

Registry Check Types

Registry Key - Checks whether a specific key exists in the registry.

Registry Value (Default) - Checks whether an unnamed (default) registry key exists or has a particular value, version, or modification date.

Registry Value - Checks whether a named registry key exists or has a particular value, version, or modification date.

Figure 11-16 Registry Check Types

a. For the Registry Key field, select the area of the client registry:

HKLM - HKEY_LOCAL_MACHINE

HKCC - HKEY_CURRENT_CONFIG

HKCU - HKEY_CURRENT_USER

HKU - HKEY_USERS

HKCR - HKEY_CLASSES_ROOT

Then type the path to be checked.

For example: HKLM \SOFTWARE\Symantec\Norton AntiVirus\version

b. For a Registry Value search, enter a Value Name.

c. For Registry Value searches, enter a Value Data Type:

1. For a "Number" Value Data Type (Note: REG_DWORD is equivalent to Number), choose one of the following Operators from the dropdown: equals, greater than, less than, does not equal, greater than or equal to, less than or equal to

2. For a "String" Value Data Type choose one of the following Operators from the dropdown: equals, equals (ignore case), does not equal, starts with, does not start with, ends with, does not end with, contains, does not contain.

3. For a "Version" Value Data Type choose one of the following Operators from the dropdown: earlier than, later than, same as.

4. For a "Date" Value Data Type, choose one of the following Operators from the dropdown: earlier than, later than, same as.

d. If specifying a "Date" Value Data Type, also choose one of two values to check. This allows you to specify "older than" or "newer than" by more than/fewer than x days to the current date.

- Type the date/time of the client machine in mm/dd/yyyy hh:MM:ss format.

- Choose the CAM date, + or - from the dropdown, and type the number of days.

e. Type the Value Data for a Registry Value search.


Note For the "String" Value Data Type, the maximum length for a string is 256 characters.


File Check Types

File Existence - Checks whether a file exists on the system.

File Date - Check whether a file with a particular modification or creation date exists on the system.

File Version - Checks whether a particular version of a file exists on the system.

Figure 11-17 File Check Types

a. For File Path, select:

SYSTEM_DRIVE - checks the C:\ drive

SYSTEM_ROOT - checks the root path for Windows 98 systems

SYSTEM_32 - checks C:\WINDOWS\SYSTEM32

SYSTEM_PROGRAMS - checks C:\Program Files

b. For Operator, select:

exists or does not exist - File Existence check

earlier than, later than, same as - File Date or File Version check

c. For a File Date check type, also choose one of two values to check for File Date. This allows you to specify "older than" or "newer than" by more than/fewer than x days to the current date.

- Type the date/time of the client machine in mm/dd/yyyy hh:MM:ss format, or

- Choose the CAM date, + or - from the dropdown, and type the number of days.

d. For a File Date check type, select a File Date Type:

Creation date

Modification date

Service Check Type

Service Status - Whether a service is currently running on the system.

Figure 11-18 Service Check Type

a. Enter a Service Name.

b. Select an Operator: running or not running.

Application Check Type

Application Status - Whether an application is currently running on the system.

Figure 11-19 Application Check Type

a. Enter an Application Name.

b. Select an Operator: running or not running.

5. Click Add Check when finished.

Create Custom Rule

A rule is an expression made up of checks and operators. A rule is the unit used by the Clean Access Agent to assess a vulnerability on a particular operating system. The result of the rule expression is considered to assess compliance with the Clean Access Agent requirement. A rule can be made up of a single check or it can have multiple checks combined with Boolean operators. Table 11-2 shows the operators along with their order of evaluation.

Table 11-2 Rule Operators

Priority
Operator
Description

1

()

parens for evaluation priority

2

!

not

3

&

and

3

|

or


Operators of equal priority are evaluated from left to right. For example, a rule may be defined as follows:

adawareLogRecent & (NorAVProcessIsActive | SymAVProcessIsActive) 

The adawareLogRecent check and either the NorAVProcessIsActive check or the SymAVProcessIsActive check must be satisfied for the rule to be considered met. Without parentheses, the following would be implied:

(adawareLogRecent & NorAVProcessIsActive) | SymAVProcessIsActive

In this case, either SymAVProcessIsActive or both of the first two checks must be true for the rule to be considered met.

Create a Custom Rule

1. In the Clean Access Agent tab, click the Rules submenu link and then New Rule.

Figure 11-20 New Rule

2. Type a unique Rule Name.

3. Enter a Rule Description.

4. Select the Operating System for which the rule applies. If Updates have been downloaded, the pre-configured checks for that operating system appear in the Checks for Selected Operating System list below.

5. Create the Rule Expression by combining checks and operators. Use the list to select the names of checks and copy and paste them to the Rule Expression text field. Use the following operators with the checks: () (evaluation priority), ! (not), & (and), | (or).

For example:

adawareLogRecent & (NorAVProcessIsActive | SymAVProcessIsActive) 

For a simple rule that tests a single check, simply type the name of the check:

SymAVProcessIsActive 

6. Click Add Rule.

The console validates the rule and, if formed correctly, the rule appears in the Rule List. From there, you can delete the rule, modify it, or copy it (create a new rule by copying this one).

Validate Rules

The Clean Access Manager automatically validates rules and requirements as they are created. Invalid rules have incompatibilities between checks and rules, particularly those relating to the target operating system. These errors can arise when you create checks and rules for a particular operating system but later change the operating system property for a check. In this case, a rule that uses the check and which is still applicable for the formerly configured operating system is no longer valid. Rule validation detects these and other errors.

The Validity column under Device Management > Clean Access > Clean Access Agent > Rules > Rule List displays a blue checkmark if the rule is valid and a red "X" if the rule is invalid. Highlight this icon with your mouse to reveal which check is causing the rule to be invalid, in the form:

Invalid rule [rulename], Invalid check [checkname] in rule expression. 

Figure 11-21 Rule List

To Correct an Invalid Rule:

1. Go to Device Management > Clean Access > Clean Access Agent > Rules > Rule List.

2. Click the Edit button for the invalid rule.

3. Correct the invalid Rule Expression. If the rule is invalid because a check has been deleted, make sure you associate the rule with a valid check.

4. Make sure the correct Operating System. is selected.

5. Make sure the Requirement met if: expression is correctly configured.

6. Click Save Rule.

7. Make sure any requirement based on this rule is also corrected as described in Validate Requirements.

Create Custom Requirement

A requirement is the mechanism that maps a specified collection of rules for an operating system to the files, distribution links, or instructions that you want pushed to the user via Clean Access Agent dialogs. Requirements can point to installation files or links where software can be downloaded. For local checks not associated with a specific installation file, the requirement can map the rule to an informational message, for example, instructing the user to remove software or run a virus check. A new requirement can be created at any time in the configuration process. However, the requirement must be associated to both a rule for an operating system and a user role before it can take effect.

Create File Distribution / Link Distribution / Local Check Requirement

1. In the Clean Access Agent tab, click the Requirements submenu link and then New Requirement.

Figure 11-22 New Requirement (File Distribution)

2. Select a Requirement Type:

File Distribution - This distributes the required software directly by making the installation package available for user download using the Clean Access Agent. In this case, the file to be downloaded by the user is placed on the CAM using the File to Upload field. For the Agent to download this file, a traffic policy allowing HTTP access only to the CAM should be created for the Temporary role. See Adding Traffic Policies for Default Roles, page 8-26.

Link Distribution - This refers users to another web page where the software is available, such as a software download page. Make sure the Temporary role is configured to allow HTTP (and/or HTTPS) access to the link.

Local Check - This is used when creating checks not associated with installable software, for example, to check if Windows Update Service (Automatic Updates) is enabled, or to look for software that should not be on the system.

AV Definition Update - This is used when creating AV rules. See Configuring AV/AS Definition Update Requirements for details.

AS Definition Update - This is used when creating AS rules. See Configuring AV/AS Definition Update Requirements for details.

Windows Update - This is used to configure a Windows Update options on the client. See Configuring Windows Update Requirement for details.

Launch Programs - This is used to launch a remediation program on the client when the requirement fails. See Configure Launch Programs Requirement for details.

3. Choose an Enforce Type from the dropdown menu:

Mandatory—Enforce requirement.

Optional—Do not enforce requirement. See Configure an Optional/Audit Requirement

Audit—Silently audit.

4. Specify the Priority of the requirement. Requirements with the lowest number (e.g "1") have the highest priority and are performed first. If a requirement fails, the remediation instructions configured for the requirement are pushed to the user without additional requirements being tested. Therefore you can minimize processing time by putting the requirements that are most likely to fail at a higher priority.

5. The Version field lets you keep track of various versions of a requirement. This is particularly useful when there are updates to the required software. You can use any versioning scheme you like, such as numbers (1, 2, 3), point numbers (1.0), or letters.

6. If you chose File Distribution as the Requirement Type, click Browse next to the File to Upload field and navigate to the folder where you have the installation file (.exe) for the required software.

7. If you chose Link Distribution as the Requirement Type, enter the URL of the web page where users can get the install file or patch update in the File Link URL field.

8. For the Requirement Name type a unique name to identify the system requirement. The name will be visible to users on the Clean Access Agent dialog.

9. In the Description field, type a description of the requirement and instructions for the benefit of your users. Note the following:

File Distribution displays Download button on the Agent.

Link Distribution displays Go To Link button on the Agent.

Local Check displays Download button (disabled) on the Agent.

AV Definition Update displays Update button on the Agent.

AS Definition Update displays Update button on the Agent.

Windows Update displays Update button on the Agent.

Launch Programs displays Launch button on the Agent.

10. Select the Operating System for which the requirement applies (at least one must be chosen).

11. Click Add Requirement to save the settings for the download requirement.

12. The requirement appears in the Requirement List.

Figure 11-23 shows an example of how requirement configuration fields display in the Clean Access Agent.

Figure 11-23 Example Optional Link Distribution Requirement

Map Requirement to Rules

Once the requirement is created and the remediation links and instructions are specified, map the requirement to a rule or set of rules. A requirement-to-rule mapping associates the ruleset that checks whether the client system meets the requirement to the user requirement action (Agent button, instructions, links) needed for the client system to comply.

1. In the Clean Access Agent tab, click the Requirements submenu and then open the Requirement-Rules form.

Figure 11-24 Requirement-Rules Mapping

2. From the Requirement Name menu, select the requirement to map.

3. Verify the operating system for the requirement in the Operating System menu. The Rules for Selected Operating System list will be populated with all rules available for the chosen OS.

4. For AV Virus Definition Rules (yellow background) and AS Spyware Definition rules (blue background), you can optionally configure the CAM to allow definition files on the client to be a number of days older than what the CAM has available from Updates (see Rules > AV-AS Support Info for the latest product file dates). This allows you to configure leeway into a requirement so that if no new virus/spyware definition files are released from a product vendor, your clients can still pass the requirement.

Click the checkbox for either:

For AV Virus Definition rules, allow definition file to be x days older than:

For AS Spyware Definition rules, allow definition file to be x days older than:

Type a number in the text box. The default is "0" indicating the definition date cannot be older than the file/system date.

Choose either:

Latest file date—This allows the client definition file to be older than the latest virus/spyware definition date on the CAM by the number of days you specify.

Current system date—This allows the client definition file to be older than the CAM's system date when the last Update was performed by the number of days you specify.


Note For AS Spyware Definition rules, the system will enforce this feature (allowing the definition files to be X days older then the current system date) until Cisco Update service is available to regularly update the date/version for Spyware definition files.

When this feature is configured for a requirement, the Agent checks for the definition date of the AV/AS product then verifies whether the date meets the requirement. If the Agent cannot detect the definition date (i.e., def date detection is not supported for that product), the system ignores this feature and the Agent checks whether the client has the latest definition version.


5. Scroll down the page and click the Select checkbox next to each rule you want to associate with the requirement. The rules will be applied in their order of priority, as described in Table 11-2.

Figure 11-25 Select Rules to Map to Requirement

6. For the Requirements met if option, choose one of the following options:

All selected rules succeed—if all the rules must be satisfied for the client to be considered in compliance with the requirement.

Any selected rule succeeds—if at least one selected rule must be satisfied for the client to be considered in compliance with the requirement.

No selected rule succeeds—if the selected rules must all fail for the client to be considered in compliance with the requirement.

If clients are not in compliance with the requirement, they will need to install the software associated with the requirement or take the steps instructed.

7. Click Update.

Apply Requirements to Role

Once requirements are created, configured with remediation steps, and associated with rules, they need to be mapped to user roles. This last step applies your requirements to the user groups in the system.


Note Make sure you already have normal login user roles created as described in Create User Roles, page 6-1.


1. In the Clean Access Agent tab, click the Role-Requirements submenu link.

Figure 11-26 Role- Requirements Mapping

2. From the Role Type menu, select the type of the role you are configuring. In most cases, this will be Normal Login Role.

3. Select the name of the role from the User Role menu.

4. Click the Select checkbox for each requirement you want to apply to users in the role.

5. Click Update.

6. Before finishing, make sure users in the role are required to use the Clean Access Agent. See Create Clean Access Agent Requirements.

Validate Requirements

The Clean Access Manager automatically validates requirements and rules as they are created. The Validity column under Device Management > Clean Access > Clean Access Agent > Requirements > Requirement List displays a blue checkmark if the requirement is valid and a red "X" if the requirement is invalid. Highlighting this icon with your mouse reveals which rule and which check is causing the requirement to be invalid, in the form:

Invalid rule [rulename] in package [requirementname] (Rule verification error: Invalid 
check [checkname] in rule expression)

The requirement must be corrected and made valid before it can be used. Typically requirements/rules become invalid when there is an operating system mismatch.

To Correct an Invalid Requirement:

1. Go to Device Management > Clean Access > Clean Access Agent > Requirements > Requirement-Rules

2. Correct any invalid rules or checks as described in Validate Rules.

3. Select the invalid Requirement Name from the dropdown menu.

4. Select the Operating System.

5. Make sure the Requirement met if: expression is correctly configured.

6. Make sure the rules selected for the requirement are valid (blue checkmark in Validity column).

Figure 11-27 Requirement List

Configure an Optional/Audit Requirement

You can make any requirement Mandatory, Optional, or Audit-only using the Enforce Type dropdown menu in the New Requirement or Edit Requirement form. Optional requirements allow you to view administrative reports for a Clean Access Agent user without blocking the client from the network if the optional requirement fails. If an optional requirement fails, the user is put in the Temporary role and will see "Optional" preceding the name of the requirement in the Agent dialog; however the user can click Next and either proceed to the next requirement or to the network if no other requirements are configured.

If you want to provide an extended period of time for users to meet requirements without blocking them from the network, you can configure an optional requirement with instructions to comply by a certain date. You can later enforce the requirement at the specified date to make the requirement mandatory.

If you want to ensure the client system is checked "silently" for the requirement without notifying the user, and a report is generated, you can configure an audit-only requirement that only reports results (pass or fail) does not affect user network access.

To Create an Optional/Audit Requirement:

1. Go to Device Management > Clean Access > Clean Access Agent > Requirements > New Requirement

Figure 11-28 Optional/Audit Requirement

2. Choose a Requirement Type from the dropdown.

3. Choose Optional (do not enforce) or Audit (silent assessment) as the Enforce Type from the dropdown menu.

For an Optional requirement, the user is informed of the requirement but can bypass it if desired (by clicking "Next"). The client system does not have to meet the requirement for the user to proceed or have network access. For an Audit requirement, the system generates audit reports, but no user dialogs appear on the client machine and the user's network access is unaffected.

4. Choose the Priority of execution for this requirement on the client. A high priority (e.g. 1) means this requirement is checked on the system ahead of all other requirements (and appears in the Agent dialogs in that order). Note that if a Mandatory requirement fails, the Agent does not continue past that point until that requirement succeeds.

5. Configure specific fields for the requirement type.

6. Type the Requirement Name for the optional requirement.

7. Type instructions in the Description field to inform users that this is an optional requirement and that they can still proceed to the network by clicking the Next button on the Agent dialog. Note the following:

File Distribution displays Download button on the Agent.

Link Distribution displays Go To Link button on the Agent.

Local Check displays Download button (disabled) on the Agent.

AV Definition Update displays Update button on the Agent.

AS Definition Update displays Update button on the Agent.

8. Click the checkbox(es) for the Operating System.

9. Click Add Requirement.

Optional requirements must be mapped to rules and user roles in the same way as mandatory requirements. Refer to the following sections to complete configuration:

Map Requirement to Rules

Apply Requirements to Role

Figure 11-29 Agent Dialog for Optional Requirement

Launch Programs Example

The following example shows how to use Launch Programs to launch a qualified (signed) program. If using a CA authority to sign the program, you can skip the steps related to how to perform your own application signing in the example.

If the user has admin privileges on the client machine, any program that is an executable is qualified.

If the user does not have admin privileges, the target executable is launched via Agent Stub. The executable must have:

1. A valid digital signature signed by certificates with specific field value(s)

2. Optionally, file version information with specific item value(s).

The values for certificate and file version information are also configurable in the registry.

Code or program signing is the process of attaching a digital signature to the program so that it can be considered "trustworthy" of launching. When NAC Appliance launches a signed program, the "Launcher" confirms that the signature is from a trusted source (i.e. CA certificate is in trusted store) before executing it. Application signing is needed because launching unsigned applications is a security risk. Anyone can mask a trojan/worm as the program that you are trying to launch and cause harm.

Certificate Authorities (CA), such as Thawte and Verisign, offer signing services.

To sign programs yourself, you need:

CA Server (Public or Private)

Certificate Issued by CA server

Private Key, CA server public key, for above cert

The .exe, .dll, .scr, .wsh that needs be signed

A signing tool (such as signcode.exe/signtool.exe)


Note Example references/tools:

http://www.pantaray.com/signcode.html

http://www.cryptguard.com/documentation_resources_tools.shtml


Add Requirement


Step 1 Create a New Requirement of type Launch Programs.

Step 2 Indicate whether the Requirement is Optional, Mandatory, or Audit.

Step 3 Indicate the root location from which to launch the qualified Program:

System_Root = C:\Windows

System_32 = C:\Windows\System32

System_Programs = C:\Program Files

Figure 11-30 Choose Root Location

Step 4 A more specific path and program parameters can be added:

Figure 11-31 Specify Program Parameters

Step 5 Click Add Program to add the program to the Program Name list.

Figure 11-32 Add Program

Step 6 Click Save Requirement.

Configure Application Signing


Step 1 Obtain a certificate and Private Key that will be used to sign your .exe file. You can obtain this from a Private CA (e.g. MS CA server) or Public CA (Verisign/Thawte, etc.).The rest of the files are tools you will need.

Figure 11-33 Obtaining Certificate

Step 2 Use the cert2spc.exe tool to create a SPC file also known as Software Publishing Certificate.

C:\inetsdk\test>cert2spc prem1.cer prem1.spc
Succeeded

Step 3 This creates a prem1.spc file as shown

Figure 11-34 Create Software Publishing Certificate (SPC)

Step 4 Run signcode.exe

C:\inetsdk\test>signcode

Figure 11-35 Run signcode. exe

Step 5 Browse and pick the .EXE that needs to be signed (tftpd.exe, in this example).

Figure 11-36 Choose Executable to Sign

Step 6 Pick the "Custom" option

Figure 11-37 Choose Custom Option

Step 7 Click "Select from File" and select the prem1.spc file created earlier.

Figure 11-38 Select SPC File

Step 8 Click "Browse" to select the private key prem1.pvk file.

Figure 11-39 Browse to Private Key

Step 9 Enter the password needed to use your private key (if any).

Figure 11-40 Enter Password to Private Key

Step 10 Select the hash algorithm you want to use for the signature.

Figure 11-41 Select Hash Algorithm

Step 11 Leave default values for the screens shown.

Figure 11-42 Leave Defaults

Step 12 Click Finish.

Figure 11-43 Click Finish

Step 13 If prompted again for Private Key, re-enter it. You will see the message:

Figure 11-44 Re-Enter Private Key if Necessary

Step 14 Confirm that your EXE is signed by right- clicking the file and selecting "Properties". The digital signatures tab and the Certificate CN name will confirm it.

Figure 11-45 Confirm Signed Executable

Step 15 Next, create a custom check/rule on NAC Appliance to check if the application called TFTPD32.exe is running or not.

Figure 11-46 Create Check

Step 16 Finally, create a requirement that uses this rule as follows:

Figure 11-47 Create Requirement


Launch Signed Program: User View


Step 1 User logs in with Agent. NAC Appliance detects that TFTPD32.exe is not running. User is quarantined and asked to remediate.

Step 2 User clicks on Launch and TFTPD32.exe is launched.

Step 3 User clicks Next and logs onto network.

Figure 11-48 Launch Signed Program: User View


Viewing Clean Access Agent Reports

The Clean Access Agent Reports page (under Device Management > Clean Access > Clean Access Agent > Reports > Report List) gives you detailed information about the activities of the Clean Access Agent. The information includes user access attempts and system check results.

Report List entries with an orange background indicate clients who failed system checking.

Using the Report page, administrators can log and search Clean Access Agent reports to facilitate information gathering. The Reports page provides an "Advanced/Simple" toggle option that expands the search criteria to include the following options:

AV/AS Software:
The AV/AS Software dropdown menu allows you to search/display client reports for the following cases:

AntiVirus Software Installed

AntiSpyware Software Installed

Unknown AV/AS Software Installed

Requirement and Success/Failure:
The Requirement dropdown lists all Clean Access Agent requirements configured in the system, and the Success/Failure dropdown option allows you to search/display success or failure client reports for the chosen requirement.

Clicking the Show button after selecting any of the Simple or expanded Advanced search options will display a summary of all entries that match the criteria as well the detailed administrator report for each client.

Figure 11-49 Clean Access Agent Administrator Report

Click the View button to see an individual user report, as shown in Figure 11-50.

Figure 11-50 Example Clean Access Agent User Report

In addition to user, operating system, Agent version, and domain information, the Clean Access Agent report lists the requirements applicable for the user role (both Mandatory and Optional). Requirements that the user met are listed in green, and failed requirements are listed in red. The individual checks making up the requirement are listed by status of Passed, Failed, or Not executed. This allows you to view exactly which check a user failed when a requirement was not met.

Not Executed checks are checks that were not applied, for example because they apply to a different operating system. Failed checks may be the result of an "OR" operation. To clear the reports, click the Delete button. The button clears all the report entries that are currently selected by the filtering criteria.

Limiting the Number of Reports

You can limit the number of reports in the log under Device Management > Clean Access > Clean Access Agent > Reports > Report Setting. Specify the maximum number of reports as a value between 100 and 200000 (default is 30000).

Clean Access Agent reports are stored in their own table and are separate from the general Event Logs.

Clean Access Agent User Dialogs

This section describes the following:

Windows Agent Dialogs

Mac OS X Agent Dialogs (Authentication Only)

RADIUS Challenge-Response Agent Dialogs


Note For details on localized language templates for the Clean Access Agent, refer to Agent Localized Language Templates, page 10-20.


Windows Agent Dialogs

This section illustrates the user experience when Cisco NAC Appliance is installed on your network and the Clean Access Agent is required and configured for the user role.


Note For details on the Clean Access Agent when configured for Single Sign-On (SSO) behind a VPN concentrator, see the Cisco NAC Appliance - Clean Access Server Installation and Configuration Guide, Release 4.1(2).


1. When the user first opens a web browser, the user is redirected to the web login page (Figure 11-52).

Figure 11-51 Login Page

2. The user logs into the web login page and is redirected to the Clean Access Agent Download page (Figure 11-52) for the one-time download of the Clean Access Agent installation file.

Figure 11-52 Clean Access Agent Download Page

3. The user clicks the Download Clean Access Agent button (the button will display the version of the Agent being downloaded).


Note If the "Allow restricted network access in case user cannot use Clean Access Agent" option is selected under Device Management > Clean Access > General Setup > Agent Login, the Get Restricted Network Access button and related text will display in the Download Clean Access Agent page. See Agent Login, page 9-17 for details.


4. The user should Save the CCAAgent_Setup.exe file to a download folder on the client system, then Run the CCAAgent_Setup.exe file.


Note If the CAS certificate is not trusted on the client, the user must accept the certificate in the Security Alert dialog that appears before Agent installation can successfully proceed.


5. The Welcome to the InstallShield Wizard for Clean Access Agent dialog appears (Figure 11-53).

Figure 11-53 Clean Access Agent InstallShield Wizard

6. The setup wizard prompts the user through the short installation steps to install the Clean Access Agent to C:\Program Files\Cisco Systems\Cisco Clean Access\Clean Access Agent and adds a desktop shortcut on the client (Figure 11-54).

Figure 11-54 Desktop Shortcut

7. When the InstallShield Wizard completes and the user clicks Finish, the Clean Access Agent login dialog pops up (Figure 11-55) and the Clean Access Agent taskbar icon appears in the system tray.

Figure 11-55 Clean Access Agent Login Dialog

8. The user enters credentials to log into the network. Similar to the web login page, an authentication provider can be chosen from the Provider list (if configured for multiple providers).


Note Clicking the session-based Remember Me checkbox causes the User Name and Password fields to be populated with the last values entered throughout multiple logins/logouts if the user does not exit or upgrade the application or reboot the machine. On shared machines, the Remember Me checkbox can be unchecked to ensure multiple users on the machine are always prompted for their individual username and password.

If Cisco Clean Access employs a RADIUS server for user authentication and the server has been configured to authenticate users with additional credentials, the user may be presented with one or more additional challenge-response dialogs like those described in Example Windows RADIUS Challenge-Response User Login Session Dialogs.


9. The user can right-click the Clean Access Agent icon in the system tray to bring up the taskbar menu for the Agent (Figure 11-56).

Figure 11-56 Clean Access Agent Taskbar Menu

Taskbar menu options are as follows:

Login/Logout—This toggle reflects the login status of the user.

Login means the user is behind a Clean Access Server and is not logged in.

Logout means the user is already logged into Cisco NAC Appliance.

Disabled (grey) Login occurs when there is no SWISS response from the CAS to the Agent. This condition is expected in the following cases:

The Clean Access Agent cannot find a Clean Access Server.

OOB deployments: the Agent user has already logged in through the CAS and is now on the Access VLAN.

Multi-hop L3 (VPN/WLC) deployments with SSO: the user has authenticated through the VPN concentrator and therefore is already automatically logged into Cisco NAC Appliance.

Device Filters: MAC address-based authentication is configured for the machine of this user and therefore no user login is required.

Popup Login Window—This option is set by default when the Agent is first installed and causes the Agent login dialog to automatically pop up when it detects that the user is behind a Clean Access Server and is not logged in.

Properties—Selecting Properties brings up the Agent Properties and Information dialog (Figure 11-57) which shows all of the AV and AS products installed on the client machine and the Discovery Host for L3 deployments.

Figure 11-57 Properties

About—Displays the version of the Agent (Figure 11-58).

Figure 11-58 About

Exit—Exits the application, removes the Agent icon on the taskbar, and automatically logs off the user.


NoteAfter exiting the Agent or if the taskbar icon is not running, the user can click the Desktop shortcut (Figure 11-57) to bring up the Agent and display the taskbar icon.

If "Popup Login Window" is disabled on the taskbar menu, the user can always right-click the Agent icon from the system tray and select Login (Figure 11-56) to bring up the login dialog.



Note Auto-Upgrade for Already-Installed Agents: When the Agent is already installed, users are prompted to auto-upgrade at each login, unless you disable upgrade notification. You can optionally force logout at machine shutdown (default is for users to remain logged in at machine shutdown). You can configure auto-upgrade to be mandatory or optional. With auto-upgrade enabled and a newer version of the Agent available from the CAM, existing Agent users will see one of the following upgrade prompts at login (Figure 11-59 or Figure 11-60).

Figure 11-59 Example Auto-Upgrade Prompt (Mandatory)

Figure 11-60 Example Auto-Upgrade Prompt (Optional)

10. Clicking OK or Yes then brings up the setup wizard to upgrade the Agent to the newest version (Figure 11-53). After Agent upgrade and user log in, requirement checking proceeds.


11. After the user submits his or her credentials, the Clean Access Agent automatically checks whether the client system meets the requirements configured for the user role. If network scanning is also configured, the dialog shown in Figure 11-61 additionally appears.

Figure 11-61 Agent Scanning Dialog

12. If required software is determined to be missing, the You have temporary access! dialog appears (Figure 11-62). The user is assigned to the Clean Access Agent Temporary role for the session timeout indicated in the dialog. The Temporary role session timeout is set by default to 4 minutes and should be configured to allow enough time for users to access web resources and download the installation package for the required software.

Figure 11-62 Temporary Access—Requirement Not Met

13. When the user clicks Continue, the Agent dialog for the AV or custom requirement displays to identify the missing software and present the instructions, action buttons, and/or links configured for the requirement type.

14. The Description text displays what you configured in the Description field of the requirement to direct the user to the next step. Specify instructions for the AV or AS update to be executed, the web resource to be accessed, the installation file you are distributing through the CAM, or any other aspects of the requirement that may need explanation.

For an AV Definition Update requirement (Figure 11-63), the user clicks the Update button to update the client AV software on the system.

Figure 11-63 AV Definition Update Requirement Example

The Clean Access Agent will display a success confirmation once the AV/AS software is updated (Figure 11-64)

Figure 11-64 AV Definition Update Success Confirmation


Note The Agent displays a success confirmation based on the response it receives from the update mechanism of the AV/AS software installed on the client. The Agent does not control the update interaction itself between the AV/AS client software and the update server.


For an AS Definition Update requirement (Figure 11-65), the user clicks the Update button to update the definition files for the Anti-Spyware software on the client system.

Figure 11-65 AS Definition Update Requirement Example

For a Windows Update requirement (Figure 11-66), the user clicks the Update button to set the Windows Update and force updates on the client system if "Automatically Download and Install" is configured for the requirement.

Figure 11-66 Windows Update Requirement Example

For a Windows Server Update Service requirement (Figure 11-67), the user clicks the Update button to set the Windows Server Update Service and force updates on the client system.

Figure 11-67 Windows Server Update Service Requirement Example

For a Launch Program requirement (Figure 11-68), the user clicks the Launch button to automatically launch the qualified program for remediation if the requirement is not met.

Figure 11-68 Launch Program Requirement Example

For a File Distribution requirement (Figure 11-69), the button displays Download instead of Go To Link. When the user clicks download, the Save file to dialog appears. The user needs to save the installation file to a local folder, and run the executable file from there.

Figure 11-69 File Distribution Requirement Example

For a Link Distribution requirement (Figure 11-70), the user can access the website for the required software installation file by clicking Go To Link. This opens a browser for the URL specified in the Location field.

Figure 11-70 Link Distribution Requirement Example

15. Clicking Cancel at this stage stops the login process.

16. For each requirement, the user needs to click Next to proceed after completing the action required (Update, Go To Link, Download). The Agent again performs a scan of the system to verify that the requirement is met. If met, the Agent proceeds to the next requirement configured for the role.

17. If a Network Policy page was configured for the role, the following dialog will appear (Figure 11-71) after requirements are met. The user can view the "network usage policy" HTML page (uploaded to the CAM or external server) by clicking the Network Usage Terms & Conditions link. The user must click the Accept button to successfully log in.

Figure 11-71 Network Policy Dialog

See Configure Network Policy Page (Acceptable Use Policy) for Agent Users, page 10-6 for details on configuring this dialog.

18. When all requirements are met (and Network Policy accepted, if configured), the user is transferred from the Temporary role to the normal login role and the login success dialog appears (Figure 11-72). The user is free to access the network as allowed for the normal login role.


Note If the "Do not enforce requirement" option is checked (to make a requirement optional), when the user clicks Next in the Agent for the optional requirement, the next requirement dialog will display or the login success dialog will appear if all other requirements are met.



Note The administrator can configure the Login and Logout success dialogs to close automatically after a specified number of seconds, or not to appear at all. See Agent Login, page 9-17 for details.


Figure 11-72 Successful Login

19. To log off the network, the user can right-click the Clean Access Agent icon in the system tray and select Logout. The logout screen appears (Figure 11-73). If the administrator removes the user from the network, the Login dialog will reappear instead (if Popup Login Window is set).


Note The administrator can configure the Login and Logout success dialogs to close automatically after a specified number of seconds, or not to appear at all. See Agent Login, page 9-17 for details.


Figure 11-73 Successful Logout

20. Once a user has met requirements, the user will pass these Clean Access Agent checks at the next login unless there are changes to the user's computer or Clean Access Agent requirements.

21. If a required software installation requires users to restart their computers, the user should log out of the network before restarting. Otherwise, the user is still considered to be in the Temporary role until the session times out. The session timeout and heartbeat check can be set to disconnect users who fail to logout of the network manually.

Mac OS X Agent Dialogs (Authentication Only)

Cisco NAC Appliance provides a Clean Access Agent for Mac OS X machines that performs authentication only. The Agent is in the form of a universal binary that supports Mac OS 10.2 to 10.4. The Mac OS X Clean Access Agent supports single-sign on (SSO) with VPN deployments but does not support SSO with Active Directory.


Note In the CAM web console, you can view the distribution options for the Mac OS X Clean Access Agent under Device Management > Clean Access > Clean Access Agent > Distribution. See Distribution Page, page 10-12 for details.



Note For details on "SSL Requirements for Mac OS/CAS Communication" refer to the Cisco NAC Appliance - Clean Access Server Installation and Configuration Guide.


Figure 11-74 Distribution - CAM Web Console

The Mac OS Agent user sequence is as follows.

1. The user is redirected to the Login page (Figure 11-75).

Figure 11-75 Login Page—Mac OS X

2. The user is directed to the Download Clean Access Agent page (Figure 11-76).

Figure 11-76 Download Agent—Mac OS X

3. The user clicks the "Download" button and the CCAAgent_Mac OSX.tar.gz.tar file is download to the desktop (Figure 11-77) and untarred.

Figure 11-77 Download Clean Access Agent Setup Executable to Desktop

4. The user double-clicks the CCAAgent.pkg file and the Mac OS installer for the Clean Access Agent starts up (Figure 11-78).

Figure 11-78 Double-Click CCAAgent.pkg to Start Clean Access Agent Installer

5. The user clicks the Continue button to proceed with the Read Me and Select Destination screens of the installer (Figure 11-79).

Figure 11-79 Installation Executes

6. The user clicks the Upgrade button to perform the installation (Figure 11-80). When done, the user clicks Close.

Figure 11-80 Installation Executes (Continued


Note If the Agent has never been installed on the machine, the Installation screen (Figure 11-80) displays an "Install" button. If the Agent was installed at one point, even if there is no Agent currently in the system when the installer is invoked, the "Upgrade" button is displayed.


7. After installation, the Clean Access Agent login dialog appears. The Agent icon is now available from the Tool Menu (Figure 11-81). Right-clicking the Agent icon brings up the menu choices:

Login/Logout (toggle depending on login status)


Note If Cisco Clean Access employs a RADIUS server for user authentication and the server has been configured to authenticate users with additional credentials, the user may be presented with one or more additional challenge-response dialogs like those described in Example Mac OS X RADIUS Challenge-Response User Login Session Dialogs.


Auto Popup Login Window (enabled by default)

About (displays version screen for the Agent)

Quit (exits the Agent application)

Figure 11-81 Agent Login Pops Up / Desktop Icon Available from Tool Menu

8. The Agent login status is indicated by the tool tip popup and the color of the Agent icon in the menu.

GREEN (Figure 11-82) indicates:

CAS is discovered

Login status is "Logged In"

CAS status is Fallback: "Allow All"; user status will be "Bypass"

Agent is filtered by MAC address with "Allow/Role", with user status of "Logged-In"

Figure 11-82 Agent Login Status—Green (Logged In)

GREY (Figure 11-83) indicates the CAS is not discovered.

Figure 11-83 Agent Login Status—Grey (CAS is Not Discovered)

ORANGE (Figure 11-84) indicates:

CAS is discovered

Login status is not logged in

CAS status is Fallback: "Block All"; user status will be "Blocked"

Agent is filtered by MAC address with "Deny"; user status will be "Blocked"

Agent is filtered by MAC address with "Check"; user status is not supported currently.

Figure 11-84 Agent Login Status—Orange (CAS is Discovered/Agent Not Logged In)

9. The Clean Access Agent application itself is installed under Macintosh HD > Library > Application Support > Cisco Systems > CCAAgent (Figure 11-85)

Figure 11-85 Clean Access Agent—Application Installation Location

10. The Clean Access Agent event.log debug file and setting.plist system preferences file are installed under <username> > Library > Application Support > Cisco Systems > CCAAgent (Figure 11-86)

Figure 11-86 Clean Access Agent—Event.log and Setting.plist File Locations

11. The setting.plist file (Figure 11-87) will include:

LogLevel selected for Agent event.log

Whether Remember Me is checked in the Login screen

Whether AutoPopup Login Window is checked in the Menu.

Figure 11-87 Clean Access Agent—Setting.plist File Contents

RADIUS Challenge-Response Agent Dialogs

If you configure the Clean Access Manager to use a RADIUS server to validate remote users, the end-user Clean Access Agent login session may feature extra authentication challenge-response dialogs not available in other dialog sessions—beyond the standard user ID and password. This additional interaction is due to the user authentication profile on the RADIUS server, itself, and does not require any additional configuration on the Clean Access Manager. For example, the RADIUS server profile configuration may feature an additional authentication challenge like verifying a token-generated PIN or other user-specific credentials in addition to the standard user ID and password. In this case, one or more additional login dialog screens may appear as part of the login session.

The following two sections provide examples of the dialog exchange for both Windows and Mac OS X Agent user authentication.

Example Windows RADIUS Challenge-Response User Login Session Dialogs

1. The remote user logs in normally and provides their username and password as shown in Figure 11-55.

Figure 11-88 Clean Access Agent Login Dialog

2. If the associated RADIUS server has been configured to authenticate users with additional credentials, the user is presented with one or more additional challenge-response dialogs (like the password renewal scenario shown in Figure 11-89) for which they must provide additional credentials to authenticate and connect.

Figure 11-89 Additional Windows RADIUS Challenge-Response Session Dialog

3. Once the additional challenge-response(s) are validated, the RADIUS server notifies the Clean Access Manager that the user has successfully authenticated and should be granted remote access.

Figure 11-90 Windows RADIUS Challenge-Response Authentication Successful

Example Mac OS X RADIUS Challenge-Response User Login Session Dialogs

1. The remote user logs in normally and provides their username and password in the Agent login dialog as shown in Figure 11-91.

Figure 11-91 Mac OS X Login Dialog

2. If the associated RADIUS server has been configured to authenticate users with additional credentials, the user is presented with one or more additional challenge-response dialogs (like the password renewal scenario shown in Figure 11-92) for which they must provide additional credentials to authenticate and connect.

Figure 11-92 Additional Mac OS X RADIUS Challenge-Response Dialogs

3. Once the additional challenge-response(s) are validated, the RADIUS server notifies the Clean Access Manager that the user has successfully authenticated and should be granted remote access.

Figure 11-93 Mac OS X RADIUS Challenge-Response Authentication Successful

Troubleshooting the Agent

This section contains the following:

Client Cannot Connect/Login

No Agent Pop-Up/Login Disabled

Client Cannot Connect (Traffic Policy Related)

AV/AS Rule Troubleshooting

Known Issue for Windows Script 5.6

Known Issue for MS Update Scanning Tool (KB873333)

Client Cannot Connect/Login

The following client errors at login can indicate CAM/CAS certificate related issues (i.e. the CAS does not trust the certificate of the CAM, or vice-versa):

Users attempting web login continue to see the login page after entering user credentials and are not redirected.

Users attempting Agent login see the following error: "Clean Access Server could not establish a secure connection to the Clean Access Manager at <IPaddress or domain>

To resolve these issues, refer to Troubleshooting Certificate Issues, page 14-15.

No Agent Pop-Up/Login Disabled

For L2 or L3 deployments, the Clean Access Agent will pop up on the client if "Popup Login Window" is enabled on the Agent and the Agent detects it is behind the Clean Access Server. If the Agent does not pop up, this indicates it cannot reach the CAS.

To Troubleshoot L2 Deployments:

1. Make sure the client machine can get a correct IP address. Open a command tool (Start > Run > cmd) and type ipfconfig or ipconfig /all to check the client IP address information.

2. If necessary, type ipconfig /release, then ipconfig /renew to reset the DHCP lease for the client.

To Troubleshoot L3 Deployments:

1. Check whether the Discovery Host field is set to the IP address of the CAM itself under Device Management > Clean Access > Clean Access Agent > Installation | Discovery Host. This field must be the address of a device on the trusted side and cannot be the address of the CAS.

2. Uninstall the Agent on the client.

3. Change the Discovery Host field to the IP address of the CAM and click Update.

4. Reboot the CAS.

5. Re-download and re-install the Agent on the client.


Note The Login option on the Agent is correctly disabled (greyed out) in the following cases:

For OOB deployments, the Agent user is already logged in through the CAS and the client port is on the Access VLAN.

For multi-hop L3 deployments, Single Sign-On (SSO) has been enabled and the user has already authenticated through the VPN concentrator (therefore is already automatically logged into Cisco NAC Appliance).

MAC address-based authentication is configured for the machine of this user and therefore no user login is required.


Client Cannot Connect (Traffic Policy Related)

The following errors can indicate DNS, proxy or network traffic policy related issues:

User can login via Agent, but cannot access web page/Internet after login.

User cannot access web login page without typing in https://<CAS_IP_address> as the URL.

To troubleshoot these issues:

Verify and/or change DNS Servers setting on the CAS (under Device Management > CCA Servers > Manage <CAS_IP> > Network > DNS)

If enabling the CAS as a DHCP server, verify and/or change the DNS Servers field for the Subnet List (under Device Management > CCA Servers > Manage <CAS_IP> > Network > DHCP > Subnet List > List | Edit).

If remediation sites cannot be reached after login, verify default host policies (Allowed Hosts) are enabled for the Temporary role (under User Management > User Roles > Traffic Control > Host).

If using a proxy server, make sure a traffic policy allowing HTTP traffic to the proxy server is enabled for the Temporary role. Verify the proxy is correctly set in the browser (from IE go to Tools > Internet Options > Connections > LAN Settings | Proxy server).

See Troubleshooting Host-Based Policies, page 8-28 for additional details.

AV/AS Rule Troubleshooting

To view administrator reports for the Clean Access Agent, go to Device Management > Clean Access > Clean Access Agent > Reports. To view information from the client, right-click the Agent taskbar icon and select Properties.

When troubleshooting AV/AS Rules, please provide the following information:

1. Version of CAS, CAM, and Clean Access Agent.

2. Client OS version (e.g. Windows XP SP2)

3. Name and version of AV/AS vendor product.

4. What is failing—AV/AS installation check or AV/AS update checks? What is the error message?

5. What is the current value of the AV/AS def date/version on the failing client machine?

6. What is the corresponding value of the AV/AS def date/version being checked for on the CAM? (see Device Management > Clean Access > Clean Access Agent > Rules > AV/AS Support Info)

Known Issue for Windows Script 5.6

Windows Script 5.6 is required for proper functioning of the Clean Access Agent. Most Windows 2000 and older operating systems come with Windows Script 5.1 components. Microsoft automatically installs the new 5.6 component on performing Windows updates. Windows installer components 2.0 and 3.0 also require Windows Script 5.6. However, PC machines with a fresh install of Windows 98, ME, or 2000 that have never performed Windows updates will not have the Windows Script 5.6 component. Cisco NAC Appliance cannot redistribute this component as it is not provided by Microsoft as a merge module/redistributable.

In this case, administrators will have to access the MSDN website to get this component and upgrade to Windows Script 5.6. For convenience, links to the component from MSDN are listed below:

Win 98, ME, NT 4.0:

Filename: scr56en.exe

URL: http://www.microsoft.com/downloads/details.aspx?familyid=0A8A18F6-249C-4A72-BFCF-FC6AF26DC390&displaylang=en

Win 2000, XP:

Filename: scripten.exe

URL: http://www.microsoft.com/downloads/details.aspx?familyid=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en

If these links change on MSDN, try a search for the file names provided above or search for the phrase "Windows Script 5.6."

Known Issue for MS Update Scanning Tool (KB873333)

Background

KB873333 is a critical update that is required for Windows XP Professional and Home for SP1 and SP2. It fixes an OS vulnerability that can allow remote code to run. However, Microsoft had a bug in this hotfix which caused problems on SP2 editions (home/pro). This bug required another fix (KB894391), because KB873333 on SP2 caused a problem with displaying Double Byte Character Sets (DBCS). However, KB894391 does not replace KB873333, it only fixes the DBCS display issue.

Ideally, KB894391 should not be installed or shown in updates unless the user machine has KB873333. However, the MS Update Scanning Tool tool shows it irrespective of whether or not KB873333 is installed. In addition, if due to ordering of the updates, KB894391 is installed, the MS Update Scanning Tool does not show KB873333 as being installed, thereby leaving the vulnerability open. This could happen if the user does not install KB873333 and only selects KB894391 to install from the updates list shown or manually installs KB894391 without installing KB873333 first. In this case, the next time updates are run, the user will not be shown KB873333 as a required update, because the MS Update Scanning Tool (including MS Baseline Analyzer) will assume KB873333 is installed if KB894391 is installed, even if this is not true and the machine is still vulnerable.

Workaround

Because of this potential vulnerability, Cisco does not intend to remove the update check for KB87333 from the Clean Access ruleset and users should manually download and install KB873333 to protect their machines. This can be done in one of two ways:

Option 1 (Cisco Recommended Option)

Create a new Link requirement in the CAM web console to check for KB873333, using the following steps:

1. Create a rule to check for the presence of KB873333. To create this rule, go to the Rules section of the web console and click New Rule. Give the rule a name (e.g. "KB873333_Rule"), and for the rule expression, copy/paste the exact name of the KB873333 check from the list of checks displayed on that page (the list of available checks appear below the new rule creation section). Save the rule by clicking "Add Rule."

2. Download the update executable for KB873333 from Microsoft's website and host it on an available web server.

3. Create a Link Requirement on CCA, and enter the URL from step 2.

4. Create Requirement-Rules for this requirement by selecting the rule you created in step 1.

5. Finally, go to the Role-Requirements section, and associate the Requirement you just created with the role to which you want this to be applied.


Note On the Requirements page, make sure that the KB873333 requirement is above the Windows Hotfixes requirement.


Option 2

Uninstall KB894391 from affected machines. After rebooting, go to the Windows Update page again. Windows Update should now display both the updates. Install KB873333 and KB894391 on the client machine. Note that this requires administrators to educate users or manually perform this task on the user machines.