802.1X EAP failure with Windows AD Radius - Help!

[ElectroDan]

Okay so I've spent several DAYS on this and seem to be getting nowhere 😕 I'm starting to get fairly frustrated having followed numerous guides exactly.

I used this to setup the Meraki side:

https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_...

This is the latest guide I followed:

http://www.cracknells.co.uk/servers-side/configuring-radius-authentication-for-a-wireless-network-80...

No matter what I try though, I can't get my phone or laptop to connect, nor get the Test function to succeed from the SSID > Radius Servers section.

When I click Test, I get:
Total APs: 14
APs failed: 14

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:

<Event><Timestamp data_type="4">11/15/2018 14:15:21.607</Timestamp><Computer-Name data_type="1">MY-DC03</Computer-Name><Event-Source data_type="1">IAS</Event-Source><Class data_type="1">311 1 10.33.102.23 11/15/2018 13:06:56 231</Class><Client-IP-Address data_type="3">10.32.108.21</Client-IP-Address><Client-Vendor data_type="0">0</Client-Vendor><Client-Friendly-Name data_type="1">Meraki - AP1</Client-Friendly-Name><Session-Timeout data_type="0">30</Session-Timeout><Proxy-Policy-Name data_type="1">Meraki Staff Secure Wireless Connections</Proxy-Policy-Name><Provider-Type data_type="0">1</Provider-Type><SAM-Account-Name data_type="1">MYDOMAIN\JohnDoe</SAM-Account-Name><Fully-Qualifed-User-Name data_type="1">MYDOMAIN\JohnDoe</Fully-Qualifed-User-Name><Authentication-Type data_type="0">5</Authentication-Type><NP-Policy-Name data_type="1">Meraki Staff Secure Wireless Connections</NP-Policy-Name><Packet-Type data_type="0">11</Packet-Type><Reason-Code data_type="0">0</Reason-Code></Event>

I get pretty much the same error logged when trying to connect from my laptop. I also see this in the Meraki event log:

Nov 15 14:24:57	Purchasing	Radius_Test	ITSPARE01	802.11 association	channel: 40, rssi: 29
Nov 15 14:24:57	Purchasing	Radius_Test	ITSPARE01	802.11 disassociation	unknown reason
Nov 15 14:24:57	Purchasing	Radius_Test	ITSPARE01	802.1X deauthentication	radio: 1, vap: 4, client_mac: 84:3A:4B:56:F4:5C  more »
Nov 15 14:24:48	Purchasing	Radius_Test	ITSPARE01	802.1X deauthentication	radio: 1, vap: 4, client_mac: 84:3A:4B:56:F4:5C  more »
Nov 15 14:24:48	Purchasing	Radius_Test	ITSPARE01	802.11 association	channel: 40, rssi: 28
Nov 15 14:24:47	Purchasing	Radius_Test	ITSPARE01	802.11 disassociation	unspecified reason
Nov 15 14:24:47	Purchasing	Radius_Test	ITSPARE01	802.1X deauthentication	radio: 1, vap: 4, client_mac: 84:3A:4B:56:F4:5C  more »
Nov 15 14:24:47	Purchasing	Radius_Test	ITSPARE01	802.1X EAP failure	radio: 1, vap: 4, client_mac: 84:3A:4B:56:F4:5C  more »
Nov 15 14:24:47	Purchasing	Radius_Test	ITSPARE01	802.1X deauthentication	radio: 1, vap: 4, client_mac: 84:3A:4B:56:F4:5C  more »
Nov 15 14:24:47	Purchasing	Radius_Test	ITSPARE01	802.11 association	channel: 40, rssi: 29

Any ideas?

[kYutobi]

Hello Dan,

Did you add the AP's to the RADIUS clients? They need to be added so that RADIUS can work.

[ElectroDan]

Yes, all of my Meraki AP's were added with their IP addresses. I created a Shared Secret template first, which I applied to all APs when adding them as RADIUS Clients.

[kYutobi]

Does NPS server have a certificate installed & configured in the NPS policy? I'm just making sure I get all the common denominators as I ask you this by the way.

[ElectroDan]

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.

[kYutobi]

Check on this thread please and see if the problem might be there:

https://community.meraki.com/t5/Wireless-LAN/authentication-fails-in-windows-7-with-802-1X-with-Mera...

[ElectroDan]

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?

[NolanHerring]

I'm torn because I've seen instances where the AP fails that test, but radius still works. So at this point I would say try it and ignore those test results and see what happens.

