Microsoft made a decision to force what they consider to be insecure certificate bindings out of use, placing my great little workaround for modernising NPS onto life support. When their planned changes kick in, my own fleet of Azure AD-joined devices will be kicked out.
Third-party products exist which solve this problem by operating independently of AD, however in a cash-strapped education context they aren’t financially viable against the negligible cost of running NPS. My aim remains finding a way to support it or to replace it with a service that avoids burdensome recurring costs.
Interestingly, the initial deadline for ‘full enforcement mode’ was set for next month but Microsoft quietly published an update to the KB article in early December last year (flagged to me by @beamflash) which changes the requirement to 14th Nov 2023 “or later”. Why give a specific date if it might be later? Who knows!
Potential Solutions
Manual Mapping
This looks like the most promising option and is likely the only way to keep NPS in play.
In the original process a mapping was achieved via matching the name of an issued certificate with the name of a computer account object in AD. This was advantageous as all issued certificates would match for the lifetime of a device since they would always be issued to its name.
This mapping fails under the new requirements, which need associations to be unique, i.e. some detail from a specific issued certificate needs to be stored in the computer account object in AD such that only it will match. Where this cannot be done automatically, Microsoft says:
we recommend that you create a manual mapping by… adding the appropriate mapping string to a users altSecurityIdentities attribute in Active Directory.
So to comply, we need to fetch certificates issued from our CA, match these to devices in AD and then copy the serial number into the altSecurityIdentities attribute – and when a device renews its cert, we need to repeat this within a short enough window that authentication doesn’t fail.
I came across an elegant solution for ADCS which was later modified for AADJ devices based on the same source I’m using. That doesn’t help me given that I’m set on using SCEPman as a cloud CA (it’s free, lightweight, more secure, easy to manage for multiple campuses and remote devices, etc.) but it started the ball rolling on some thoughts.
I can view my issued certificates in Endpoint Manager and export them to a CSV so figured there might be an API. Turns out there’s two; managedAllDeviceCertificateState and deviceConfigurationsAllDeviceCertificates. The latter has no documentation and the former is beta and bears the caveat of “production use is not supported”. Testing in Graph Explorer worked however, as this example shows:
Results include both attributes we would need for mapping –managedDeviceDisplayName
and certificateSerialNumber
– as well as two we need for filters, certificateRevokeStatus
(limit to current certs) and certificateIssuerName
(limit to SCEPman certs). Combined, these would allow a basis for comparison with AD records.
The end result would be this amendment to the former process:
The ghost object automation would then not only create the computer account object in AD but with each subsequent routine execution compare its stored certificate serial with the serial of the most recent unrevoked SCEPman certificate issued in Intune and update it accordingly.
Herein lies the rub, since it’s difficult to predict exactly when devices will renew their certificates (they start trying with 10 percent duration remaining) and the window between renewal (when the device starts using its new cert) and update (when AD knows about it) may result in network unavailability for a device. It’s a problem worth having if everything else works though, since it would only happen once per year on any device.
Should this approach pan out, I’ll move this section to a new post and expand it with a more complete description.
Packetfence
This open-source network access control server has a degree of support for Intune devices but integrations use deprecated APIs and I have discounted EAP-TTLS-PAP which is the simpler deployment route because it’s still a password-based authentication mechanism. With a bit of updating and refinement this could represent a powerful and stable long-term solution in a post-AD world so it’s still on my radar.
MEM Certificate Lifecycle Management
This is the least likely option to be practical. Per @Collab_Seth There were hints that Microsoft will produce a cloud CA in Endpoint Manager as a premium option:
“MEM also will have a cloud-based “certificate lifecycle management solution” at some point. It’s described as a “cloud certificate management solution for Public Key Infrastructure (PKI),” which will permit IT pros to “easily deploy certificates from within Endpoint Manager.”
There hasn’t been word of this feature elsewhere since then and even if it did eventuate, this would only get us halfway there. Without an integration with on-prem AD via Azure AD Connect in a way that would create NPS-compliant objects for certificate-based authentication, we’re still in the dark.
Update 2/3/23: This was announced today under the umbrella of the new Intune Suite, named “Cloud Certificate Management”. Despite the announcement acknowledging that there are indeed Intune devices that use certificates for wi-fi without on-prem infrastructure, it seems that my previous assumption holds; this is not a complete answer to authentication and will only replace what SCEPman can already do for free.
Collected Thoughts
These are some references I collected in an earlier version of this post. There’s nothing here but acknowledgement that this is a problem.
From Microsoft
My rather horrified reflection on a tweet from Steven Hosking, Senior Program Manager at Microsoft stating that he does not recommend using NPS for RADIUS:
Wow this is illuminating. Here’s literally every school using NPS for RADIUS trying to get on board with AADJ for reduced TCO and then finding it costs more because of gaping holes in the offering needing expensive third party services to plug. https://t.co/9P6S8C2bJE
— Chris Beattie (@jabbrwcky) July 2, 2022
From The Community
Murray is on fire with this one. There is indeed an internal divide that’s visible in these actions.
At the moment, there's a war going on inside Microsoft' Some want to keep investing in on-premises solutions, cloud-enabling them, and creating migration features to go all cloud; Others only want to do cloud; Customers are left stranded until both sides agree.
— Murray (@MyNameIsMurray) July 30, 2022
Marc-André completes the thought, pointing out that the pull of cloud is set against the dead weight of legacy and customers are caught between the two.
On one side, you have the on-premises technology stack that people still use, but barely gets improved as opposed to their cloud counterparts, because it's "the future", so instead we get a hybrid stack with the advantages of the cloud and the disadvantages of on-premises stuff
— Marc-André Moreau (@awakecoding) July 30, 2022
The number of responses to this tweet from folk agreeing that certificate-based auth is the primary reason many organisations remain hybrid AAD-joined.
If you are using HAADJ today what are the reasons you have not yet moved to AADJ for windows devices? So many benefits and still get onprem enterprise SSO when you are on the intranet. https://t.co/h8fSb2iRO0
— Jef Kazimer (@JefTek) July 13, 2022