AD+Group+AUTH [Résolu]
-
- qu'as-tu défini dans les autres champs ?
- quel est ton baseDN ?
- cette branche (OU=openvpn) est-elle accessible de manière anonyme ?
et enfin, as-tu essayé cette requête en dehors de pfSense avec un client LDAP, juste pour t'assurer que AD y répond ?
-
Connexion anonyme , non.
J'arrive bien à cliquer le bouton select, donc la connexion se fait puisqu' il m'affiche des OU….
j'ai mis un screen ça sera plus simple
-
ton DN pour authentification est très bizarre. Ce n'est pas un format LDAP mais un format Windows AD (même pas samaccountname ;D) qui correspond à l'authentificaiton Windows dans le domaine.
Je te suggère de remplacer celui-ci par un vrai DN.
Par ailleurs, le fait que tu arrives à lire une partie du DIT ne signifie pas que cette authentification fonctionne.
-
oups Chris, c'est bien une auth AD(avec un windows active directory) pas LDAP
-
Pour compléter ma réponse:
il faut toujours être très méfiant avec les programmes et interfaces qui te demandent un DN pour s'authentifier afin de faire une recherche afin de trouver d'autres comptes ou groupes.Un programme client LDAP normalement écrit devrait demander un login, faire une recherche en mode anonyme, puis sur la base de la réponse, faire un bind.
Malheureusement, peu de programmes font ça et de plus, cela nécessite d'avoir accès aux ACL du serveur LDAP pour s'assurer qu'au moins ce compte utilisé à des fins administratives est accessible de manière anonyme.
A ce jour, le principal serveur LDAP du marché (en nombre de serveur) à savoir AD n'est pas du tout flexible de ce point de vue :-(Du coup, ces programmes font directement un bind (dans le meilleur des cas) avec le DN fourni, raison pour laquelle il faut que ce soit un vrai DN.
Dans le pire des cas, le programme va tenter de reconstruire le DN à partir d'un login, un cn ou un uid. A fuir comme la peste ;D ;D ;D
-
oups Chris, c'est bien une auth AD(avec un windows active directory) pas LDAP
Ce que Microsoft a mis longtemps à mettre en avant dans leurs formations (je me souviens encore des formations du siècle dernier) c'est que AD n'est rien d'autre qu'un serveur LDAP, avec des contraintes et limitation supplémentaires.
Du coup, lorsque utilisé avec un client LDAP, il faut respecter la syntaxe LDAP et donc mettre un DN dans ce champ. Trust me ;)
-
mouais… mais ici le seul soucis avec de config une auth si un user fait partie d 'un group..
si je configure qd meme l'auth via ldap ça fonctionne, sauf que là tout mes users faisant partie d'une OU ont accès. Je voudrais limiter l'accès aux user de cet OU et qui sont dans un group nommé X(vpngroup dans mon cas)
-
si je configure qd meme l'auth via ldap ça fonctionne, sauf que là tout mes users faisant partie d'une OU ont accès. Je voudrais limiter l'accès aux user de cet OU et qui sont dans un group nommé X(vpngroup dans mon cas)
Ceci est normalement pris en charge par le filtre de recherche qui doit ressembler à quelque chose du genre:
(&(samAccountName=username)(memberof=cn=vpngroup,OU=openvpn,DC=domain,DC=local))et ça, comme je te l'ai déjà suggéré, tu peux le vérifier avec un client LDAP pour t'assurer que ta requête est correcte et renvoie bien ce à quoi tu t'attends.
Avec un serveur LDAP "traditionnel", il suffit de regarder dans le log. Avec AD, c'est moins souple mais il y a peut-être un moyen d'activer le niveau de log qui va bien.
Par ailleurs, l'interface de pfSense est construite, de ce point de vue et à mon avis, de manière un peu bizarre car au lieu de demander le filtre de recherche, celui-ci est "construit" et tu ne sais donc pas, à moins de regarder dans le log LDAP (ou wireshark ;D) quel est le filtre résultant.
-
yop,
j'ai réussi , merci Chris…
Bonne journée,
-
Ce qui serait vraiment sympa pour les autres (faisant potentiellement face au même type de problème) c'est d'expliquer ce qui n'allait pas et ce que tu as corrigé ;)
et ensuite tu peux éditer le titre du premier message et le marqué comme [RESOLU] 8)
-
Donc mini howto….
ce que j'ai fait:
1. créer une OU openvpn (par exemple) qui se trouve dans mon cas à la racine de mon AD OU=openvpn,DC=domain,DC=local
2. créer un user dans cet OU , ici dans ce cas openvpn et lui donner un mot de passe (fait gaffe si vous utiliser des caractères style && @ etc)
3. dans cet OU créer un group , dans ce cas vpngroup.ceci est fait c'est déjà pas mal....
base DN: DC=domain,DC=local
Auth Container : OU=openvpn,DC=domain,DC=localBind Credentials: DOMAIN\openvpn(le user créer dans OU) et le mot de passe que vous avez donné
ensuite cliquer sur select(bouton) et là sélectionner dans quel OU vous avez mis vos user
pour ma part j'ai qq chose comme ceci dans mon AD
Domain.local
People
Admin Users
Standart Users
Account Usersdonc dans la fenêtre du select je coche OU=People,DC=Domain,DC=local
si vous êtes dans le même cas que moi, cocher Entire Subtree
dans query search (il faut cocher)
mettre ceci:
memberOf=CN=vpngroup,OU=People,DC=Domain,DC=local et pas memberOf=CN=vpngroup,OU=openvpn,DC=Domain,DC=local puisque aucun de mes users s'y trouvent
pour les attrivutes dans l'ordre
samAccountName
cn
memberOfsauver et tester depuis le menu diagnotics-> authentification
vérifier que votre user est bien dans le group vpngroup
si auth est ok, virer le group vpngroup de votre user et tester à nouveau , logiquement ça vous donnera un échec.
Bàv,
-
Merci pour le feedback.
Ce qui est intéressant, c'est que pfSense autorise la connexion LDAP avec un DN qui n'est pas un DN pour l'authentification ;D ;D