I ran into an issue where the wireless clients were unable to connect to the wireless network and the only error to be found was 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 spending many hours checking clocks, downgrading certificates from 4096 bits to 1024 bits, googling like crazy I finally found and verified that the July patch of 2017, KB4025335, broke 802.1X authentication.
Error message in NPS
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: removed$
Account Name: host/removed.removed.local
Account Domain: removed
Fully Qualified Account Name: removedClient Machine:
Security ID: NULL SID
Account Name: –
Fully Qualified Account Name: –
OS-Version: –
Called Station Identifier: MACADR:SSID
Calling Station Identifier: MACADRNAS:
NAS IPv4 Address: 10.10.10.10
NAS IPv6 Address: –
NAS Identifier: Cisco-wlc
NAS Port-Type: Wireless – IEEE 802.11
NAS Port: 13RADIUS Client:
Client Friendly Name: Cisco-wlc
Client IP Address: 10.10.10.10Authentication Details:
Connection Request Policy Name: Use Windows authentication for all users
Network Policy Name: Nps_policy_01
Authentication Provider: Windows
Authentication Server: radiusserver.removed.local
Authentication Type: EAP
EAP Type: Microsoft: Smart Card or other certificate
Account Session Identifier: removed
Logging Results: Accounting information was written to the local log file.
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.
Verified broken by Microsoft
Microsoft has noted a known limitation in KB4025335.
NPS authentication may break, and wireless clients may fail to connect.
Fix
Since uninstallation of the patch didn’t work, I was happy to see that Microsoft also included a workaround in KB4025335.
On the server, set the following DWORD registry key’s value to = 0: SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\DisableEndEntityClientCertCheck
However, there is no information about what the registry entry does. But a fair guess is the bug disabled the check of the endpoint certificate which is obviously a bad thing.
I will update this post if I find more information about the registry key and/or information about when the issue will be fix and the key can be removed.
I’m in the same boat! Concerned with what the registry entry actually does. I initially thought the same as you, but the key is “disable…” and we’re setting it to 0, so, logically we’re disabling the disabling of cert check. Either way, I’d love an explanation of what the setting is doing!
I have not found any information, but the best guesstumate is that the bug enabled “DisableCertCheck” and the workaround is to turn off the disabling of CertCheck.
This is how I fixed it for all the NPS servers in my environment:
$session = new-pssession -computername (get-adgroupmember “ras and ias servers”).name
invoke-command -session $session {New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\ppp\eap\13 -propertyType dword -Name DisableEndEntityClientCertCheck -Value 0 ; get-service *ias* | restart-service }