17 Tips For Windows 7 (and Some fun)
Landers Hoang
I have Accounting enabled on the Windows Server (which is now a DC running Server 2016. I had been running 2012 R2 but decided to wipe it and install 2016 afresh as though maybe RADIUS worked better!). The NPS Account log shows this when I click the Test button:
I joined this forum purely to post this reply, hopefully it helps your case. I was dealing with this problem today, and got to the point where I had the exact same issue above. My Windows 10 wifi would not authenticate, but my iPhone wifi would authenticate and work fine with the username and password once you trust a cert.
I solved this on my Windows 10 machine by connecting to the SSID, and not ticking "use my Windows user account" at the prompt, and instead I typed in my username and password without the domain prefix. A new message will appear asking you to confirm the expected domain it found, then it connects. Who knew.
Yes, I have a certificate selected in NPS > Network Policies > My Meraki Policy > Constraints > Auth Methods > Microsoft PEAP > (Edit), issued by the server I installed the CA role on. I suspect it could be failing to do with this? I think at some point I created a Group Policy to deploy that certificate to client PC's, perhaps something is amiss with that but I can't seem to get enough info from any logs.
Thanks, I did come across that thread previously (with all the Spanish screenshots!) but I think I need to get the Test button working from the Meraki dashboard > Access Control for SSID first, before I then troubleshoot client PC's, would you agree?
Okay I'll give it a go. Our clients are all Windows 10. At the moment when I try to connect to the Radius SSID it prompts me for credentials, with a tickbox to 'use my Windows user account', which if I tick fills in the boxes with my AD credentials. It check network requirements after clicking OK, but the credentials prompt just comes back again.
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:
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.
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.
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.
I was really hopeful with your suggestion on 802.11r, however I don't seem to have an 802.11r section in my dashboard! Searching for it just takes me to the Access Control page but the nearest thing to that on the page is 802.11w.
I've opened my AD user properties, navigated to the Dial-in tab, changed Network Access Permission to 'Control access through NPS Network Policy', then rebooted my laptop but no joy. I then changed it to 'Allow access' but still no joy. I made these changes on my local domain controller, but I'll try again in an hour or so in case it's referring to another DC for some reason.
With my user profile in AD set to 'Allow access' under the Dial-in tab, and the computer account having always been set to 'Control access through NPS Network Policy', I now see in Event Viewer on the NPS server:
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.
Note that when using conditions in NPS that all conditions have to be true. So when you want to match on Windows Groups (and assuming whatever needs access is not in both groups) you have to put both of those groups into a single condition.
If I change it to an OR condition, which I have previously tried, and set the condition to Windows Groups, when attempting to connect it just hangs on 'Verifying and connecting' on the laptop for a minute or so, then eventually ask for credentials. I tick the box for 'Use my Windows user account' and click OK, it checks for network requirements, then prompts for credentials again, and at no stage does anything get logged in the NPS event log.
Consequently if you create an NPS policy and list each as seperate conditions it can never match, as the user will never be in the "Meraki Staff Group" AND the "Meraki Computer Group" at the same time.
Next you said there was a big delay when you had this configuration. This is another seperate problem. Is the CA certificate that issued the certificate being used for the PEAP authentication in NPS trusted by the clients as a root authority? Also this certificate can not be self-signed.
If both of these certificate requirements are not met the Windows workstations will not allow the authentication to succeed. Note it is the workstation and not the NPS server refusing it in this case.
I changed the condition in the network policy to only check for the Meraki Staff Group, and attempted to reconnect. I was then prompted whether to use Windows Credentials, so ticked the box again and clicked OK. It failed to connect.
I would've thought the EAP information should show some values? Either way, I'm going to change it to an OR statement for the Network Policy by removing the User Group condition and adding the 2 security groups as Windows Groups on the same line, then retest.
I also deployed a GPO to set a PEAP Wireless Profile on the laptop (using machine authentication as per the "(Optional) Deploy a PEAP Wireless Profile using Group Policy" section in the Meraki guide), which I can see is applied to the laptop after I do a gpupdate, but when attempting to connect it just tries and tries but logs no errors.
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.
Just another suggestion to check - which I'm not sure will be relevant or not, but might be worth checking. Does the Connection Request Policy you are hitting also have EAP selected as an Authentication method? If the Connection Request Policy doesn't have EAP specifically selected as an Authentication Method then the type of EAP isn't passed through to the Network Policy, and so this can cause the unknown EAP type error.
In the Meraki dashboard I can now get the Test function to work from the Radius servers section for my SSID. How? Well, a while back we set a group policy to disable TLS 1.0 and 1.1. Seems this was breaking Meraki.
Thank you. I probably ran into this the last time I set up NPS, but it's been so long, I forgot this time around.
The other issue I was seeing was on Server 2019. Windows Firewall had created rules for UDP_1812 when I installed NPS, but a look at the logs and UDP_1812 was being dropped. I had to run sc sidtype IAS unrestricted at a Command Prompt (not PowerShell). This is a known issue.
Just to check a couple of things that I've come across in the past... (although admittedly this was on a Windows Server 2012 R2 server). Make sure that the the 'Extensible Authentication Protocol' service on the Windows Server running NPS is not disabled (it should be set to Manual), and make sure that you have registered the NPS server with Active Directory. Both of these can prevent EAP with user credentials working.
haha! glad it worked for you. I'm actually not even using Meraki gear (we are on Ubiquiti) but the setup for radius auth is nearly identical. I used this forum for lots of reference getting it working, so I thought sharing my resolution is good karma
I just had to through this issue myself, turns out, when you install AD CA role on the server, NPS server will automagically decide I don't like the previous cert, let's use the wildcard you've just added to your CA role. Problem is, I not only don't distribute that cert yet but prefer uncerted selfsigned cert for now.
Thank you so much Berlin_IT_Guy. That fixed our problem. I did not call Meraki to change the MTU. I added the Frame-MTU attribute on the NPS server under the settings tab of our network policy and set it to 1344. I'll adjust that later but our wireless network is finally up. Thank you!
7fc3f7cf58