802.1X WLAN using Aruba Controller & ClearPass (AOS8)

In this post, I will show you how to create an 802.1X WLAN using an Aruba Mobility Controller, ClearPass and Active Directory (AD) using the RADIUS protocol. I do a lot of consultancy work for private schools here in Australia so I will emulate a school network by authenticating students and staff members and applying separate security policies for each. As this is a lab environment, I will only configure the network to support EAP-PEAP with MSCHAPv2 (username and password authentication). We will allow the use of client-side certificates (EAP-TLS) in a future post.

Note that I am using an AOS8 version of the Mobility Controller software in this scenario. As part of my ACCX studies, I previously blogged the process for the 6.x release train of Mobility Controllers.

RADIUS Workflow

The RADIUS workflow for ClearPass can be a little confusing at first so I have created the image below in an attempt to simplify it for those just getting started. In this scenario the Network Access Device (NAD) is the Aruba Mobility Controller.

Controller Configuration

In this example I am using a standalone Mobility Controller and will be configuring all of my WLAN settings from the top level ‘Mobility Controller’ folder. The folder or device that you configure your settings from may differ with your environment especially if you are using one or more Mobility Masters.

SSID Profile

The SSID Profile is where we define our SSID name, authentication and encryption methods. Click Configuration > System > All Profiles > SSID and click the + sign.

Type in the Profile Name and the ESSID (the name of the network to be advertised by your APs) select WPA2AES as the encryption method. I’m leaving the rest of the settings as defaults however, in a production environment I would optimise these to meet customer requirements.

RADIUS Server

Click Configuration > Authentication > Auth Servers and click the + sign under the list of RADIUS Servers. In the text box type the name of the ClearPass server, the IP address/hostname and click Submit. If you are using the ClearPass server for TACACs, the hostname has to be different for each protocol. In a production environment, I would append _radius to the server name for the RADIUS server and _tacacs for the TACACS server.

Click on the name of the server you just created in the server list and enter the Shared Key. This Key is a shared secret that will also be to configure the controller as a Network Access Device (NAD) on ClearPass. Click Submit.

Get in the habit of creating a Server Group and applying that to your AAA profile. A Server Group allows you to add all of the authentication servers that are available to process a specific type of service. The Aruba Mobility Controllers currently allow TACACS, RADIUS, LDAP, and Windows servers (NTLM) to be added to a Server Group. If you are using a single ClearPass server for 802.1X authentication, adding it to a server group will allow you to easily add servers in the future with no impact to the wireless environment.

To create a Server Group click Configuration > Authentication > Auth Servers > Server Group and click the + sign. Type the name of your Server Group in to the text box and click Submit.

Click on the name of the Server Group you just created in the Server Group area and click the + sign under the Server Group Name section. Click on the Add existing server radio button, select the name of the server you just created and click submit.

Next, we need to create an RFC 3576 Server. RFC 3576 is an extension to the IETF RADIUS standard that allows authorization changes without having to terminate a user session. While some vendors have the option to toggle this on and off within the RADIUS server settings, Aruba Controllers require you to configure a separate RFC 3576 server.

To create an RFC 3576 Server click Authentication > Auth Servers and click the + sign under the All Servers section. Type in the IP Address and select RFC 3576 in the Type field and click Submit.

Click on the server you just created under the All Servers section. Type and retype the Key in the section that appears below. This is the same shared secret that you specified when you created the RADIUS server earlier. Click Apply. Repeat this step for each ClearPass server you have. Although not too common, there are use cases where you may require some servers to perform Change of Authorization (CoA) actions but not process RADIUS requests themselves.

Controller Roles

Roles are containers which can be pre-configured with various settings such as bandwidth contracts, QoS settings and security policies. Assigning a role to a user will automatically apply the configuration to contained within a role to the user session.

In this example, ClearPass will be responsible for determining the appropriate role based on one of two AD Groups the authenticating user is a member of. Using Aruba Vendor-Specific Attributes (VSAs) it will inform the Controller which role is to be assigned to the session. The Controller will apply the following configuration to each role.

Before you can specify VLAN IDs in your user roles, you need to ensure that the VLANs have been created and an IP address has been assigned. Below is a screenshot of my VLAN interfaces with the Staff VLAN expanded showing its IP Address details.

To create a user role click Configuration > Roles & Policies > Roles and click the + sign .

Type in the name of the new role and click Submit.

Click on the name of the role you just created and click Show Advanced View on the bottom right of the screen.

