Tickets :: Comment on [#12688] LDAP Group Backend Fails when "bindas" = "user"

* Your Email Address
* Spam protection	Enter the letters below: .__ . .._..___.__ [ __\| \| \| [__ [__) [_./\|/\\|_\|_[___[__)
Comment	> 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', I get > numerous LDAP related errors, errors that prevent users from logging in. > > 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"] > > 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 (as found in $conf['group']['params']). 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 a filter > constructed to find users (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). The error also occurs in calls to findUserDN in > Horde_Group_Ldap->listUsers and Horde_Group_Ldap->addUser when > $conf['group']['params']['attrisdn'] is set to True. > > I've found two solutions, one a workaround, the other a code change. > The workaround is to set the basedn for groups (i.e., > $conf['group']['params']['basedn']) 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 > configured for groups. This makes for inefficient searches of the > ldap database when actually searching for groups, however. > > The code change is to change the call to "search" in the findUserDN > method to pass in an explicit search base rather than "null" (passing > null causes findUserDN to use the default basedn set for the > Horde_Ldap instance). For example, replacing the "null" in the call > to findUserDN with "$GLOBALS['conf']['auth']['params']['basedn']" > works of all users who can be added to groups are in the LDAP subtree > set up > in the LDAP user authentication parameters. This is not an ideal > solution for a number of reasons, however. I'd suggest what needs to > be done is to have a separate set of parameters for searching for > users that is specific to the LDAP group backend, but this would > require changes in both the Horde_Group_Ldap class and the Horde_Ldap > class (at least to the findUserDN method).
Attachment
Watch this ticket

Saved Queries