Closed in favor of the catch-all ticket #8353.

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

There are some notes related to this in Bug: 8270



Also, FWIW, the Ansel ticket cited ( Bug:8269 ) has been resolved, 
albeit in a non-ideal way (by allow an admin to explicitly disallow 
attempting to read other user's prefs if they do not want to provide 
an appropriate search DN to bind with).



Why this in failing in Turba *after* viewing the contact created by 
another user then returning to the address book browse view, I'm not 
sure. My only idea is that maybe by the time the notification is 
pushed for the bind error, it's too late to display on the current 
screen, so it is pushed after the next page reload. I'm not an LDAP 
guy, nor do I have a LDAP server available to test this theory on...
AFAIK, this is what the search dn is for.
The problem (as described in the other tickets as well) is that there 
are parts of Horde where we need to attempt access to another user's 
preferences, for example, when retrieving a user's Identity settings 
so we can display full names instead of usernames.

Horde debug logs:



May 15 10:16:07 HORDE [debug] [turba] LDAP query by 
Turba_Driver_ldap::_search(): user = simon, root = 
ou=shared_addressbook,dc=simonandkate,dc=lan 
(server01.simonandkate.lan); filter = 
"(|(objectclass=top)(objectclass=person)(objectclass=organizationalPerson)(objectclass=inetOrgPerson)(objectclass=turbaContact))"; attributes = "dn, uid, turbaType, turbaMembers, cn, mail, sn, givenName, homephone, telephonenumber, mobiletelephonenumber, homepostaladdress, calFBURL"; deref = "0"  ; sizelimit = 200 [pid 1812 on line 186 of 
"/usr/share/horde/turba/lib/Driver/ldap.php"]

May 15 10:16:07 HORDE [debug] [turba] SQL query by 
Horde_Alarm_sql::_list(): SELECT alarm_id, alarm_uid, alarm_start, 
alarm_end, alarm_methods, alarm_params, alarm_title, alarm_text, 
alarm_snooze, alarm_internal FROM horde_alarms WHERE alarm_dismissed = 
0 AND ((alarm_snooze IS NULL AND alarm_start <= ?) OR alarm_snooze <= 
?) AND (alarm_end IS NULL OR alarm_end >= ?) AND (alarm_uid = ? OR 
alarm_uid = ?) ORDER BY alarm_start, alarm_end [pid 1812 on line 148 
of "/usr/share/horde/lib/Horde/Alarm/sql.php"]

May 15 10:16:07 HORDE [debug] [turba] LDAP query by 
Turba_Driver_ldap::_search(): user = simon, root = 
ou=simon,ou=personal_addressbook,dc=simonandkate,dc=lan 
(server01.simonandkate.lan); filter = "(&(turbaType=*Group*))"; 
attributes = "dn, turbaType, cn, sn"; deref = "0"  ; sizelimit = 0 
[pid 1812 on line 186 of "/usr/share/horde/turba/lib/Driver/ldap.php"]

May 15 10:16:07 HORDE [debug] [turba] LDAP query by 
Turba_Driver_ldap::_search(): user = simon, root = 
ou=shared_addressbook,dc=simonandkate,dc=lan 
(server01.simonandkate.lan); filter = "(&(turbaType=*Group*))"; 
attributes = "dn, turbaType, cn, sn"; deref = "0"  ; sizelimit = 200 
[pid 1812 on line 186 of "/usr/share/horde/turba/lib/Driver/ldap.php"]

May 15 10:16:10 HORDE [debug] [horde] Connected to the following 
memcache servers:localhost:11211 [pid 1584 on line 127 of 
"/usr/share/horde/lib/Horde/Memcache.php"]

May 15 10:16:10 HORDE [debug] [turba] SQL query by 
Horde_Alarm_sql::_list(): SELECT alarm_id, alarm_uid, alarm_start, 
alarm_end, alarm_methods, alarm_params, alarm_title, alarm_text, 
alarm_snooze, alarm_internal FROM horde_alarms WHERE alarm_dismissed = 
0 AND ((alarm_snooze IS NULL AND alarm_start <= ?) OR alarm_snooze <= 
?) AND (alarm_end IS NULL OR alarm_end >= ?) AND (alarm_uid = ? OR 
alarm_uid = ?) ORDER BY alarm_start, alarm_end [pid 1584 on line 148 
of "/usr/share/horde/lib/Horde/Alarm/sql.php"]

May 15 10:16:10 HORDE [error] [turba] Error rebinding for prefs 
writing: [53]: Server is unwilling to perform [pid 1584 on line 270 of 
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]

May 15 10:16:10 HORDE [error] [turba] Internal LDAP error.  Details 
have been logged for the administrator. [pid 1584 on line 348 of 
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]

