AD+Group+AUTH [Résolu]



  • Bonjour,

    j'essaie en vain de configurer l'authenfication des users d'un AD faisant partie d 'un group…mais en vain.

    Le groupe= vpngroup

    le schéma AD se compose comme ceci:

    Domain.local
      openvpn
          vpngroup

    dans vpngroup j'ai bien sûr des utilisateurs.

    j'ai essayé plusieurs choses mais aucune ne fonctionne

    base dn: DC=domain,DC=local
    OU=openvpn,DC=domain,DC=local

    extended query :

    memberOf=CN=vpngroup,OU=openvpn,DC=domain,DC=local

    mais marche pas....pourtant d'après la doc c'est ce qu'il faut....



    • 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



  • @Globule:

    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)



  • @Globule:

    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=local

    Bind 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 Users

    donc 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
    memberOf

    sauver 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


Log in to reply