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

[Stuart C. Naifeh]

Thank you, Jan.  My issue is related, but not the same.

The issue in ticket 12128 is that the system has ['ldap']['bindas'] set to
'admin' and also has ['group']['params']['attrisdn'] set to true.  When
attrisdn is true, the Horde_Group_Ldap instance makes calls to findUserDN
(specifically in listGroups and addUser), but findUserDN depends on
['ldap']['bindas'] being set to 'user'.  If findUserDN is called with
bindas set to anything other than 'user,' the result is the erroneous query
reported in ticket 12128  -- "(&(objectclass=)(=userid))."

My issue occurs when bindas is set to 'user,' which causes a different
error in findUserDN, an error that occurs regardless of the setting of
'attrisdn.'  I will create a new ticket.




On Mon, Sep 16, 2013 at 5:09 AM, Jan Schneider <jan at horde.org> wrote:

>
> Zitat von "Stuart C. Naifeh" <scnaifeh at hotmail.com>:
>
>
>  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.
>>
>
> If this is not http://bugs.horde.org/ticket/**12128<http://bugs.horde.org/ticket/12128>,
> create a new ticket.
> --
> Jan Schneider
> The Horde Project
> http://www.horde.org/
>
>
> --
> Horde mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: horde-unsubscribe at lists.horde.**org<horde-unsubscribe at lists.horde.org>
>
>