Fortigate AP RADIUS Authentication

[fivefive]

All - I have 15 FortiAP's connected to my Fortigate and whenever I get more than 6 or so computers in a conference room the wpad_ac process tanks one of the CPU's of the Fortigate and doesn't allow any more computers to be authorized to our network.

I have a ticket open with Fortinet and they've said the issue is known and will be fixed in the upcoming 6.0.4 release.  They've also stated it will not be fixed in the 5.6.x code stream (which is what we're running).  They've also not offered a workaround during the interim time until 6.0.4 is ready and we go through the necessary preparation for a major OS upgrade.

My question is: has anyone else had this problem and if so did you solve it?  I can't believe our setup is unique - it conforms to the standard enterprise setup using Windows NPS as the RADIUS server outlined in Fortinet's cookbook.  Also never had a problem with the setup during our 5.4 days.

I'm still pressing Fortinet for some better answers but I thought I'd post here to see if, on the very off chance, someone had a magic button to make it all good.

Thanks much,

Ryan

[Mike_FTNT · Accepted solution]

Hi Ryan,

What is your ticket number?

FOS 6.0.4 will fix a bug that if "Session-Timeout" attribute is configured under a RADIUS user account, it may result in wpad_ac high CPU usage when FGT authenticating that user.

Please double-check your "Windows NPS as the RADIUS server" ---- If any user account(s) happened to have "Session-Timeout" attribute configured, please try to remove that attribute from the affected user(s), and observe users connections for a while.

Thanks,

Mike

[Mike_FTNT · Accepted solution]

Hi Ryan,

What is your ticket number?

FOS 6.0.4 will fix a bug that if "Session-Timeout" attribute is configured under a RADIUS user account, it may result in wpad_ac high CPU usage when FGT authenticating that user.

Please double-check your "Windows NPS as the RADIUS server" ---- If any user account(s) happened to have "Session-Timeout" attribute configured, please try to remove that attribute from the affected user(s), and observe users connections for a while.

Thanks,

Mike

[fivefive]

Mike - ticket number 3050262.  I'll look into the session timeout attributes - thanks for the tip!

[fivefive]

Mike you may be the hero I needed.  I disabled session time outs in the NPS server and attempted to recreate the problem and I was unable to do so.  It remains to be seen whether it happened to be a fluke that it worked, but I was able to recreate it pretty faithfully.

So, if this works, my only question would be, where do I send the box of cookies to represent my eternal thanks?

[Mike_FTNT]

You're very welcome, Ryan.

I checked ticket 3050262. It matches the bug mentioned above, but FOS 5.6.x won't fix that bug.

Disabling session timeout attribute on RADIUS server could be a workaround, when your FGT is running FOS 5.6.x.

Best Regards,

Mike

[fivefive]

Any security considerations to be concerned about if I leave the timeouts disabled until I can move to 6.0.4?  If I understand what I'm reading it just means that my clients will just hold on to their session for the duration of the working day instead of re-authenticating after the default 60 minutes for users and 180 minutes for computers.

The majority of our laptops are wired and only use wireless when their in conference rooms.  Which means when they dock they disconnect from the wifi anyway.  I don't see any big concerns.

Any additional thoughts?

Thanks again,

Ryan

[Mike_FTNT · Accepted solution]

People usually won't notice the interruption caused by session timeout, because WiFi driver or network software (wpa_supplicant) etc. can "remember" username & password and quickly/automatically re-do authentication/connection. Right?

So, I'd not think that it is a big concern to disable session timeout, unless one unauthorized guy could grab the laptop somehow.

In FOS WiFi configuration, there is a setting to enable/disable EAP re-authentication.

For example: config wireless-controller vap     edit <vap name>         set security wpa2-only-enterprise         set auth radius         set radius-server "PEAP"         set eap-reauth enable         set eap-reauth-intv 1800     next end "eap-reauth-intv" (in seconds) could be used as a temp replacement if necessary. Thanks, Mike

[fivefive]

Thanks again Mike - agreed.  I'm comfortable with the work around.  And thanks for the extra mile with extra information about the Fortigate config.

So PM me your address and favorite snack and I'll send you a dozen. 

[nikjohn1538]

Hi @mike

You can perform user authentication when the wireless client joins the wireless network and when the wireless user communicates with another network through a firewall policy. WEP and WPA-Personal security rely on legitimate users knowing the correct key or passphrase for the wireless network. The more users you have, the more likely it is that the key or passphrase will become known to unauthorized people. WPA-Enterprise and captive portal security provide separate credentials for each user. User accounts can be managed through FortiGate user groups or an external RADIUS authentication server.

Configuring the connection to a RADIUS server - web-based manager

[ul]

Go to User & Device > RADIUS Servers and select Create New.

Enter a Name for the server.

This name is used in Fortiauthenticator configurations. It is not the actual name of the server.

In Primary Server Name/IP, enter the network name or IP address for the server.

In Primary Server Secret, enter the shared secret used to access the server.

Optionally, enter the information for a secondary or backup RADIUS server.

Select OK.[/ul]

To configure the FortiGate unit to access the RADIUS server - CLI config user radius

edit exampleRADIUS

set auth-type auto

set server 10.11.102.100

set secret aoewmntiasf

end

Thanks,

Nikhil John

Forti Network security expert

[fivefive]

Thanks Nikhil - we already had a RADIUS server up and running.  We now know that when the timeout settings are enabled in the NPS Windows service, there is a bug that causes it to cease authenticating users.

Hopefully this will be helpful on both fronts.

Ryan