Best practices and points to remember while deploying user and machine auth using Clearpass


Best thing about using PEAP/MSCHAP SSIDs is that the user need only enter their credentials. However, this makes it a prime candidate for abuse. When using Active Directory as the authentication source it is very easy for an attacker to force accounts into a locked state: guess the username and enter three bad passwords (by default), the account will be locked for 30 minutes (by default).

Here are some ideas on how to mitigate this issue. Article also discusses related issues.


By configuring and applying the best practices mentioned below, it becomes evident that implementation of user and machine auth against ClearPass server through AD is a viable solution to mitigate such threats.





Best thing about using PEAP/MSCHAP SSIDs is that the user need only enter their credentials. However, this makes it a prime candidate for abuse. When using Active Directory as the authentication source it is very easy for an attacker to force accounts into a locked state: guess the username and enter three bad passwords (by default), the account will be locked for 30 minutes (by default).

Here are some ideas on how to mitigate this issue. Article also discusses related issues.

Windows Domain PC

PCs that are members of a domain should be configured to perform “User and Machine Authentication” within the SSID’s definition:


Once configured, when the PC connects to the SSID it will perform and 802.1X machine authentication at power-on (RADIUS User-Name=host\<hostname>), a 802.1X user authentication at user login (RADIUS User-Name=<domain>/<username>) and a 802.1X machine authentication at user logoff.

(NOTE ClearPass must be joined to the domain to successfully validate the hashed passwords – these are not presented within the LDAP database).

Only PCs that are members of the AD Domain can successfully perform the machine authentication – this is guaranteed with Kerberos secrets. We can be fairly certain that devices that successfully perform the machine authentication are legitimate corporate devices.


There are a few circumstances where the machine authentication does not generally occur:

  1. Moving from media to media: eg login at docked laptop over wired then undock and login over wireless – this only performs a user authentication
  2. Recovering from Hibernate or Sleep

We could think of three solutions to this problem:

  1. Manually define all the Corporate devices
  2. For user authenticated only devices to a captive portal that instructs them to re-login
  3. For user authenticated only devices dynamically verify the PC’s state within AD and connect accordingly

The remainder of this document discusses these options.

Manually defined Corporate Device

The easiest method to mitigate against this problem is to only allow known devices to connect to this SSID. Although you could use the Endpoint’s Known attribute this is also generally set with a guest’s registration.

 Because of this it is best to create another attribute within Endpoint – in my example I create an attribute called Owner:

This attribute can then be manually set within the Endpoint:

Within the Service the Endpoint:Owner can be directly checked at the service’s “match” time:

Devices that do not have this attribute set will not match this service.

The challenge here is creating an effective method to set the Endpoint:Owner. The obvious approaches are:

  1. Individual Endpoint editing
  2. Bulk Endpoint editing
  3. Automatic registration

Each is described below


Individual Endpoint editing
This is self-explanatory.

Bulk Endpoint editing
Export the desired Endpoints:



The password is not import as Endpoints don’t have hidden fields.


I prefer to save the file this XML file as this default to IE browse on my Win7 PC and I need to edit it.


Open the file with your preferred editor…


If this file is large it is easier to convert this to a CSV, manipulate accordingly and then convert back to a XML import file – discuss with TAC for details…

Once the file is complete: re-imported. This will report the number of endpoints that have been changed.



Automatic registration

Ultimately it is desirable to make the “registration” of these devices as seamless as possibly. If the devices are already known within other databases then this information can be used to set the Endpoint:Owner at their first connect. There are two obvious examples:

< >Domain PCs performing Machine AuthenticationOther managed device databases, eg MDM 


To achieve this I add another service to ClearPass:

This service is inserted below the locked down 802.1X service (IAP 802.1X Wireless –Lockdown). I craft it to only allow machine authentication – ie the RADIUS User-Name begins with “host”:


This service will only handle successful machine authentication against AD.

NOTE: This check could be made more specific based of the PC’s hostname… (often they have a particular structure).  I use the normal authentication against AD:




The Enforcement Policy effectively only allows Machine Authentication:


The  “Set Corp Device” sets the Endpoint:Owner attribute:

