Question L'authentification Apache contre LDAP échoue pour les mots de passe avec des trémas


Lors de l'authentification auprès de LDAP (Active Directory, Server 2008) à partir d'un serveur Apache, le message suivant s'affiche dans le journal des erreurs:

authentication failure for "/": Password Mismatch

Cela ne se produit que lorsque le mot de passe contient des trémas allemands (ä, ö, ü). Après avoir modifié le mot de passe ou essayé avec un autre compte sans mot de passe, l'authentification fonctionne correctement.

Voici ma configuration:

AuthType Basic
AuthzLDAPAuthoritative off
AuthLDAPURL "ldap://[SERVER]:3268/DC=[DOMAIN]?sAMAccountName?sub?(objectClass=user)"
AuthLDAPBindDN       "user"
AuthLDAPBindPassword "pass"
require valid-user

J'utilise Apache2 (2.2.16-6 + squeeze1) sous Debian (2.6.26-2-686). Ce qui est amusant, c’est que la configuration ci-dessus a fonctionné jusqu’à hier (même pour les mots de passe avec trémas) et que je ne l’ai pas touchée (je jure ;-)). J'ai déjà trouvé d'autres personnes avec le même problème mais pas de solution.

Quelqu'un a-t-il une idée de la façon de résoudre le problème ou simplement quoi faire ensuite pour éventuellement identifier le module erroné?

Meilleures salutations, Stefan


7
2017-08-23 14:32


origine


Peut-être que certains de vos paramètres régionaux ont été modifiés récemment? - Dana the Sane
Non, les paramètres régionaux sont (toujours) définis sur UTF-8. - StefanMacke
Ici vous pouvez trouver que les trémas allemands ne sont pas supportés: social.technet.microsoft.com/Forums/ie/de-DE/… - Mr.M


Réponses:


Il semblerait qu’un problème d’encodage se produise quelque part. Je ne peux pas vous dire où il se trouve, mais je peux suggérer comment le trouver.

Si j'ai bien compris, il y a 5 endroits où l'encodage pourrait être mal traité ou interprété. Ceux-ci sont:

  1. Navigateur convertissant les caractères en octets à envoyer au serveur Web
  2. Apache comprenant ces octets pour construire la chaîne de mot de passe
  3. Apache + OpenLDAP transformant la chaîne de mot de passe en octets à envoyer au serveur LDAP
  4. Active Directory convertissant les octets de la demande de liaison LDAP en quelque chose qu'il peut comparer à sa base de données de mots de passe
  5. Active Directory convertissant des caractères en octets lors de la définition du mot de passe de l'utilisateur

En supposant que vous puissiez vous connecter à Windows en tant qu’utilisateur, nous savons que le numéro 5 n’est pas votre problème. Ce que vous devez faire est d’identifier l’avancement de votre problème. Mon impression est que c'est aux étapes 2 ou 3, mais je ne peux pas en être sûr.

Tout d'abord, assurez-vous que vous n'utilisez pas https pour parler au serveur Web et n'utilisez pas ldaps pour parler au serveur LDAP. (Vous ne voudrez peut-être pas cela pour la production, mais cela rend la vie plus facile). Utilisez maintenant Wireshark pour détecter le trafic sur les deux segments, navigateur -> Apache et Apache -> AD. Voyez-vous les informations correctes ici?

Ensuite, configurez le niveau de journalisation dans Apache pour le débogage et voyez ce qui est imprimé. Cela ne vous montrera pas le mot de passe, mais au niveau de débogage, il devrait vous montrer d'autres informations comme le nom d'utilisateur. Si vous utilisez un faux nom d'utilisateur contenant des accents, apparaissent-ils correctement?

Une fois que vous avez identifié l'étape qui casse l'encodage, vous avez environ 90% de la façon de savoir comment le réparer!


3
2017-08-28 20:32