WPA2 RADIUS against Windows Server 2019 NPS error

[MikeN1]

I have been tasked with troubleshooting an issue where Meraki WPA2-Enterprise RADIUS authentication against a Windows Server 2019 NPS server doesn't work. 

The NPS server OS is hardened to CIS benchmarks, only TLS 1.2 is allowed and insecure cipher suites are disabled. 

It was configured as outlined in the documentation:

Configuring RADIUS Authentication with WPA2-Enterprise - Cisco Meraki

Testing Radius authentication returns the following error:

Authentication Type: PEAP
EAP Type: -
Account Session Identifier: -
Logging Results: Accounting information was written to the local log file.
Reason Code: 269
Reason: The client and server cannot communicate, because they do not possess a common algorithm.

I assume this is because perhaps Meraki requires using an insecure cipher suite.

Meraki support has refused to help saying that this is outside the scope of support, they haven't been able to tell me what level of TLS and what cipher suites are required to be supported by the RADIUS server. 

Has anyone else run in to this?

Thank You. 

[Bruce]

You mention testing RADIUS, is this using an actual client, or using the ‘test RADIUS’ button on the configuration page? I’d always try with a client to see what error you get, if any. The other part I’d double check is that your NPS policy is configured to support PEAP-MSCHAPv2.

With regards to the TLS version I can’t help there, but I was always under the impression that the TLS session was established directly between the authentication server (using the certificate installed on it) and the supplicant (the client), so the AP plays no part in it. The RADIUS messages are sent between the AP and authentication server before the TLS session is established, and then after it’s torn down to inform the AP of the outcome (accept or reject, and any AV pairs). Happy to be corrected by someone with 802.1x expertise if I’m wrong here.

[MikeN1]

In this case, the failure is when using the Test button in the configuration interface. 

It is configured to use PEAP-MSCHAPV2

Offices are still closed due to covid, i'll need to test it out the next time someone's in an office to see if it works directly from a client. 

[PhilipDAth]

PEAP is negotiated between the RADIUS server and the device trying to authenticate, not the network infrastructure.  Meraki will play no part in the security negotiation.

This means the crypto settings on NPS and your client device do not contain an overlapping set.  If you need to use the specific settings you have configured, you'll need to configure those same settings on your clients.

[PhilipDAth]

ps. Everyone has been using TLS1.2 for a while - so it won't be that.  It will be related to the cipher sets selected.

[WB]

What happens if you enable TLS 1.0/1.1?

[MikeN1]

I did try to enable both TLS 1.0 and 1.1 client and server with the same results. 

As a next step I'm going to try to get someone to go on site to test from a laptop. 

If the required cipher suites are indeed directly between the client and RADIUS server then that may prove that this is actually working even though the test button in the interface fails and causes the error to be logged on the NPS server. 

[Nizam]

My server team recently added more higher security suite on the AD server( NPS server).

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA

The next day all my user (windows 10) failed to connect to the ssid.

Check on the event logs on NPS server it shows " the client and server cannot communicate because they don't possess a common algorithm". 

Revert the cipher suite setting on NPS server solve the issue.

I did study all the cipher suite that enable on windows 10, all the above cipher are in the list. If that's the case, why my client still failed to authenticate?

[Bruce]

@Nizam that’s a Windows issue, and not really a Meraki issue. However, did you configure the clients to use the correct protocols? Just because the client can support the cipher doesn’t mean it’s been configured to use it.

[Nizam]

Hi @Bruce

I know it's not the meraki issue, how do i check what is cipher that has been configure in the client windows 10?