| Summary | Wicked tries (and fails) to bind to LDAP as Page creator |
| Queue | Wicked |
| Type | Bug |
| State | Duplicate |
| Priority | 1. Low |
| Owners | |
| Requester | simon (at) simonandkate (dot) net |
| Created | 05/13/2009 (5894 days ago) |
| Due | |
| Updated | 06/16/2009 (5860 days ago) |
| Assigned | 06/04/2009 (5872 days ago) |
| Resolved | 06/05/2009 (5871 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
Taken from Michael Rubinsky
Taken from Ben Klang
Taken from ben
ticket #8353.State ⇒ Duplicate
bug #8271.Simon
this information, but currently it's complicated by the fact that the
notification is actually pushed directly from the Prefs_* object where
the failure occurs, hence there is no way to differentiate between a
identity lookup vs pref lookup as far as silencing errors is
concerned. We would have to remove all of the pushes from the pref
code then move notification entirely to client code (where it probably
belongs anyway), but that would likely require BC-breaking changes to
the pref system so this may be a solution for Horde 4.
It seems to me that per-user binding should probably be deprecated,
but I am not an LDAP guy, so I would leave that decision to someone
who is more educated then I...
credentials to bind to LDAP rather than a "system" account that has
read and/or write access across the tree. For most applications this
works fine, but there are some places in Horde where it is necessary
to access other users' information. For example: when resolving a
user ID into a friendly name, an Identity object is created (backed by
Prefs) which is used to try to look up the Personal Information. If
you are using LDAP to store prefs, and LDAP is configured to use the
user's own credentials rather than a single system-type credential,
this operation fails.
The question, though, is how to solve it? In my own environments I
have created a Horde user in LDAP that has the appropriate access to
all users so it avoids this problem. But one of the configuration
options we allow in Horde currently is to use the user's own
credentials when binding to LDAP. Do we need to deprecate that
feature or make Identity lookup failurs (and other similar cross-user
Prefs actions) fail silently since they are "soft" errors?
Assigned to Michael Rubinsky
Assigned to Ben Klang
Assigned to ben
State ⇒ Assigned
May 15 10:03:00 HORDE [debug] [horde] Connected to the following
memcache servers:localhost:11211 [pid 1577 on line 127 of
"/usr/share/horde/lib/Horde/Memcache.php"]
May 15 10:03:00 HORDE [debug] [wicked] Wicked_Driver_sql::_retrieve():
SELECT * FROM wicked_pages WHERE page_name = 'Server_Setup' [pid 1577
on line 927 of "/usr/share/horde/wicked/lib/Driver/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked]
Wicked_Driver_sql::logPageView(Server_Setup): UPDATE wicked_pages SET
page_hits = page_hits + 1 WHERE page_name = ? [pid 1577 on line 558 of
"/usr/share/horde/wicked/lib/Driver/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Wicked_Driver_sql::getPages():
SELECT page_id, page_name FROM wicked_pages [pid 1577 on line 763 of
"/usr/share/horde/wicked/lib/Driver/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Cache miss:
perm_exists_wicked:pages:3 (Id b388c006a6ca2417ee65b88de6435e97 newer
than 1242259380) [pid 1577 on line 169 of
"/usr/share/horde/lib/Horde/Cache/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] SQL Query by
DataTree_sql::_exists(): SELECT datatree_id FROM horde_datatree WHERE
group_uid = ? AND datatree_name = ? AND datatree_parents = ?, array (
0 => 'horde.perms',
1 => 'wicked',
2 => '',
) [pid 1577 on line 398 of "/usr/share/horde/lib/Horde/DataTree/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] SQL Query by
DataTree_sql::_exists(): SELECT datatree_id FROM horde_datatree WHERE
group_uid = ? AND datatree_name = ? AND datatree_parents = ?, array (
0 => 'horde.perms',
1 => 'pages',
2 => ':83',
) [pid 1577 on line 398 of "/usr/share/horde/lib/Horde/DataTree/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] SQL Query by
DataTree_sql::_exists(): SELECT datatree_id FROM horde_datatree WHERE
group_uid = ? AND datatree_name = ? AND datatree_parents = ?, array (
0 => 'horde.perms',
1 => '3',
2 => ':83:84',
) [pid 1577 on line 398 of "/usr/share/horde/lib/Horde/DataTree/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Cache set:
perm_exists_wicked:pages:3 (Id b388c006a6ca2417ee65b88de6435e97 set at
1242345780 expires at 1242432180) [pid 1577 on line 211 of
"/usr/share/horde/lib/Horde/Cache/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] 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 1577 on line 148
of "/usr/share/horde/lib/Horde/Alarm/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Cache hit:
perm_exists_wicked:pages:3 (Id b388c006a6ca2417ee65b88de6435e97 newer
than 1242259380) [pid 1577 on line 175 of
"/usr/share/horde/lib/Horde/Cache/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Wicked_Driver_sql::_retrieve():
SELECT * FROM wicked_attachments WHERE page_id = 3 [pid 1577 on line
927 of "/usr/share/horde/wicked/lib/Driver/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Cache hit:
perm_exists_wicked:pages:3 (Id b388c006a6ca2417ee65b88de6435e97 newer
than 1242259380) [pid 1577 on line 175 of
"/usr/share/horde/lib/Horde/Cache/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Cache hit:
perm_exists_wicked:pages:3 (Id b388c006a6ca2417ee65b88de6435e97 newer
than 1242259380) [pid 1577 on line 175 of
"/usr/share/horde/lib/Horde/Cache/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Cache hit:
perm_exists_wicked:pages:3 (Id b388c006a6ca2417ee65b88de6435e97 newer
than 1242259380) [pid 1577 on line 175 of
"/usr/share/horde/lib/Horde/Cache/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Cache hit:
perm_exists_wicked:pages:3 (Id b388c006a6ca2417ee65b88de6435e97 newer
than 1242259380) [pid 1577 on line 175 of
"/usr/share/horde/lib/Horde/Cache/sql.php"]
May 15 10:03:00 HORDE [debug] [wicked] Cache hit:
perm_exists_wicked:pages:3 (Id b388c006a6ca2417ee65b88de6435e97 newer
than 1242259380) [pid 1577 on line 175 of
"/usr/share/horde/lib/Horde/Cache/sql.php"]
May 15 10:03:00 HORDE [error] [wicked] Error rebinding for prefs
writing: [53]: Server is unwilling to perform [pid 1577 on line 270 of
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]
May 15 10:03:00 HORDE [error] [wicked] Internal LDAP error. Details
have been logged for the administrator. [pid 1577 on line 348 of
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]
May 15 10:03:00 HORDE [error] [wicked] Error rebinding for prefs
writing: [53]: Server is unwilling to perform [pid 1577 on line 270 of
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]
May 15 10:03:00 HORDE [error] [wicked] Internal LDAP error. Details
have been logged for the administrator. [pid 1577 on line 348 of
"/usr/share/horde/lib/Horde/Prefs/ldap.php"]
May 15 10:03:00 HORDE [debug] [wicked] Cache hit:
perm_exists_wicked:pages:3 (Id b388c006a6ca2417ee65b88de6435e97 newer
than 1242259380) [pid 1577 on line 175 of
"/usr/share/horde/lib/Horde/Cache/sql.php"]
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Queue ⇒ Wicked
Summary ⇒ Wicked tries (and fails) to bind to LDAP as Page creator
Type ⇒ Bug
When accessing a page in Wicked that has been created by another user,
Wicked makes a call to LDAP and tries to bind as the page author. The
first time after logging on that this occurs results in an error: "The
preferences backend is currently unavailable and your preferences have
not been loaded. You may continue to use the system with default
settings."
LDAP log:
May 14 00:47:55 server01 slapd[1156]: conn=113175 op=2 BIND
dn="uid=simon,ou=users,dc=simonandkate,dc=lan" method=128
May 14 00:47:55 server01 slapd[1156]: conn=113175 op=2 RESULT tag=97
err=53 text=unauthenticated bind (DN with no password) disallowed
On subsequent page accesses the error is still logged by LDAP, but the
error message in Horde appears to be suppressed.
This appears to be occurring across several of the Horde apps, see
other bug tickets logged over last few weeks - 8269, 8251, 8246, 7418.
Jan I notice has commented in a couple of them (in the Kronolith and
Nag tickets) as to the user being called not necessarily being the
current user. It would appear there is a basic setup issue with the
way I (and at least one other) am using LDAP and the Horde code.
I am happy to provide details of my LDAP setup if it will help anyone
debugging why Horde is trying to do this.