In a masterful stroke of irony, within days of me sharing my solution for NPS RADIUS with AADJ devices, itself made necessary because Microsoft doesn’t consider the needs of their cloud-first customers, they made a major change to how certificates work in Active Directory in KB5014754 without considering the needs of their cloud-first customers. This change breaks the mechanism my solution relies on to operate and while there is a workaround, it is only viable until the change kicks in. This date was initially set for Feb 2023 and later delayed to “November 14, 2023 or later”. I’ll break down why this is, discuss the inconsistencies with Microsoft’s approach and where this leaves us now.
Since NPS only looks at on-prem AD computer objects for authentication, how do we allow it to authenticate an Azure AD-joined (AADJ) device? – This was the original problem I set out to solve; the solution I posted previously involves creating a ‘ghost’ on-prem AD computer object that contains enough details to allow a match. The elegant part (conceived by @blurn) is that the certificate mapping between the on-prem AD object and the AzureAD device only relies on the I (issuer) and CN (common name) fields. The CN in our case is the AzureAD device ID which is unique and immutable, thus the mapping can be set once and any certificates issued to that device will match. This is important since we need to provide for expiry and renewal of certificates as time goes by without imposing the burden of having to update the on-prem AD object each time.
If it ain’t broke…
Unfortunately some issues came to light that showed weak mappings based on non-unique, non-immutable fields could be leveraged by an attacker to forge credentials and escalate privileges. Steve Syfuhs explains:
The long and the short of it is that attackers in certain privileged positions can mint certificates that impersonate other named principals.— Steve Syfuhs (@SteveSyfuhs) May 10, 2022
It's not a pants-on-fire situation because most environments already have mitigations in place that make this sort of attack difficult.
Sadly despite the low likelihood of attack, Microsoft decided to enforce a change to certificate mapping functionality. Application of the update inaugurates a grace period, after which only associations deemed ‘strong’ will be permitted:
Mapping types are considered strong if they are based on identifiers that you cannot reuse –KB5014754
A non-reusable identifier means one tied to an individual certificate, therefore its SR (serial), SKI (security key identifier) or public key. This completely invalidates the mapping of CN, rendering our great little NPS solution inoperable.
Strangely there is an alternative option referenced that flies in the face of the ‘cannot reuse’ mandate, namely an X.509 certificate extension at OID 188.8.131.52.4.1.311.25.2 containing the AD object SID (security identifier). This is a unique, immutable value used to identify an AD object and would allow the mapping to be set once and match on all certificates carrying the extension (sound familiar?). The reasoning for this exception isn’t explicitly outlined in the article, however the error text below (which is what is shown in the grace period when an authentication would have failed) would seem to indicate that it is deemed ‘strong’ and on par with the unique methods:
This begs the question: why is the SID a strong method while the CN, which could be equally immutable and unique, is deemed to be weak? Either the problem is reusable identifiers or it isn’t. More importantly, why take this decision out of the hands of customers by enforcing the change rather than leaving ‘compatibility mode’ as a viable option in future? Certainly in an ideal world we wouldn’t have the option for a weak mapping since administrative error could cause it to be added to a sensitive account, however as with many other settings that could be configured unsafely, this could simply be recommended against and audited to check.
Back to my original point about Microsoft not incorporating cloud-first environments in their plans though; this isn’t only a problem for me and my NPS workaround. In fact, no certificates issued by Intune / MEM are compatible with the new OID:
I've tested. On-premises certificates issued with update KB5014754 installed have the new OID. Certificates issued via #msintune using PKCS or SCEP do not.— Richard Hicks (@richardhicks) May 20, 2022
This is very disappointing as it removes the simplest method of maintaining continuity in certificate mapping and leaves us with the difficult questions of how to change our existing device mappings to certificate-specific ones and how to update these on an ongoing basis when certificates are replaced. I don’t yet have an answer to either and none seems apparent; it may sadly be that the only practical long-term solution is outside of the Microsoft fold.
I did find an answer to my question on SID vs CN. My assumption was that the notion of reusability referred to in the KB article was in relation to reuse of mappings across multiple certificate assignments to the same AD principal, i.e. if more than one unique certificate could match. That isn’t the case; rather the reusability refers to associations across multiple AD principals. The security concern is that since there is no verifiable association between the CN and the principal, it could be used as a means for impersonation where one principal has a certificate assigned to the CN of another.
This attack is not exposed in a pure Intune / MEM environment where certificate operations are performed automatically by devices based on policy, the CN is pulled from the device’s Azure AD details via Graph API and users don’t have admin access to their devices to change this, nor any access to AD itself. For this reason it would be sensible for Microsoft to leave the option of maintaining CN mappings into the future. Perhaps the delayed deadline is a sign of some difficulties or pushback from customers on this issue.