FWIW- I could not get this setup to work with a Thawte issued Wildcard certificate, so we ended up using an internal certificate from a AD integrated CA and just deal with the trust / validation warnings on Macs and Android devices.    Windows clients authenticate fine, since they have the GPO that forces the specific internal CA to be trusted for the wireless profile assigned to the SSID.   I'd LOVE to know how a public cert can be used in this situation properly, but i am not sure if it is possible with NPS. ... View more

Strange that there is no 802.11r options in your Dashboard. I'm not sure how Meraki includes / excludes features (AP type? Licensing?). Like I said, this was the fix for us.   I'm looking at your NPS logs and its definitely trying to authenticate a computer account (as opposed to a user security group), is this by design? You will need to have a matching NPS policy which allows the AD computer group(s) under NPS > Policies > Network Policies > (policy name) > Properties > "Conditions" Tab. I didn't realize that you can have Dial-in properties on computer accounts too. I suspect that this is also set to "Control access through NPS Network Policy".   It may be necessary to create a GPO as outlined here: https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise#(Optional)_Deploy_a_PEAP_Wireless_Profile_using_Group_Policy   In order for these machine accounts to manually trust your Active Directory root and intermediate CAs and boot up with the correct wireless profile with SSID configured, etc.   Are you applying a GPO like this to the OU that contains the computer accounts that are trying to connect? ... View more

ElectroDan-   Interesting to read your post, i'm in pretty much the same boat. So I can sympathize with your struggles, I'm dealing with almost the same thing. One thing I wanted to mention is to be sure that your NPS Network Policy is configured per the Meraki Documentation for 802.1X authentication (in addition to having your RADIUS Clients portion configured) since I found it needed both in order to test from the Meraki Dashboard. Check the following:   - The right certificate is selected under the NPS Policy > Constraints Tab > Microsoft: Protected EAP (PEAP) options > Edit Protected PEAP Properties - The "Conditions" allow the proper AD user groups to authenticate ex: DOMAIN\Domain Users   So, i've gone through much of what you've already outlined and get the same interesting behavior. Macs and Apple IOS devices can successfully authenticate against AD using RADIUS, but only after they "Trust" the AD CS certificate used on our Domain.    Our workstation environment consists of almost exclusively Windows 10 PC's and they all seem to do the same thing when a user tries to connect to wifi in the building:   1) Get prompted to authenticate (check "use my windows user account" or manually type in AD creds) 2) Windows prompts about the certificate. The thumbprint matches a cert issued by a trusted AD intermediate CA, user accepts 3) Immediately get a prompt "Can't connect to this network"   NPS doesn't give any useful output, and I know its validating accounts since iPhones and Mac OSX computers are able to get onto the wireless network.   There are never any reject or denied message in NPS logging (see below)   Network Policy Server granted access to a user. User: Security ID: DOMAIN\user.name Account Name: user.name Account Domain: DOMAIN Fully Qualified Account Name: DOMAIN\user.name Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - Called Station Identifier: E2-CB-AC-B5-5B-0A:SSID NAME Calling Station Identifier: 80-B0-3D-7F-EA-EA NAS: NAS IPv4 Address: 10.2.X.X NAS IPv6 Address: - NAS Identifier: 0bb3dca34b449637d61c5e0a6f2590af2dc7d2e9eff19b8a NAS Port-Type: Wireless - IEEE 802.11 NAS Port: 1 RADIUS Client: Client Friendly Name: Meraki APs Client IP Address: 10.2.X.X Authentication Details: Connection Request Policy Name: Meraki Network Policy Name: Meraki Authentication Provider: Windows Authentication Server: DOMAINDC01.domain.local Authentication Type: PEAP EAP Type: Microsoft: Secured password (EAP-MSCHAP v2) Account Session Identifier: 46353632394546364635453539383730 Logging Results: Accounting information was written to the local log file. I'm at a loss. I think this is a certificate issue on the windows end stations, but i am not sure how to fix this. I'd like to avoid having to push out a GPO to get this going. We have a large traveling workforce that doesn't always get GPO updates in a timely manner because they are off the domain most of the time.   UPDATE: I was able to get this resolved / working. Make sure that Wireless > Access Control > 802.11r is set to "Adaptive" (not Enabled). I think at one point we had turned this on. The tooltip description of what 802.11r made me think it only applied to old systems, not the Windows 10 computers we were having problems with.   802.11r technology reduces overhead when a client roams from one AP to another, delivering a more seamless transition. "Enabled" will activate 802.11r for devices that support it, though some legacy clients may not be able to join the network. "Adaptive" enables a custom version of 802.11r just for Apple iOS devices. Very few devices will have compatibility challenges with the "Adaptive" mode.   The description is misleading in that I didn't think it applied to our Windows 10 systems since they're not really legacy devices, yet. 😉 ... View more