[horde] Errors with LDAP auth and groups when bindas = 'user'

Stuart C. Naifeh scnaifeh at hotmail.com
Fri Sep 13 20:57:17 UTC 2013


I have seen a discussion of similar issues before, but despite much
googling, I have not been able to find a resolution for my issue.

I use LDAP as my authentication source and LDAP as my group backend.  If in
Horde's LDAP configuration, I set 'bindas' to 'anon', I have no trouble
logging in or using Horde.  If I set it to 'user', however, I cannot log
in, even when I leave binddn and bindpw blank, which according to the
documentation should cause Horde to bind anonymously when looking up the
login uid.  If I change bindas to 'user' and haven't yet logged out, I get
numerous LDAP related errors when continuing to use horde.

The errors I get are, e.g.:

ERR: HORDE [kronolith] DN for user testuser not found [pid ---- on line 873
of "/src/horde-git/framework/Ldap/lib/Horde/Ldap.php"]

EMERG: HORDE [horde] DN for user testuser not found [pid ---- on line 1612
of "/src/horde-git/framework/Core/lib/Horde/Registry.php"]

As you can see, I am running the Horde git repository, but I get the same
error on a production machine running the latest stable Horde.  This also
causes the dreaded "PHP Fatal error:  Allowed memory size of 134217728
bytes exhausted (tried to allocate 65068523 bytes) in
/src/horde-git/framework/Core/lib/Horde/ErrorHandler.php on line 111."

I have attempted to debug this problem, and as far as I can see, it stems
from calls to findUserDN from the object instances of type
Horde_Group_Ldap.  By default, when Horde_Core_Factory_Group creates a
Horde_Group_Ldap instance, it sets the parameters for the associated
Horde_Ldap instance to those configured in Horde's group settings.  In my
case, those settings include an ldap basedn set to the subtree where groups
live.  When findUserDN is called against that Horde_Ldap instance, it
searches the group subtree for an object matching the user filter (in my
case, the filter is (&(objectclass=inetOrgPerson)(uid=username))), and of
course, it doesn't find it.

For the most part, this occurs in calls to findUserDN on line 78 of
/Horde/Core/Factory/Ldap.php whenever the factory is used to create an Ldap
instance associated with a group (which occurs whenever
Horde_Core_Factory_Group->create is called with Ldap as the group
backend).

I've found two solutions, one a workaround, the other a code change.  The
workaround is to set the basedn for groups to a high enough level in the
LDAP tree to encompass both the user and group subtrees, and to rely on the
objectclass filter to make sure I only see groups, making sure I am using
subtree as the scope for group searches.  That way, findUserDN can find the
users, even when searching using the basedn for groups.

The code change is to change the call to "search" in the findUserDN method
to pass in an explicit search base rather than null.  I am using
"$GLOBALS['conf']['auth']['params']['basedn']" to pull in the user base set
in the LDAP authentication parameters.  I think this is not good from a
design perspective, as it makes the framework reference the installations
configuration, but I could not see any other simple way to get this
information from within findUserDN.

One related issue I noticed is that if I leave the
[ldap][user][objectclass] configuration parameter as the default of '*', I
get LDAP errors due to the filter being encoded as '(?objectclass=\2A)',
which openldap does not like.  I can't figure out where this encoding is
happening.


More information about the horde mailing list