NAC with Intune and Aruba ClearPass: a certificate, a query, and a maturity exam
- The problem
- Only healthy corporate devices should get on the network, but the switch port has no idea what Intune knows.
- What I built
- A PKCS machine certificate carrying the Intune Device ID, an 802.1X Wi-Fi profile, and the Graph queries ClearPass uses to decide.
- What came of it
- ClearPass authorises by Intune compliance at the port, and a clear picture of what an organisation needs before trying.
Network access control is on almost every organisation’s wish list, and for good reason: the switch port and the SSID are the one control point every device has to pass. The pitch is simple: only corporate, managed, compliant devices get on the corporate network.
The implementation is not a product you switch on. In this integration my half was Intune; the network team ran Aruba ClearPass following the vendor’s guidance. What made it work was agreeing on a very small interface between the two worlds: one certificate attribute and one Graph query.
The Intune half
Three pieces, deployed as configuration profiles:
A machine certificate via PKCS, with the Intune Device ID placed in the certificate subject. This is the whole trick: the certificate the device presents at the port carries the exact key ClearPass needs to look the device up in Intune. No agent, no captive portal: the identity travels inside the EAP-TLS handshake.
The trust chain: the root and intermediate CA certificates as trusted-certificate profiles, so the client can authenticate and validate the server side of the conversation.
The Wi-Fi profile: WPA2-Enterprise with 802.1X, EAP-TLS, machine authentication, so the device authenticates as itself, before any user signs in.
The ClearPass half, and the interface
ClearPass needs to answer two questions at connection time: is this one of ours? and is it healthy right now?
For the first, it keeps a periodically synchronised list of Intune devices, pulled through Microsoft Graph. My contribution to the network team was the query that returns the device inventory with the Intune Device ID. When a device connects, ClearPass extracts the ID from the certificate subject and matches it against that list.
For the second, it queries Graph for that specific device and reads its compliance state, fresh, at authorisation time. Enrolled but non-compliant can then mean a remediation VLAN rather than a flat yes or no.
When something doesn’t connect, the two consoles meet in the middle: Intune’s certificate monitor shows whether the PKCS certificate actually reached the device, and netsh wlan on the client shows whether the Wi-Fi profile landed and what it contains.
The part nobody writes in the design doc
Here is the honest half of this story: at another organisation I worked in, NAC was on the table, it was a solid control, and the right decision was not to do it yet, because NAC does not create maturity, it exposes the maturity you have. Before the first policy is written, an organisation needs real answers to:
- Where do you enable it: corporate wireless, ethernet, or both? Each answer drags in different switches, different teams, different exceptions.
- For which devices? And the question behind it: are all devices actually enrolled? Every unmanaged-but-legitimate device becomes a support case at the exact moment someone tries to work.
- What are the exceptions, named and listed: printers, AV equipment, lab instruments, visitors, the things with an ethernet port and no MDM. An exception list you discover at the port is an outage; one you wrote beforehand is a policy.
- Is the segmentation ready for a remediation VLAN to mean something?
- Can you trust your inventory? NAC turns every stale or duplicate device object into someone locked out of the network. This is where device inventory hygiene stops being housekeeping and becomes a prerequisite.