Omniauth-ldap informations d'identification non valides

Question

J'ai beaucoup de mal à faire fonctionner omniauth-ldap avec notre serveur AD, et je crois que c'est parce que nos noms d'utilisateur contiennent nos noms de domaine.

Cela se connecter avec succès à notre serveur ldap:

ldapsearch -h ldap.ourdomain.com -b "dc=ourdomain,dc=int" -D "OURDOMAIN\username" -w <password> '(sAMAccountName=username)' 

Mais, ces paramètres dans OmniAuth résultat que dans des "lettres de créance non valides"

Padrino.use OmniAuth::Strategies::LDAP, 
    :host => "ldap.ourdomain.com", 
    :base => "dc=OURDOMAIN,dc=INT", 
    :uid => "sAMAccountName", 
    :bind_dn => 'OURDOMAIN\%{username}', 
    # This is hard coded for now, but I need it to be the value entered by the user 
    :password => "mypassword" 

MISE À JOUR

de travail sur cette En outre, j'ai découvert que omniauth-ldap définit la méthode bind sur: anonyme si: bind_dn et: password ne sont pas définis.

Cependant, il n'insère pas le nom d'utilisateur et ne fournit pas le mot de passe entré par l'utilisateur si les valeurs sont.

Ce que je dois est

:bind_dn => 'OURDOMAIN\<user entered username>', 
:password => <user entered password> 

mais le mot de passe et nom d'utilisateur saisi ne sont fournis à la connexion si vous les coder en dur.

Answer 1

J'ai dû résoudre ce problème en créant un compte de service. Ce compte se connecte puis interroge l'existence et la validité de l'utilisateur qui tente actuellement de se connecter. Les informations d'identification du compte de service peuvent être définies dans votre configuration Omniauth. Vous pouvez ensuite utiliser omniauth-ldap comme toute autre méthode omniauth.

Answer 2

Ceci est principalement dû à un choix de conception qu'omniauth-ldap fait. Le design est que le nom d'utilisateur fourni par l'utilisateur (email ou id) est insuffisant pour construire un DN (nom distinctif) qui peut être utilisé pour la liaison. D'où ce fait est omniauth ldap

1. Appel d'une recherche ldap (bind_dn et mot de passe utilisé si la recherche anonyme non autorisé dans votre AD/LDAP) pour extraire un DN pour l'utilisateur.
2. Ensuite, il se lie à LDAP/AP en utilisant le DN de l'étape 1 et le mot de passe entré par l'utilisateur.

Je crois que l'étape 1) est inutile. La plupart des DN peuvent être dérivés du nom d'utilisateur.