SOLVED

Windows 11 clients cannot authenticate to NPS server using computer authentication

%3CLINGO-SUB%20id%3D%22lingo-sub-2827382%22%20slang%3D%22en-US%22%3EWindows%2011%20clients%20cannot%20authenticate%20to%20NPS%20server%20using%20computer%20authentication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2827382%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20have%20a%20Windows%20server%202019%20datacenter%20server%20running%20NPS.%20Our%20WiFi%20Office%20clients%20authenticate%20to%20this%20server%20for%20access%20to%20the%20corporate%20WiFi%20network.%20We%20use%20computer%20authentication%2C%20so%20members%20of%20the%20%22domain%20computers%22%20group%20are%20allowed%20access%20in%20the%20policy%20(we%20only%20want%20domain%20computers%20on%20this%20network%20and%20we%20don't%20want%20users%20to%20need%20to%20enter%20their%20user%20credentials).%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20use%20GPO%20to%20provision%20a%20WiFi%20profile%20to%20the%20domain%20computers%2C%20in%20which%20we%20configure%20that%20computer%20authentication%20is%20needed.%20Our%20Windows%2010%20clients%20(literally%20all%20of%20them)%20are%20connecting%20nicely%20(I%20have%20anonimized%20the%20event%20log%20for%20security%20purposes%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENetwork%20Policy%20Server%20granted%20access%20to%20a%20user.%3C%2FP%3E%3CP%3EUser%3A%3CBR%20%2F%3ESecurity%20ID%3A%20DOMAIN%5CCOMPUTER%24%3CBR%20%2F%3EAccount%20Name%3A%20host%2FCOMPUTER.domain.nl%3CBR%20%2F%3EAccount%20Domain%3A%20DOMAIN%3CBR%20%2F%3EFully%20Qualified%20Account%20Name%3A%20DOMAIN%5CCOMPUTER%24%3C%2FP%3E%3CP%3EClient%20Machine%3A%3CBR%20%2F%3ESecurity%20ID%3A%20NULL%20SID%3CBR%20%2F%3EAccount%20Name%3A%20-%3CBR%20%2F%3EFully%20Qualified%20Account%20Name%3A%20-%3CBR%20%2F%3ECalled%20Station%20Identifier%3A%20xx-xx-xx-xx-xx-xx%3ASSID%3CBR%20%2F%3ECalling%20Station%20Identifier%3A%20XX-XX-XX-XX-XX-XX%3C%2FP%3E%3CP%3ENAS%3A%3CBR%20%2F%3ENAS%20IPv4%20Address%3A%20x.x.x.x%3CBR%20%2F%3ENAS%20IPv6%20Address%3A%20-%3CBR%20%2F%3ENAS%20Identifier%3A%20AP01%3CBR%20%2F%3ENAS%20Port-Type%3A%20Wireless%20-%20IEEE%20802.11%3CBR%20%2F%3ENAS%20Port%3A%201%3C%2FP%3E%3CP%3ERADIUS%20Client%3A%3CBR%20%2F%3EClient%20Friendly%20Name%3A%20SonicPoint%20HQ%201%3CBR%20%2F%3EClient%20IP%20Address%3A%20x.x.x.x%3C%2FP%3E%3CP%3EAuthentication%20Details%3A%3CBR%20%2F%3EConnection%20Request%20Policy%20Name%3A%20NAP%20802.1X%20(Wireless)%3CBR%20%2F%3ENetwork%20Policy%20Name%3A%20NAP%20802.1X%20(Wireless)%20Non%20NAP-Capable%3CBR%20%2F%3EAuthentication%20Provider%3A%20Windows%3CBR%20%2F%3EAuthentication%20Server%3A%20NPS.DOMAIN.nl%3CBR%20%2F%3EAuthentication%20Type%3A%20PEAP%3CBR%20%2F%3EEAP%20Type%3A%20Microsoft%3A%20Secured%20password%20(EAP-MSCHAP%20v2)%3CBR%20%2F%3EAccount%20Session%20Identifier%3A%20%22edited%22%3CBR%20%2F%3ELogging%20Results%3A%20Accounting%20information%20was%20written%20to%20the%20local%20log%20file.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20a%20Windows%2011%20client%20(all%20of%20them%20actually)%20tries%20to%20connect%2C%20we%20see%20the%20following%20logged%20(again%2C%20anonimized)%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENetwork%20Policy%20Server%20denied%20access%20to%20a%20user.%3C%2FP%3E%3CP%3EContact%20the%20Network%20Policy%20Server%20administrator%20for%20more%20information.%3C%2FP%3E%3CP%3EUser%3A%3CBR%20%2F%3ESecurity%20ID%3A%20NULL%20SID%3CBR%20%2F%3EAccount%20Name%3A%20host%2FCOMPUTER.domain.nl%3CBR%20%2F%3EAccount%20Domain%3A%20DOMAIN%3CBR%20%2F%3EFully%20Qualified%20Account%20Name%3A%20DOMAIN%5CCOMPUTER%24%3C%2FP%3E%3CP%3EClient%20Machine%3A%3CBR%20%2F%3ESecurity%20ID%3A%20NULL%20SID%3CBR%20%2F%3EAccount%20Name%3A%20-%3CBR%20%2F%3EFully%20Qualified%20Account%20Name%3A%20-%3CBR%20%2F%3ECalled%20Station%20Identifier%3A%20XX-XX-XX-XX-XX-XX%3ASSID%3CBR%20%2F%3ECalling%20Station%20Identifier%3A%20XX-XX-XX-XX-XX-XX%3C%2FP%3E%3CP%3ENAS%3A%3CBR%20%2F%3ENAS%20IPv4%20Address%3A%20x.x.x.x%3CBR%20%2F%3ENAS%20IPv6%20Address%3A%20-%3CBR%20%2F%3ENAS%20Identifier%3A%20AP01%3CBR%20%2F%3ENAS%20Port-Type%3A%20Wireless%20-%20IEEE%20802.11%3CBR%20%2F%3ENAS%20Port%3A%201%3C%2FP%3E%3CP%3ERADIUS%20Client%3A%3CBR%20%2F%3EClient%20Friendly%20Name%3A%20SonicPoint%20HQ%201%3CBR%20%2F%3EClient%20IP%20Address%3A%20x.x.x.x%3C%2FP%3E%3CP%3EAuthentication%20Details%3A%3CBR%20%2F%3EConnection%20Request%20Policy%20Name%3A%20NAP%20802.1X%20(Wireless)%3CBR%20%2F%3ENetwork%20Policy%20Name%3A%20-%3CBR%20%2F%3EAuthentication%20Provider%3A%20Windows%3CBR%20%2F%3EAuthentication%20Server%3A%20NPS.domain.nl%3CBR%20%2F%3EAuthentication%20Type%3A%20PEAP%3CBR%20%2F%3EEAP%20Type%3A%20-%3CBR%20%2F%3EAccount%20Session%20Identifier%3A%20%22edited%22%3CBR%20%2F%3ELogging%20Results%3A%20Accounting%20information%20was%20written%20to%20the%20local%20log%20file.%3CBR%20%2F%3EReason%20Code%3A%2016%3CBR%20%2F%3EReason%3A%20Authentication%20failed%20due%20to%20a%20user%20credentials%20mismatch.%20Either%20the%20user%20name%20provided%20does%20not%20map%20to%20an%20existing%20user%20account%20or%20the%20password%20was%20incorrect.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20only%20real%20difference%20I%20see%20is%20that%20for%20the%20Windows%2011%20client%2C%20NULL%20SID%20is%20provided%20as%20%22Security%20ID%22.%20Could%20it%20be%20that%20this%20is%20causing%20NPS%20to%20not%20be%20able%20to%20verify%20that%20the%20machine%20that%20is%20attempting%20to%20connect%20is%20a%20member%20of%20the%20security%20group%20which%20is%20allowed%20to%20connect%20(the%20default%20group%20%22Domain%20Computers%22)%3F%3C%2FP%3E%3CP%3E%3CBR%20%2F%3ELooking%20forward%20to%20either%20a%20quick%20bug%20fix%20or%20a%20configuration%20change%20I%20need%20to%20make.%20Maybe%20other%20Windows%20Server%20admins%20are%20also%20experiencing%20this%20issue%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2827382%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3Ecomputer%20authentication%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3Enps%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EWindows%2011%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EWireless%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2841555%22%20slang%3D%22en-US%22%3ERe%3A%20Windows%2011%20clients%20cannot%20authenticate%20to%20NPS%20server%20using%20computer%20authentication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2841555%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F1179816%22%20target%3D%22_blank%22%3E%40PaulvDam%3C%2FA%3E%26nbsp%3BWe%20are%20also%20experiencing%20the%20same%20exact%20issue.%26nbsp%3B%20Clients%20get%20the%20certificate%20and%20will%20not%20connect%20to%20our%20NPS%20server%20to%20connect%20to%20our%20wifi.%26nbsp%3B%20Were%20you%20able%20to%20find%20a%20fix%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2841595%22%20slang%3D%22en-US%22%3ERe%3A%20Windows%2011%20clients%20cannot%20authenticate%20to%20NPS%20server%20using%20computer%20authentication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2841595%22%20slang%3D%22en-US%22%3ENot%20yet%2C%20all%20my%20hopes%20are%20resting%20on%20this%20forum%20post%20%3A)%3C%2Fimg%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2855861%22%20slang%3D%22en-US%22%3ERe%3A%20Windows%2011%20clients%20cannot%20authenticate%20to%20NPS%20server%20using%20computer%20authentication%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2855861%22%20slang%3D%22en-US%22%3EHad%20this%20with%20802.1x%20and%20AlwaysOn%20VPN.%20Maybe%20it's%20the%20same%20for%20your%20Wifi%20profile%2C.%20The%20reason%20is%20documented%20here%20%3CA%20href%3D%22https%3A%2F%2Fdirectaccess.richardhicks.com%2F2021%2F09%2F23%2Falways-on-vpn-error-853-on-windows-11%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdirectaccess.richardhicks.com%2F2021%2F09%2F23%2Falways-on-vpn-error-853-on-windows-11%2F%3C%2FA%3E%3C%2FLINGO-BODY%3E
New Contributor

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?

6 Replies

@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?

 

 

Not yet, all my hopes are resting on this forum post :)
best response confirmed by PaulvDam (New Contributor)
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/

@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.

@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

@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!