ne peut pas comprendre pourquoi l'authentification LDAP apache échoue

Soudain, hier, l'un de mes serveurs Apache est devenu incapable de se connecter à mon serveur LDAP (AD). J'ai deux sites en cours d'exécution sur ce serveur, qui utilisent tous deux LDAP pour s'authentifier sur mon serveur AD lorsqu'un utilisateur se connecte à l'un ou l'autre site. Cela fonctionnait bien il y a deux jours. Pour des raisons inconnues, hier, il a cessé de fonctionner. Le journal des erreurs indique seulement ceci:

auth_ldap authenticate: user foo authentication failed; URI /FrontPage [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server], referer: http://mysite.com/

Je pensais que mon certificat SSL auto-signé avait peut-être expiré, alors j'en ai créé un nouveau pour mysite.com, mais pas pour le nom d'hôte du serveur lui-même, et le problème a persisté. J'ai activé la journalisation au niveau du débogage. Il montre la transaction SSL complète avec le serveur LDAP et semble se terminer sans erreur jusqu'à la fin lorsque je reçois le message «Impossible de contacter le serveur LDAP». Je peux exécuter ldapsearch à partir de la ligne de commande sur ce serveur, et je peux me connecter à celui-ci, qui utilise également LDAP, donc je sais que le serveur peut se connecter et interroger le serveur LDAP / AD. Ce n'est qu'apache qui ne peut pas se connecter.

Googler pour une réponse n'a rien révélé, alors je demande ici. Quelqu'un peut-il donner un aperçu de ce problème?

Voici la section LDAP de la configuration apache:

<Directory "/web/wiki/">
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Login"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    #AuthBasicAuthoritative off
    AuthLDAPUrl ldaps://domain.server.ip/dc=full,dc=context,dc=server,dc=name?sAMAccountName?sub
    AuthLDAPBindDN cn=ldapbinduser,cn=Users,dc=full,dc=context,dc=server,dc=name
    AuthLDAPBindPassword password
    require valid-user
</Directory>

Une trace de paquet provenant du serveur httpd / client LDAP a révélé un message indiquant que l'autorité de certification était inconnue.

Alerte TLSv1 (Niveau: Mortel, Description: Autorité de certification inconnue)

J'ai trouvé et ajouté l'option suivante à mon httpd.conf:

  LDAPVerifyServerCert          off

Cela a résolu mon problème sous CentOS 6. Les serveurs httpd de CentOS 5 n'ont nécessité aucune modification et ont fonctionné sans option.

J'ai déjà rencontré un problème similaire à celui-ci avec AD sur Windows 2003: la solution que j'ai trouvée était de ne pas lier en utilisant le DN complet mais d'utiliser plutôt la syntaxe user @ domain:

AuthLDAPBindDN [email protected]

Avez-vous accès aux journaux de votre serveur LDAP? Ils peuvent être utiles pour résoudre ce problème.

Je l'ai vu lorsqu'une mise à jour de package provoque des modifications dans le client ldap.conf (généralement /etc/ldap.conf ou /etc/openldap/ldap.conf) et réinitialise l'option TLS_REQCERT à un paramètre plus strict. Il peut négocier correctement le SSL, mais échouera toujours à la fin car il ne peut pas valider la chaîne de certificats à partir d'une racine de confiance.

Vous voudrez peut-être vérifier l'horloge des serveurs. Si le décalage horaire est supérieur à quelques minutes, le ticket d'authentification sera invalide.

Bien que ce ne soit pas exactement le message d'erreur, la partie «l'autre serveur obtient soudainement le même problème» peut indiquer un tel problème.

Vous devez altérer le certificat de l'autorité de certification LDAP pour travailler avec LDAPS

J'ai un problème similaire, que j'ai identifié en exécutant cette commande:

openssl s_client -connect $ldap_host:636 -state -nbio 2>&1. Je pense que mod_ldap utilise openssl en dessous, donc cela devrait être assez cohérent pour le débogage.

