LDAP Administrators Makes MRBS Too Slow

[jberanek]

Hello MRBS Developers,

I'm having an issue with the LDAP settings for administrators that is making the MRBS site very very slow. The site works (admin users can edit and regular users cannot) but MRBS takes about 1000 times longer to load every page. With the LDAP admin settings disabled and using the $auth["admin"] instead it works nice and fast.

Here are some firebug load times for reference (cache disabled).

• Not logged in: 1.14s
• Logged in as user using $auth["admin"]: 993ms
• Logged in as admin using $auth["admin"]: 1.11s
• Logged in as user using $ldap_admin_group_dn: 22.36s
• Logged in as admin using $ldap_admin_group_dn: 12.78s

When $ldap_admin_group_dn is set I see a ton of LDAP activity in the logs (debugging enabled) every time I load a page. Without it set the only LDAP activity is done simply at login. It looks like if $ldap_admin_group_dn is set it will constantly re-authenticate against the LDAP server on every page load for every user (admin or not).

To fix this I would think that it should only check once that the user is in the admin group or not and store that in the session so it would not have to check on every load against he LDAP server.

Sorry if this was done by design and is not a bug but as of now the performance impact of having our admin users in an LDAP group is too much and we cannot use it.

Thank you again for making a sweet piece of software.

PLATFORM INFORMATION MRBS version - 1.4.8 Web server and version - Apache/2.2.3 (Red Hat) PHP version - 5.2.10 Database and version - MySQL 5.0.95 Server platform - Red Hat Enterprise Linux 5

Reported by: grandmasterv

Original Ticket: mrbs/bugs/235

[jberanek]

Hello

I had a similar problem. But my installation only got slow if a "standard"user was logged in. If i logged in as Administrator the system was very fast. After i set "$ldap_debug = FALSE;" the system seems to be fast for everybody :-) Do you mean with "debugging enabled" that you set $ldap_debug=true? Try turning it off, if you don't need it.

Thank you for making such a nice, useful software. We're using it to book our cars.

PLATFORM INFORMATION MRBS version - 1.4.8 (?) Web server and version - Apache/2.2.21 PHP version - 5.3.8 Database and version - MySQL 5.5.16 Server platform - Windows Server 2003 Standard LDAP-Server - Windows Server 2003 Standard - Active Directory

Original comment by: esquilaxde

[jberanek]

Hi Esquilaxde,

I tried setting "$ldap_debug = FALSE;" and it did not fix the problem.

I'll also add a little info about our directory. It is a bit different since we are using 389 directory and not open ldap or ms active directory. Instead of using groups we are using roles which should be fine but maybe thats the problem. We chose to use roles instead of groups due to our user objects NOT having a "memberof" attribute to enable group membership lookup from the user object. If we use roles the user gets a "nsrole" attribute to look up role membership just like how "memberof" group attribute works in other directories.

Thanks,

• Vince

Original comment by: grandmasterv

[jberanek]

Hi,

I confirm that I have the same issue.

I use AD LDAP server (no TLS) and I use ldap_admin_group_dn, pointed to AD group.

When not logged-in, everything works fast, when logged-in, it slows down (for example, you need to wait about 10 seconds to display page with 9 auditoriums). When ldap_admin_group_dn is commented out, it works fast even when logged-in.

I enabled ldap_debug, and I see, that MRBS connects to AD for every event and checks, if logged-in user is member of admins group:

[Tue Mar 27 17:27:08 2012] [error] [client 10.11.2.7] authLdapCheckAdminGroupCallback: base_dn 'ou=admin,ou=_users,dc=domain,dc=lt' dn 'CN=Eimantas \xc5\xa0erpenskas,OU=admin,OU=_users,DC=domain,DC=lt' user_search 'distinguishedName=CN=Eimantas \xc5\xa0erpenskas,OU=admin,OU=_users,DC=domain,DC=lt' user 'eimis', referer: http://booking.domain.lt/day.php?area=2&day=27&month=3&year=2012 [Tue Mar 27 17:27:08 2012] [error] [client 10.11.2.7] authCheckAdminGroupCallback: search successful memberof, referer: http://booking.domain.lt/day.php?area=2&day=27&month=3&year=2012 [Tue Mar 27 17:27:08 2012] [error] [client 10.11.2.7] authLdapAction: Got LDAP connection, referer: http://booking.domain.lt/day.php?area=2&day=27&month=3&year=2012 [Tue Mar 27 17:27:08 2012] [error] [client 10.11.2.7] authLdapAction: Result of initial bind is 1, referer: http://booking.domain.lt/day.php?area=2&day=27&month=3&year=2012 [Tue Mar 27 17:27:08 2012] [error] [client 10.11.2.7] authLdapAction: Found one entry using 'sAMAccountName', referer: http://booking.domain.lt/day.php?area=2&day=27&month=3&year=2012 [Tue Mar 27 17:27:08 2012] [error] [client 10.11.2.7] authLdapAction: base_dn 'ou=admin,ou=_users,dc=domain,dc=lt' user eimis dn CN=Eimantas \xc5\xa0erpenskas,OU=admin,OU=_users,DC=domain,DC=lt, referer: http://booking.domain.lt/day.php?area=2&day=27&month=3&year=2012

These lines repeated many times, about 2000 lines.

Thanks, Eimantas

Original comment by: eimser

[jberanek]

A possibly-related bug: https://sourceforge.net/tracker/?func=detail&aid=3515309&group_id=5113&atid=105113

Original comment by: dwpoon

[jberanek]

Mass-close of old tickets. (LDAP caching has been added since)