Bug #3383
closed
Web GUI becomes slow or unusable if the LDAP server used for GUI auth is unreachable
100%
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
Updated by Renato Botelho almost 11 years ago
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.
Updated by Jim Pingle almost 11 years ago
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.
Updated by Adam Esslinger about 10 years ago
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.
Updated by Adam Esslinger about 10 years ago
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)
Updated by Robert Middleswarth almost 10 years ago
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
Updated by Jim Pingle over 9 years ago
- 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.
Updated by Jim Pingle over 9 years ago
- 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
Updated by Jim Pingle over 9 years ago
- 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
Updated by Jim Pingle over 9 years ago
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.
Updated by Jim Pingle about 9 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset d6b4dfe36b2be8b71df733823bb7ffe552300676.
Updated by Chris Buechler about 9 years ago
- Affected Version changed from 2.1 to All
Updated by Jim Pingle about 9 years ago
- 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.