This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(60.8, 90%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EG%3C/text%3E%3C/svg%3E)
Hello,
after installing the latest patch tuesday (May 2022) updates and restarting the servers the domain computers (Win 10) are not able to join to company's local network via ethernet or Wifi anymore. Both connection methods are using NPS with EAP and certificate based authentication.
Before installing the updates everything was working fine. This problem appeared right after installing the updates and rebooting the servers. No change in any settings regarding NPS or certificates were made before the problem started.
After installing the updates the NPS log stopped logging new events despite it seemed to be still enabled for both success and failure. I disabled and then re-enabled the logging and now it seems to log properly.
auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable
Now the log event for every computer trying to join the company's local network seem to be this:
Event ID: 6273
Keyword: Audit Failure
Reason Code: 16
Reason: 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.
What could be the causing this problem?
Thank you in advance!
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(268.8, 30%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ES%3C/text%3E%3C/svg%3E)
We got the systems working again without tweaking registry and without uninstalling the patch. We re-enrolled all certs with the new SID attribute and checked that the NPS is offering right certificate from the client side event log. It wasn't doing that originally even though all dialogs showed the right certificate is chosen, but we had to change it to another and back to get it to actually offer the right certificate.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(281.6, 18%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAV%3C/text%3E%3C/svg%3E)
I haven't been able to get it to work. I can see the client has the new OID 1.3.6.1.4.1.311.25.2 in the client certificate that is populated with the client computer's SID after I re-enrolled the certificate. Where is the location in the client side event log that I can check whether the correct certificate is being offered?
Hi, it should be in System Event log. Event source Schannel, description says something about expired certificate.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(70.4, 80%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ES%3C/text%3E%3C/svg%3E)
Thank you for the update in how you resolved the issue. We are still troubleshooting this in our organization and was curious if you happen to have some step-by-step instructions you are able to share or is there a site you followed to resolve?
I read the kb from MS like tens of times and finally understood that the SID extension should be there. So if you have that above mentioned OID 1.3.6.1.4.1.311.25.2 in all the certificates, that part should be okay. If not, re-enroll them from CA management.
After that, verify from client which certificate is offered from NPS (by checking event log, schannel source).
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(57.599999999999994, 55.00000000000001%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EVK%3C/text%3E%3C/svg%3E)
For us the workaround was to add reg key here:
HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel\
value: CertificateMappingMethods
Data Type: DWORD
Data: 0x1F
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(297.6, 4%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAD%3C/text%3E%3C/svg%3E)
hi there,
Did you make this change on the client, NPS server or Domain Controller?
Edit: NPS is running on DC so can't comment this one.
Keep in mind that changing the SChannel registry key value back to the previous default (0x1F) will revert to using weak certificate mapping methods.
We have NPS running on DC, so we did those changes across Domain Controllers
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(25.6, 22%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EG%3C/text%3E%3C/svg%3E)
We ran into this and have seperate AD/NPS servers. I applied it only to the DCs and it corrected the issue for now until we can investigate the stricter certificate mappings. No reboot of the DCs was required.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(198.4, 38%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EF0%3C/text%3E%3C/svg%3E)
We did the same this morning only on our DC servers. (NPS is on another server)
I confirm no DC reboot was required and it fixes the issue.
Hello, we have the same issues after the update installation.
All our WiFi clients stop working.
Microsoft released some KB here https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-21h2#you-might-see-authentication-failures-on-the-server-or-client-for-services
however it is not clear if its fully safe to do those changes across domain controllers or not
That KB matches our issues as well. Really poor effort from Microsoft to release a patch that kills critical functionality.
Some additional info:
I found this site.
I added the registry entry and rebooted the NPS-server. Unfortunately it didn't help and the problem still remains.
As a workaround, create the following registry on your server: Create DWORD registry key under:
SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\
New_DWORD: DisableEndEntityClientCertCheck
and set value to 0
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(124.80000000000001, 47%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ENF%3C/text%3E%3C/svg%3E)
We are having similar issues with NPS as well. This update has also caused DHCP to fail.
I'm thinking of uninstalling the CU.
Thank you for the help!
Modifiying the registry as suggested by VasylKlyuyev seems to get authentication working again.
That is still a temporary workaround, 'cause it uses weak certificate mapping methods - hope that Microsoft will soon provide a proper update to fix this.
The SChannel registry key default was 0x1F and is now 0x18. If you experience authentication failures with Schannel-based server applications, we suggest that you perform a test. Add or modify the CertificateMappingMethods registry key value on the domain controller and set it to 0x1F and see if that addresses the issue. Look in the System event logs on the domain controller for any errors listed in this article for more information. Keep in mind that changing the SChannel registry key value back to the previous default (0x1F) will revert to using weak certificate mapping methods.
Here are a couple of links related to this matter.