A firewall policy with the same name as the role you created will appear. There is an implicit deny all policy at the bottom of the list of policies but we haven’t permitted any traffic yet. Click on the name of the new policy, which in my case is named staff, and click on the + sign that appears in the policy rules section below. I am going to simply create a rule that permits users to all destinations based on IP address so I am selecting the Access control radio button. Click OK to continue.

A forwarding rule section will appear further down the screen. I am leaving the default options which allow all source IPv4 addresses to communicate with all destination IPv4 addresses. You may wish to create multiple forwarding rules permitting and denying traffic based on your requirements. Where possible I prefer my wired and wireless traffic control to be performed on the same device i.e. a dedicated firewall appliance downstream. Click on Submit* to continue.

*On the version of code I was running at the time of writing this post, the submit button was disabled until I modified one of the options and set it back to its previous state. Maybe a bug? Leave a comment if you know why this occurs!

Click on the More tab that appeared when you enabled the advanced options earlier. Select the VLAN ID (or a named VLAN if you prefer) and any other options you require and click Submit.

Repeat the process for additional roles.

AAA Profile

Next, we create a AAA Profile which defines the type of authentication to be used. We will be using 802.1X authentication.

To create a AAA Profile, click Configuration > Authentication > AAA Profiles > AAA and click the + sign in the New Profile Area.

Type in the name of the profile name. When doing 802.1x authentication the initial role does not usually apply. I am not doing MAC authentication so there is no need to change the value here either. In the 802.1X Authentication Default Role drop-down box, I have assigned a role named denyall, which places the user into one of my non-routable VLANs and has an implicit deny all firewall policy attached. The default role is applied to a user session when they have passed authentication. This is overridden by applying the roles we created earlier however, I’d rather deny access to users that pass authentication but aren’t applied a role for any reason, than grant them full access to the network. A user will quickly let you know if they can’t access the network, so you could troubleshoot and modify your policies to resolve the issue if necessary. Click Submit.

Click on 802.1X Authentication under the name of the AAA profile you just created on the left. Under the 802.1X Authentication Profile dropdown box and select default. I am not going to configure machine authentication in this lab so I will not worry too much about these settings. If for any reason you need to terminate the user sessions on the Controller before ClearPass you have the ability to configure that here as well.

Click on 802.1X Authentication Server Group and select the server group that you created earlier and click Apply.

Click on RFC 3576 Server, click the + sign and select the IP address of the RFC 3576 Server you created earlier. Click OK to continue.

Virtual AP Profile

A Virtual AP profile (VAP) groups all of the configuration we have created so far into a unique SSID that can be advertised by one or more APs. To create a VAP, click Configuration > System > Profiles > Wireless LAN > Virtual AP. Click the + sign.

Type in the Profile name. Select the default VLAN that users will be placed in to upon authentication. We are using ClearPass to assign user roles which have a VLAN mapping on the Controller, so this will not be applied in our scenario. In the event that we misconfigure something and allow unauthorised users on to the network, I have specified VLAN 666, a non-routable VLAN. The VLAN you specify here must be configured Configuration > Interfaces > VLANs. Specify the Forward Mode. In this example I am using Tunnel Mode, but if you want clients to be locally switched at the AP, select Bridge. Click Submit.

Click on AAA and select the name of the AAA profile you created earlier in the AAA Profile dropdown box and click Submit.

Click on SSID and select the name of the SSID profile you created earlier and click Submit.

AP Group

An AP group allows us to apply the same WLAN and RF configuration to multiple APs. A common use case is to create an AP group per floor or building and optimise the configuration within that area. To create a new AP group click Configuration > AP Groups and click the + sign. Type in the name of your AP group and click Submit.

Click on the name of the AP group you created and select the WLAN tab below. Click the + sign, select the name of the Virtual AP Profile that contains your SSID and click Submit.

Click on Configuration > Access Points and select one or more APs that you want to be associated with the AP group you just created. Click Provision. Select the name of the AP group you created earlier in the dropdown box and click Submit. Click Continue & Reboot when prompted and wait for the AP to rejoin the controller.

Navigate to Dashboard > Access Points and you should see your AP listed. The AP will be broadcasting your new SSID but you won’t be able to connect to it just yet.

ClearPass Configuration

Domain Join

In order to authenticate users against AD when using PEAP, we first must join ClearPass to an AD domain that the users reside in. This is a one-time procedure which must be performed from an account that has the ability to join a computer to the domain. The account being used for the domain join must have the following permissions:

  • Create computer objects
  • Delete computer objects
