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:

Graph Explorer Query

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:

New 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:

From The Community

Murray is on fire with this one. There is indeed an internal divide that’s visible in these actions.

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.

The number of responses to this tweet from folk agreeing that certificate-based auth is the primary reason many organisations remain hybrid AAD-joined.