Tickets :: Comment on [#8271] LDAP preferences - unauthenticated bind attempt / failure

* Your Email Address
* Spam protection	Enter the letters below: .. ..__..___. __. \|\| \|\| \| _/ (__ \__\|\|/\\|\|__\./__..__)
Comment	> As I was having this issue across so many of the Horde apps, I > changed my LDAP prefs configuration to be as follows (which has > resolved the issues for me): > > > > $conf['prefs']['params']['hostspec'] = 'server01.simonandkate.lan'; > > $conf['prefs']['params']['port'] = 389; > > $conf['prefs']['params']['version'] = '3'; > > $conf['prefs']['params']['tls'] = true; > > $conf['prefs']['params']['basedn'] = 'dc=simonandkate,dc=lan'; > > $conf['prefs']['params']['searchdn'] = > 'cn=horde,ou=accounts,dc=simonandkate,dc=lan'; > > $conf['prefs']['params']['searchpw'] = '*******'; > > $conf['prefs']['params']['writedn'] = 'searchdn'; > > $conf['prefs']['params']['uid'] = 'uid'; > > $conf['prefs']['driver'] = 'ldap'; > > > > Thus using a more privileged user for prefs access. > > > > I have made the following notes at http://bugs.horde.org/ticket/8269: > > > > "Horde uses the setting $conf[prefs][params][writedn] (which it says is > > for "Bind to LDAP as which user when writing permissions to LDAP") to > > bind with to read* users' HordePrefs when opening Ansel (for all > > Gallery owners), Wicked pages (for the page author) etc. Making that > > setting a DN with minimum read access to all users HordePrefs > > resolves these issues across all apps. Obviously if that user has only > > read access however you can't change any of your own prefs. > > > > Setting it to a user with write access allows you to change your own > > prefs, but also gives you rights (albeit with no obvious ability) to > > change any users Prefs, not just read them. > > > > Set it to either "Bind As Admin" (or "Use Search Credentials" with > > $conf[prefs][params][searchdn] set to a user with write access to all > > users' HordePrefs etc) and no more Error 53 on LDAP binds. > > > > > > That doesn't seem right to me - this setting would appear to me to be > > for the purpose of writing one's own prefs, not for reading other > > users' prefs. > > > > What I have done as a 'work-around' is use the > > cn=horde,ou=accounts,dc=simonandkate,dc=lan account that I have for > > groups management, it's got (in slapd.conf): > > > > access to * > > attrs=@hordePerson > > by dn="cn=horde,ou=accounts,dc=simonandkate,dc=lan" write > > > > So all these bugs that I have raised appear to me to come back to a > > Horde LDAP issue - with an LDAP backend it would appear that the > > $conf[prefs][params][writedn] parameter needs to have all users > > HordePerson attributes write access - using "Bind As User" in that > > setting will cause the failures logged in the bugs I have raised when > > trying to access another user's prefs. > > > > I would much rather have it set to Bind As User, and have an > > additional setting that the Horde LDAP code uses to READ all users > > HordePrefs etc. Along the lines of a setting > > $conf[prefs][params][readdn] "User Horde uses to bind to LDAP to read > > other users' preferences"." > > > > > > > > Bind as admin is obviously overkill (but works). Bind as user causes > the issues shown here (despite the fact that any user or even > anonymous can read any user's prefs it tries to bind as the other > user with no password). > > > > As I've mentioned the fact that this is called 'writedn' but is used > to read seems odd to me. > > > > Hope some of that makes sense! :) > >
Attachment
Watch this ticket

Saved Queries