FortiOS v5.2.5: Windows XP cannot connect to WPA2 Enterprise WiFi

[VicAndr]

We have WiFi networks with WPA2 Enterprise security successfully working in our environment. After recent firmware upgrade from v.5.2.3 to v.5.2.5 on all our FortiGate and FortiWifi boxes, old computers with Windows XP on them cannot connect to the wireless networks any longer.

Although we do not have many Windows XP installations left - none of them cannot connect to WPA2 Enterprise wireless networks. There was no such a problem before the upgrade.

All our FortiAPs units (FAP 220B, 320C, 321C) have the latest (v5.2.4 build 0245) on them.

Does anyone experience the same issue?

Thank you for any thoughts and ideas.

[Bromont_FTNT]

So just to recap... I'd change this:

config wireless-controller vap     edit "TCET"

set auth usergroup         set usergroup "TCET_WLAN_Enterprise"

end

 to this:

config wireless-controller vap     edit "TCET"

set auth radius         set radius-server "TCET_WLAN_Enterprise"

end

[VicAndr]

Bromont wrote:

Is there any reason you want the Fortigate Certificate instead of your radius server cert? I'd point directly to the radius server in your SSID setup so the Fortigate wouldn't be involved with certs at all

Principal difference between RADIUS configurations for WPA2-Enterprise with RADIUS being a member of local firewall group and with direct RADIUS authentication in SSID setup is that, in the first case you can explicitly specify what security group on RADIUS server (Active Directory fro that matter) you want to perform authentication against. Direct RADIUS connection from SSID setup does not make any distinction between groups on RADIUS server – and that is the problem.

We use the same virtual RADIUS server (combination of 2 physical ones: primary and secondary) for different authentication/authorization purposes in many places throughout firewall configuration:

   VPN IPSec clients’ XAUTH    MAC addresses for WPA2-Enterprise WLAN    Users’ Accounts for WPA2-Enterprise WLAN

Separate security groups in AD are dedicated to each of the aforementioned purposes; we want to ensure that each occurrence of authentication/authorization is performed against an appropriate group:

   VPN authentication checks whether account exists in IPSec_VPN group,    MAC authentication – MAC_addresses group,    and WPA2-Enterprise – TCET_WLAN_Enterprise group.

When it comes to WPA2-Enterprise setup, we want to control both users’ AND devices’ connections to wireless network. As you can see RADIUS server is being used twice during each client’s WiFi connection attempt: first – it authenticates device, and then – user him/her-self.

Even if configuration change you recommend works - it is not an option in the circumstances, since it compromises security. It is not a big deal to sniff a MAC address “in the air”. And then the very same MAC address which was used to authenticate a device might be used to “impersonalize” user authentication as well.

Bromont wrote:

set radius-mac-auth enable         set radius-mac-auth-server "TCET_RADIUS"

Fort troubleshooting I'd disable the mac authentication you have above.

I tried - it didn't make a difference.

What I do not understand is - why after disabling server certificate validation on the client side (I mean XP in this case; everything else works fine) it still cannot pass the validation?

[Bromont_FTNT]

VicAndr wrote:

Even if configuration change you recommend works - it is not an option in the circumstances, since it compromises security. It is not a big deal to sniff a MAC address “in the air”. And then the very same MAC address which was used to authenticate a device might be used to “impersonalize” user authentication as well.

I don't follow why you think the change compromises security. In any case I'm sure the others here who have this working with XP are point directly at the Radius server instead of a Fortigate user group.

[VicAndr]

Bromont wrote:

I don't follow why you think the change compromises security. In any case I'm sure the others here who have this working with XP are point directly at the Radius server instead of a Fortigate user group.

It compromises security because with MAC address alone (without the need to know User's ID and Password) you may get access to WiFi network: first - your device is authenticated with its MAC address, and then you use the same MAC address again to pass through WPA2-Enterprise authentication. Since sniffing a MAC address on a WiFi network is relatively easy - it becomes a security hole. Is it a little more clear now?

In regards to pointing directly to RADIUS in SSID setup instead of a firewall group... I agree - it might be a viable option in simple firewall configurations. But when you have multiple groups on RADIUS serving your FortiGate units, you want to find some ways to specify (i.e. enforce) which exactly security group you want connection attempt to authenticate against.

[Bromont_FTNT]

Ok Vic, I didn't suggest removing username/password authentication, I suggested removing the mac authentication during troubleshooting. 

Are you allowing only Domain member workstations to connect or are you performing mac authentication for other kinds of devices as well? 

[VicAndr]

Bromont wrote:

Ok Vic, I didn't suggest removing username/password authentication, I suggested removing the mac authentication during troubleshooting.

You had this suggestion already, and I did respond to it early in the thread. Yes, for troubleshooting purposes I disabled MAC authentication while leaving RADIUS as a member of firewall group. XP machines could not still connect. "Moving" RADIUS authentication from local group into SSID setup, would likely solve the problem (as you and others are indicating here) but due to the aforementioned shortcoming that's not a "solution" I am looking for.

Bromont wrote:

Are you allowing only Domain member workstations to connect or are you performing mac authentication for other kinds of devices as well? 

Our WPA2-Enterprise wireless network being used by all kind of mobile devices: various flavors of Windows, MAC, iOS and Android. Overwhelming majority of them are not members of Domain (Domain members workstations usually have wired connections on our network). But if they were, what difference would it make?

Except Windows XP - everything else works perfectly fine on the WiFi network. The problem with XP on WiFi is, in fact, not a big deal since, first - there are not many XP-based machines left on the network (usually they are not being used by staff, but serve some utilitarian purposes); and secondly - there are few workarounds to get the job done anyway. So this issue became rather theoretical discussion.

According to discussions in this thread as well as with Fortinet support engineers (ticket is still open), it seems that "Windows XP on WPA2-Enterprise WLAN" issue caused by SHA256 cert. introduced with FortiOS 5.2.5. Now, could someone explain (or, perhaps, point to some document or KB article) how a certificate being used in the course of WPA2-Enterprise client connection negotiation, and why disabling certificate validation on the client side still doesn't "fix" WiFi connectivity issue (in case of XP)?

[emnoc]

Confusion;

If this ( your new problem )  is just a new SHA256 cert, why can't that be changed? And why hasn't TAC suggested it?

[Bromont_FTNT]

Are you running XP SP3?

[VicAndr]

emnoc wrote:

If this ( your new problem )  is just a new SHA256 cert, why can't that be changed? And why hasn't TAC suggested it?

That's a good question. This is an "iteration" of my own question I can't get answer to from anyone: "Why we can't disable certificate validation altogether?"

As to TAC... The ticket is open for 3 weeks and now has the 3rd owner. The last response from him was "I am still researching information regarding your issue".

Bromont wrote:

Are you running XP SP3?

Yes, all XP workstations have the latest Service Pack.

[localhost · Accepted solution]

VicAndr wrote:

Now, could someone explain (or, perhaps, point to some document or KB article) how a certificate being used in the course of WPA2-Enterprise client connection negotiation, and why disabling certificate validation on the client side still doesn't "fix" WiFi connectivity issue (in case of XP)?

This will just accept certificates which are not signed by a know ceritificate authority.

But the certificate will still be used to create an encrypted channel to exchange the authentication information.