ClearPass & Sophos Mobile Control

A lot of companies are using MDM to control and manage their (mobile) assets. By connecting the MDM solutions to HPE Aruba ClearPass an organization has the possibility for advanced context-aware access for a (mobile) device to the corporate network, wired and wireless. ClearPass supports multiple MDM solutions via built-in “External Context Servers”, like Airwatch and MobileIron.

The MDM solution from Sophos, Sophos Mobile Control, has no built-in integration with ClearPass. I needed to help a customer to link ClearPass with Sophos Mobile Control, because the customer would like to distinguish BYOD from corporate devices. All corporate devices are managed via Sophos Mobile Control. In this setup, Sophos Mobile Control uses an MSSQL database to store all relevant information. One of the tables in the MSSQL database stores the Wi-Fi MAC address from the asset. I use this table to distinguish the BOYD devices from the corporate devices. If the MAC address of the device is present in the database, the device is a corporate device.

I started by adding the MSSQL database as an authentication source to the ClearPass configuration. The customer created a dedicated SQL user with read-only access to the database. The MSSQL database is added in ClearPass under Configuration – Authentication – Sources. I added a source from the type “Generic SQL DB”.

The next step involves the creation of a proper SQL filter statement. I would like to have the Wi-Fi MAC address as output from the SQL filter. The following SQL filter is used for this (with special thanks to the customer, who had some more experience with SQL statements!!!!)

SELECT LOWER(deviceproperty.value) AS mac_address FROM deviceproperty INNER JOIN device ON deviceproperty.deviceid = device.deviceid WHERE deviceproperty.propertykey = ‘Wi-Fi MAC address’ AND device.managed = ‘managed’ AND deviceproperty.value = ‘%{Connection:Client-Mac-Address-NoDelim}’;

I would like to use the MAC address as a string in the authentication/authorization process. In the end I will check if the MAC address in the RADIUS requests matches a MAC address in the Sophos MDM database. The SQL filter is added in the Filter option within the Authentication Source, like in the image below. Just go to the Attributes tab and choose the option Add More Filters.

The Authentication Source is added to the appropriate Service as Authorization Source. I always add the Source first, before I start to configure some Roles and Role Mappings, because I would like to see which output I receive from the MSSQL database. There are two possible outcomes:

  1. The MAC address exists in the MSSQL database
  2. The MAC address doesn’t exist in the MSSQL database

If the MAC address exists in the MSSQL database, you will see the value of the MAC address in the Access Tracker.

As you can see the MAC address is listed without any delimiter. If the MAC address doesn’t exist in the database, the MAC address won’t be listed in the Access Tracker and you will see the following Alert Message.

Now that we know, which information we receive in the Access Tracker during an authentication request, we can configure the correct Roles and Role Mappings. In this example I assign the Role [VDI Trusted] to the device, when the MAC address from the device equals the MAC address in the MSSQL database.

The last step is easy. Just configure the appropriate Enforcement Policy and Profile you match the Role and set the correct attributes on the Wi-Fi or wired network.

ClearPass – dual interface and routing

When you are using both interfaces on a ClearPass server (MGMT and DATA) than ClearPass uses the DATA interface to connect to services, like LDAPS to Active Directory, SMTP delivery, Active Directory joining and more. ClearPass uses the DATA interface as default gateway if no specific route is available on the MGMT interface.

That being said, you have the option to add routes to the ClearPass routing table. Routes are added via the ClearPass shell. Use the following command to add a route.

Usage:

network ip add <mgmt|data|greN|vlanN> [-i <id>] <[-s <SrcAddr>] [-d <DestAddr>]> [-g <ViaAddr>]

Where:

  • greN — Name of the gre tunnel where N corresponds to the gre
    tunnel number ranging from 1,2,3…N
  • vlanN — Vlan interface where N corresponds to the vlan id ranging from 1,2,3…N. For example if the configured vlan identifier is ’85’ then input ‘vlan85’
  • -i — Optional parameter. Id of the network ip rule. If unspecified the system will auto generate the Id
  • -s <SrcAddr> — Optional parameter. The source interface ip address or netmask from where the network ip rule is specified. The allowed values are valid IP Address or Netmask or ‘0/0’
  • -d <DestAddr> — Optional parameter. The destination interface ip address or netmask where the network ip rule is specified. The allowed values are valid IP Address or Netmask or ‘0/0’
  • -g <ViaAddr> — Optional parameter. The via or gateway ip address through which the network traffic should flow. The allowed value is valid IP Address

An example:

[appadmin@CPPM01]# network ip add mgmt -d 10.10.10.0/24 -g 20.20.20.1
INFO – Added route for destination=10.10.10.0/24 via=20.20.20.1
INFO – New ip rule created with the id = 12000

You can check the routing table via the command: network ip list.

Aruba ClearPass – Cisco Prime – TACACS+

When using Cisco Prime you have the option to configure authentication to a remote AAA server via RADIUS or TACACS+. Today I configured Cisco Prime to use HPE Aruba ClearPass as remote AAA server based on the TACACS+ protocol. The configuration of an AAA server in Cisco Prime is very straightforward. Configure the AAA Mode Setting under Administration / Users / Users, Role & AAA / AAA Mode Settings. The next step involves adding HPE Aruba ClearPass as TACACS+ servers via the option menu Administration / Users / Users, Role & AAA / TACACS+ Servers.

I configured a TACACS+ service in ClearPass with a very basic Enforcement Profile. In the beginning I used the same Enforcement Profile, which I also use to enforce privilege level 15 to switches and routers. Authentication will fail at this point. In the Access Tracker I get the following error message:

Tacacs service=NCS:HTTP not enabled

And the login screen from Cisco Prime shows me the following error message.

I created a new Enforcement Profile and added the TACACS+ service NCS:HTTP to the Enforcement Profile. Now I see an access granted in the Access Tracker, but I still get the same error message on the Cisco Prime website. After some digging in Cisco Prime I noticed that Cisco Prime needs to receive TACACS+ attributes from the AAA server to grant access and assign privileges and tasks to the user.

First you need to get the TACACS+ attributes from the Virtual Domain configuration. In the menu options navigate to Administration \ Users \ Virtual Domains. At the upper right corner you have the option to “Export Custom Attributes”.

These attributes need to be configured in ClearPass. As you notice you also need to configure these attributes if you would like to use RADIUS as authentication protocol. You also need to add the attributes from the user group. Navigate to Administration / Users / Users, Role & AAA / User Groups. Click the “Task List” option next to the User Group you would like to use. I use Root in this example.

The User Group Root contains 194 tasks, which need to be added to the Enforcement Profile in ClearPass. Below you see a snippet from the Enforcement Profile configuration.

To make it easy for you, I exported the Enforcement Profile including all the 194 tasks for the Root User Group. You can download the Enforcement Profile in XML format below. Just import the profile into ClearPass and you are good to go!!!

Download here: Cisco Prime Enforcement Policy

ClearPass & MobileIron – Error: not well-formed (invalid token)

This post isn’t going to describe what HPE Aruba ClearPass or MobileIron is. And neither will it describe the configuration steps necessary to add MobileIron to ClearPass, but I will give a short summary:

  1. Add the MobileIron VSP to ClearPass as Endpoint Context Server (CPPM – Administration – External Servers);
  2. The account on MobileIron needs API rights to enable ClearPass to retrieve information from MobileIron;

This post tells a bit more about an error message I suddenly started to receive in the CPPM Eventy Viewer.

CPPM - MDM - invalid token

Error: not well-formed (invalid token)

I checked the internet, but I couldn’t find any useful information. I opened a TAC case to look into this error. The TAC engineer told me he had seen this error before, where MobileIron sends invalid token characters to ClearPass. He told me that CPPM does batch processing of the devices and the entire batch fails when CPPM doesn’t understand special characters. He also told me how to see which device is causing the problem.

You have to collect the CPPM logs (CPPM – Administration – Server Manager – Server Configuration – Collect Logs). After you untar the tar.gz file, you should look at the directory “strange string”\PolicyManagerLogs\mdm\MI\mdm-server and you should open the file 0.xml.bak.

Scroll down to the line mentioned in the error message and you will see something like below. I always use Notepad++ to open the file.

CPPM MDM - XML Error

CPPM doesn’t understand these special characters in the key. When you start scrolling up, you can determine which device in MobileIron triggers the error message in CPPM.

After I found the device in MobileIron I checked every setting on the device to find the special character, but I couldn’t find one. In the end there was only one solution for me: retire the device. This basically means remove the device from MobileIron and the user needs to reprovision the device in MobileIron. The sync between CPPM en MobileIron was successful again after I retired the device.

Tip of the week: I guess you aren’t always looking at the Event Viewer for errors, so maybe it is useful to configure ClearPass Insight to send a notification if a System Error Event occurs!!!

ClearPass – concurrent session limit

I tried to configure a restriction to the concurrent number of active sessions a user can have on the wireless network. I found a great article on AirHeads Community “How to deny access for authentication requests based on session limit?

In short the article tells you to:

  1. Edit the Insight Repository
  2. Add more Filiters on the Attributes tab
  3. Enter the following information
    1. Filter Name: sessions
    2. Filter Query: see below
    3. Name: sessions
    4. Alias Name: sessions
    5. Data Type: Integer
    6. Enabled As: Role
  4. Add the Insight Repository as Authorization Source
  5. Create an Enforcement Policy Condition to check the Insight Repository
    1. Type: Authorization:[Insight Repository]
    2. Name: sessions
    3. Operator: GREATER_THAN_OR_EQUALS
    4. Value: <number of allowed simultaneous connections + 1

I configured my ClearPass environment like shown in the article, but I didn’t see any active sessions in the access tracker. The counter remained 0. I connected to the Insight database with the tool pgAdmin to see if the Insight database is updated. The database is updated, so every thing seems to be working.

Be accident I found the solution. The SSID is using EAP-PEAP authentication and users enter there username as <username>@<domain-name>, like rene@booches.nl. This is necessary, because the SSID is configured to work with Govroam. Govroam provides government employees with seamless access to WiFi networks, wherever the service has been made available by participating organisations. To authenticated the users correctly, I configured the CPPM Service with Strip Username Rules.

Strip Username Rules

The SQL query checks the attribute %{Authentication:Username}

select count(*) as sessions from radius_acct where (username = ‘%{Authentication:Username}’) AND end_time is null AND termination_cause is null AND (updated_at BETWEEN (now() – interval ‘1 hour’) AND now());

In the InsightDB the username has the format <username>@<domain-name>, but the attribute %{Authentication:Username} has the format <username>. I saw this “mismatch” while checking the Access Tracker.

ClearPass Access Tracker

I altered the query by changing %{Authentication:Username} into %{Authentication:Full-Username}. After this the session information was correct and I could use the session counter in a Role Mapping or Enforcement Profile to limit the concurrent number of active sessions from a user.