Windows 2012 R2 RADIUS Authentication TLS Troubleshooting

I’ve steadily been working on improving the security on our internal systems. One of the recommendations is to disable SSL 3.0 and TLS 1.0 on your Windows Servers along with weak ciphers. As with all things IT, there is always some unexpected repercussions when making changes 🙂 Shortly after pushing out a GPO update to disable SSL 3.0 TLS 1.0 users could not longer connect to the WiFi network using RADIUS authentication. The error was: “Can’t connect because the sign-in requirements for your device and the network aren’t compatible. Contact your IT support person”. So I reverted the changes so I could dig into it a bit more.

We use a Fortigate with FortiAPs and I assumed (incorrectly) that the RADIUS setup on the Fortigate was to blame. I assumed that the Fortigate somehow brokered the RADIUS authentication, but it only acts as a “facilitator”. Fortinet support were nice enough to point out that my problem was more likely between my RADIUS server and the supplicant and sent me the following summary of the authentication steps:

Yes, indeed Fortigate plays a part in the WPA2 AES authentication with EAP-PEAP MSchapv2, to summarize.

There are three parts to this authentication.
One: Supplicant – which can be windows/linux/mac/ios/android device that connect to wifi.
Two: Authenticator (Radius client) – which converts the EAPOL packets to RADIUS packets (RADIUS Request/Radius Challenge/Radius Reject etc) and send to Radius server.
-which can be the networking device such as FortiAP + Fortigate OR Cisco AP + Cisco Controller etc.
Three: Authentication server (radius server) – which processes the Radius requests sent by the Authenticator on behalf of client.

Once the outer tunnel is formed, the SSL handshake happens directly between the supplicant and the radius server. (in your case/as per the configuration)
So, in the case of SSL handshake, it depends on the Supplicant SSL version/ cipher suite capability and the radius server SSL Version/cipher suite capability.

So with some testing I figured out that disabling TLS 1.0 was the thing that broke RADIUS auth. Some reading suggested that Windows 10 clients preferred TLS 1.2, so given where I was making changes my issue was seemingly on Windows 2012 R2, but technical articles suggested it was supposed to support TLS 1.2?

After a bit more googling I found a fantastic article by Jim Vajda over at Frame by Frame. He demonstrates how to use Wireshark to verify cipher suites. At first I tried this on the client side, but the capture didn’t yield any results for RADIUS. I then ran the capture on the RADIUS server and discovered the problem: In the “client hello” I could see the Windows clients were sending TLS 1.2 as preferred, yet when my RADIUS server responded it was sending back TLS 1.0 as preferred and they would negotiate on what the server offered. When I disabled TLS 1.0 completely I would then get a Access-Reject error.

Back to google with a more focused search revealed that you can set the preferred TLS version for EAP in the registry. As a final hurdle, I got stymied by a copy and paste “feature”. If you create the registry entry and copy paste “0xC00” into the field it will happily accept it, however if you manually type it in, you quickly discover that the “x” is invalid and all you really need is “C00”. With EAP now forced to 1.2, TLS 1.0 disabled and services restarted the server finally responded with TLS 1.2 as preferred and my Windows 10 clients could once again connect.

Here are some samples from Wireshark. These are captured on the Windows RADIUS server. You can simply use RADIUS as a filter in Wireshark to find the correct packets.
Client Hello with TLS 1.2

Server Hello with TLS 1.0

Rejection Error (When disabling TLS 1.0 completely. Which results in the error seen on the Windows 10 clients)

Server Hello with TLS 1.2 (after applying EAP registry change)

Anyway hope you enjoy this fun bit of troubleshooting and that it’s of some use to you.