Sounds like this was resolved.

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.

Correction:



That last line should be this:



$this->_params['uid'] . '=' . $userId;



...not this:

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

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']));

Ooookay. Lets try that attachment with a .patch extension...?

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.

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.
I'll do that today and maybe diff the one that breaks to see what's changed.

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.

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)

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.

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?

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!