2

I am trying to get ldaps to work through Apache 2.2.17 (Windows Server 2008). If I use ldap (plain text) my configuration works great.

LDAPTrustedGlobalCert CA_DER C:/wamp/certs/Trusted_Root_Certificate.cer
LDAPVerifyServerCert Off
<Location />
    AuthLDAPBindDN "CN=corpsvcatlas,OU=Service Accounts,OU=u00958,OU=00958,DC=hca,DC=corpad,DC=net"
    AuthLDAPBindPassword ..removed..
    AuthLDAPURL "ldaps://gc-hca.corpad.net:3269/dc=hca,dc=corpad,dc=net?sAMAccountName?sub"
    AuthType Basic
    AuthName "USE YOUR WINDOWS ACCOUNT"
    AuthBasicProvider ldap
    AuthUserFile /dev/null
    require valid-user
</Location>

I also tried the other encryption choices besides CA_DER just to be safe, with no luck.

Finally, I also needed this with Apache tomcat. For tomcat I used the tomcat JRE and ran a line like this:

keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias mycert -file Trusted_Root_Certificate.cer

After doing the above line ldaps worked greate via tomcat. This lets me know that my certificate is a-ok.

Update: Both ldap modules are turned on, since using ldap instead of ldaps works fine.

When I run a git clone this is the error returned:

C:\Temp>git clone http://eqb9718@localhost/git/Liferay.git
Cloning into Liferay...
Password:
error: The requested URL returned error: 500 while accessing http://eqb9718@loca
lhost/git/Liferay.git/info/refs
fatal: HTTP request failed

access.log has this:

127.0.0.1 - eqb9718 [23/Nov/2011:18:25:12 -0600] "GET /git/Liferay.git/info/refs service=git-upload-pack HTTP/1.1" 500 535
127.0.0.1 - eqb9718 [23/Nov/2011:18:25:33 -0600] "GET /git/Liferay.git/info/refs HTTP/1.1" 500 535

apache_error.log has nothing. Is there any more verbose logging I can turn on or better tests to do?

Update 2: I can run wireshark on the apache server and I can clearly see the outgoing connection but I can't really make heads or tails of anything else. I'm no wireshark guru, just looks like jargon.

Also, I used ldap browser to verify that ldaps is working great from the machine.

Update 3: I turned apache logging to debug and this is the error coming back:

[3016] auth_ldap authenticate: user eqb9718 authentication failed; URI /git/Liferay.git/info/refs [LDAP: ldap_simple_bind_s() failed][Server Down]

Now keep in mind that on this same Server 2008 machine I can use LDAP Browser to connect via ldaps to port 3269 and nothing is "down". What is that error telling us?

Update 4: Here are the results from running openssl s_client -connect gc-hca.corpad.net: 3269 -showcerts: http://pastebin.com/2yEGN4C1

I have also tried the openssl command going directly to a domain controller on port 636 which works and I have tried it in my httpd.conf which produces the same error. I don't know if it is important to note that when I go directly to a controller (389 or 636) I have to add a container to the url like ou=group,dc=hca,etc. That makes using the GC a must. Must be a bug in mod_ldap since I found that solution from many other posts.

Update 5: I started up apache manually instead of via a service and this is the ldap debug that is printing out:

C:\wamp\bin\apache\Apache2.2.17\bin>httpd
[Thu Nov 24 19:19:08 2011] [debug] util_ldap.c(1769): LDAP: SSL verify server ce
rtificate - FALSE
[Thu Nov 24 19:19:08 2011] [debug] mod_authnz_ldap.c(1010): [3144] auth_ldap url
parse: `ldaps://gc-hca.corpad.net:3269/dc=hca,dc=corpad,dc=net?sAMAccountName?s  
ub?(objectClass=*)', Host: gc-hca.corpad.net:3269, Port: 3269, DN: dc=hca,dc=cor
pad,dc=net, attrib: sAMAccountName, scope: subtree, filter: (objectClass=*), con
nection mode: using SSL

1 Answer 1

2

Your LDAPVerifyServerCert Off is rendering the trusted root configuration inert - so trust is not an issue.

Are there really that number of spaces in OU=Service Accounts?

And do you have mod_ldap and mod_authnz_ldap enabled?

If neither of those are the issue, can you check your error logs for anything useful?

5
  • There are not that many spaces, it is just a problem when I pasted it in here. Both of those apache modules are enabled. Keep in mind when I change it from ldaps to ldap:// and the port to 3268 it works great over plain text. I also verified throug tomcat that ldaps works fine too. I will update the above post with logs and more information. Nov 24, 2011 at 0:27
  • I have added some more debug logging information. Nov 24, 2011 at 16:29
  • @user101956 Verify that the 3269 listener is working properly as an SSL listener, and actually presenting a certificate (I've seen cases where these listeners stay up but stop presenting a cert) - openssl s_client -connect gc-hca.corpad.net:3269 -showcerts. Also, any particular reason that you're using the global catalog instead of the normal listener? Maybe try 636. Nov 24, 2011 at 18:05
  • The connection using openssl (or LDAP Browser) works fine. I will update my above post with a link to the output of that (pastebin.com/2yEGN4C1). The Active Directory group tells me to use the GC, I assume for redundancy. However, I have tried pointing to one specific controller on port 636 and get the same error. Nov 24, 2011 at 21:04
  • Hrm. Maybe try against ldap://...:3268 with LDAPTrustedMode TLS to get it throwing a STARTTLS on that connection instead? The only other thing I can think of is a cert validation issue - can you verify that the trusted cert is in DER and not PEM format? And maybe try turning LDAPVerifyServerCert back to On? Nov 25, 2011 at 3:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .