[German]The May 10, 2022 security updates for Windows cause several issues. One concerns authentication on domain controllers. This seems to fail for various machines (client and server) due to certificate errors. All clients are affected, from Windows 7 SP1 (with ESU) up to Windows 11 and the relevant server counterparts. Microsoft has since confirmed the problem.
Advertising
Multiple reports
Within my German blog there is this detailed discussion about problems with 802.1x certificates after patching domain controllers and NPS servers. Michael writes about this:
Yes, I have the NPS running here with computer certificates.
With the update KB5013941 no more authentications can be done due to certificates (Error 16, Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect).
After uninstalling the update, the NPS works again.
I had briefly pointed out this problem in the post Windows, Office: May 2022 Patchday issues and mysteries. At reddit.com there is this thread with a similar description of issues:
My NPS policies (with certificate auth) have been failing to work since the update, stating "Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing account or the password was incorrect.".
The server also serves the DC and ADCS role (don't ask, working on severing).
Uninstalling KB5014001 and KB5014011 resolves this but obviously would rather get them patched.
Anyone else seeing this? Running on 2012R2.
This issues are confirmed by other users and also for other server versions (2019 etc.).
Microsoft confirms this bug
Microsoft has since addressed the issue in the Windows 11 Health-Dashboard under the Know Issues in the post You might see authentication failures on the server or client for services as of May 11, 2022 and confirms the issue:
After installing updates released May 10, 2022 on your domain controllers, you might see authentication failures on the server or client for services such as Network Policy Server (NPS), Routing and Remote access Service (RRAS), Radius, Extensible Authentication Protocol (EAP), and Protected Extensible Authentication Protocol (PEAP). An issue has been found related to how the mapping of certificates to machine accounts is being handled by the domain controller.
Note: Installation of updates released May 10, 2022, on client Windows devices and non-domain controller Windows Servers will not cause this issue. This issue only affects installation of May 10, 2022, updates installed on servers used as domain controllers.
So it confirms exactly the authentication issue with domain controllers (ADs) and ADSC roles that was addressed above. The following Windows versions are affected by the clients
Advertising
- Windows 11 Version 21H2
- Windows 10 Version 21H2, 21H1; 20H2
- Windows 10 Version 1909; Enterprise LTSC 2019
- Windows 10 Version 1809
- Windows 10 Version 1607; Enterprise LTSC 2016
- Windows 10 Enterprise 2015 LTSB
- Windows 8.1
- Windows 7 SP1
and from the servers the following variants:
- Windows Server 2022
- Windows Server Version 20H2
- Windows Server Version 1909; Windows Server 2019
- Windows Server Version 1809
- Windows Server 2016
- Windows Server 2012 R2
- Windows Server 2012
- Windows Server 2008 R2 SP1
- Windows Server 2008 SP2
Addendum: Just in case, I've listet the May 2022 security updates for Windows within the blog post Microsoft has fixed the (PetitPotam) NTLM Relay Vulnerability (CVE-2022-26925) with Windows May 2022 Update. Just check the server relevant updates you have to avoid.
Microsoft is currently investigating the issue and plans to provide an update in one of the next releases. Until then, Microsoft suggests the following as a workaround:
Workaround: The preferred mitigation for this issue is to manually map certificates to a machine account in Active Directory. For instructions, please see Certificate Mapping.
So the manual mapping of certificates to a machine account in Active Directory. The instructions are the same for mapping certificates to user or machine accounts in Active Directory. If the preferred workaround does not work in your environment, see KB5014754—Certificate-based authentication changes on Windows domain controllers for other possible workarounds in the SChannel registration keys section. Other workarounds such as uninstalling the update are not recommended by Microsoft because of the security issues.
Similar articles:
Microsoft Office Updates (May 3, 2022)
Microsoft Security Update Summary (May 10, 2022)
Patchday: Windows 10-Updates (May 10, 2022)
Patchday: Windows 11/Server 2022-Updates (May 10, 2022)
Windows 7/Server 2008R2; Windows 8.1/Server 2012R2: Updates (May 10, 2022)
Exchange Server Security Updates (May 10, 2022)
Windows 11: Update KB5013943 results in application error 0xc0000135
MS-Patchday wrap-up: Issues with April 2022 updates
Windows Server 2022: RDS bug (RDCB role broken) caused by KB5011497, not fixed in May 2022
Windows Update KB5012599: Microsoft plans fix for install error 0x8024200B and 0x800F0831
Windows 11: Update KB5013943 results in application error 0xc0000135
Advertising
Thanks for this post! Very unintuitive error and it had me really scratching my head. Curious if anyone has a lab to test the workaround with certificate mappings. For now I've uninstalled on my DC's and up and running again. That was scary!
Thanks! Saved my day and the day of many employees.
Many Many Thanks !! This help us a lot to debug NPS machine certificate check issue due to patch KB5014001 on our DC.
Thank you! I wish I had found this post before. I was seeing events 4625 and 6273 appearing consecutively on the Security logs of my NPS server and I do use Computer certificates on my EAP-TLS authentication (WPA-Enterprise).
I can confirm that the SChannel registry key workaround really works and for me it is the real recommended approach for now. I've set the "CertificateMappingMethods" key to 1F on my domain controllers and on my NPS server, and it started working again right away (a reboot might be needed).
Path: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Key name: CertificateMappingMethods
Type: DWORD
Value: 1F
This changes the behavior back to the automatic mapping based on the certificate's subject. I also want to point out that my newly issued certificates already had the OID 1.3.6.1.4.1.311.25.2 defined and I tried both computer and user certificates and it didn't work.
Manually mapping countless certificates is not a feasible workaround, specially because they are usually valid for a year only, and if you were to automate this process you would probably be doing what the authentication process itself was already doing prior to this update. Let's hope for a future update that really fix this problem. Thanks again!