2 votes

Comment importer un certificat pour Apache + LDAPS ?

J'essaie de faire fonctionner ldaps avec Apache 2.2.17 (Windows Server 2008). Si j'utilise ldap (texte brut), ma configuration fonctionne parfaitement.

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>

J'ai également essayé les autres choix de cryptage en plus de CA_DER, juste pour être sûr, sans succès.

Enfin, j'en avais aussi besoin avec Apache tomcat. Pour tomcat, j'ai utilisé le JRE tomcat et j'ai exécuté une ligne comme celle-ci :

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

Après avoir fait la ligne ci-dessus, ldaps a fonctionné correctement via tomcat. Cela me permet de savoir que mon certificat est correct.

Mise à jour : Les deux modules ldap sont activés, puisque l'utilisation de ldap au lieu de ldaps fonctionne bien.

Lorsque je lance un clone git, voici l'erreur renvoyée :

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

Le fichier access.log contient ceci :

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 ne contient rien. Existe-t-il une journalisation plus détaillée que je peux activer ou de meilleurs tests à effectuer ?

Mise à jour 2 : Je peux exécuter wireshark sur le serveur apache et je peux clairement voir la connexion sortante, mais je ne peux pas vraiment comprendre quoi que ce soit d'autre. Je ne suis pas un gourou de wireshark, ça ressemble juste à du jargon.

J'ai également utilisé le navigateur ldap pour vérifier que ldaps fonctionne bien sur la machine.

Mise à jour 3 : J'ai mis la journalisation d'Apache en mode débogage et voici l'erreur qui revient :

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

Gardez à l'esprit que sur cette même machine Server 2008, je peux utiliser LDAP Browser pour me connecter via ldaps au port 3269 et rien n'est "down". Que nous dit cette erreur ?

Mise à jour 4 : Voici les résultats de l'exécution de openssl s_client -connect gc-hca.corpad.net : 3269 -showcerts : http://pastebin.com/2yEGN4C1

J'ai également essayé la commande openssl allant directement à un contrôleur de domaine sur le port 636 qui fonctionne et je l'ai essayé dans mon httpd.conf qui produit la même erreur. Je ne sais pas s'il est important de noter que lorsque je vais directement à un contrôleur (389 ou 636), je dois ajouter un conteneur à l'url comme ou=group,dc=hca,etc. Cela rend l'utilisation du GC indispensable. Ce doit être un bug dans le mod_ldap puisque j'ai trouvé cette solution dans de nombreux autres posts.

Mise à jour 5 : J'ai démarré apache manuellement au lieu de passer par un service et voici le débogage de ldap qui s'affiche :

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

2voto

Shane Madden Points 112034

Votre LDAPVerifyServerCert Off rend la configuration de la racine de confiance inerte - la confiance n'est donc pas un problème.

Y a-t-il vraiment autant d'espaces dans OU=Service Accounts ?

Et avez-vous mod_ldap y mod_authnz_ldap activé ?

Si aucun de ces éléments n'est à l'origine du problème, pouvez-vous vérifier si vos journaux d'erreurs contiennent des informations utiles ?

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X