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_with_WPA2-Enterprise   --sk ... View more

We didn't experiment with changing client assignment, so I don't know.   FWIW:  we replicated the same issue (MR32 quits forwarding ARP frames) for clients connecting at 2.4GHz ... we resolved this by disabling 2.4GHz network-wide   --sk ... View more

Or syslog   I have now scribbled together a reporting tool which counts which users connect on which bands (i.e.2.4 and 5)   In my tiny environment (~700+ users in 2021) - 32 have only associated at 2.4GHz - 272 have only associated at 5GHz -~400+ have associated at both 2.4 and 5GHz   Poking deeper at the 32 who have only ever associated at 2.4GHz ... only a single device has not only *associated* but has also *authenticated* ... and that device belongs to someone who left the company early this year ... the rest seem to be just devices that 'passed through' our building, without a need (or at least an attempt) to authenticate   Sounds like it is time to disable 2.4GHz   Thank you for pointing me in this direction!   --sk ... View more

I have a flock of ~150 MR32 & MR33 contained in a single building.  I have documented the issue with (3) clients: - OS X laptop - NetAlly EtherScope NG - NetAlly AirCheck2   I have anecdotal evidence of other clients being affected as well, but no pcaps to support these claims   I have built up a library of simultaneous pcaps captured in the air next to the Client, at the WiFi side of the MR32, and at the Wired side of the MR32 ... showing what you report, i.e. that the DHCP frame gets dropped at the MR32.  We have also tried statically assigning an IP address to the Client; at that point, we see ICMP Echos also dropped at the MR32 ... which suggests to us that when the MR32 has entered this state, it drops all WiFi-side IP frames   We have tried and failed to replicate the problem as follows: (a) At 5GHz with the MR32 (b) At 2.4GHz with the MR33   OK, so your experience suggests a more narrow fingerprint than mine.  But useful to me to know that at least one other customer has seen a variation on this issue -- thank you   --sk   ... View more

Good point, 'on the wire' is not correct -- I have edit my post above to replace 'on the wire' with 'on the air'   But wait a minute, are you saying that you can search the Access Points page for a BSSID and get a hit?  I have been unsuccessful in doing that ... but I'll try more times, if you tell me that you are successful.  [We have <200 APs ..]   --sk ... View more

wrt to traffic shaping -- now that's an idea.  In some ways, 'ip dhcp snooping limit rate 25' is a form of traffic shaping, however crude:  allows a given AP (or, more precisely, the clients behind it) to emit no more than 25 DHCP Requests in a given second, and then shuts them down cold.  You're suggesting a more sophisticated approach -- perhaps permit 20 DHCP Requests every second forever, as an example.   Thank you -- I hadn't thought of that ... View more