[ElectroDan]

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.

[aekinaka]

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. 😉

[ElectroDan]

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.

[ElectroDan]

Okay, so working through the Event Viewer Security log, seems my user account is blocked from dial-in in my AD user properties. I don't recall this being mention in ANY of the guides I've read?!

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.

[ElectroDan]

Have gotten a bit further.

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:

Network Policy Server denied access to a user.

Reason Code: 66
Reason: The user attempted to use an authentication method that is not enabled on the matching network policy.

[ElectroDan]

I've now found out that if I remove the Machine Group from NPS > Policies > Network Policies > MyPolicy > Conditions, I don't get anything logged in the Security Event Log.

Once I add that back in, I see log entries again.

Still failing though with:

Reason Code: 66
Reason: The user attempted to use an authentication method that is not enabled on the matching network policy.

[aekinaka]

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_...

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?

[ElectroDan]

I'm back on this now Christmas is out of the way 🙂

I had some default policies still enabled on my 2016 NPS Server, which I've disabled. They were:

Connection Request Policies > Use Windows authentication for all users.

Network Policies > Connections to other access servers.

Network Policies > Connections to Microsoft Routing and Remote Access server.

With those 3 disabled, I'm no longer getting the following Information level event logged in Event Viewer:

Reason code: 66

Reason: The user attempted to use an authentication method that is not enabled on the matching network policy.

Instead, I am now getting:

Reason code: 48

Reason: The connection request did not match any configured network policy.

I have 3 conditions set for the Staff WiFi Network Policy:

Condition: NAS Port Type, Value: Wireless - IEEE 802.11 OR Wireless - Other

Condition: User Groups, Value: MYDOMAIN\Meraki Staff Group

Condition: Machine Groups, Value: MYDOMAIN\Meraki Computer Group

The laptop I'm testing on is a member of the Meraki Computer Group, and the user account I'm logged on with belongs to the Meraki Staff Group.

I get a 'Reason Code: 48' event logged twice each time I try to connect; first for the user, then 10 seconds later for the machine:

-------------------------------------------------------------------------------------------------------------

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
     Security ID: MYDOMAIN\ElectroDan
     Account Name: MYDOMAIN\ElectroDan
     Account Domain: MYDOMAIN
     Fully Qualified Account Name: MYDOMAIN\ElectroDan

Client Machine:
     Security ID: NULL SID
     Account Name: -
     Fully Qualified Account Name: -
     Called Station Identifier: 9A-15-54-AB-52-67:Radius_Test
     Calling Station Identifier: 84-3A-4B-56-F4-5C

NAS:
     NAS IPv4 Address: 10.99.108.26
     NAS IPv6 Address: -
     NAS Identifier: -
     NAS Port-Type: Wireless - IEEE 802.11
     NAS Port: -

RADIUS Client:
     Client Friendly Name: Meraki - Purchasing
     Client IP Address: 10.99.108.26

Authentication Details:
     Connection Request Policy Name: WiFi_Staff
     Network Policy Name: -
     Authentication Provider: Windows
     Authentication Server: DC03.mydomain.local
     Authentication Type: EAP
     EAP Type: -
     Account Session Identifier: 41413346334133424138354636383335
     Logging Results: Accounting information was written to the local log file.
     Reason Code: 48
     Reason: The connection request did not match any configured network policy.

-------------------------------------------------------------------------------------------------------------

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
     Security ID: MYDOMAIN\ITSPARE01$
     Account Name: host/ITSPARE01.mydomain.local
     Account Domain: MYDOMAIN
     Fully Qualified Account Name: MYDOMAIN\ITSPARE01$

Client Machine:
     Security ID: NULL SID
     Account Name: -
     Fully Qualified Account Name: -
     Called Station Identifier: 9A-15-54-AB-56-2D:Radius_Test
     Calling Station Identifier: 84-3A-4B-56-F4-5C

NAS:
     NAS IPv4 Address: 10.99.108.25
     NAS IPv6 Address: -
     NAS Identifier: -
     NAS Port-Type: Wireless - IEEE 802.11
     NAS Port: -

RADIUS Client:
     Client Friendly Name: Meraki - Accounts
     Client IP Address: 10.99.108.25

Authentication Details:
     Connection Request Policy Name: WiFi_Staff
     Network Policy Name: -
     Authentication Provider: Windows
     Authentication Server: DC03.mydomain.local
     Authentication Type: EAP
     EAP Type: -
     Account Session Identifier: 41433342464337434233394535444334
     Logging Results: Accounting information was written to the local log file.
     Reason Code: 48
     Reason: The connection request did not match any configured network policy.