May 15 10:16:10 HORDE [error] [turba] Error rebinding for prefs 
writing: [53]: Server is unwilling to perform [pid 1584 on line 270 of 
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]

May 15 10:16:10 HORDE [error] [turba] Internal LDAP error.  Details 
have been logged for the administrator. [pid 1584 on line 348 of 
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]

May 15 10:16:14 HORDE [debug] [horde] Connected to the following 
memcache servers:localhost:11211 [pid 1583 on line 127 of 
"/usr/share/horde/lib/Horde/Memcache.php"]

May 15 10:16:14 HORDE [debug] [turba] LDAP query by 
Turba_Driver_ldap::_search(): user = simon, root = 
ou=shared_addressbook,dc=simonandkate,dc=lan 
(server01.simonandkate.lan); filter = 
"(|(objectclass=top)(objectclass=person)(objectclass=organizationalPerson)(objectclass=inetOrgPerson)(objectclass=turbaContact))"; attributes = "dn, uid, turbaType, turbaMembers, cn, mail, sn, givenName, homephone, telephonenumber, mobiletelephonenumber, homepostaladdress, calFBURL"; deref = "0"  ; sizelimit = 200 [pid 1583 on line 186 of 
"/usr/share/horde/turba/lib/Driver/ldap.php"]

May 15 10:16:14 HORDE [debug] [turba] SQL query by 
Horde_Alarm_sql::_list(): SELECT alarm_id, alarm_uid, alarm_start, 
alarm_end, alarm_methods, alarm_params, alarm_title, alarm_text, 
alarm_snooze, alarm_internal FROM horde_alarms WHERE alarm_dismissed = 
0 AND ((alarm_snooze IS NULL AND alarm_start <= ?) OR alarm_snooze <= 
?) AND (alarm_end IS NULL OR alarm_end >= ?) AND (alarm_uid = ? OR 
alarm_uid = ?) ORDER BY alarm_start, alarm_end [pid 1583 on line 148 
of "/usr/share/horde/lib/Horde/Alarm/sql.php"]

May 15 10:16:14 HORDE [debug] [turba] LDAP query by 
Turba_Driver_ldap::_search(): user = simon, root = 
ou=simon,ou=personal_addressbook,dc=simonandkate,dc=lan 
(server01.simonandkate.lan); filter = "(&(turbaType=*Group*))"; 
attributes = "dn, turbaType, cn, sn"; deref = "0"  ; sizelimit = 0 
[pid 1583 on line 186 of "/usr/share/horde/turba/lib/Driver/ldap.php"]

May 15 10:16:14 HORDE [debug] [turba] LDAP query by 
Turba_Driver_ldap::_search(): user = simon, root = 
ou=shared_addressbook,dc=simonandkate,dc=lan 
(server01.simonandkate.lan); filter = "(&(turbaType=*Group*))"; 
attributes = "dn, turbaType, cn, sn"; deref = "0"  ; sizelimit = 200 
[pid 1583 on line 186 of "/usr/share/horde/turba/lib/Driver/ldap.php"]

I have a shared LDAP directory in Turba that functionally works fine. 
Users with granted permissions can add and edit contacts.



Error: "The preferences backend is currently unavailable and your 
preferences have not been loaded. You may continue to use the system 
with default settings."



Reproducible: yes every time - Logoff, logon, go to the shared address 
book, open a contact created by a user other than me, return to the 
shared addressbook - error is thrown.



LDAP log:



May 14 12:31:55 server01 slapd[1156]: conn=121129 op=2 BIND 
dn="uid=katie,ou=users,dc=simonandkate,dc=lan" method=128

May 14 12:31:55 server01 slapd[1156]: conn=121129 op=2 RESULT tag=97 
err=53 text=unauthenticated bind (DN with no password) disallowed



The user it is attempting to bind as is the user who created the 
shared contact.



These errors are occurring in Wicked http://bugs.horde.org/ticket/8270 
when accessing a page created by someone else, Ansel 
http://bugs.horde.org/ticket/8269 when listing galleries created by 
someone else, and Turba (this ticket) when returning from a contact 
created by someone else - consistently and repeatably.



The patches posted for Ingo http://bugs.horde.org/ticket/7418, 
Kronolith http://bugs.horde.org/ticket/8246 and Nag 
http://bugs.horde.org/ticket/8251 have solved the issues for me in 
those applications.



My Horde Prefs config is as follows:



$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']['writedn'] = 'user';

$conf['prefs']['params']['uid'] = 'uid';

$conf['prefs']['driver'] = 'ldap';



Preferences binds are done as the logged on user. Would doing a 
preferences bind as an LDAP user with permissions to all the required 
parts of LDAP solve this? I would rather bind as the user concerned... 
seems to be a more "proper" way to do it, and I'd have thought it 
should work given the option is there.