Did Windows Update break your wireless?

Today’s wireless networks are often robustly built with redundancy, both on the wireless coverage side with coverage from many access points on different channels and on the contoller side with redundant hardware (if you still use controllers).
The majority of office networks are secured with 802.1x authentication (or at least they should be!) but securing login servers is sometimes missed in redundancy plan.
Most companies separately set up dual NPS servers, but a failover to the secondary RADIUS / NPS server will normally only happen if the first RADIUS / NPS server stops responding.
If you get a deny on the user from the server, the wireless system thinks everything is working properly and the user should not be allowed onto the network.

This was clearly noticeable when people began to install the KB4034681 update from Microsoft.
This update has a known issue that causes the NPS server to fail to verify clients and computers that uses certificate based authentication (EAP).
This immediately resulted in that all users who were trying to authenticate, got denied by the NPS server and the wireless network ”ceased to work”.

The problem is logged in the event viewer on the NPS server as the following error:

Reason Code: 16
Reason: Authentication failed because of a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

For those who are not used to working with the Event viewer, all your NPS logs can be found here (Custom Views\Server Roles\Network Policy and Access Services):

Event Viewer

This issue is documented by Microsoft here:

There are two ways to resolve this issue:
Either you uninstall patch KB4034681, or as a workaround for the problem, you can create the following registry entry on your server:

Create a DWORD registry key under:

SYSTEM \ CurrentControlSet \ Services \ RasMan \ PPP \ EAP \ 13 \
New_DWORD: DisableEndEntityClientCertCheck

and set the value to 0

From what I can tell, this bug affects only Windows Server 2012 r2 and only clients with certificate authorization.
PEAP authentication with username / password, or with an computer account, seems to work normally.
I haven’t investigated if this patch also poses problems for 802.1x LAN authentication, but that seems very likely.

Should you not get any log entries at all in Event Viewer, you may need to enable logging.
This is done easiest in the command prompt (as administrator)

Audit policy / set / subcategory: "Network Policy Server" / Success: enable / fail: enable


Here you can choose if you only want to log failed events or even successful.

I would like to send a big thank you to Robert Jyllhed who gave me this script to simply identify failed logins on NPS with a PowerShell.

invoke-command -ComputerName veabnps01 -Credential $credential -ScriptBlock { get-eventlog -logname Security -EntryType FailureAudit -After (get-date).AddHours(-5) } -ov a

A more accurate error message is saved in the variable and can then be enumerated

$ A | fl

In conclusion, this error indicates that redundancy not only applies to hardware, but also to clear procedures for patch management with testing and checking of logs.

Lämna en kommentar

E-postadressen publiceras inte. Obligatoriska fält är märkta *