-------------------------------------------------------------------------------------------------------------

A couple of things I've noticed.

1) The machine account (MYDOMAIN\ITSPARE01$) is being listed in the User section, and the Client Machine section is empty.

2) The 2nd entry (for MYDOMAIN\ITSPARE01$) is registering via a different AP (Meraki - Accounts). Both AP's are within range of my test laptop.

Fun.

Not.

[PhilipDAth]

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.

So make sure:

Condition: User Groups, Value: MYDOMAIN\Meraki Staff Group

Condition: Machine Groups, Value: MYDOMAIN\Meraki Computer Group

Is actually a single conditon containing both groups (which makes it an OR).

[ElectroDan]

Hi Philip,

I can confirm that all of those conditions should match, as the user account is in the MYDOMAIN\Meraki Staff Group, and the laptop in the MYDOMAIN\Meraki Computer Group.

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.

If I take out the Meraki Computer Group condition, leaving just the NAS Port Type and User Groups conditions, again nothing gets logged and I'm repeatedly prompted for credentials.

If I remove the Meraki Computer Group condition and re-add the Meraki User Group condition, I get a Reason Code 48 logged, referencing the user account I'm testing with.

So I can't even connect with less security. Ultimately I want the AND condition to work, as I only want to allow company-issued computers that a domain user is logged onto, to connect.

[PhilipDAth]

>I can confirm that all of those conditions should match, as the user account is in the MYDOMAIN\Meraki Staff Group, and the laptop in the MYDOMAIN\Meraki Computer Group.

Negative, you missed the point.  A user account is only a member of the "Meraki Staff Group".  It is not a member of the "Meraki Computer Group".

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.

So put both groups in the same condition to convert it to an OR criteria.

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.

You need to check the event log on both the NPS server and the workstation to see which one is not happy.

[PhilipDAth]

>So I can't even connect with less security. Ultimately I want the AND condition to work, as I only want to allow company-issued computers that a domain user is logged onto, to connect.

Microsoft NPS server does not support this.  You would need to use a more advanced RADIUS server such as Cisco ISE.

[ElectroDan]

Thanks Philip, some good suggestions there.

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.

Checking the NPS server, I see 2 entries:

1)

User:

     Security ID: MYDOMAIN\ITSPARE01$

Authentication Details:

     Reason Code: 48

     Reason: The connection request did not match any configured network policy.

2)

User:

     Security ID: MYDOMAIN\ElectroDan

Authentication Details:

     Reason Code: 22

     Reason: The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.

Looking in the WLAN-AutoConfig event log on the laptop, I see several errors:

1)

Wireless 802.1x authentication failed.

Identity: host/ITSPARE01.mydomain.local

User: 

Reason: Explicit Eap failure received

Error: 0x40420016

EAP Root cause String: Network authentication failed\nWindows doesn't have the required authentication method to connect to this network.

2)

Wireless 802.1x authentication failed.

Identity: ElectroDan@mydomain.com

User: ElectroDan

Reason: Explicit Eap failure received

Error: 0x40420016

EAP Root cause String: Network authentication failed\nWindows doesn't have the required authentication method to connect to this network.

A couple of the other Information type event log entries show the Encryption for the RADIUS_Test network as AES-CCMP and the EAP Information: Type: 0, Vendor ID 0, Vendor Type 0, Author ID 0

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.

[ElectroDan]

I changed it to the OR statement, still no joy!

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.

Is there an absolute minimum configuration I can go with to try to connect, and then add security layers on top to get to where it should be?

[PhilipDAth]

Does the NPS event viewer show that it is now granting the user/machine access?

The certificate being used for PEAP on your NPS server - where did that come from? Your own CA?

[PhilipDAth]

I just spotted your other message;

>Windows doesn't have the required authentication method to connect to this network.

This is good, we are getting close.  In NPS you should (only) have PEAP selected.  And inside of the PEAP configuration you should (only) have MSCHAPv2 selected.

[ElectroDan]

In the NPS Policy, Constraints > Authentication Methods screen, I have EAP Type: Microsoft: Protected EAP (PEAP) set, which when you edit has the Eap Type Secured Password (EAP-MSCHAP v2) set.

Back on the Authentication Methods screen I have none of the Less secure authentication methods ticked.

These should all be correct as I've verified this with several guides.

Regarding the certificate, I obtained this for the RADIUS server from SSL.com, so a trusted CA. Is there a basic test I can run to check this part is setup correctly?

[aekinaka]

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.

[Bruce]

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.

[ElectroDan]

AT LAST I've made some progress (after shelving this out of frustration for several months).

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.

After re-enabling TLS 1.0/1.1, I was able to run the Radius test successfully with all AP's passing said test using my domain credentials.

Now I just need to get my test laptop connected to the SSID using Radius.

Does anyone know if I can set the Meraki kit to use TLS 1.2?

[PhilipDAth]

>Does anyone know if I can set the Meraki kit to use TLS 1.2?

I'm not sure about this one - but this is only used by the test function.  The actual TLS session is between the WiFi device and the RADIUS server.  Those two need to be talking a compatibile protocol.

I would be aiming to only support TLS1.2 these days.

[Erin]

Thank you for posting the TLS help!  That was the whole problem for us!

[Johnny_P]

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.

[Bruce]

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.

[ElectroDan]

Hi Bruce,

I can confirm the EAP service is set to Manual, and the NPS server is registered in AD.

Thanks.

[ElectroDan]

A couple of other things I've noticed.

From this guide: https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_... I'm not able to do the following:

Disable Auto Remediation

1. Navigate to Policies>Network Policies. Right click the wireless policy and select Properties.
2. On the Setting tab for the policy uncheck the box Enable auto-remediation of client computers and click OK.

The auto-remediation option isn't there on the Settings tab and I haven't located it elsewhere.

Also, in the screenshot that outlines an example of an NPS policy, it has 2 conditions which I don't have (and can't find where I set them):

NAP Enforcement: Allow full network access

Update Noncompliant Clients: False

I'd like to add these, just in case they have an affect.

[TBHPTL]

Its under the SSID.....

[ElectroDan]

I've had a go at that, however the link for rootsupd.exe is dead. I'll need to find an alternative.

[tweedle-dumb]

This right here

"NPS > Network Policies > My Meraki Policy > Constraints > Auth Methods > Microsoft PEAP > (Edit)"

helped me solve my problem. I hadn't messed with those settings, and the wrong cert was selected. Choosing the appropriate cert fixed my connection problem immediately (so far)!

[NolanHerring]

Assuming then your access points have static IP addresses? I find its easier to simply add the /24 the AP's sit on. Also assuming the access points can reach the NPS server? Pings work etc.

[ElectroDan]

All AP's are set to DHCP but have a reservation set on the DHCP server. NPS server can ping all AP's no problem.

[PhilipDAth]

Does anything appear for NPS in the Windows Security Event log on the NPS server.  It will usually say why the request has been denied.

[ElectroDan]

Okay so the Security Event Log shows this on the NPS server. I'm guessing it's trying to authenticate the computer rather than the user?:

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
Security ID: MYDOMAIN\ITSPARE01$
Account Name: host/ITSPARE01.mydomain.local
Account Domain: MYDOMAIN
Fully Qualified Account Name: mydomain.local/Mydomain/UK/Computers/ITSPARE01

Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
Called Station Identifier: 9A-15-54-AB-52-67:Radius_Test
Calling Station Identifier: 84-3A-4B-56-F4-5C

NAS:
NAS IPv4 Address: 10.32.108.26
NAS IPv6 Address: -
NAS Identifier: -
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: -

RADIUS Client:
Client Friendly Name: Meraki - Purchasing
Client IP Address: 10.32.108.26

Authentication Details:
Connection Request Policy Name: Meraki Staff Secure Wireless Connections
Network Policy Name: Connections to other access servers
Authentication Provider: Windows
Authentication Server: DC03.mydomain.local
Authentication Type: EAP
EAP Type: -
Account Session Identifier: 33364144324231353946353331303231
Logging Results: Accounting information was written to the local log file.
Reason Code: 65
Reason: 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.

[JohnR1 · Accepted solution]

Hi there

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.

[ElectroDan]

JohnR1 - is this some kind of joke?!

I tried that and IT WORKED!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Gobsmacked. After all that effort, that was the final piece.

Thanks SO MUCH for posting that reply, I'd all but given up on getting it working!

Now Meraki just needs to fix it so you can tick the "use my Windows user account" option, and it actually connect.

Cheers again!

[JohnR1]

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 🙂

[Mizerka]

Well here goes my first reply;

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.

Anyway, 50ish borked clients, had to manually go back into NPS role and change mschap to use my selfsigned cert, gpupdate for deployed profile to update and we're back on as expected.

