Bug 43249 - ldap_simple_bind_s failed when using SUN LDAP Libs w/o SSL
Summary: ldap_simple_bind_s failed when using SUN LDAP Libs w/o SSL
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_auth_ldap (show other bugs)
Version: 2.2.4
Hardware: Sun Solaris
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2007-08-30 03:58 UTC by Kevin Richter
Modified: 2018-11-07 21:10 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Richter 2007-08-30 03:58:37 UTC
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 :)
Comment 1 Brad Nicholes 2007-08-30 08:12:39 UTC
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. 
Comment 2 Kevin Richter 2007-08-30 12:26:52 UTC
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.

Comment 3 Brad Nicholes 2007-08-30 13:25:42 UTC
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.
Comment 4 Nick Kew 2009-11-15 15:31:10 UTC
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.
Comment 5 William A. Rowe Jr. 2018-11-07 21:10:00 UTC
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.