Finally, once the device acquires a fingerprint, typically via DHCP Request, that profiles it as a computer or printer (typical of a device that can do machine authentication) ClearPass will force a re-authentication: 

Other devices will be stuck in this Profile role.


What is important for Windows environments is that DHCP Profiling will record the [Endpoint Repository]:hostname attribute as this name can be used to interrogate AD to establish the devices current state.


Other Managed Device Databases

In a similar manner other databases can be used for the initial validation of a device.

Ongoing Device Validation with AD

When a user connects with a Known device the concern is that the device’s state is assumed to be good based on this “Known” state. Rather than assuming this state ClearPass can be configured to interrogate the device’s authorization source to get the current status. Within an AD environment if the machine authentication is good this will be cached (for 24 hours by default). Hence you can construct logic based around:

Device=Known & Machine Auth & User Auth à Assign Production role

However, I can envisage three scenarios where problems occur with the machine authentication’s state:

< >Device recovers from hibernate/sleep – only performs user authentication (that lasted longer than the machine authentication cache timeout)Device moves from one media to another, eg login on wired at docking station and then undock and switch over to wireless – only performs user authenticationDevice’s state is changed, eg disabled – this effectively invalidates any machine authentication cache and Endpoint:Owner = Corp) 

Within the Learning service when we see the Machine Authentication we learn the hostname.Hence, the learning service looks like this:



Where the Profiles do the following:

                Profile role                                          Placed into isolation role, ClearPass captures the DHCP Request
                Set Corp Device                                                Endpoint:Owner = Corp
                [Update Endpoint Known]          
                Set Endpoint Hostname                                Endpoint:Hostname = Host:Name
                60s Session-Timeout                      Hopefully CoA will occur before this…

Back to the Locked down service. Assuming Learning service works correctly there should never be a circumstance where ClearPass has not recorded the Hostname, but just in case:

                Authorization:[Endpoint Repository]:Hostname NOT EXIST à Profile role, 60s Session-Timeout

If Host:Name not set                                                      ==> Profile (this should never get here as the device  should be unknown), with 60s timeout

If Endpoint:Hostname not set    ==> Endpoint:Hostname=[Endpoint Repository]:Hostame, CoA

If LDAP Endpoint:Hostname NOT EXISTS OR        ==> Place in Quarantine role, this redirects to Blocked
                LDAP Endpoint:Hostname status DISABLED OR                   captive portal
                LDAP Endpoint:Hostname status LOCKED (don’t believe it can be locked?)                

Else ==> Assign Production role


LDAP Query

Use the Endpoint:Hostname to extract the AD device’s


NOTE: Using the following will only report enabled devices (&(sAMAccountName=%{Endpoint:Hostname}$)(objectClass=computer)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

Initial User Auth Learning

This state can occur if an new (unknown) device successfully Machine Auth and User Auth on the wired and then switches over to the wireless - only see a UserAuth.

AD Domain



This is potentially vulnerable to attack. Best to only have this enabled during the learning process.

Enhanced Lockdown Service

Using the original 802.1X service we enhance this to valid the device. If for some reason the device’s hostname has not been captured the conditions will address this (hopefully this won’t be required):

Condition1          Hostname not define – place in role to get DHCP, if user attempts to browse present relogin page. DHCP Profiler will cause re-connect.   

NOTE: Best to add 15s Session-Timeout
NOTE: This assume the DHCP Hostname matches the AD Hostname

Condition2          Endpoint:Hostname not define – copy [Endpoint Repository]:Hostname into Endpoint:Hostname, reconnect after 15s.
NOTE: I don’t use CoA as I want the Endpoint information to synchronize around the cluster

Condition3          Device is not in a fit state within AD: Place in Quarantine role

Condition4          Machine Authentication ONLY: Assign Machine role

Default Role       Assign User role


Service Ordering





Service logs, Monitoring access tracker information, configuration on the service in clearpass will provide all the info of how the user and machine authenticate using clearpass through AD.

Version history
Revision #:
2 of 2
Last update:
‎03-07-2016 02:23 PM
Updated by:
Labels (1)
Search Airheads
Showing results for 
Search instead for 
Did you mean: