NPS Authentication and WPA3

Solved
The_Roo
Getting noticed

NPS Authentication and WPA3

I'm setting up a new Wi-Fi network with RADIUS authentication. It will have 20 Meraki CW9166I APs installed on an existing Cisco switch network, with known good DHCP and DNS services. There is already an NPS in place, and having entered the NPS address  and credentials into the AP, the RADIUS test provide by the AP communicate with it correctly.

 

When used by authenticators other than the Meraki AP, the NPS authenticates known PC clients and allows them onto the network, but when the Meraki uses the NPS, I get this in the log:

The_Roo_0-1688113676757.png

Now this is a Wi-Fi 6-capable AP but there is a statement on the dashboard: "This SSID will not broadcast on the 6 GHz band. Use WPA3 to enable this band." During limited testing time, I set the AP to use WPA3, but I'm concerned that the issues I'm seeing are due to the Authentication conversation being trashed because the AP wants WPA3 and the PC is using WPA2.

 

This would be made clearer if there was a document that covered the latest APs....the most recent document I have found is

 

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

 

which only talks about WPA2....is there a more recent document that covers the latest APs and encryption?

 

Thanks

 

Roo

 

1 Accepted Solution
KarstenI
Kind of a big deal
Kind of a big deal

In this context ...

 
 

FyHkjJPaUAErTRx.jpeg

View solution in original post

16 Replies 16
ChristophJ
Here to help

802.1x hasn't changed in WPA3, except if you use WPA3 192bit. This one needs different cipher suites on the RADIUS server and only uses EAP.

https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/WPA3_Encryption_and_Configuratio...

Do you have any logs on the NPS side that show the authentication failing? That might shed some more lights on why it's not working.

KarstenI
Kind of a big deal
Kind of a big deal

There is one more little thing to consider. MFP (Management Frame Protection) is mandatory in WPA3. But if the client supports WPA3 it obviously also supports MFP.

GIdenJoe
Kind of a big deal
Kind of a big deal

PMF not supported would preclude a client from even associating.
Since the beacons and probe responses will only have the WPA3 RSN info the client should not even attempt association in that case.

KarstenI
Kind of a big deal
Kind of a big deal

That is what I was saying. It was mainly about that there is no difference.

I'm waiting for NPS logs, I'll post them up when I get them

 

Roo

GreenMan
Meraki Employee
Meraki Employee

Does anyone know if NPS even supports WPA3?   I haven't been able to find out (albeit I've not had masses of time to look).   My experience with NPS in recent years is that MS don't seem to have done much development with it (?)   Do the other NADs you mention successfully connect clients using WPA3 authenticated by NPS - or is WPA3 only configured on your Meraki SSIDs??

PhilipDAth
Kind of a big deal
Kind of a big deal

I don't think the RADIUS exchange should be affected.

 

My own personal experience - I have not been able to use WPA3 because of poor driver compatibility.  Whenever I have tried it, lots of devices can't connect.  I've given up trying to use it now.  Perhaps in a couple of years drivers will get better.

This discussion is helping me to crystalise my thoughts about this, and I believe Philip's point above is right.....the log from the AP shows an authentication attempt, so the supplicant is able to talk to the AP (authenticator) OK.

That exchange is the only one protected by WPA3, the conversation between authenticator and the NPS is carried out using EAP, not WPA3.

 

No, it looks now like the conversation between the AP and NPS is where the problem lays, so I'm going to do as I suggested above and get an NPS log, and hopefully sort out what is going on.

 

Keep the thoughts and suggestions coming, guys, this has been a real useful session!

 

Roo

KarstenI
Kind of a big deal
Kind of a big deal

The NPS has the worst log of any software system on the planet. But if you show us a RADIUS capture between the AP and the NPS, it's likely to see some problem areas.

GIdenJoe
Kind of a big deal
Kind of a big deal

WPA3 is between the supplicant and the authenticator, not the authentication server.
Between the AP and NPS you will only have radius exchanges.

 

It would help if you could get the logs but also get the wired packet captures between the AP and the NPS server so you can determine EAP type, username, called station id, etc etc.  Just to see if you're even matching the access rules.  Also see what ciphers the supplicant to use towards the NPS server for the TLS session and if the NPS server supports it.

Here's what I got from the NPS, I've redacted in a fairly obvious way after the raw log went through https://iso.csusb.edu/tools/nps-log-interpreter

----------------------------------------------
NAS IP: "1SR-DC-01"
Client Username: "IAS"
Timestamp: 06/29/2023 12:35:22
Service: 1
RADIUS Server: "host/8203X.redacted.local"
"redacted.local/Hardware/Laptops/Technology/8203X": "Aruba MAC Address redacted"

(Note: incumbent wireless is Aruba, being replaced by Meraki)
"Intel MAC Address redacted":
: "192.168.110.2"
"192.168.110.2": 0
0: "192.168.110.2"
"wlan controller":
: 19
:
2: 5
"Secure Wireless Connections": 0
"311 1 192.168.30.210 06/03/2023 13:59:54 190290":
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
"Secure Wireless Connections": 1
:
:
--------------------------------------------

NAS IP: "1SR-DC-01"
Client Username: "IAS"
Timestamp: 06/29/2023 12:35:22
Service: 11
RADIUS Server:
"redacted.local/Hardware/Laptops/Technology/8203X":
:
:
:
0: "192.168.110.2"
"wlan controller":
:
:
: 5
"Secure Wireless Connections": 0
"311 1 192.168.30.210 06/03/2023 13:59:54 190290": 30
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
"Secure Wireless Connections": 1
:
:
--------------------------------------------
Several iterations of the sequence above, followed by several sequences of the below:
------------------------------------------------
NAS IP: "1SR-DC-01"
Client Username: "IAS"
Timestamp: 06/29/2023 12:33:20
Service: 1
RADIUS Server: "host/8203X.redacted.local"
"redacted.local/Hardware/Laptops/Technology/8203X": "Redacted Meraki AP MAC:redacted Meraki SSID"
"Redacted Intel MAC Address":
: "Redacted Meraki AP MAC:vap1"
"Redacted Meraki IP Address": 1
0: "Redacted Meraki IP Address"
"Meraki AP's":
: 19
"CONNECT 54.00 Mbps / 802.11ax / RSSI: 47 / Channel: 44":
2: 11
"Secure Wireless Connections": 0
"311 1 redacted-radius-server-ip 06/03/2023 13:59:54 190230":
:
:
:
: "CA3866B9CE2BA82A"
:
:
: "D5B99E420436E168"
:
:
:
:
:
:
:
:
:
"Secure Wireless Connections": 1
:
:
--------------------------------------------

NAS IP: "1SR-DC-01"
Client Username: "IAS"
Timestamp: 06/29/2023 12:33:20
Service: 3
RADIUS Server:
"redacted.local/Hardware/Laptops/Technology/8203X":
:
:
:
0: "redacted-radius-server-ip"
"Meraki AP's":
:
:
: 11
"Secure Wireless Connections": 16
"311 1 redacted-radius-server-ip 06/03/2023 13:59:54 190230":
:
:
:
: "CA3866B9CE2BA82A"
:
:
:
:
:
:
:
:
:
:
:
:
"Secure Wireless Connections": 1
:
:
--------------------------------------------

Can you also check the event log for the NPS and send the screenshots of the logged requests?
You can find it in "Eventviewer -> Custom Views -> Server roles -> Network Policy and Access Services"

The logs should look like this:

ChristophJ_0-1688391857099.png

(The picture is just an example I pulled from Google)

 

It should also display why the authentication to the NPS failed when you scroll down further.

GIdenJoe
Kind of a big deal
Kind of a big deal

Yeah the redacted log is not much help 😉
You'll have to see if it has an acces-accept with certain AV-pairs or access-reject with a reason.
Usually you don't match a rule in your policy.

But it can be different like some failure to start the exchange.

A pcap on the wired port of the AP can also be helpful.  You can filter on port 1812.

The_Roo
Getting noticed

Well, that was a bit of a let-down. I had a debug session with the guy running the NPS. He made some changes which involved removal of the group policy and reinstatement and the whole thing burst into life (with Wi-Fi 6 and WPA3 disabled). So I then re-enabled WPA3 and Wi-Fi 6 and he again removed/reinstated the group policy and that worked too.

 

I was remote from him, so I'm still not sure what he did to the NPS, but the biggest clue was that when he looked in the event log of the NPS server, he said there were no alarms showing, so the EAP failures the Meraki was showing were probably down to the fact that the NPS was just ignoring the AP messages and the AP was timing out.

 

Once the Group Policy was sorted it was all OK, so it looks like the Meraki side was OK all along. It also shows that you can run WPA3 with NPS even though NPS only references WPA2.

 

Bit of a wild goose chase, guys, sorry to waste your time but for what its worth, I learnt a bit about WPA3 and Wi-Fi 6

 

Thanks for all your  help

 

Roo

KarstenI
Kind of a big deal
Kind of a big deal

In this context ...

 
 

FyHkjJPaUAErTRx.jpeg

Dude, I am SO with you on that one....been playing ISE since v1.3 (yes I am OLD) and it's a far superior system!

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels