Summary | LDAP Group Backend Fails when "bindas" = "user" |
Queue | Horde Framework Packages |
Queue Version | Git master |
Type | Bug |
State | No Feedback |
Priority | 1. Low |
Owners | |
Requester | stuart (at) ruby (dot) naifeh (dot) org |
Created | 09/16/2013 (4309 days ago) |
Due | |
Updated | 02/11/2016 (3431 days ago) |
Assigned | 01/19/2016 (3454 days ago) |
Resolved | 02/11/2016 (3431 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
State ⇒ Feedback
report, can you please try if the problem persists with current
releases?
New Attachment: 0003-In-group-config-add-search-base-for-users-who-can-be.patch
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.
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ LDAP Group Backend Fails when "bindas" = "user"
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
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).