Je l'ai comparé à un autre serveur crypté SSL que je savais fonctionner. Une connexion SSL correctement vérifiée affichera une chaîne allant vers une autorité de certification racine et retournera 0. Un échec de la vérification SSL donnera un numéro et une raison. Vous pouvez utiliser la sortie pour déterminer ce qui ne va pas.

Dans mon cas, les certificats de serveur LDAP sont signés par Verisign, qui utilise des certificats de CA intermédiaires . OpenSSL n'est pas en mesure de vérifier le certificat et la connexion est refusée («connexion refusée par le serveur» est inutile).

J'avais un problème similaire. Je pourrais obtenir le cert avec openssl, je pourrais interroger Active Directory sur SSL avec ldapsearch sur les mêmes ports. Enfin, je suis passé aux ports 3268 ou 3269 du catalogue global de Microsoft et ils ont tous deux fonctionné. Les serveurs Microsoft Windows 2003 avaient été corrigés, mais cela s'est produit quelques jours avant le début des problèmes.

J'implémentais LDAPS sur tous nos serveurs et j'ai également rencontré ce problème. Cela disparaît-il si vous revenez au LDAP en texte brut (pas idéal, mais utile pour connaître la source du problème). Si c'est le cas, je n'ai pas encore trouvé de solution, mais peut-être qu'ensemble, nous pouvons isoler un bogue dans authnz_ldap.

Je suppose que vos expériences en ligne de commande utilisaient le même "utilisateur de liaison" que dans vos configurations apache. Sinon, vous devez vérifier que vous disposez du bon mot de passe actuel.

Dans le passé, j'ai dû utiliser le port de catalogue global au lieu du port LDAP standard pour le domaine AD. Je ne me souviens pas de la raison. Pour les ldaps comme dans votre URL ci-dessus, ce serait le port 3269.

La façon dont cela fonctionne est que votre site Web doit d'abord se connecter à AD en utilisant les informations d'identification de votre utilisateur de liaison , puis, une fois cette connexion établie, il utilise cet accès pour valider les informations d'identification de l'utilisateur qui tente d'accéder à votre site Web.

Selon votre message d'erreur, il semble que le processus ne puisse pas se connecter à AD en tant qu'utilisateur de liaison (AuthLDAPBindDN).

Assurez-vous que le compte d'utilisateur de liaison n'est pas désactivé dans Active Directory et que le mot de passe que vous avez spécifié en tant que (AuthLDAPBindPassword) est correct . Assurez-vous également que votre utilisateur de liaison dispose des autorisations nécessaires pour rechercher d'autres utilisateurs (doit être membre des utilisateurs du domaine dans notre cas)

Je viens d'avoir ce problème ("impossible de contacter le serveur LDAP") sur RHEL6, et c'était le résultat de modifications apportées à openldap. yum avait mis à jour le fichier de configuration /etc/openldap/ldap.conf mais au lieu de l'écraser (au cas où il aurait été personnalisé; dans mon cas, ce ne l'était pas), il a créé un fichier ldap.conf.rpmnew.

La copie de la version .rpmnew sur ldap.conf a résolu le problème.

(Je ne peux pas accepter que la désactivation de la vérification des certificats soit une réponse à cela. Cela évite le problème d'une manière potentiellement dangereuse.)

J'ai réussi à résoudre ce problème en installant les packages berkelydbet openldaptrouvés ici .

La différence est que RedHat a commencé à lier les choses au nsslieu de la opensslprise en charge SSL. Dans ce cas, cela brise tout. L'installation de ces packages (qui sont liés à openssl) corrige le problème. Obtenez les packages et lancez:

yum install berkeleydb-ltb* openldap-ltb*

Redémarrez ensuite apache, et vous devriez être en affaires.

J'ai eu un problème identique après la mise à niveau de rhel6.6 vers rhel7.5. Quand j'étais à court d'idées, j'ai conclu que le mod_ssl sur apache 2.2.32 n'était peut-être pas compatible à 100% sur rhel7.4. J'ai mis à niveau d'Apache 2.2.32 vers Apache2.4, j'active SSL et sldap a fonctionné.