Click Administration > Server Manager > Server Configuration. Click on the server name in the list of servers.

To start the join process, click on Join AD Domain.

Enter the details of your Domain Controller and account credentials and click Save.

If successful you will see the message below.

Click Close and Save.

AD as an Authentication Source

To configure AD as an authentication source click Configuration > Authentication > Sources and click Add to create a new authentication source.

ClearPass Admin AD Auth Source

Fill out the the DC hostname, bind DN and password, base DN and any other settings you require and click Save.

ClearPass Admin AD Auth Source

AD Users and Groups

When a user authenticates, we want to differentiate whether they are a member of one of two groups, Staff and Student. Here are those groups in AD.

The Staff group has three members as I am using the same configuration I used in one of my previous posts – Authenticate Aruba ClearPass Admins against AD

Enforcement Profiles

The roles we created on the Mobility Controller are referenced and applied to user sessions in ClearPass using enforcement profiles. An enforcement profile is the part of ClearPass that is responsible for applying one or more actions based on the conditions that are matched in the enforcement policy. There is a one-to-one mapping of enforcement profiles to controller roles. We will create two user enforcement profiles:

  • Lab – Corporate Wi-Fi staff Enforcement Profile
  • Lab – Corporate Wi-Fi student Enforcement Profile

Each profile will enforce the controller role using the ‘Aruba-User-Role‘ attribute. To create an Enforcement Profile click Configuration > Enforcement > Profiles and click Add.

My ‘staff‘ enforcement profile.

And my ‘student‘ enforcement profile.

ClearPass Roles and Role Mapping Policy

A Role Mapping Policy ties together distinguishable authentication attributes to a named role that ClearPass can reference and re-use in enforcement policy decisions. I am going to create two user roles in my mapping policy. Each role will be assigned based on the authenticating AD group.

To create a role click on Configuration > Identity > Roles and click Add.

Type in the name of the role and optionally a description. Repeat this step for any additional roles you wish to create.

Enforcement Policy

Next, we create an enforcement policy which simply assigns enforcement profiles based on the assigned ClearPass role. TIPS = Trust and Identity Policy System. So ‘Tips:Role is just a fancy way of saying ‘ClearPass role’.

Click on Configuration > Enforcement > Policies and click Add to create your an enforcement policy.

Here is a summary of my enforcement policy. We are simply saying, if the ClearPass role is either staff or student (determined by our role mapping policy) then apply the corresponding enforcement profile (which informs the Controller to apply one of its own roles to the user session).

Service

It’s time to create a service, which is a means of grouping all of the policy components that serve a specific type of request into a single configuration set. While our service will reference the policies and profiles we created, it also has its own conditions the RADIUS sessions must match before the underlying configuration is processed.

Click Configuration > Service and click Add to create a new service. As there are many options to configure, I am only showing the summary tab for the service.

Things to note –

  • In a production environment, you may also require EAP-TLS for certificate authentication. This can be added to/or replace EAP-PEAP.
  • In Authentication Sources under the Authentication tab, ensure that AD is the only source in the list.
  • Depending on your AD setup, you may also need to tick the Strip Username Rules: checkbox in the Authentication tab
  • I have locked down incoming authentication requests to only be accepted from a single NAD IP Address (my Mobility Controller) of 10.0.10.21. If you have multiple Controllers, you could also create a “Device Group” containing all of your devices and reference the group instead of an IP Address.

Verification Testing

Time to test! I used an Android phone to test authentication using the following accounts:

  • Bob Frapples (Staff Member)
  • Jan Fultz (Student)

Here are the Access Tracker logs (Monitoring > Live Monitoring > Access Tracker) in ClearPass for Bob Frappes. The ClearPass role of staff was applied successfully and the correct Enforcement Profile was applied – so far so good.

If we head across to the Controller and navigate to Dashboard > Clients, we can see that Bob has been assigned the correct Controller role of staff, and has received IP address within the staff VLAN. Success! You will just have to trust that I could successfully browse the Internet on the test device.

Let’s try the same for Jan Fultz. The ClearPass Access Tracker shows that students role and enforcement profile were applied successfully.

The Controller dashboard shows that the Controller role of students has also been applied to Jan and she has received an IP address within the correct VLAN.

Congratulations, you have just created and 802.1X WLAN using an Aruba Mobility Controller and Aruba ClearPass!

Share: