This guide will show you how to use ClearPass policy logic along with custom attributes to steer users off of your open and guest networks and over to your secure SSID.
Some notes:
- For this to work, your controller must have an L3 interface for each user subnet/VLAN
- This guide assumes you already have MAC-AUTH configured for your open and guest networks
- For the purposes of this tutorial, secure network = secureNET, guest network = guestNET, open network = openNET
- Product versions used: CPPM 6.3, ArubaOS 6.4 w/ PEF-NG
- You'll need to ensure that your controller is configured for name lookups and you have DNS servers specified
There are two actions that can be assigned to an end user device after attempting to connect:
- Redirect user to an informational captive portal
- Deny all access (including DHCP; useful to conserve IP addresses)
PART 1: CPPM CONFIGURATION
Step 1: Creating attributes
The first step is to create the two custom attributes for the endpoint database. The names can be anything you want.
If you don’t want to manually create them, both attributes are attached at bottom of this post and can be imported. (Administration > Dictionaries > Attributes > Import Attributes)
Navigate to Administration > Dictionaries > Attributes, then click Add Attribute
Attribute 1: “AUTHED-VIA-1X”
Attribute summary: Endpoints will tagged with this attribute after completing successful 802.1X authentication to secureNET
Entity: “EndPoint”
Attribute data type: Boolean (true/false)
Attribute 2: “Override-OpenSSID”
Attribute summary: This is used as an override to allow a device on to open.
Entity: “EndPoint”
Attribute data type: Boolean (true/false)
Step 2: Creating enforcement profile to add attribute
If you don’t want to manually create the profile, it is attached at the bottom of this post and can be imported.
(Configuration > Enforcement > Profiles > Import Enforcement Profiles)
Navigate to Configuration > Enforcement > Profiles, then click Add Enforcement Profile
Choose “ClearPass Entity Update Enforcement” from the template list.
Choose a name and description. We’ll call it “ENDPOINTDB_AUTHED-VIA-1X_TRUE”. Click Next.
You’ll now see an empty attribute screen. Click to add an attribute.
Select “Endpoint” for type and “AUTHED-VIA-1X” for the name. Then click the check box for “Value”.
Click Next, then Save.
Step 3: Tagging AUTHED-VIA-1X on secureNET
Navigate to your secureNET enforcement policy (Configuration > Enforcement > Policies)
Either create a copy of your active enforcement policy, then open it (the copy) or create a new policy from scratch.
If you are using the copy of an existing policy, you will most likely have a few rules already configured.
ORIGINAL ENFORCEMENT POLICY
The goal here is to add the Post_Auth profile that we created in step 2 to each rule and also to check for the attribute towards the top of your policy so that you don’t write the attribute every time someone authenticates (saves processing power and time).
NEW ENFORCEMENT POLICY WITH POST_AUTH UPDATE
Step 4: Creating enforcement profiles for guestNET and openNET
In this step we will create the enforcement profile that returns the appropriate role to the controller. The names can be anything you want.
If you don’t want to manually create them, both enforcement profiles are attached at bottom of this post and can be imported. (Configuration > Enforcement > Profiles > Import Enforcement Profile)
Navigate to Configuration > Enforcement > Profiles and click Add Enforcement Profile.
Choose “Aruba RADIUS Enforcement” and give it a name. Click Next.
The Aruba-User-Role attribute is prepopulated. Click “Enter role here” and enter the Aruba User Role name that will be used on the controller (We will create this controller user role later). Click Next to review the settings and then Save.
Repeat these steps two more times to create a “GUEST-REDIRECT-ROLE” profile and also a “DENYALL-1XCAPABLE-ROLE” profile.
Step 5: Add logic to open and guest enforcement policies.
As in step 3, find your your existing MAC-AUTH policies, create a copy of them, and then open. You can also create a new one from scratch.
We’ll do the openNET enforcement as an example. The guestNET policy will be set up the same way.
You’ll need to choose the end result for your clients. If you are trying to conserve IP addresses from drive-by clients on your open network, I would suggest using the DENYALL-1XCAPABLE-ROLE. This role will block DHCP. If you want the user to get an informational web page, use the OPEN/GUEST-REDIRECT-ROLE.
Here’s the rules you’ll want to add to the top of the policy:
For the guestNET policy, just add the AUTHED-VIA-1X rule at the top.
PART 2: INFORMATIONAL PAGE
This step is where you’ll create your informational page.
A couple of notes:
- You should host this page on an external web server and not in ClearPass or on the controllers.
- Since it is solely an informational page, use HTTP. Adding an SSL certificate can add more complexity.
SAMPLE INFORMATIONAL PAGE WITH STEP-BY-STEP SCREENSHOTS FOR REMOVING OPEN NETWORK
PART 3: CONTROLLER CONFIGURATION
Step 1: Create NETDESTINATIONS
We’ll need to configure NETDESTINATIONS for sites that you want to allow.
The most important one is the server where you are hosting the informational page. Some others that you might consider:
- Your internal IT website / self-help site
- IT ticketing system
- Driver update sites (Intel.com, support.dell.com, etc)
A couple of notes:
- Ensure that name lookups are enabled on your controller and that DNS servers are configured.
- You’ll need to create each NETDESTINATION twice if you are using both IPv4 and IPv6 on your network.
Once you are logged in to the controller, navigate to:
Configuration > Advanced Services > Stateful Firewall and then click the Destination tab.
Click the Add button at the bottom. IPv4 will be selected by default. Give the destination a name.
Now click Add and select name for Rule Type. Enter in the DNS name for the informational splash screen. Click Add, then apply.
Repeat this process for any other destination networks or DNS names that you want to allow.
Step 2: Create redirect ACL
Navigate to Configuration > Security > Access Control and then click the Policies tab.
Let’s first create the captive portal redirect ACL.
Click the Add button at the bottom.
Give the ACL a name. (CAPTIVE-REDIRECT-ACL for example)
Add the following rules, then click Done.
Step 3: Create open and guest redirect user roles
Navigate to Configuration > Security > Access Control and click Add at the bottom.
Give the user role a name to match the enforcement profile in ClearPass.
Add the logoncontrol and CAPTIVE-REDIRECT-ACL ACLs then click Apply.
Repeat these steps for the GUEST-REDIRECT-ROLE.
Step 4: Create DENYALL-1XCAPABLE-ROLE user role
Navigate to Configuration > Security > Access Control and click Add at the bottom.
Give the user role a name to match the enforcement profile in ClearPass.
Click the Add button and then Create New Policy.
Give the policy a name and change the type to session. Add the following rules:
Click Apply then Done to bring you back to the user role. Now click Apply.
Step 5: Create captive portal profile
Navigate to:
Configuration > Security > Authentication > L3 Authentication > Captive Portal Authentication
In the blank text box, give the profile a name then click Add. Now click the profile in the left column.
Change the default role and guest role to the OPEN-REDIRECT-ROLE.
Change the Redirect Pause to 0.
Uncheck both User Login, Guest Login and Logout popup window.
Now for both Login page and Welcome page, enter in the URL of your information page.
For the whitelist section, use the drop down and add in the NETDESTINATIONS that we created earlier (the web server where the info page is located and any other sites that you want to allow while in this role).
Click Apply at the bottom when you are done. Repeat this step for the guest informational page.
Once both captive portal configurations are complete, you’ll want to go back to the two redirect roles you created in step 3 and select the appropriate captive portal profile.
That sums up the main configuration. Now you should enable your services in ClearPass and start testing!
Some other notes:
How do I allow a device to reconnect to openNET with the Override-OpenSSID atttribute?
In ClearPass, navigate to Configuration > Identity > Endpoints and search for the device via the MAC address.
Open the Endpoint record and navigate to the Attributes tab.
At the bottom, click "Click to add..." and then select the Override-OpenSSID attribute and click the checkbox in the value column. Then click Save at the bottom.
This device can now connect to openNET again. If the device is currently connected and in the redirect role, go to Access Tracker, find the latest authentication record for that device and do a RADIUS CoA to get the user into the normal access role (Change State button).
What about devices that have always connected to openNET and should be connecting to secure?
You can add a fallback device check to handle these kind of situations on your openNET network. Do not use this on your guestNET.
Be aware that this process is making an assumption that either the device or operating system is known to be capable of connecting to your secure network. I’ve found that it’s about 95% accurate and our help desk was willing to deal with the 5% of users that are incorrectly categorized.
You’ll need to add some new logic to your openNET role map. We’ll use a combination of ClearPass profiling and Aruba-Device-Type attributes to tag operating systems and devices that we know are capable and assigning them a ClearPass TIPS role of “DEVICE_OS-1X-CAPABLE”.
Once you have set up the role map piece, you’ll want to add a new rule to your enforcement policy.
**MAKE SURE YOU HAVE THE ENDPOINT REPOSITORY SET AS AN AUTHORIZATION SOURCE IN YOUR OPENNET SERVICE**