Chris wrote: > Using opensolaris 2008.11 with an updated image. I dont think it matters but > I am within a ipkg branded zone. > > installed: > SUNWapch22 > SUNWapr13 > SUNWapu13 > SUNWapu13-ldap > > in order to test, in the default <location /> I just add: > > AuthType basic > AuthName "svn repository" > AuthBasicProvider ldap > AuthLDAPUrl ldap://192.168.2.50/ou=people,dc=domain,dc=com >
Do you need "require valid-user" or other require as well? (that wouldn't explain your error) I'm not having any troubles with a very similar setup using the stock 2008.11 Apache build. > Then when i tried to access the given url, nothing appear. > odd; I'd expect the browser to prompt for user/pass again; did you get something besides 401 in the access log? > Apache log reveals (from the begining of the process): > > [Sun Feb 15 04:09:01 2009] [info] Init: Seeding PRNG with 136 bytes of entropy > [Sun Feb 15 04:09:01 2009] [info] Init: Generating temporary RSA private keys > (512/1024 bits) > [Sun Feb 15 04:09:01 2009] [info] Init: Generating temporary DH parameters > (512/1024 bits) > [Sun Feb 15 04:09:01 2009] [warn] Init: Session Cache is not configured > [hint: SSLSessionCache] > [Sun Feb 15 04:09:01 2009] [info] Init: Initializing (virtual) servers for SSL > [Sun Feb 15 04:09:01 2009] [info] mod_ssl/2.2.11 compiled against Server: > Apache/2.2.11, Library: OpenSSL/0.9.8a > [Sun Feb 15 04:09:01 2009] [info] Init: Seeding PRNG with 136 bytes of entropy > [Sun Feb 15 04:09:01 2009] [info] Init: Generating temporary RSA private keys > (512/1024 bits) > [Sun Feb 15 04:09:01 2009] [info] Init: Generating temporary DH parameters > (512/1024 bits) > [Sun Feb 15 04:09:01 2009] [info] Init: Initializing (virtual) servers for SSL > [Sun Feb 15 04:09:01 2009] [info] mod_ssl/2.2.11 compiled against Server: > Apache/2.2.11, Library: OpenSSL/0.9.8a > [Sun Feb 15 04:09:01 2009] [info] APR LDAP: Built with Sun Microsystems Inc. > LDAP SDK > [Sun Feb 15 04:09:01 2009] [info] LDAP: SSL support unavailable: LDAP: > ldapssl_client_init() failed. > [Sun Feb 15 04:09:01 2009] [notice] Apache/2.2.11 (Unix) mod_ssl/2.2.11 > OpenSSL/0.9.8a DAV/2 configured -- resuming normal operations > [Sun Feb 15 04:09:01 2009] [info] Server built: Feb 15 2009 03:46:54 > [Sun Feb 15 04:09:01 2009] [debug] prefork.c(1001): AcceptMutex: fcntl > (default: fcntl) > [Sun Feb 15 04:09:07 2009] [debug] mod_authnz_ldap.c(377): [client > 192.168.4.116] [23094] auth_ldap authenticate: using URL > ldap://192.168.2.50/ou=people,dc=domain,dc=com > [Sun Feb 15 04:09:07 2009] [warn] [client 192.168.4.116] [23094] auth_ldap > authenticate: user jelan authentication failed; URI / [LDAP: > ldap_simple_bind_s() failed][Can't connect to the LDAP server] > > > ldapclient/ldaplist works fine however: > root at code:/usr/local/apache2/logs# ldapclient list > NS_LDAP_FILE_VERSION= 2.0 > NS_LDAP_BINDDN= cn=proxyagent,ou=people,dc=domain,dc=com > NS_LDAP_BINDPASSWD= {NS1}4a3788e8c053424f > NS_LDAP_SERVERS= 192.168.2.50 > NS_LDAP_SEARCH_BASEDN= dc=domain,dc=com > NS_LDAP_CACHETTL= 0 > > root at code:/usr/local/apache2/logs# ldaplist > dn: ou=people,dc=domain,dc=com > From "ldapclient list", which shows binddn and bindpasswd, I guess your LDAP server doesn't allow anonymous binds? Have you tried using AuthLDAPBindDN and AuthLDAPBindPassword? (see http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html#authldapbinddn) (Disclaimer: I don't really understand the connection between that output and the Apache config, but there seem to be some discrepancies in the Apache configuration. The base DN is a tiny bit different too.) > I tried pretty much everything I could think off (using SUNW packages, > compiling httpd manually with included apr/apr-util, https and > apr/apr-utils), same result every time... > > Tried with openldap from blastwave, not much luck either. > The stock build should be fine for non-SSL connections to the ldap server. > Any ideas ? Any hep would be very much appreciated ! > Have you tried using the ldapsearch command as a simple test outside of Apache? You can get "Can't connect to the LDAP server" for simple errors like bad IP or bad port, but I suspect you can also get them for application-level bind failures. You may need to check your LDAP server logs as well to help diagnose application layer issues.
