Tickets :: Comment on [#8269] Tries to bind to LDAP as each user that has a gallery

* Your Email Address
* Spam protection	Enter the letters below: .___..__.. .. .. . \| \| \|\ /\| \|\| \| \| \|__\ \/ \|__\|\|__\|
Comment	>> Added a configuration switch to allow turning this off. To the > >> original poster, this will fix your issue, but you might also want to > >> try providing a specific DN to bind with for searches. Otherwise, > >> there are a number of other places in Horde where this particular > >> issue will bite you. > > > > Thanks Michael, I will put in the patches and see how that goes. > > > > You are right - this is biting me in several places across Horde - > The LDAP prefs backend is refusing these unauthenticated binds from > at least 5 or 6 of the Horde apps for me. Some of them are patched > (thanks Matthias Rolke) as they are simply trying to bind as > current user but without password (e.g. Kronolith), but some of > them are failing trying to read other user's preference data (e.g. > Ansel and Turba). > > > > When you say providing a specific DN to bind with for searches do you > mean at Horde's $conf[prefs][params][searchdn] and > $conf[prefs][params][searchpw]? Does the DN specified there need to > be able to write to LDAP prefs or just read them? I'm trying to avoid > putting privileged LDAP access data into config files on the Horde > box. At the moment I have those entries blank, which says it should > be binding "anonymously" - it doesn't appear to be doing so? An > anonymous bind to read should work fine... a bind as an actual user > but without password does not. I can do an anonymous bind login in > phpldapadmin and read all the Horde prefs without an issue. > > > > From looking at my LDAP server logs, I cannot see any anonymous > binds from Horde, even though the above entries are set to search via > an anonymous bind. When phpmyldapadmin does an anonymous bind I see: > > > > May 16 09:00:32 server01 slapd[1156]: conn=138020 op=1 BIND dn="" method=128 > > > > All the Horde binds are as a user, even with the search DN set as > blank. That does not seem to be correct?
Attachment
Watch this ticket

Saved Queries