Bug #3383
closed
Web GUI becomes slow or unusable if the LDAP server used for GUI auth is unreachable
Added by Florent THOMAS almost 11 years ago.
Updated about 9 years ago.
Category:
User Manager / Privileges
Affected Architecture:
All
Description
Hy,
This one have been difficult to find.
I set up a ldap server in user manager through the web gui. Everything works fine.
One day I made a reboot of my virtual environment and the ldap server wasn't in the boot process. The web gui of pfsense wasn't availble. Actually it was but horribly slow and impossible to get out from the index.html.
Then I made a reboot of the ldap server and it works well.
Yesterday, I destroyed my VM ldap and create a new ldap server with a new IP. of course, my pfsense wasn't able to reach the old one. The result was the same. Impossible to reach normally the web GUI.
Then when I use viconfig to delete the ldap reference, everything woks fine.
I think it's a bug and maybe a warning could be thrown if too many attempt to reach a server failed.
hope it can help.
regards
On pfSense 2.2 you will be able to revert GUI auth backend to Local Database on the same option you use to restore GUI password on console. See #3341
I'm not sure if there is something better we could provide to help on this.
It seems like maybe the authentication fallback that allows a person to login using local auth when their LDAP server isn't available should be remembering the decision once per session instead of once per page load. Once the user is authenticated it shouldn't need to hit the LDAP server for every subsequent pageload like it appears to be doing.
It would also be nice if it supported multiple LDAP servers. In an AD environment there are multiple directory servers, so it would be nice if pfSense supported either querying for the directory servers or where you could add 2-4 additional servers to query. In addition pfsense should only query once per session upon logon instead of querying for each page.
Another option would be to add an authentication realm drop down to the login page, like you would get on a windows machine when its joined to Active Directory. (username, password, authentication realm)
Renato Botelho being able to revert to local DB is a useful workaround compared to the current process of having to edit the config or taking 30 min to go though the webpages but wouldn't a better fix be to either setup ldap so if it failed during login it doesn't try on ever page or as someone suggested if you have radius or ldap defined add a 3rd option when logging in auth source of local DB and auth name.
Thanks
Robert
- Category set to User Manager / Privileges
- Assignee set to Jim Pingle
- Target version set to 2.3
- Affected Architecture All added
- Affected Architecture deleted (
Looks like the problem here is due to the way LDAP groups are obtained. The GUI does not cache the obtained LDAP group info in $_SESSION but rather performs a new search/query/bind on each page load to determine the LDAP groups, which will slow down a lot if the LDAP server is unreachable.
One option is to cache the group info at login. It would cut down on the number of LDAP queries performed by the GUI and eliminate this issue. The downside to that is if the LDAP user is removed (e.g. user was terminated) then they could still keep accessing pages as long as their session is active. With the current method they would be rejected once the account was removed. At the moment that's also how local users work, but not RADIUS (See #935)
If the info is not cached then the fact that the auth server was unavailable could be noted in $_SESSION so that future page loads would not continuously attempt to access it and would keep using local auth.
Either way this should be a fairly easy change to make for 2.3.
- Subject changed from Web GUI no more available if a defined ldap server is no more available to Web GUI becomes slow or unusable if the LDAP server is unreachable
- Subject changed from Web GUI becomes slow or unusable if the LDAP server is unreachable to Web GUI becomes slow or unusable if the LDAP server used for GUI auth is unreachable
PHP's LDAP library has a network timeout now and that seemed like a good choice that wouldn't increase complexity or compromise security. I pushed a change to add the field to RELENG_2_2 but the commit will need to be replicated on master after the bootstrap merge, so this needs to stay open.
The timeout defaults to 25 seconds (current timeout is ~1m20sec) and if this happens to someone a lot, lowering to 10 seconds isn't a bad move. Things would still be sluggish, but usable.
- Status changed from New to Feedback
- % Done changed from 0 to 100
- Affected Version changed from 2.1 to All
- Status changed from Feedback to Resolved
I've tested this on 2.2 and again now on 2.3, I think this is as close as we're going to get. With the server timeout set reasonably low (e.g. 10s) the GUI is a little sluggish but not unusable like before.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by