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

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/8271
------------------------------------------------------------------------------
  Ticket             | 8271
  Updated By         | simon at simonandkate.net
  Summary            | LDAP preferences - unauthenticated bind attempt /
                     | failure
  Queue              | Turba
  Version            | 2.3.1
  Type               | Bug
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky, Ben Klang
------------------------------------------------------------------------------


simon at simonandkate.net (2009-06-04 19:22) wrote:

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! :)