Thu, 09 Apr 2026 17:14:43 +0000 https://bugs.horde.org/ticket/7640 LDAP Authentication not working I've got Horde 3.3 LDAP authentication configured exactly the same way as I had it in 3.1 and it refuses to authenticate. Originally I had the message "Empty Result" and applied the fix from ticket #6362. I might add that although this fix is marked as having been applied to HEAD in March 2008, it is still not in the final release code so might have gotten overlooked. Regardless, I now get the message "Login failed." The horde.log entries don't tell me much, other than the fact that the login failed. I'm authenticating against an AD v.3 server using SSL (ldaps://) with md5-hex password encryption, and when I go back to Horde 3.1 with the same exact configuration, it allows me to log in with no problem. I can't really provide more information based on the debug info. I'm getting. Is there something I can do to get a better handle on what's going on in the background? I removed the '@' form all the ldap statements in lib/Horde/Auth/ldap.php and didn't see any errors. Thanks! Wed, 05 Nov 2008 15:48:50 +0000 https://bugs.horde.org/ticket/7640#t50279 Does login to the new Horde install work with any other auth backend? Is there anything in the LDAP server logs? Thu, 06 Nov 2008 05:26:24 +0000 https://bugs.horde.org/ticket/7640#t50372 I just tried it with both 'auto' and 'sql' with local accounts and they both work fine. I should add that I've tested this on several different Ubuntu and Fedora servers running both PHP4 and PHP5 and it won't do LDAP authentication at all. Running the 3.1 version on all of these machines works fine. > Does login to the new Horde install work with any other auth backend? > Is there anything in the LDAP server logs? Thu, 06 Nov 2008 13:36:21 +0000 https://bugs.horde.org/ticket/7640#t50397 It also works with IMAP authentication; the IMAP server is LDAP authenticated so the same credentials can be used. > Does login to the new Horde install work with any other auth backend? > Is there anything in the LDAP server logs? Thu, 06 Nov 2008 13:41:21 +0000 https://bugs.horde.org/ticket/7640#t50399 We're looking at the LDAP logs... > It also works with IMAP authentication; the IMAP server is LDAP > authenticated so the same credentials can be used. > >> Does login to the new Horde install work with any other auth backend? >> Is there anything in the LDAP server logs? > Thu, 06 Nov 2008 14:59:31 +0000 https://bugs.horde.org/ticket/7640#t50401 The LDAP logs are clean. Lots of entries that look like this (proprietary info. replaced with 'x'): Nov 6 03:39:59 xxxxxx slapd[5541]: conn=xxxxxxx fd=xx ACCEPT from IP=xxx.xxx.xxx.xxx:xxxxx (IP=0.0.0.0:636) > Does login to the new Horde install work with any other auth backend? > Is there anything in the LDAP server logs? Thu, 06 Nov 2008 18:33:53 +0000 https://bugs.horde.org/ticket/7640#t50411 If I had to guess, looking at the changes to the LDAP auth driver between 3.1 and 3.3, this one stands out: http://cvs.horde.org/diff.php/framework/Auth/Auth/ldap.php?r1=1.89&r2=1.90 However, it'd be helpful to get something saying _what_ is failing. Shouldn't there be authentication attempts in the LDAP logs? Or is login failing something else on the PHP side in the LDAP driver? Ben K., bringing you in on this since you've authored most changes to the driver lately. Kristian, the next troubleshooting technique here, aside from putting in debug code, is probably for you to try the different versions between 3.1 and 3.3 (http://cvs.horde.org/framework/Auth/Auth/ldap.php) and see at what point it breaks. Fri, 07 Nov 2008 03:12:13 +0000 https://bugs.horde.org/ticket/7640#t50423 > However, it'd be helpful to get something saying _what_ is failing. > Shouldn't there be authentication attempts in the LDAP logs? Or is > login failing something else on the PHP side in the LDAP driver? That's what it looks like so far--like the LDAP auth is fine, but something else between that step and actually being logged into Horde is gumming things up. > Kristian, the next troubleshooting technique here, aside from putting > in debug code, is probably for you to try the different versions > between 3.1 and 3.3 > (http://cvs.horde.org/framework/Auth/Auth/ldap.php) and see at what > point it breaks. I'll do that today and maybe diff the one that breaks to see what's changed. Fri, 07 Nov 2008 12:39:13 +0000 https://bugs.horde.org/ticket/7640#t50442 I started with the version I'm currently running (3.1.6) on my production servers, and worked my way up, one release at a time, following this testing process: - unpack horde-x.x.x and rename as 'horde' - add .htaccess with 'Allow from all' and 'DirectoryIndex index.php' - chmod 777 horde/config - execute 'for f in *.dist; do cp $f `basename $f .dist`; done' in horde/config - chmod 666 *.* in horde/config - open web browser and clear cache, cookies, etc. - point browser to /horde on test server (automatically logs in as Administrator first time) - Setup -> horde -> Authentication - select 'LDAP authentication' and configure for ldap server - Setup -> horde -> Preference System - select 'PHP Sessions' - Log out - Log in Version 3.1.9 is the last version in which LDAP authentication works for me with the settings I've always used. I also noticed that 3.2 is the first version in which the default password encryption is not md5-hex in the Authentication setup form; just in case that's relevant. Attached is a diff of the changes between horde/lib/Horde/Auth/ldap.php on version 3.1.9 and 3.2. Fri, 07 Nov 2008 13:43:10 +0000 https://bugs.horde.org/ticket/7640#t50443 Ooookay. Lets try that attachment with a .patch extension...? Fri, 07 Nov 2008 13:47:40 +0000 https://bugs.horde.org/ticket/7640#t50445 I've narrowed it down to this change, which, when I revert back to the old code, allows me to log in successfully: @@ -135,9 +147,11 @@ function _findDN($userId) { /* Search for the user's full DN. */ + $filter = $this->_getParamFilter(); + $filter = '(&(' . $this->_params['uid'] . '=' . $userId . ')' . + $filter . ')'; $search = @ldap_search($this->_ds, $this->_params['basedn'], - $this->_params['uid'] . '=' . $userId, - array($this->_params['uid'])); + $filter, array($this->_params['uid'])); Fri, 07 Nov 2008 14:12:23 +0000 https://bugs.horde.org/ticket/7640#t50446 The rest of the code isn't really functionally different, just formatted differently. The $filter value is pretty much the only thing that's changed: Currently, its value is this: '(&(' . $this->_params['uid'] . '=' . $userId . ')' . $this->_getParamFilter() . ')'; ...and it used to be this: $this->_params['uid'] . '=' . $userId, array($this->_params['uid'] Fri, 07 Nov 2008 14:19:33 +0000 https://bugs.horde.org/ticket/7640#t50447 Correction: That last line should be this: $this->_params['uid'] . '=' . $userId; ...not this: > $this->_params['uid'] . '=' . $userId, array($this->_params['uid'] Fri, 07 Nov 2008 14:26:56 +0000 https://bugs.horde.org/ticket/7640#t50448 So it is http://cvs.horde.org/diff.php/framework/Auth/Auth/ldap.php?r1=1.89&r2=1.90. Ben, can you advise on this? I presume a config setting change is in order, but I don't know. Fri, 07 Nov 2008 20:27:30 +0000 https://bugs.horde.org/ticket/7640#t50463 While trying to figure out another problem (http://bugs.horde.org/ticket/7900) related to not being able to see LDAP users in permissions forms, I landed on the ExistingLDAPHowTo (http://wiki.horde.org/ExistingLDAPHowTo) web page on the horde site and went through the process of checking my LDAP config. As it turns out, a value that I used to use for the objectClass, 'uid', is no longer valid. It was probably never valid, but Horde 3.3 enforces the rules properly. I have replaced this value with 'shadowAccount' and that has resolved this problem. > So it is > http://cvs.horde.org/diff.php/framework/Auth/Auth/ldap.php?r1=1.89&r2=1.90. > Ben, can you advise on this? I presume a config setting change is in > order, but I don't know. Fri, 30 Jan 2009 16:26:55 +0000 https://bugs.horde.org/ticket/7640#t52152 Sounds like this was resolved. Thu, 18 Oct 2012 05:20:58 +0000 https://bugs.horde.org/ticket/7640#t73793