Fri, 10 Apr 2026 17:02:23 +0000 https://bugs.horde.org/ticket/7418 Unable to write filters to prefs with ldap backend (binds without password) I have horde setup to let imp handle the authentication. Imp talks to cyrus which talks to ldap. I have no problems logging in. I have set up Ingo to use the 'prefs' storage driver. Ingo can read and publish filters just fine using the timsieved driver. Unfortunately Ingo fails when trying to write the filters to prefs/ldap. According to the ldap.log this is because it is trying to bind without a password. It is however possible to change the 'Update script...' setting. Settings in other modules are also saved fine. Versions: horde-ingo-1.2.1-1mdv2008.1 horde-imp-4.2-2mdv2008.1 horde-3.2.2-1mdv2008.1 Additional information: $conf['prefs']['maxsize'] = 2147483647; $conf['prefs']['params']['hostspec'] = 'localhost'; $conf['prefs']['params']['port'] = 389; $conf['prefs']['params']['version'] = '3'; $conf['prefs']['params']['basedn'] = 'ou=MailAccounts,dc=example,dc=com'; $conf['prefs']['params']['writedn'] = 'user'; $conf['prefs']['params']['uid'] = 'uid'; $conf['prefs']['driver'] = 'ldap'; $conf['auth']['admins'] = array('Administrator', 'johnil'); $conf['auth']['checkip'] = true; $conf['auth']['checkbrowser'] = true; $conf['auth']['alternate_login'] = false; $conf['auth']['redirect_on_logout'] = false; $conf['auth']['params']['app'] = 'imp'; $conf['auth']['driver'] = 'application'; I added this (at line 241) to Prefs/ldap.php: Horde::logMessage("Inside trying to rebind as :".$this->_dn." with: ".$this->_password, __FILE__, __LINE__, PEAR_LOG_NOTICE); From horde.log: Sep 30 21:01:41 HORDE [notice] [ingo] Inside trying to rebind as :mail=johannes.nilsson@example.com,ou=MailAccounts,dc=example,dc=com with: [pid 925 on line 241 of "/usr/share/horde/lib/Horde/Prefs/ldap.php"] Sep 30 21:01:41 HORDE [error] [ingo] Error rebinding for prefs writing: [53]: Server is unwilling to perform [pid 925 on line 260 of "/usr/share/horde/lib/Horde/Prefs/ldap.php"] Sep 30 21:01:41 HORDE [error] [ingo] Internal LDAP error. Details have been logged for the administrator. [pid 925 on line 338 of "/usr/share/horde/lib/Horde/Prefs/ldap.php"] And ldap.log: Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 fd=54 ACCEPT from IP=127.0.0.1:35658 (IP=0.0.0.0:389) Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=0 SRCH base="ou=MailAccounts,dc=example,dc=com" scope=2 deref=0 filter="(uid=johnil)" Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=0 SRCH attr=dn Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=1 BIND dn="mail=johannes.nilsson@example.com,ou=MailAccounts,dc=example,dc=com" method=128 Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=1 RESULT tag=97 err=53 text=unauthenticated bind (DN with no password) disallowed Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 fd=55 ACCEPT from IP=127.0.0.1:35659 (IP=0.0.0.0:389) Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 op=0 SRCH base="ou=MailAccounts,dc=example,dc=com" scope=2 deref=0 filter="(uid=johnil)" Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 op=1 UNBIND Sep 30 21:01:41 mettemauge slapd[17113]: conn=18316 fd=55 closed Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 fd=55 ACCEPT from IP=127.0.0.1:35660 (IP=0.0.0.0:389) Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 op=0 SRCH base="ou=MailAccounts,dc=example,dc=com" scope=2 deref=0 filter="(uid=johnil)" Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 op=1 UNBIND Sep 30 21:01:41 mettemauge slapd[17113]: conn=18317 fd=55 closed Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 op=2 UNBIND Sep 30 21:01:41 mettemauge slapd[17113]: conn=18315 fd=54 closed Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 fd=54 ACCEPT from IP=127.0.0.1:35661 (IP=0.0.0.0:389) Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=0 SRCH base="ou=MailAccounts,dc=example,dc=com" scope=2 deref=0 filter="(uid=johnil)" Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=0 SRCH attr=dn Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=1 BIND dn="mail=johannes.nilsson@example.com,ou=MailAccounts,dc=example,dc=com" method=128 Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=1 RESULT tag=97 err=53 text=unauthenticated bind (DN with no password) disallowed Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 op=2 UNBIND Sep 30 21:01:41 mettemauge slapd[17113]: conn=18318 fd=54 closed Tue, 30 Sep 2008 19:20:39 +0000 https://bugs.horde.org/ticket/7418#t49317 > I have horde setup to let imp handle the authentication. I just changed this to let horde handle the authentication itself (auth driver ldap). It works fine, but made no difference to the filter problem. Tue, 30 Sep 2008 20:34:23 +0000 https://bugs.horde.org/ticket/7418#t49318 I am also having this issue when using the LDAP backend for Prefs with horde 3.3.2/ingo 1.2.1. I did not have this issue with horde 3.1.1. I have located the cause of the issue and implemented a *workaround* in my install to allow it to work. In ingo/lib/Storage/prefs.php lines 38-40 an instance of the Prefs singleton is generated but w/ a blank password (the 4th argument). If I set the 4th arg to Auth::getCredential('password') then ingo works correctly.. I also am changing that on line 139. back in horde 3.1.x ingo's pref driver would access a global $prefs object instead of using the singleton object. Wed, 31 Dec 2008 03:22:39 +0000 https://bugs.horde.org/ticket/7418#t51521 OK, if I remove arguments 4-6 don't set a password, and more importantly don't override the 6th argument ($cache) with false and leave the default to TRUE, it works as well.. Is there any specific reason WHY in the case of ingo, the 6th arg is set to false???? Wed, 31 Dec 2008 03:25:40 +0000 https://bugs.horde.org/ticket/7418#t51522 I have the same problem using kolab. Is there a solution for this? Will there be a patch? Fri, 16 Jan 2009 11:00:04 +0000 https://bugs.horde.org/ticket/7418#t51769 > I have the same problem using kolab. Is there a solution for this? > Will there be a patch? Ditto - exactly the same issue. CVS is the same. When set to LDAP backend, Ingo tries to bind unauth and gets rejected. Result is that when you first go to Filters after logging on, you get the Preferences unavailable message, and no filters are saved from the session. Set to SQL backend it is fine, although some actions still seem to trigger a call to the preferences system in my setup (LDAP) and return the same message, but with no functionality impact that I can see. Sat, 04 Apr 2009 15:11:21 +0000 https://bugs.horde.org/ticket/7418#t53512 I can confirm this bug, too. The users password is needed when the option $conf['prefs']['params']['writedn'] in the horde conf.php is set to 'user'. Adding the users password as the fourth argument in the "$prefs = &Prefs::singleton" call fixed this issue for me. Thank you urkle for this tip (Comment #3)! Sadly, this bug appears not only in ingo but in kronolith and some other horde apps, too. I did a quick search in my horde directory and found many other calls to the Prefs::singleton function, where the password argument is an empty string. So, is there a reason why applications should not pass the users passwort to the singleton function? I would prefer the method of writing preferences to the LDAP as the logged-in user instead of writing as admin. Thank you in advance! Fri, 17 Apr 2009 14:49:48 +0000 https://bugs.horde.org/ticket/7418#t53757 At least in those cases where we explicitly use the current user's preferences, i.e. where we don't try to access preferences of other users, this makes sense. A patch that fixes all those places would be great. Fri, 17 Apr 2009 15:19:08 +0000 https://bugs.horde.org/ticket/7418#t53758 attached a patch for ingo > At least in those cases where we explicitly use the current user's > preferences, i.e. where we don't try to access preferences of other > users, this makes sense. A patch that fixes all those places would be > great. Mon, 04 May 2009 12:31:08 +0000 https://bugs.horde.org/ticket/7418#t53994 The patch fixes it for me... Mostly... :) Thanks. This patch means that the rules are successfully entered in LDAP, and are remembered, so functionally at least I am now able to store the rules in LDAP along with all other preferences. There's still an issue somewhere though, not sure where - Ingo is still trying to do an LDAP binds as user somewhere without a password being obtained. Ingo throws 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" under the following circumstances: With Ingo prefs set to use preference system, which is set in Horde setup to LDAP, logout. Login, go to Filters, and click on the Spam rule. It throws the error. However, any changes that are made are successfully retained. Any future access to the Spam rule in the current session does NOT throw the error. The error appears to be cosmetic only, as full functionality is retained. I can reproduce the same error under the same circumstances with Ingo set to use SQL for preferences, so Ingo is still trying to do an anonymous LDAP bind somewhere else. My LDAP logs confirm: May 5 11:32:28 server01 slapd[1156]: conn=66725 op=2 BIND dn="uid=simon,ou=users,dc=simonandkate,dc=lan" method=128 May 5 11:32:28 server01 slapd[1156]: conn=66725 op=2 RESULT tag=97 err=53 text=unauthenticated bind (DN with no password) disallowed As stated, these occur with either preferences system / LDAP backend or SQL backend. Tue, 05 May 2009 01:58:55 +0000 https://bugs.horde.org/ticket/7418#t53998 Found it! :) ingo/lib/Storage.php - it also has the "Ingo::getUser(), '', null, false);" line that it calls to try and find . I replaced that with "Ingo::getUser(), Auth::getCredential('password'), null, false);" and it has resolved the issue. Patch file attached. never done one before, so I hope it's OK. Tue, 05 May 2009 02:16:32 +0000 https://bugs.horde.org/ticket/7418#t53999 > Found it! :) > > ingo/lib/Storage.php - it also has the "Ingo::getUser(), '', null, > false);" line that it calls to try and find . I replaced that with > "Ingo::getUser(), Auth::getCredential('password'), null, false);" and > it has resolved the issue. > > Patch file attached. never done one before, so I hope it's OK. > Patch file was "diff'ed" the wrong way :) Can someone with permissions remove the earlier one please? Tue, 05 May 2009 03:05:37 +0000 https://bugs.horde.org/ticket/7418#t54000 Kronolith is doing the same thing. With LDAP preference backend set, first new calendar entry after a login generates a bind as user with no password and the "Preference system not available message". LDAP log entry: May 6 18:25:18 server01 slapd[1156]: conn=73358 op=2 BIND dn="uid=simon,ou=users,dc=simonandkate,dc=lan" method=128 May 6 18:25:18 server01 slapd[1156]: conn=73358 op=2 RESULT tag=97 err=53 text=unauthenticated bind (DN with no password) disallowed Should I do a new bug report? Wed, 06 May 2009 09:59:54 +0000 https://bugs.horde.org/ticket/7418#t54015 > Kronolith is doing the same thing. > Should I do a new bug report? I see you already did this for kronolith: http://bugs.horde.org/ticket/8246 I've created another bug for nag: http://bugs.horde.org/ticket/8251 Now for ingo, we have two patches, fixing the following three places: > ingo/lib/Storage.php:749: $prefs = Prefs::factory($GLOBALS['conf']['prefs']['driver'], fixed with storagephp(2).patch > ingo/lib/Storage/prefs.php:36: $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'], fixed with 0001-fix-7418-Unable-to-write-filters-to-prefs-wit.patch > ingo/lib/Storage/prefs.php:133: $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'], fixed with 0001-fix-7418-Unable-to-write-filters-to-prefs-wit.patch Thu, 07 May 2009 13:37:41 +0000 https://bugs.horde.org/ticket/7418#t54036 Closed in favor of the catch-all ticket #8353. Tue, 16 Jun 2009 13:37:47 +0000 https://bugs.horde.org/ticket/7418#t54604