Connecting the world…


Downloadable User-Roles and NTP sync

The HPE Aruba switches have this cool feature called downloadable user-roles (DUR). DUR enables the switch to use a central ClearPass server to download user-roles to the switch for authenticated users.

More and more customers want to implement wired authentication to strengthen the security level of their network. Via DUR the switches perform an HTTPS API request against ClearPass to download the user-role configuration. This makes the configuration of multiple switches easier, because you don’t need to configure the user-roles locally on the switches anymore, but you push them from a central server. The communication between switch and ClearPass is illustrated in the picture below.

Source: ClearPass Solution Guide: Wired Policy Enforcement

I won’t describe the whole DUR configuration step-by-step, but below you can find the most important configuration for the switch.

radius-server host “” key “radius-secret”
radius-server host “” dyn-authorization
radius-server host “” time-window plus-or-minus-time-window
radius-server host “” time-window 30
radius-server host “” clearpass
radius-server cppm identity “admdur” key “admdur-key”
ip client-tracker trusted
aaa server-group radius “GRP-CPPM” host “”
aaa authentication port-access eap-radius server-group “GRP-CPPM”
aaa authentication mac-based chap-radius server-group “GRP-CPPM”
aaa accounting network start-stop radius server-group “GRP-CPPM”
aaa authentication captive-portal enable
aaa authorization user-role enable download
aaa port-access authenticator 1/1
aaa port-access authenticator 1/1 tx-period 10
aaa port-access authenticator 1/1 supplicant-timeout 10
aaa port-access authenticator 1/1 client-limit 10
aaa port-access mac-based 1/1
aaa port-access mac-based 1/1 addr-limit 10
aaa port-access 1/1 controlled-direction in

For the HTTP GET to work the switch needs to trust the certificate chain from ClearPass. In ArubaOS 16.08 and later the certificate is automatically downloaded when specifying the option “clearpass” when configuring the RADIUS client. Another very important step for DUR to work is NTP time sync. The time on the switches needs to be in sync and here a “problem” arises.

After a switch power outage, the switch has to sync its time with an NTP server. And the time needs to be in sync before the first wired clients start authenticating. Even when I use the “iburst option with the NTP server for aggressive polling, I see that the time isn’t always synced in time.

Below you see the output from “show log -r” when the client authenticates, but the switch hasn’t synced its time yet.

I 02/12/19 10:55:46 04908 ntp: ST1-CMDR: The system clock time was changed by 918813141 sec 661757827 nsec. The new time is Tue Feb 12 10:55:46 2019
I 01/01/90 01:03:11 04911 ntp: ST1-CMDR: The NTP Server is unreachable.
I 01/01/90 01:02:55 00584 WebMacAuth: ST1-CMDR: Port 1/1, re-auth timeout 10 too short.
I 01/01/90 01:02:55 05747 DFP: ST1-CMDR: device_fingerPrinting: Hardware Rules updated successfully for port:1/1, protocol:80, client:08:00:0F:9D:45:BF
W 01/01/90 01:02:55 05204 dca: ST1-CMDR: Failed to apply user role VOIP___DUR-3005-1_7Z4q to macAuth client 08000F9D45BF on port 1/1: user role is invalid.
W 01/01/90 01:02:55 05620 dca: ST1-CMDR: macAuth client 08000F9D45BF on port 1/1 assigned to initial role as downloading failed for user role VOIP___DUR-3005-1.
I 01/01/90 01:02:51 00076 ports: ST1-CMDR: port 1/1 is now on-line
I 01/01/90 01:02:51 00435 ports: ST1-CMDR: port 1/1 is Blocked by STP

The port is placed in the initial-role which is by default the role denyall. “Problem” with the default role is the missing option “reauthentication period”, so the connected clients will not automatically reauthenticate after an X-period of time.

User Role Information
Name : denyall
Type : predefined
Reauthentication Period (seconds) : 0
Cached Reauth Period (seconds) : 0
Logoff Period (seconds) : 300

To “fix” this issue I added a new local user-role to the switch and configured this user-role as initial-role. I added the reauthentication period to the user-role, so the clients reauthenticate when time isn’t synced yet and they receive this initial-role from the switch. The configuration of the role is displayed below.

class ipv4 “IP_ANY_ANY”
10 match ip
policy user “DENYALL”
10 class ipv4 “IP_ANY_ANY” action deny
aaa authorization user-role name “reauth-role”
policy “DENYALL”
reauth-period 30
vlan-id 1

To use this role as initial-role you need to execute the following command.

aaa authorization user-role initial-role reauth-role

Next I tested the role by rebooting the switch. After rebooting I noticed that the switch port is placed in the “reauth-role“, because I receive the error message “assigned to initial role as downloading failed for user role” in the logs. In ClearPass I see another authentication request from the client after X seconds. At that moment the time on the switch is in sync and the switch port is configured with the correct user-role.

Edited: February 13th 2019
I created a topic on the AirHeads community on this matter and HPE Aruba responded with:

A software fix for the clock reset on cold boot/power loss issue on the 2930F and 2540 is in the works, and is expected to be released by the end of February.

ClearPass – REST API


I created some Python scripts for ClearPass. The scripts can be found on Github. There are several directories:

  • config: contains the parameters to authenticate against ClearPass and acquire an access token;
  • general_scripts: some general configuration scripts, like a Password Generator script or Date/Time script;
  • guests: scripts for adding or deleting guest accounts. I created a script to add guest accounts via a CSV file and print the most important information to a Guest Pass in Word format;
  • localusers: scripts for adding or deleting local user accounts;

First of all, I would like to thank Tim Cappalli for the ClearPass Authentication scripts!!

GuestPass Example



A special thanks to Tim Cappalli for the ClearPass Authentication scripts!!

ClearPass and InTune Integration Guide

Lately, I have been “playing” with the integration between ClearPass and Microsoft InTune. I found this very good integration guide at the AirHeads Community. I downloaded the Integration Guide and started clicking. In the end, I wasn’t able to sync any attributes from InTune into the EndPoint database. I consulted Aruba TAC and they couldn’t find the problem either. The ClearPass side was configured correctly. The next step should be consulting Microsoft…….

Yesterday I had to change some settings on my own Azure Portal. I needed to configure another App Registration including some custom permissions. Since I never ever have done anything with Azure, I just follow all guides step-by-step. This guide added another (logical) step after changing the required permissions for the Registered App. I had to click “Grant Permissions” after changing the permissions.

So I did the same step for the ClearPass-InTune app registration and the ClearPass API started to fetch the InTune attributes. So if you follow the ClearPass InTune Integration Guide v3.0 you have to add this step after you reached page 19.





Download a copy of the integration guide: ClearPass TechNote Extensions – Microsoft Intune Integration v3.0

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.


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


  • 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 -g
INFO – Added route for destination= via=
INFO – New ip rule created with the id = 12000

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