Microsoft introduced important changes affecting certificate-based authentication on Windows domain controllers as part of the May 10, 2022 update KB5014754 that may affect Always On VPN deployments. The update addresses privilege escalation vulnerabilities when a domain controller is processing a certificate-based authentication request. The recommendation from Microsoft is that the update be applied to all Windows domain controllers and Active Directory Certificate Services (AD CS) servers as soon as possible.
Updated 5/20/2022: An out-of-band update to address authentication issues reported with this update is now available. Updates are available for Windows Server 2022, Windows Server 20H2, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 SP1, and Windows Server 2008 SP2.
Certificate Services
After applying the update to certification authority (CA) servers, a non-critical extension with Object Identifier (OID) 1.3.6.1.4.1.311.25.2 is added to all issued certificates with the user or device security identifier (SID) included. Domain controllers with the update installed will use this information to validate the certificate used for authentication and ensure that it matches the information in Active Directory.
Domain Controllers
The update operates in Compatibility Mode, by default, when applied to domain controllers. Windows monitors authentication requests and records audit events for certificates presented for authentication under the following conditions.
No strong mapping (event ID 39) – The certificate has not been mapped explicitly to a domain account, and the certificate did not include the new SID extension.
Certificate predates account (event ID 40) – A certificate was issued before the user existed in Active Directory, and no explicit mapping could be found.
User’s SID does not match certificate (event ID 41) – A certificate contains the new SID extension, but it does not match the SID of the corresponding user account.
Certificate Mapping
Administrators can map certificates explicitly to accounts in Active Directory, but this results in a significant administrative burden in most environments. A better option is to reissue user and device authentication certificates after applying the KB5014754 update to all issuing CA servers.
Reenroll Certificates
Administrators should reissue user and device authentication certificates after applying the KB5014754 update. Open the Certificate Templates management console (certtmpl.msc), identify the user or device authentication certificate template, then right-click on the template and choose Reenroll All Certificate Holders.
Enforcement Mode
After applying update KB5014754, administrators should monitor domain controller event logs for event IDs 39, 40, and 41. Once all certificates have been updated, and none of these events have been recorded for 30 days, administrators can switch to Full Enforcement Mode by enabling it in the registry on all domain controllers.
Key: HKLM\SYSTEM\CurrentControlSet\Services\KDC
Value: StrongCertificateBindingEnforcement
Type: DWORD
Data: 2
Updated 12/8/2022: Microsoft has pushed back the original enforcement date of May 9, 2023, to November 14, 2023 “or later”. Stay tuned!
Updated 11/29/2022: Microsoft now states that the full enforcmenet mode date is now February 11, 2025 “or later”. Once again, stay tuned!
Known Issues
There have been some reports of authentication issues after installing the KB5014754 update. Early indications are that device authentication certificates missing a Subject Alternative Name (SAN) entry are to blame. Administrators are encouraged to update their device certificates to include the SAN entry. Optionally, but not recommended, administrators can place the update in disabled mode by editing the registry.
Note: An out-of-band update for these authentication issues is now available. See the reference links at the top of this article for more information.
Caveat
It’s important to understand that this new OID is added only to online templates. Online templates are those that build the subject information from Active Directory. Unfortunately, this new OID is NOT applied to offline templates (templates where the subject name is supplied in the request), such as those used for delivering certificates with Microsoft Endpoint Manager/Intune using PKCS or SCEP. It is impossible to move to enforcement mode when issuing user or device authentication certificates with Microsoft Endpoint Manager or Intune today. Microsoft is aware of this limitation and is working to address this issue as we speak. I expect a fix to be available sometime before the May 2023 deadline when Microsoft permanently switches on enforcement mode.
Additional Information
KB5014754 – Certificate-based authentication changes on Windows domain controllers
Microsoft Windows Always On VPN Users Prompted for Certificate
Chris
/ May 16, 2022What would be the right order to apply this without having VPN outages?
Patch CA -> Patch ALL DC’s -> Reenroll?
We have multiple domain controllers in place. We already see some authentication errors because one DC has already updated.
Any advice?
Richard M. Hicks
/ May 16, 2022The preferred method would be update all CAs, re-enroll all certificate holders, then update DCs.
sebus
/ May 25, 2022Sadly new issued certificate(s) after all infrastructure update, do NOT get Object Identifier (OID) 1.3.6.1.4.1.311.25.2 in the certificate from template
Any ideas?
Richard M. Hicks
/ May 25, 2022Did you apply the May 2022 update to your issuing CA servers? If so, certificates issued after the update is applied will include the new OID by default.
mikewmathis
/ May 25, 2022In my testing we found we had to change the SAN name we were using from the DNS name of the computer to the UNC for the computer account.
Mark
/ May 4, 2023Do you mean you got offline cert to work with this method or? To date i only know of 3rd party tools to do this or having to do manual maping with powershell. https://system32.blog/post/adsmapcertificates/
sebus
/ May 25, 2022This new Object Identifier (OID) (1.3.6.1.4.1.311.25.2) is added to any newly issued Certificates ONLY if they are issued via AutoEnrollment !
If certificate is requested by user, it does NOT have this object
Richard M. Hicks
/ May 25, 2022That is not expected behavior. Are you issuing these certificates on-premises directly? Or with Intune using PKCS or SCEP?
Nate
/ June 10, 2022For me, certs issued through GPO auto-enrollment have the new OID. Certs issued through the Intune PKCS connector do not have the OID. This is after ensuring the Intune cert connectors were up to date and after installing the out-of-band MS update.
Richard M. Hicks
/ June 10, 2022I’m seeing that as well, as most others are too. Still awaiting something from Microsoft on this. I suspect an update to the Intune certificate connector may be required. Hopefully, they are adding this capability as we speak.
Alex Ledger
/ June 20, 2022Newly enrolled certs issues by AD Autoenrollment get the new OID. SCEP certs issues via Intune do not. Is there anything i can do to add OID for certs issues via Intune ?
Richard M. Hicks
/ June 20, 2022That is expected. It appears to be a limitation Microsoft hasn’t yet addressed. I’m investigating as we speak. Stay tuned!
Ed Morgan
/ July 13, 2022Hi,
Which of the event viewer logs would event IDs 39, 40, and 41 be found in?
Cheers
Ed
Richard M. Hicks
/ July 13, 2022They can be found in the System event log.
Ed Morgan
/ July 13, 2022Thanks Richard!
Florian B (@jackdead88)
/ November 15, 2022Hey Richard, do you have any news to the caveat from MS?
Richard M. Hicks
/ November 15, 2022Although Microsoft has not stated anything publicly, I have customers with open support cases that have been informed that Microsoft is working on a solution. For now, there are two open-source options, but only one of them is available now.
Uwe Gradenegger has published his code here: https://github.com/Sleepw4lker/TameMyCerts.
Vadims Podans will be publishing his code soon.
Hope that helps!
Leo Bhaskara
/ December 27, 2022Howdy Richard,
We’re just about to finish new implementation of NPS + ADCS for .1X machine auth for a customer, and when I searched for any potential problem in the future I found this blog. No kidding.
Since the customer owns multiple non-domain-joined devices (Macs, Androids), we decided to use Intune with Certificate Connector to request certs to the CA and distribute them to all devices including Windows.
We also use a single dummy computer object for the above non-domain-joined devices and issue machine certs with the object’s name for the certs’ SAN attribute.
I found logs with event ID 39 in our domain controllers’ system logs.
For now I’m considering manual mapping, but there are so many of these devices I’m not sure how many values can fit inside the altSecurityIdentities attribute of a single object!
And there’s another problem of manually updating the above values when the certs were replaced.
Do you have any advice for this scenario?
Richard M. Hicks
/ December 28, 2022Manual mapping doesn’t scale well, unfortunately. You could probably automate it, though, but it’s not something I’ve tried yet. Honestly, your best bet is to wait until Microsoft addresses this issue. They’ve indicated they are working on it. Eventually, Microsoft must support adding EKU 1.3.6.1.4.1.311.25.2 to offline templates for the Intune certificate connector (PKCS and SCEP); just not sure when that’s coming. It should be available before the May 2023 deadline. If not they’ll have to postpone enforcement because it would break lots of customers.
FYI, there is an open-source solution available now if you are interested. Details here: https://github.com/Sleepw4lker/TameMyCerts.
Leo Bhaskara
/ December 28, 2022Thanks Richard,
I also looked around for the documentation of the new OID and I found this: https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-WCCE/%5bMS-WCCE%5d.pdf (page 52)
So, the new OID contains the objectSid attribute value of the AD object (in my case, the dummy computer object’s). In this case -in my understanding- multiple certs can have the same SID that points to a single AD object. I was worried if the OID was for one-to-one mapping of the cert to the AD object.
Now we just have to wait for Microsoft to fix the certificate connector.
Leo Bhaskara
/ September 19, 2023Howdy Richard,
https://blogs.windows.com/windows-insider/2023/09/14/releasing-windows-11-build-22621-2359-to-the-release-preview-channel/
“This update affects the Key Distribution Center (KDC) and user security identifiers (SID). KDC now reads the user SID from the Subject Alternative Name (SAN) of a certificate. Because of this, mobile device management (MDM) providers can use offline templates to fill in the user SID. To learn more, see KB5014754.”
I found the above release note from Microsoft. Since it’s a release preview, I believe it’s highly likely that the change will make it to the next final release.
It’s for Windows 11, though. Do you think it will be the same for Windows Server?
I checked the PKCS template in Intune and its official documentation but the change hasn’t been reflected there, yet.
Richard M. Hicks
/ September 19, 2023Thanks for the heads up on this. No doubt this is a prerequisite for the changes required to support the SID in offline templates as required for PKCS and SCEP certificates with Intune. Although this appears to be for Windows 11 only, I expect that all supported versions of Windows would get this update eventually.
Bert
/ February 7, 2023Hi Richard, thanks for this post.
Do you have any news on the caveat regarding NDES/Intune?
What I see in our environment is that none of the Intune certificates have a strong binding (as expected), however only some of them generate an event 39. Most of them seem to pass without warnings. I discovered that the ones that generate an event have an ancient published certificate in AD (that doesn’t match the Intune Cert), so that could explain the Event. (I’m still testing if the events disappear when I delete the legacy certificates from AD). It doesn’t explain why all the others seem to be OK without any strong binding. Perhaps the OU path in the subject is still considered?
I still can’t find any MS update about this, and the deadline is approaching….
Thanks!
Richard M. Hicks
/ February 7, 2023Microsoft is still working to address this limitation. There’s no ETA on a fix, however. Microsoft recently announced they are pushing back the enforcement date to November 14, 2023. Curiously they added “or later” to that statement, which suggests they aren’t confident with the November 2023 target. :/
I’m not sure why you don’t see event 39 consistently, however. I don’t think it has anything to do with the OU.
jan slavik
/ April 21, 2023Hi Richard,
do you have some update ? We opened ticket to unified support but it is absolutely horrible. No update from them.
Richard M. Hicks
/ April 22, 2023I’ve not heard much from Microsoft on this. They did push back the enforcement date, though. Interestingly, the KB now states the enforcement date has been pushed back to November 14, 2023 “or later”. The last bit is telling. It seems they aren’t confident about meeting this deadline. 😉 They’ve got a fair amount of work to do to address this. Hoping they’ll have something for us by the end of this year.
Martony
/ September 16, 2023Hi guys!
I’ve talk to Per Larsen (Intune PM) last week at the Paris MEM Summit 2023, the more evidence we can get, the more chance we have to force MS to move on this.
“I talked to our feature PM about NPS and getting AAD/Intune device support.
We are going over the customer evidence again – we do not have enough customers evidence, so if you have more information and more customer evidence you can share.
Customer name, size and use case.
Thanks Per”
Please send it to [email protected]
#IWork4Dell
Richard M. Hicks
/ September 16, 2023Azure AD has already been addressed. Details here: https://directaccess.richardhicks.com/2023/07/11/azure-conditional-access-certificates-with-sid-information-now-available/.
I understand that Microsoft is working to address certificates issued via Intune using SCEP and PKCS as we speak. I’m hoping we’ll see something available before the end of the year.
Thanks!
Mathieu Allard
/ November 10, 2023Hey Richard, I was checking back on this and at least from the original KB article (https://support.microsoft.com/en-au/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16) in the “Take Actions” section the Deadline for the full enforcement mode now seems to be Feb 11th 2025 instead of Nov 2023.
That said, have you heard anything since for what needs to be done to support the Strong Mappings in SCEP Certificates?
Richard M. Hicks
/ November 10, 2023To be clear, it says February 11, 2025 “or later”. 😉 That tells me this date can and likely will move again. Microsoft is still working on the changes required to support this for PKCS and SCEP. They’ve already fixed this for Azure Conditional Access certificates, as explained here.
https://directaccess.richardhicks.com/2023/07/11/azure-conditional-access-certificates-with-sid-information-now-available/
The last I heard the fix for PKCS/SCEP was due out by the end of the year. If that’s the case, the February 2025 date is reasonable. If the fix isn’t released until later next year, the enforcement date might be pushed out again.