Ich versuche, LDAPs über Apache 2.2.17 (Windows Server 2008) zum Laufen zu bringen. Wenn ich LDAP (Klartext) verwende, funktioniert meine Konfiguration einwandfrei.
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>
Sicherheitshalber habe ich auch die anderen Verschlüsselungsoptionen außer CA_DER ausprobiert, jedoch ohne Erfolg.
Schließlich brauchte ich dies auch mit Apache Tomcat. Für Tomcat verwendete ich die Tomcat JRE und führte eine Zeile wie diese aus:
keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias mycert -file Trusted_Root_Certificate.cer
Nach der Ausführung der obigen Zeile funktionierte LDAP über Tomcat einwandfrei. Dadurch weiß ich, dass mein Zertifikat in Ordnung ist.
Update: Beide LDAP-Module sind aktiviert, da die Verwendung von LDAP anstelle von LDAPs problemlos funktioniert.
Wenn ich einen Git-Klon ausführe, wird folgender Fehler zurückgegeben:
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 enthält Folgendes:
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 enthält nichts. Kann ich ausführlichere Protokolle aktivieren oder bessere Tests durchführen?
Update 2: Ich kann Wireshark auf dem Apache-Server ausführen und die ausgehende Verbindung deutlich sehen, aber mit allem anderen komme ich nicht wirklich klar. Ich bin kein Wireshark-Guru, es sieht nur nach Fachjargon aus.
Außerdem habe ich den LDAP-Browser verwendet, um zu überprüfen, ob LDAPs auf dem Computer einwandfrei funktioniert.
Update 3: Ich habe die Apache-Protokollierung auf Debug umgestellt und dieser Fehler tritt erneut auf:
[3016] auth_ldap authenticate: user eqb9718 authentication failed; URI /git/Liferay.git/info/refs [LDAP: ldap_simple_bind_s() failed][Server Down]
Bedenken Sie nun, dass ich auf derselben Server 2008-Maschine den LDAP-Browser verwenden kann, um über LDAPs eine Verbindung zum Port 3269 herzustellen, und nichts ist „down“. Was sagt uns dieser Fehler?
Update 4: Hier sind die Ergebnisse der Ausführung von openssl s_client -connect gc-hca.corpad.net: 3269 -showcerts:http://pastebin.com/2yEGN4C1
Ich habe auch versucht, den OpenSSL-Befehl direkt zu einem Domänencontroller auf Port 636 zu senden, was funktioniert, und ich habe ihn in meiner httpd.conf versucht, was denselben Fehler erzeugt. Ich weiß nicht, ob es wichtig ist zu beachten, dass ich, wenn ich direkt zu einem Controller (389 oder 636) gehe, der URL einen Container wie ou=group,dc=hca usw. hinzufügen muss. Das macht die Verwendung des GC zu einem Muss. Muss ein Fehler in mod_ldap sein, da ich diese Lösung in vielen anderen Beiträgen gefunden habe.
Update 5: Ich habe Apache manuell statt über einen Dienst gestartet und dies ist das LDAP-Debug, das ausgedruckt wird:
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
Antwort1
Sie LDAPVerifyServerCert Offmachen die vertrauenswürdige Stammkonfiguration unwirksam. Vertrauen stellt also kein Problem dar.
Sind in wirklich so viele Leerzeichen vorhanden OU=Service Accounts?
Und haben Sie mod_ldapes mod_authnz_ldapaktiviert?
Wenn keines davon das Problem ist, können Sie in Ihren Fehlerprotokollen nach nützlichen Ergebnissen suchen?