Windows 11 clients cannot authenticate to NPS server using computer authentication

[PaulvDam]

We have a Windows server 2019 datacenter server running NPS. Our WiFi Office clients authenticate to this server for access to the corporate WiFi network. We use computer authentication, so members of the "domain computers" group are allowed access in the policy (we only want domain computers on this network and we don't want users to need to enter their user credentials). 

We use GPO to provision a WiFi profile to the domain computers, in which we configure that computer authentication is needed. Our Windows 10 clients (literally all of them) are connecting nicely (I have anonimized the event log for security purposes:

Network Policy Server granted access to a user.

User:
Security ID: DOMAIN\COMPUTER$
Account Name: host/COMPUTER.domain.nl
Account Domain: DOMAIN
Fully Qualified Account Name: DOMAIN\COMPUTER$

Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
Called Station Identifier: xx-xx-xx-xx-xx-xx:SSID
Calling Station Identifier: XX-XX-XX-XX-XX-XX

NAS:
NAS IPv4 Address: x.x.x.x
NAS IPv6 Address: -
NAS Identifier: AP01
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: 1

RADIUS Client:
Client Friendly Name: SonicPoint HQ 1
Client IP Address: x.x.x.x

Authentication Details:
Connection Request Policy Name: NAP 802.1X (Wireless)
Network Policy Name: NAP 802.1X (Wireless) Non NAP-Capable
Authentication Provider: Windows
Authentication Server: NPS.DOMAIN.nl
Authentication Type: PEAP
EAP Type: Microsoft: Secured password (EAP-MSCHAP v2)
Account Session Identifier: "edited"
Logging Results: Accounting information was written to the local log file.

When a Windows 11 client (all of them actually) tries to connect, we see the following logged (again, anonimized):

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
Security ID: NULL SID
Account Name: host/COMPUTER.domain.nl
Account Domain: DOMAIN
Fully Qualified Account Name: DOMAIN\COMPUTER$

Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
Called Station Identifier: XX-XX-XX-XX-XX-XX:SSID
Calling Station Identifier: XX-XX-XX-XX-XX-XX

NAS:
NAS IPv4 Address: x.x.x.x
NAS IPv6 Address: -
NAS Identifier: AP01
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: 1

RADIUS Client:
Client Friendly Name: SonicPoint HQ 1
Client IP Address: x.x.x.x

Authentication Details:
Connection Request Policy Name: NAP 802.1X (Wireless)
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: NPS.domain.nl
Authentication Type: PEAP
EAP Type: -
Account Session Identifier: "edited"
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.

The only real difference I see is that for the Windows 11 client, NULL SID is provided as "Security ID". Could it be that this is causing NPS to not be able to verify that the machine that is attempting to connect is a member of the security group which is allowed to connect (the default group "Domain Computers")?

Looking forward to either a quick bug fix or a configuration change I need to make. Maybe other Windows Server admins are also experiencing this issue?

[#2]

@PaulvDam We are also experiencing the same exact issue.  Clients get the certificate and will not connect to our NPS server to connect to our wifi.  Were you able to find a fix?

[#3]

Not yet, all my hopes are resting on this forum post :)

[#4 · Accepted solution]

Had this with 802.1x and AlwaysOn VPN. Maybe it's the same for your Wifi profile,. The reason is documented here https://directaccess.richardhicks.com/2021/09/23/always-on-vpn-error-853-on-windows-11/

[#5]

@Wolfgang42 

Thanks for this very good suggestion, I have looked into it and there is indeed a case difference between the policy and the certificate. 

However, after remediating this (setting the policy to upper case for both our NPS servers), the problem remained. This is no doubt all related, because more or less the same GUI is user for direct access always online VPN profiles, so I'm guessing we are almost there in solving this issue.

[#6]

@PaulvDam 

We figured our issue out.  We had a GPO that pointed to our NPS server and in the GPO the NPS server name was all lowercase and our NPS server is capitalized.  That was ultimately the problem.  A simple fix but not obvious at all

[#7]

@jmichels @Wolfgang42 

OK something unexpected here... I had to recreate the WiFi profile using a new Profile Name (Windows remembered the lower case setting if the profile had the same name).

This solved the issue, so in the end it was also the case sensitivity that was introduced in Windows 11.

Thanks a lot guys!

[#8]

We had a similar issue, but instead of not connecting, Windows 11 users were presented a message stating the certificate could not be verified, if you're trying to connect to your organizations network go ahead and connect. Clicking the connect button would allow the connection.
We discovered the PEAP settings in the GPO creating the wireless profile had the box checked to verify the certificate but did not specify any Root CAs. Adding our Root CA to the policy fixed the issue, the warning prompts went away. This policy has been working fine on our Windows 10 laptops and tablets.

[#9]

We had the case mismatch between the server name listed in the PEAP properties, and the Subject Alternate Name on the server cert. PEAP properties is in the group policy, and SAN is on the NPS server. So, open certificates snap-in on the NPS server, open the server cert, and check the SAN. The PEAP properties (drill down, edit the profile, security tab, properties, "Connect to these servers:") have to match the exact case as shown on the SAN. This article has 3 likes. Soon it will have hundreds, as enterprises start to roll out Windows 11.

[#10]

Just adding my experience here. I was having trouble with my Windows 11 clients not authenticating automatically and popping up the "Action Needed" dialog box. The computers would not authenticate automatically, but when following the dialog boxes we could get them to authenticate by manually telling the computer to try.

We have our switches configured to authenticate with Microsoft NPS and are using Group Policy to configure the computers. Our Windows 10 computers worked without flaws. After reading this thread I decided to check my Group Policy and the only difference is that I was not specifying the servers they could authenticate to, so I was not having the problem with the case mismatch. I found the fix to be checking the box next to my domain CA in the Trusted Root Certification Authorites section below the box where you can specify which servers to connect to.

[#11]

Thanks! That was the trick, you made my day!

[#12]

For our environment it was due to credential guard.  This will break anything using PEAP w/MS-CHAPv2, including machine authentication.  It's also extremely tricky to debug because this requires Windows Enterprise version and since we are using E3 licenses (included in there is the OS Enterprise license) this problem only surfaces eventually when the OS is upgraded to enterprise in the background (enabled by default with Enterprise, does not get enabled with only Pro).

Fix: Group Policy->Administrative Templates->System->Device Guard->Turn On Virtualization Based Security (set to DISABLED).

[#13]

@Nick_A - I registered just to say that this was the fix for me! Credential guard is enabled by default for any device that can handle it in Windows 11 22H2 (in Windows 11 Enterprise and Education).

Wally

[#14]

This is the solution for me as well.

[#15]

@BenBoldt can you elaborate a bit on what GPO you did make, in order to solve this issue? :)

We just Upgraded our Windows 10 hybrid to Windows 11 - and now we got this issue. :(

[#16]

But seriously - to Disable Device Guard - is that even an option you want?

[#17]

Our fix is to rename the NPS server so its name is lowercase.  Since our NPS's are also a a DCs the steps are

1. uninstall Certificate Authority

2. rename the server to lowercase using the following

netdom computername DC1.domain.local /add:dc1.domain.local

netdom computername DC1.domain.local /makeprimary:dc1.domain.local

shutdown /r

3. Install Certificate Authority again

I have a lot of servers to change so if there is a less disruptive workaround I love to hear what it is.

[#18]

Hello,
Please keep in mind having a CA on a domain controller is not supported (and will block you from upgrading to another OS). Having NPS role on domain controllers is also not recommended.

@MikkelLundKnudsen Device Guard offers a critical protection against numerous ransomwares as it counters Mimikatz-based attacks, so that's a big no in my book.

[#19]

@Nick_A 

instead of disabling a critical security feature (credential guard) you should fix your NPS to not use ms-chap, as this is documented very well to not work with credential guard.