Salut,
j'appuie le point 2 cité par Florent ! Toujours récupérer le véritable DN de l'utilisateur avant de binder.
Ca coute une connexion supplémentaire et ca oblige à entrer en dur les credentials d'un compte de service avec les droits suffisants dans le code mais ca peut éviter bien des galères et ca garantie une certaine portabilité de ton code.
Trop d'applications estiment que le RDN vaut le login entré par l'utilisateur et qui tente une connexion LDAP directe avec un DN forgé à partir de cette information.
Ca dépend également du DIT. On peut faire une vue dédiée, mais bon...
De : FRsAG [frsag-bounces@frsag.org] de la part de Florent Bacci [florentbacci@gmail.com]
Date d'envoi : mardi 9 septembre 2014 17:19
À : Alexandre
Cc: French SysAdmin Group
Objet : Re: [FRsAG] comparaison du hash d'un password
Bonjour Alexandre,
Effectivement, la méthode n'est pas optimale. L'idée d'une authentification LDAP est que c'est le serveur LDAP qui fait le calcul et la comparaison des hash.
Pour cela, l'enchaînement à suivre est du style :
1. Récupérer le login/mdp du user
2. Se connecter au LDAP avec le compte d'administration pour trouver le DN de l'utilisateur grâce à son login. Si la recherche échoue, c'est que le login/mdp du user est incorrect
3. Se déconnecter du LDAP
4. Se connecter au LDAP avec le DN de l'utilisateur précédemment trouvé et le mdp du user. Si la connexion échoue, c'est que le couple login/mdp du user est incorrect.
Grâce à cette méthode tu es indépendant de l'algo de hash utilisé par ton LDAP et tu n'as pas besoin de récupérer l'attribut userPassword.
Bon courage à toi!