Network Policy Server on Windows Server 2022 and Meraki MR authentication

skendric
Getting noticed

Network Policy Server on Windows Server 2022 and Meraki MR authentication

We use NPS running under Windows Server 2019 to authenticate WiFi users.  We are testing NPS under Windows 2022; authentication is failing.

 

From the Windows Security logs

  • The certificate chain was issued by an authority that is not trusted
  • The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access to the user. To change the Network Access Permission setting to either Allow access or Control access through NPS Network Policy, obtain the properties of the user account in Active Directory Users and Computers, click the Dial-in tab, and change Network Access Permission.

 

  • A pcap from a Windows laptop shows Access-Requests, Access-Challenges, and (unsurprisingly) a final Access-Reject

 

Anyone know what has changed in 2022?

 

--sk

2 Replies 2
Brash
Kind of a big deal
Kind of a big deal

I'm not aware of any major braking changes to NPS between the two versions.

 

Are your policies identical?

Are both servers using the same CA's/certificate chain?

Does the 2022 NPS server have the root certs stored in its certificate store?

Is the cert showing in the NT Auth store?

 - From memory this command should provide the output: "certutil -verifystore -enterprise NTAuth"

 

skendric
Getting noticed

OK, turns out I had forgotten to "Register server in Active Directory" ... so I have gotten past the above potholes now


However, authentication still fails. And I have replicated the issue on a fully-patched Windows 2019 Server, so this isn't just a Win2022 issue


EVENT LOGS
Network Policy Server discarded the request for a user.

[...]

Authentication Details:
Connection Request Policy Name: SciNet-WiFi
Network Policy Name: SciNet-WiFi-Policy
Authentication Provider: Windows
Authentication Server: nps-test-wifi-2019.{company.com}
Authentication Type: PEAP
EAP Type: -
Account Session Identifier: 41424331464242453635453438434146
Reason Code: 1
Reason: An internal error occurred. Check the system event log for additional information.


Compare to a successful authentication (taken from the production NPS server)
[...]
Authentication Details:
Connection Request Policy Name: SciNet-WiFi
Network Policy Name: SciNet-WiFi-Policy
Authentication Provider: Windows
Authentication Server: nps-prod-1.{company.com}
Authentication Type: PEAP
EAP Type: Microsoft: Secured password (EAP-MSCHAP v2)
Account Session Identifier: 39423242324642444345394132443636
Logging Results: Accounting information was written to the local log file.



PCAPs
- For a successful authentication against the production NPS server, I see the MR44 proposing TLS v1.0 (instead the EAP authenticatin), which eventually succeeds (Access-Accept). For the failed authentication against the test NPS server, I see the MR44 proposing TLS v1.2 (? -- I don't see TLS version as a configureable option in the Meraki Dashboard ... how does this happen?), and eventually, the NPS server quits responding at the end of the EAP noegitation ... until finally the MR44 starts the process over

==> How does one instruct Meraki to use TLS v1.0 vs 1.2 in EAP negotiations between Authenticator and Authentication Server (NPS)?
https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_...

 

--sk

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels