[#12688] LDAP Group Backend Fails when "bindas" = "user"
Summary LDAP Group Backend Fails when "bindas" = "user"
Queue Horde Framework Packages
Queue Version Git master
Type Bug
State No Feedback
Priority 1. Low
Requester stuart (at) ruby (dot) naifeh (dot) org
Created 2013-09-16 (2071 days ago)
Updated 2016-02-11 (1193 days ago)
Assigned 2016-01-19 (1216 days ago)
Resolved 2016-02-11 (1193 days ago)
Patch No

2016-02-11 15:14:25 Jan Schneider State ⇒ No Feedback
2016-01-19 13:59:55 Jan Schneider Comment #3
State ⇒ Feedback
Reply to this comment
There have been several fixes in Horde_Ldap and Horde_Group since this 
report, can you please try if the problem persists with current 
2013-09-20 13:02:12 stuart (at) ruby (dot) naifeh (dot) org Comment #2
New Attachment: 0003-In-group-config-add-search-base-for-users-who-can-be.patch Download
Reply to this comment
Here is a patch proposing one possible solution for this bug.  It adds 
a new configuration parameter to Groups when the selected backend is 
LDAP.  This paraameter specifies the base DN to search wen looking for 
group members.
2013-09-16 18:00:13 stuart (at) ruby (dot) naifeh (dot) org Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ LDAP Group Backend Fails when "bindas" = "user"
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
Reply to this 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).

Saved Queries