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

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12688
------------------------------------------------------------------------------
  Ticket             | 12688
  Created By         | stuart at ruby.naifeh.org
  Summary            | LDAP Group Backend Fails when "bindas" = "user"
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


stuart at ruby.naifeh.org (2013-09-16 18:00) wrote:

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).