Bug in 6.0.6 SSLVPN/LDAP user auth?

[kallbrandt]

Just my findings about this. Someone else might be drowning in the same marsh..

I had serious problems with a client's 600D not honoring the configured LDAP groups for VPN authentication. It turned out that the Fortigate authenticated all users against radius... No radius users are configured. But during the auth sequence, the firewall check for radius config, then tacacs config, then ldap. If it finds a radius server, it proceeds to authenticate the users on that! I am still waiting for the TAC to tell me if this really is the expected behaviour, but I suspect not. It would be impossible to use more then one type of authentication server then. Well, as it is now at least. The solution for me was to remove the radius config - Hey presto! LDAP works, groups are honored!

Or wait, there was a 2nd snafu: LDAPS was configured, all checks were green in gui. But LDAP auth fails with "unsupported protocol" when you do your diag debug on auth...

[Toshi_Esumi]

My understanding was it's supposed to send an auth request to all remote auth servers configured in the group(s). I don't know the exact decision making process if multiple servers replied with conflicting answers: "pass" and "deny", though. Was that working fine with 6.0.5? Or which version did you upgraded the 600D from, then found this problem?

[kgipe]

We actually just ran into this same issue and have a ticket in on it.  In our case, we added in a new Radius server and user group but had not even applied it anywhere and it started trying to authenticate SSL VPN users against it.  I don't know if it was the same on 6.0.5 as I added the Radius server in after upgrade.

[kallbrandt]

kgipe wrote:

We actually just ran into this same issue and have a ticket in on it.  In our case, we added in a new Radius server and user group but had not even applied it anywhere and it started trying to authenticate SSL VPN users against it.  I don't know if it was the same on 6.0.5 as I added the Radius server in after upgrade.

Aha! That kinda screams bug to me... We upgraded the firewall all the way from 5.2.14 -->6.0.6 via the supported upgrade path. I don't know about the firmware versions inbetween, but this was not a problem in 5.2.13.

Anyway, for our setup, it is solvable, but if you depend on your radius for other things, you're kinda toast right now. Let's hope for a fix soonish.

[Toshi_Esumi]

Probably that's the key - NOT configured in any groups - in other words, not used. In our office we use FGT60E w/ 6.0.5 and it has two different sets of RADIUS servers for WiFi and admin user authentication. But so far it's acting as expected after upgraded from 5.6.6.

[kallbrandt]

I actually tried to configure a few radius groups, didn't make any difference.

So, you'll have to upgrade to 6.0.6 to find out. :)

[Toshi_Esumi]

Either of you, please let the rest of us know when you get a bug ID. By that time you would know more about the conditions.

I was planning to upgrade our 60E cluster to 6.0.6 in a couple of weeks. I'll test auth for two different user groups w/ different RADIUS servers. Then if it doesn't work as expected, I'll revert it (swap the partitions) to go back to 6.0.5.

[Alivo__FTNT]

Hello kallbrandt,

Do you have in you RADIUS configuration : "set all-usergroup enable" ?

[kallbrandt]

Nope, but I think I just found the reason. It seems that radius authentication was triggered by several separate events. We had an old radius policy that sent back a vendor specific option that applied a non-existing user-group (something was obviously setup for testing in back in 2015 or so, with a usergroup that must have existed back then). The radius policy was pretty much wide open, an active account was enough. The Fortigate was triggered to continue to auth all users with Radius after that. I guess because the vendor specific option was returned to the fw, it decided to go with radius auth. I have no other explanation. When I removed the vendor specific option, radius was not triggered. Note once again that NO radius users NOR groups is configured. Everything is using LDAP. IMHO, radius auth should not be triggered if no users/groups are configured, but I guess this "exploit" is not that practical to make use of, since it requires admin access to the fw in order to set the radius up.

[kallbrandt]

toshiesumi wrote:

My understanding was it's supposed to send an auth request to all remote auth servers configured in the group(s). I don't know the exact decision making process if multiple servers replied with conflicting answers: "pass" and "deny", though. Was that working fine with 6.0.5? Or which version did you upgraded the 600D from, then found this problem?

The thing is - the radius servers was NOT configured in any groups or users - They were just present in the config and reachable.