when i capture the traffic between the AD and apache, i can see the bind happen, then the query, then the response with one record and proper sAMAccountName, but no subsequent bind to the LDAP server using the DN and the password passed by the HTTP client.
i can run the same exact query using ldapsearch and it gets back identical results (and captured traffic looks the same):
to be a bit more specific, what i am not seeing is another bind request to AD that looks like this:
----------- Lightweight Directory Access Protocol LDAP Message, Bind Request Message Id: 1 Message Type: Bind Request (0x00) Version: 3 DN: CN=Lastname\, Firstname,OU=Users-BLAH-BLAH,OU=BLAH2,DC=XYZ,DC=ABC,DC=com Auth Type: Simple (0x00) Password: user's password that i provided in the browser -----------
...followed by a successful response from AD.
it seems that the initial response to a search query that it got back from AD is unsatisfactory, so it does not even try to bind with the newly found name. any ideas why this is happening?
i even tried some other products (not apache) where AD auth works, and their network capture looks just like apache's, except they also do the second bind.
and that worked, confirming the theory that apache's ldap gets confused when encountering LDAP search result reference in the LDAP response from the initial search (see http://rafb.net/paste/results/9Duquf89.html). once OU has been provided, apache's LDAP works fine, since reference is not returned anymore.
however this is not an option for me, since in my case OU=BLAH* is actually referring to different campuses in multiple cities, so there is no single all-encompassing entity underneath the root of the AD that includes all the users.
fiddling with AuthLDAPDereferenceAliases (setting it to all available options) did not make any difference.
this behavior has been confirmed in 2.0.55 and 2.2.2 using openldap 2.3.21.
any suggestions on making it work while binding to the root of the tree?
compiled apache 2.2.2 with Sun Microsystems Inc. LDAP SDK that came with solaris:
$ pkginfo -l SUNWlldap PKGINST: SUNWlldap NAME: LDAP Libraries CATEGORY: system ARCH: sparc VERSION: 11.8.0,REV=2000.01.08.18.12 BASEDIR: / VENDOR: Sun Microsystems, Inc. DESC: Ldap libraries in for software development of dynamically linked executables PSTAMP: on28-patch20040428123135 INSTDATE: Aug 06 2004 06:00
apache behavior is the same - if i do not bind to the root directly, but provide OU, then it works. if i do not provide OU, it seems to get into a loop when it searches for the sAMAccountName, gets a result with a reference, searches the reference, unbinds, and then repeats the whole thing (i have network traces to confirm this). changing values of AuthLDAPDereferenceAliases has no effect on this behavior.
any suggestions? i think i am about ready to file a bug/enhancement report for ldap + active directory.
SOLVED. see this thread for more details: http://mail-archives.apache.org/mod_mbox/httpd-users/200606.mbox/%3cCF83BAA 719FD2C439D25CBB1C9D1D30203B5E...@HQ-MAIL4.ptcnet.ptc.com%3e
in short - use global catalog (http://tinyurl.com/pbhhr) instead of domain-level lookup. in order to do this, use port 3268 instead of 389.
now apache 2.0.55 and 2.2.2 work fine with bundled SUN LDAP SDK, as well as OpenLDAP.
the network trace looks exactly the way it should (no reference record returned by AD).
reading up on global catalog does not make it obvious that i should have used it, especially since other apps that rely on AD authentication work fine against port 389, ignoring the references (and we only have one domain).
just for the reference, this is my working 2.0.55 config:
