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