Home > Networking Solutions > Campus Switches and Solutions > Campus and Mobility Networking Solutions > Guides > ClearPass NAC and Posture Assessment for Campus Networks Deployment Guide > Dell W-ClearPass configuration – wireless
W-ClearPass is configured using a UI on standard browsers. This guide will show the key steps and screenshots for configuring the example scenario. The entire browser window is not shown in each screenshot to improve readability. Usually, the navigation window on the left side of the screen is not shown. To ensure readers understand the configuration location shown, the navigation path is given before each screenshot. Within each major section, the current tab is highlighted with a dark blue color.
W-ClearPass allows administrators to configure policies and profiles directly from the main service configuration screen. When using this method of configuration, the necessary windows are opened automatically, which can streamline the amount of time it takes an experienced user to configure a fully functional service. In this guide, each profile and policy will be built before the creation of the service to aid in the description of navigating this configuration in this document.
Note: This guide does not detail the initial setup of the W-ClearPass server. For more information about VM installation, initial server configuration, and licensing, see the W-ClearPass User Guide at https://www.dell.com/support.
Before W-ClearPass will recognize authentication requests, the controller originating the request must be added to the list of network devices in W-ClearPass. The IP Address and RADIUS shared secret must match the configuration used on the controller as shown in the figure below.
To add Active Directory as an Authentication Source, perform the following steps:
The figure above shows a partial configuration of the Active Directory Authentication Source. This example uses a Windows Server with Active Directory installed as the source for username and password credential store.
W-ClearPass supports many different authentication sources.
Note: For more details on Active Directory configuration and other source types, see the W-ClearPass User Guide at https://www.dell.com/support.
W-ClearPass includes templates for many common services. These templates allow administrators to easily build the services and their associated policies.
This section details the use of the Aruba 802.1X Wireless template in the Start Here section within the Configuration section.
To create an 802.1X Wireless Service with Posture checks:
Note: The 802.1X Wireless name is later appended to the name prefix.
Note: Extra authentication sources can be added later.
Note: This message is displayed any time OnGuard detects a posture compliance issue.
Note: The User Role names must match exactly. These settings can be changed and added later.
Two Services are now added to the Services list.
Note: The numbering may vary between deployments.
To view the services, go to Configuration > Services. The two Services shown in previous figure are modified after the Posture, Role Mapping, and Enforcement Policies are configured.
The Aruba 802.1x Wireless template creates three posture policies with the prefix name used in the template. These policies are identical to the policies generated in the wired Define Posture policies section.
Note: Administrators can use the same wired and wireless policies to simplify the configuration. This example uses the wired policies previously created. If the wired example has not been completed within your network, see the Define Posture policies section.
Role Mappings are used to apply conditions to each user to classify them into Roles. The Roles are then used to identify users and can be used to enforce policies within the Service. There are numerous conditions and rules that can be used to form a Role Mapping. For more information about Roles and Role Mapping, refer to the W-ClearPass Policy Manger User Guide at https://www.dell.com/support.
In this guide, this example uses default Roles built into the W-ClearPass Policy Manger. The two Roles are [Employee] and [Guest]. Brackets surrounding the name identify default configurations in W-ClearPass.
Administrators can build sophisticated condition lists and any number of Rules to be as specific as needed to identify many types of users. This simplistic example will result in any user with the Employee department name in Active Directory being assigned the [Employee] Role. Any user that does not have this Active Directory department field populated with Employee will be assigned the default [Guest] Role.
The new role mapping will be used in the 802.1x RADIUS Service. A role mapping will not be used for the Health Check Service. A more detailed explanation of the two services is discussed later in this section.
Enforcement Policies are a group of rules with conditions that direct enforcement actions that ultimately are sent to the Network Access Device, which in this example is the W-Series controller. Enforcement profiles are a collection of attributes that define those enforcement actions.
The Aruba 802.1x Wireless template with posture checks produced two Services the Health Check Service and the Radius Service. Both of these services need Enforcement Policies, and their associated Enforcement Profiles. The Health Check Service produces a posture token by performing an action), while the Radius Service will use that token (within its conditions) to determine a User Role assignment action.
Enforcement Profiles are used within the Enforcement Policies, so the profiles are configured first.
The Health Check Service requires a profile to terminate the session so that the RADIUS 802.1X authentication Service can use the posture token in a new authentication routine. The terminate session profile uses the Change of Authorization feature to force a reauthentication.
W-ClearPass has a default terminate session profile that can be used with the W-series controller. The name of the profile is [Aruba Terminate Session]. This example uses the default profile.
The following will detail an example of configuring the Enforcement Policy for the Health Check Service. The prepopulated policy from the template is sufficient for this example and most of the default settings are kept.
In this example, the name is Posture Scenario Aruba 802.1X Wireless OnGuard Agent Enforcement Policy, and its type is WEBAUTH. The template automatically generates this policy based on the prefix name.
For the example in this guide, use the prepopulated conditions and actions, leaving all other conditions at their default setting.
The first condition states that any posture token values not equal to HEALTHY (0) trigger this rule to be enforced. The Enforcement Profiles under the condition are the actions that are applied if the conditions in this rule are met. The first profile in the list is named [Agent] Posture Scenario Aruba 802.1X Wireless Quarantined Agent Enforcement. This profile displays a quarantine message to the client. You can access this profile in the list of Enforcement Profiles by clicking Configuration > Enforcement > Profiles. The profile was created from the Service template during the Service creation earlier. The settings for this profile are kept as the default and are not shown in this guide.
The second condition states that any posture token values equal to HEALTHY(0) trigger this rule to be enforced. The Enforcement Profiles under the condition are the actions that are applied if the conditions in this rule are met. The first profile in the list is named [Agent] Posture Scenario Aruba 802.1X Wireless Healthy Agent Enforcement. This profile displays a healthy message to the client. You can access this profile in the list of Enforcement Profiles by clicking Configuration > Enforcement > Profiles. The profile was created from the Service template during the Service creation earlier. The settings for this profile are kept as the default and are not shown in this guide.
This concludes the Enforcement Policy and profiles for the Health Check Service. The next steps detail the configuration for the policy and profiles used in the RADIUS 802.1X Service.
The RADIUS 8021.X Service requires an Enforcement profile to enable the assignment of a user role. In this example, a client device that fails a health check will be assigned to a quarantine user role named OnGuard-redirect. A client device that passes a health check will be assigned an employee user role named Employee. These user roles were previously configured in the W-Series controller.
The following steps create a profile to enforce a user role assignment.
Note: This example uses W-Series Employee Role as the profile name.
Note: In this example, Employee is the User role. Verify that the User role name exactly matches the user role name on the controller.
The following steps create a profile to enforce a quarantine user role assignment.
Note: This example uses W-Series Redirect to OnGuard as the profile name.
Note: In this example, OnGuard-redirect is the user role.
Use the following steps in this section to configure the Enforcement Policy for the RADIUS 802.1X Service. Use the prepopulated policy from the template for this example and note that some settings will be kept as default.
The following steps describe the contents of the Enforcement Policy.
Note: In this example, the name is Posture Scenario Aruba 802.1X Wireless Enforcement Policy, and the type is RADIUS. The template for this policy is automatically generated based on the prefix name.
Note: This example uses the quarantine profile to place users that fail authentication checks into the quarantine user role. If the administrator chooses, a profile to deny access or place users into a different user role is possible here.
In this example, the authentication policy has only two outcomes given the correct credentials:
The first outcome places the user in the employee user role Employee. The second outcome places the user into a quarantine user role OnGuard-redirect.
Note: If other user classifications and conditions are needed, you can add them now. More profiles or user roles may be required.
Note: The first condition must be saved before the second condition can be created.
Condition 1
Condition 2
Note: The first condition must be saved before the second condition can be created.
Condition 1
Condition 2
After you have defined and configured all the components of the Service, you can now configure the Services.
The template populates the Service Rules with two rules and requires that all rules match. In this example, you will only have to define the SSID name. Administrators can add other rules to narrow the devices that this Service will be applied to.
Note: In this example, the SSID name is Employee_CPDG. The Service tab should look like the following image.
Note: This example uses Microsoft Active Directory with username and password credentials. Keep the authentication methods for this example at the default settings. Dell Technologies recommends that you use any type of authentication method as required by your network security policy.
Note: For this example, leave all other options at their default setting.
Note: For this example, Roles are not needed for the Health Check Service.
During testing, you can keep the Posture Policies at their default settings, however, Dell Technologies recommends that you modify each policy specific to the operating system to reflect the heath posture being tested.
For initial testing, Dell Technologies recommends that you validate the functionality using the health check settings within a single operating system, such as Windows 7 and firewall.
Note: It is also useful to have control over the health status of the client. Autoremediation can fix many health issues automatically on the device. To verify that the assigned VLANs and other enforcement actions, Dell Technologies recommends that you clear the Remediate End-Hosts checkbox. This box can be checked at any time after verifying the policy actions are behaving as expected.
The template populates the appropriate Enforcement Policy in the drop-down menu.
W-ClearPass Services are now configured to include all supporting policies and roles.
The captive portal function within the W-Series controller can be used on both guest and employee networks. In this example, an employee network is enabled with a captive portal to allow easy access to the OnGuard download URL. It also provides access to the OnGuard dissolvable client URL.
W-ClearPass Guest provides a single solution web-hosting feature that does not require a separate webpage. If necessary, administrators can also use their own web hosting solution.
To create an OnGuard landing webpage:
Note: The Page Name should match the name used in the URL in the Create Captive Portal Authentication Profile section (http://ClearPass.IP.address/guest/page_name.php where page_name is the name entered in this step).
Note: Leave the Anonymous User field blank, as it will autopopulate the necessary information.
{nwa_text id=7980}<p>
<br>
To determine if your client meets the minimum security requirements:
<br>
<br>
Press the button below to run the dissolvable agent
<br>
<br>
</p>{/nwa_text}
Note: You can view the URL by accessing the W-ClearPass Policy Manager UI, or by clicking Administration > Agents and Software Updates > OnGuard Settings.
In this example, the following HTML is used:
{nwa_text id=7979}<p>
<br>
<p>OR</p>
<br>
<br>
<p>Click the link to download the persistent client.
<br>
<br>
</p>
<a href="http://172.25.172.188/agent/installer/windows/ClearPassOnGuardInstall.exe">Windows OnGuard Persistent Agent
</a>
<br>
<br>
<a href="http://172.25.172.188/agent/installer/mac/ClearPassOnGuardInstall.dmg">Mac OSX OnGuard Persistent Agent
</a>
<br>
<br>
<a
href="http://172.25.172.188/agent/installer/ubuntu/ClearPassOnGuardInstall.tar.gz">Ubuntu OnGuard Persistent Agent
</a>
</p>{/nwa_text}
The page displays in a new browser. If the example settings and HTML coding provided was used, the Login page should look like the following example:
The W-ClearPass and N-Series configuration in this guide can be tested with any client. The following details the use of a Windows 7 laptop.