Error: auth_ldap authenticate: user myself authentication failed; URI /test/ [LDAP: ldap_simple_bind_s() failed][Can't connect to the LDAP server] My config: AuthLDAPUrl "ldap://1.2.3.4:389/ou=group,dc=xyz,dc=de?uid?one" NONE Reason: File srclib/apr-util/ldap/apr_ldap_init.c Row 149, Function apr_ldap_init [snip] #if APR_HAS_LDAPSSL_INIT *ldap = ldapssl_init(hostname, portno, 0); #elif APR_HAS_LDAP_SSLINIT *ldap = ldap_sslinit((char *)hostname, portno, 0); #else *ldap = ldap_init((char *)hostname, portno); #endif [/snip] It uses ldapssl_init to open an SSL-less connection. What the hell? ;-) My change is: [snip] #if APR_HAS_LDAPSSL_INIT // *ldap = ldapssl_init(hostname, portno, 0); *ldap = ldap_init((char *)hostname, portno); #elif APR_HAS_LDAP_SSLINIT *ldap = ldap_sslinit((char *)hostname, portno, 0); #else *ldap = ldap_init((char *)hostname, portno); #endif [/snip] Everything works :)
There is something else going on in your environment. ldapssl_init() doesn't actually create a connection or talk over SSL to an ldap server. It just prepares the client connection handle to allow an SSL connections if necessary. The resulting handle could be used to make a non-ssl connection or an ssl connection. In fact ldapssl_init(..., 0) is functionally equivalent to ldap_init(...). If Solaris requires some additional special handling, then that would need to be identified and handled separately. SSL is one of the areas that is very different between SDKs.
I dont think, that my environment is weird. Its a fresh Solaris 10 install with all latest patch clusters. My configure command is: ./configure --prefix=/opt/local/app/apache-2.2.4 --enable-mods-shared=most --enable-so --with-mpm=worker --enable-nonportable-atomics --disable-userdir --disable-authn-dbd --disable-authn-dbm --disable-authz-dbm --disable-authnz-ldap --disable-status --disable-dbd --disable-dav --disable-dav-fs --disable-dav-lock --disable-cgi --enable-cgid --enable-unique-id --enable-suexec --with-suexec-caller=webservd --with-suexec-docroot=/data/web --with-suexec-uidmin=100 --with-suexec-gidmin=100 --with-suexec-logfile=/data/logs/suexec_log --enable-ssl --enable-authnz-ldap --enable-ldap --with-ldap-lib=/usr/lib --with-ldap-include=/usr/include --with-ldap=yes --with-ssl=/opt/local --enable-proxy --enable-proxy-http The SUN LDAP packages SUNWhea SUNWlldap are installed. No OpenLDAP and no SFW LDAP (like SFWoldap). $ ls -l /usr/include/*ldap* -rw-r--r-- 1 root bin 56030 Jan 21 2005 /usr/include/ldap.h $ ls -l /usr/lib/*ldap* lrwxrwxrwx 1 root root 12 Feb 13 2007 /usr/lib/libldap.so -> libldap.so.5 -rwxr-xr-x 1 root bin 214076 Jan 23 2005 /usr/lib/libldap.so.4 -rwxr-xr-x 1 root bin 367208 Jan 24 2007 /usr/lib/libldap.so.5 lrwxrwxrwx 1 root root 13 Feb 13 2007 /usr/lib/libsldap.so -> libsldap.so.1 -rwxr-xr-x 1 root bin 233416 Jan 24 2007 /usr/lib/libsldap.so.1 -rw-r--r-- 1 root bin 18479 Jan 22 2005 /usr/lib/llib-lldap -rw-r--r-- 1 root bin 78630 May 29 06:03 /usr/lib/llib-lldap.ln -rw-r--r-- 1 root bin 3490 Jan 22 2005 /usr/lib/llib-lsldap -rw-r--r-- 1 root bin 86080 May 29 06:04 /usr/lib/llib-lsldap.ln -rwxr-xr-x 1 root bin 116764 May 29 20:49 /usr/lib/nss_ldap.so.1 /usr/lib/ldap: total 388 -r-xr-xr-x 1 root bin 131282 Nov 7 2006 idsconfig -r-xr-xr-x 1 root bin 50532 Jan 23 2005 ldap_cachemgr How I said, there is nothing weird. I would laugh if any other user can use the .htaccess authorization against LDAP without SSL with these SUN LDAP libs without a patch. And in fact I dont know if the ldapssl_init(..., 0) and ldap_init(...) are really equivalent in the SUN LDAP implementation. But I dont think so, otherwise both versions should work.
The LDAP functionality has been tested with OpenLDAP, Novell LDAP and Netscape LDAP SDKs. To my knowledge, no real testing or integration has been done against the SUN LDAP SDK. As I mentioned before, SSL is one of those tricky parts that usually functions differently between SDKs. I would expect that somebody who knows a lot more about the SUN LDAP SDK than I do, needs to work up and submit some patches so that it works correctly and doesn't break the other platforms.
Is this in fact the same underlying bug as PR 42682? In other words, does your fix to that bug deal with this one too? You've posted another fix to the same line of code here.
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.