If in your environment, a Network Access Control (NAC) solution is in place that integrates with Microsoft Intune utlizing the Intune NAC service API to query and retrieve a device’s enrollment and compliance state for the purpose of managing access control to the on-premises resources like Wi-Fi or VPN, then this short blog post is for you.
Table of Contents
The impending change – Intune NAC service deprecation
Microsoft has announced the deprecation of the original Intune NAC service that the partner NAC solutions made use of to get the device enrolment and compliance state for access control decisions by the end of the year 2022. (December 31, 2022.)
As a replacement to the original Intune NAC service, Microsoft has already introduced the Compliance Retrieval service back in June 2021, which as per Microsoft, offers improved security and reliability.
How does this change impact you?
If your environment has setup CISCO ISE or similar NAC products like Aruba ClearPass, F5 big-IP, Citrix gateway, etc. for access decisions based on endpoint (Devices) compliance status, the integration of the NAC solution with Intune on the basis of Intune NAC API, post the deprecation, your NAC solution will fail to get the required endpoint status from Intune, thus causing your users to not being able to connect to Corp Wifi or VPN from Intune managed endpoints. (You can guess the problem it will raise at that time!)
If you want to know how NAC integration with Intune works, read about the flow from here. The impending change is going to break step 5 of the flow (highlighted in the below snap) causing further failures.
Why this change?
Over the years, NAC solutions have primarily used either the MAC address or UDID like SerialNumber (in the case of VPN flows where MAC address is not available) for the purpose of endpoint identification.
And the “to-be-deprecated” Intune NAC service supported such MAC address or UDID-based queries originating from the NAC solutions for the purpose of retrieval of the enrolment and compliance state data of an endpoint from Intune.
However, in the recent past, we have seen the topic of user privacy emerge as a hot topic.
For every device that wants to connect to a Wi-Fi access point, the device shares its unique MAC address with the AP to facilitate the low-level inter-device communication required to establish a connection. The MAC address is something that is bound to the hardware and set by the phone manufacturer and being persistent, unique, and universal across all devices, can be used to uniquely identify a device for any reason!
This is a problem since identifying a device is nearly the same as identifying a person. And, when a person is identified, then everything they do on their device can potentially be tracked.
For this reason, unique device identifiers are considered sensitive and as a result of which, we saw operating systems like Android and iOS/iPadOS begin to limit the ability of applications to access the device’s original MAC address(es), making use of MAC randomization which ensures that the original purpose of the MAC address, to allow a device to connect to a network, works properly, while also mitigating privacy issues.
But this created more of a challenge for the MDM vendors to collect and rely on MAC addresses on these platforms. Because MAC randomization results in MAC addresses that are dynamically generated by the OS platform to be used for establishing a connection with a Wi-Fi AP, they often fluctuate and are not static, making them unreliable for the purpose of unique identification of a device.
This is the reason why Microsoft decided to stop the use of MAC addresses across all operating systems, thereby forming the basis of Intune NAC service deprecation!
The new Compliance Retrieval service makes use of the Intune Device ID (a GUID) as the checking attribute and does not supports MAC or UDID-based queries.
What does this mean?
NAC solutions that are utilizing the Intune NAC service for integration, API queries to Intune will start to fail post deprecation of the API, resulting Intune managed devices failing to connect to Wi-Fi or VPN protected by the NAC solution.
It means, you now need to
- move/upgrade to a NAC solution that utilizes the new Compliance Retrieval Service for retrieving endpoint registration/compliance data from Intune, and also
- deploy necessary certificates to your endpoints which includes IntuneDeviceID in SAN of the certificates (for the NAC solution to be able to use it for querying data from Intune)
What do you need to do next?
Many NAC providers have already launched their upgraded version which makes use of the Compliance Retrieval API to support the change, like the ones mentioned below
- Cisco ISE 3.1
- Citrix Gateway 13.0-84.11 and higher
- Citrix Gateway 13.1-12.50 and higher
- F5 BIG-IP Access Policy Manager 17.0
If your environment uses NAC, then it is recommended that you migrate to these new offerings as soon as possible and work with your NAC partner to determine what changes you need to make and when, to maintain NAC availability in your environment.
Resources…
- Microsoft’s note about the API change can be found here.
- Cisco’s note for this change is here.
- Release notes for F5’s update to BIG-IP Version 17.0.0 supporting the change can be found here.
- Release notes from Citrix for Citrix ADC release Build 13.0-84.11. and 13.1–12.51. for the change.
And last but not the least, the blog which made me aware of this change is here.