[UdiBurg]

But when configuring NPS radius there is no use of user name and password.

The issue is that the initial test doesn't pass.

[Berlin_IT_Guy]

Good day all,

I had a similar issue and would just like to share what resolved it for me.

After getting a radius error stating in the logs stating that "The RADIUS Request message that Network Policy Server received from the network access server was malformed."

I did a verbose packet capture and found that the packet was indeed not well formed and seems to be missing some data.

Turns out this was caused by a Bad MTU size, since my radius server sits in the cloud and is reached via VPN.

So the upstream provider used a MTU size of 1400 and Meraki MX by default uses 1500.

as you can imagine this caused some issues with the radius packets.

After logging a request for Meraki to change my MTU size to 1338, everything started working with Radius again.

Here is an article about changing the MTU size for Meraki. https://documentation.meraki.com/zGeneral_Administration/Tools_and_Troubleshooting/Troubleshooting_M...

I ran this ping to test and kept lowering the MTU until I found the correct combo that produced a successful ping response.

ping "My Radius Server" -l 1472 -f

Hope this helps someone.

[Rod_F]

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!

[sureelam]

Team,

We are experiencing a recurring problem with our NPS and Cisco Meraki MR Access Point. This issue has surfaced recently, where the AP authentication initially functions properly upon installation but stops working after 3 hours, despite no alterations to the network configuration.

The notable difference in the logs is the appearance of the user as Security ID: NULL SID (previously displayed as the username). The reason for this anomaly is identified as a malformed RADIUS Request message received by the Network Policy Server from the network access server.

Reason : The RADIUS Request message that Network Policy Server received from the network access server was malformed.

Our network setup consists solely of Meraki APs, connected in the following sequence: MR ----> Aruba Switch ----> Palo Alto Firewall ----> RADIUS via IPsec tunnel.

Looking forward to hearing from you guys soon... 

[Berlin_IT_Guy]

We had a sumular issue and it turned out to be due to MTU size. The packets would be broken up into smaller chunks that are not big enough to contain the header information in the packet required for raduis auth. The packets then arrive with only partial incomplete header information. Changing to the correct MTU fixed the issue for us. 

[mito]

Thank you for posting this! I've been fighting with this for over a week and your suggestion worked!

[PhilipDAth]

This thread is 6 years old.  It would be better if you started a new thread.

[AZR-DDespard]

Putting this here in case someone has this issue but user specific.

I was having a similar issue with Radius authentication. What I did to resolve this was narrow it down to a select group of users. Opened their AD accounts server side. On the dial-in tab, Changed the radial button under Network Access Permission to "Control access through NPS Network Policy". Applied and worked like a charm. 

[PhilipDAth]

I better way to handle this @AZR-DDespard  is in the NPS policy tick the option to ignore the dial-in properties.  They are a relic from the past.

[tyoung]

I have an update on this thread.

1. The Test button does not work with NPS.  It appears not to use PEAP and MS-CHAPv2, or maybe it is a TLS issue as described earlier.  I don't want to modify the registry and enable TLS 1.0 or 1.1.
2. The WiFi client DOES work.  So, keep that in mind when using the Test button.

[Mizerka]

No, it works just fine, been using it for several years across multiple deployments.

Make sure you set your certificate in nps policy to allow it to communicate with meraki securely, even unsigned will do. 

[Rod_F]

Thank you for the post Mizerka. I'm new to certs, our test button does not work.  How do you make the cert allow communication with Meraki securely?

[Mizerka]

you have to give it some cert, doesn't matter which one even, I still use just my nps server's self signed cert, but it NEEDS one to be able to use mschap and to authenticate correctly, recently I've installed ad ca role on my nps server which broke this and I had to recreate self signed in nps policy to get it going again.

[Rod_F]

Thank you for the reply back Mizerka.  Actually after I reduced the MTU size as indicated by Berlin_IT_Guy it not only resolved the connection problem but also fixed the Test button failing.  By the way, we did not call Meraki to change the MTU size.  Instead I changed the network policy on our NPS server on the Settings tab under Standard.  I added the Frame-MTU attribute and set it to 1344. That got everything working again.  I'll gradually increase it to see how high I can set it but so glad the wireless is working again after trying many things for several days.  Thank you all!

[WB]

Ye sorry just chipping in to say we run PEAP w/ MS-CHAPv2 and it works well for us!

[mito]

BerlinITGuy's suggestion worked.  Also crazy that this still hasn't been addressed by Cisco.