LDAP preferences - unauthenticated bind attempt / failure

I have a shared LDAP directory in Turba that functionally wo

Thu, 14 May 2009 02:43:18 +0000

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.

Horde debug logs: May 15 10:16:07 HORDE [debug] [turba] L

Fri, 15 May 2009 00:18:43 +0000

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"]

There are some notes related to this in Bug: 8270 Also, F

Thu, 04 Jun 2009 13:54:17 +0000

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... > 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? AFAIK, this is what the search dn is for. > 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. 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.

As I was having this issue across so many of the Horde apps,

Thu, 04 Jun 2009 23:22:13 +0000

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

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

Tue, 16 Jun 2009 13:38:09 +0000

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