LDAP Auth not working on SSL VPN after upgrade to 5.6.6

[m0j0]

I've also posted this in the VPN section as I'm not sure if the problem is with the SSLVPN config or LDAP...

I've got three 80C's in three offices around the world.  All are configured identically as far as SSL VPN goes and all were working in the past.  They all authenticate against the same LDAP server where users who are members of the "VPN Users" group are allowed to log in.  I recently upgraded the firmware on one firewall from 5.4.4 to 5.4.6 and it appears it's been since this time that I can no longer log in to that firewall while the other two still work fine.  When I try on this firewall, I get a "Permission denied" error and the logs on the firewall also show the permission is denied with a "SSL user failed to log in" message.

If I run a tcpdump on the directory server, I see some initial back and forth which I assume is the handshake, then I see a couple of packets from the firewall that get responded to via the directory server as ICMP host unreachable - admin prohibited packets.  However, if go into the LDAP server config on the firewall and click Test Connectivity it all works fine and the tcpdump looks normal.  I've checked my iptables on the directory server and the firewall is definitely allowed - besides, if that was the problem then the connectivity test would fail.  Also, I can browse the directory fine from the firewall.

I've got no idea what to look at.  Everything looks the same on both firewalls.  I have noticed that there's an SSL-VPN Realms page on the 5.6.6 that doesn't exist on 5.6.4 interface.  I don't have anything configured under there, not sure if I need to.  I'm almost tempted to role back to 5.6.4 but I'd rather fix the issue.

[hnmr]

[link]https://forum.fortinet.com/tm.aspx?m=168448[/link]

[hnmr]

We faced a similar issue after upgrading from 5.6.5 to 5.6.6: user authentication by LDAP (Microsoft Active Directory) stopped working. We saw that the bind worked, the user credentions were verified successfuly agains the AD and that the search after group membership failed. 

We opened a bug report at Fortinet support. They said that the LDAP routine might have been re-built a lot between 5.6.5 and 5.6.6. It seems to be a bug in LDAP implementation of 5.6.6. 

We got a work around by changing the group-filter (this one to aplly in 5.6. to be found in Fortinet KB) and by reducing the number of groups to search through, becasue the groups we look for begin in our environment with a pre-defined prefix. It workes fine now. 

[Handoz56]

Hello, same problem here. Upgrade a 60D cluster from 5.6.2 to 5.6.6 in uk : no problem, upgrade a 60d cluster from 5.6.2 to 5.6.6 in shanghai (to correct a cpu problem with vpnssl) and since i can no longer log in the cluster with ldap and can't connect with vpnssl anymore (authentification error). I checked everything and the connexion test in user ldap is working...

[Handoz56 · Accepted solution]

Hey, just find my problem with the help of fortinet support :

config system global set ldapconntimeout 1000 end

it was a timeout in the ldap request , 500 is the default value and if you put 1000 now it works for me, maybe same problem for you?

Best Regards

[hnmr]

Inceasing ldapconntimeout to up to 5000 didn't change anything for us.

thank you for sharing anyhow!

[m0j0]

What do you know, that worked!

Thank you very much for taking the time to post that.  Such a simple solution but never would have worked it out myself.

Regards,

Mark

[hnmr]

Jsut to share my findings with you:

We have updated from 5.6.6 to 5.6.8.

FortiOS 5.6.8 resolves the issue with LDAP(S) and group-filter for nested groups.