Requirement: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.
Solution: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.
Configuration:Objective
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:
- Moving from media to media: eg login at docked laptop over wired then undock and login over wireless – this only performs a user authentication
- Recovering from Hibernate or Sleep
We could think of three solutions to this problem:
- Manually define all the Corporate devices
- For user authenticated only devices to a captive portal that instructs them to re-login
- 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:
- Individual Endpoint editing
- Bulk Endpoint editing
- 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
status:
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
VerificationService 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.