Forum général.général Couple login/password pour accèder à OpenLDAP

Posté par  .
Étiquettes : aucune
0
2
nov.
2007
Bonjour,

J'ai un annuaire LDAP décrivant le système d'informations de mon entreprise et j'aimerai rendre accessible cette source de données à tous les utilisateurs (avec les restrictions nécessaires bien entendu).

Dans mon esprit, l'accès doit se faire après identification utilisateur. Pour le moment, cela n'est possible qu'en se binding directement sur l'annuaire (cn=uid,ou=Users,dc=domain,dc=tld).
Je ne peux pas demander à mes utilisateurs de rentrer leur DN complet. J'aimerai que l'accès s'effectue via un couple login/password simple

L'utilisateur n'aurait plus besoin d'utiliser
cn=uid,ou=User,dc=domain,dc=tld/password

mais
uid/password


où password est contenu dans l'attribut userPassword de l'utilisateur.

Comment faire pour arriver à un tel résultat? C'est à cela que sert SASL?
  • # Authentifcation LDAP

    Posté par  . Évalué à 1.

    Et bien tout dépend de l'outil qu'utilisent tes utilisateurs pour accéder à l'annuaire.

    En effet, cet outil peut très bien faire un bind sur le DN qui va bien et ensuite l'utilisateur a juste à spécifier le couple login/password.

    Peux-tu nous donner davantage de détails ?
  • # OpenLDAP et SASL

    Posté par  (site web personnel) . Évalué à 1.

    Si utiliser le dn complet est trop contraignant pour tes utilisateurs, je me demande avec quel client LDAP tu comptes leur permettre d'afficher les données fournies par ton serveur. En effet, s'il s'agit d'un annuaire d'entreprise dans lequel on peut trouver les coordonnées des différents collaborateurs, celui-ci n'a pas besoin d'être accessible qu'avec identification préalable d'un utilisateur. En général, on permet l'accès anonyme aux données non critiques (comme userPassword). Un contrôle d'accès à ce type d'attributs et personne, à part l'administrateur et l'utilisateur correspondant au dn ne pourra lire cet attribut :


    # The userPassword by default can be changed
    # by the entry owning it if they are authenticated.
    # Others should not be able to see it, except the
    # admin entry below
    access to attrs=userPassword
    by dn="cn=manager,dc=example,dc=com" write
    by anonymous auth
    by self write
    by * none

    Pour SASL, il est possible d'obtenir une identification pour OpenLDAP qui ne se base pas sur le seul dn et permette un couple « classique » d'uid et mot de passe. Il y a toutefois plusieurs mécanismes disponibles avec SASL et je vais en citer quelques-un :
    - GSSAPI ;
    - DIGEST-MD5 ou CRAM-MD5 ;
    - EXTERNAL.
    La commande suivante te permettra de savoir quels sont les mécanismes supportés par ton serveur :

    $ ldapsearch -LLL -x -b "" -s base supportedSASLMechanisms
    dn:
    supportedSASLMechanisms: NTLM
    supportedSASLMechanisms: LOGIN
    supportedSASLMechanisms: PLAIN
    supportedSASLMechanisms: DIGEST-MD5
    supportedSASLMechanisms: CRAM-MD5
    supportedSASLMechanisms: EXTERNAL

    Le premier (GSSAPI) évoque Kerberos est nécessite donc d'avoir déjà un royaume disponible. L'avantage, en entreprise, c'est que tes utilisateurs n'auraient plus besoin de s'identifier auprès du serveur LDAP pour y accéder tout en étant identifiés.
    Le deuxième s'appuie sur une base locale, sasldb, pour stocker les utilisateurs. Il faudrait donc créer autant d'utilisateurs dans cette base que d'utilisateurs dans le serveur LDAP. S'ils sont nombreux, cela peut s'avérer très rébarbatif.
    Le troisième fait appel à un processus externe.

    Cependant, le projet Cyrus-SASL fournit un service nommé saslauthd qui peut être utilisé pour exploiter l'un ou l'autre mécanisme et c'est là où le serpent peut finir par se mordre la queue car il est possible d'interroger un serveur ...LDAP. C'est exactement ce que je fais pour postfix.

    J'avoue cependant ne pas avoir poussé plus que cela la recherche quant OpenLDAP et SASL mais voici ce que j'ai trouvé sur Google pour t'aider :
    http://www-lor.int-evry.fr/~michel/LDAP/SASL/ActivationSASL.(...)
    http://www-lor.int-evry.fr/~michel/LDAP/SASL/Scenarios/diges(...)

    Pour diriger ta recherche, la directive sasl-regexp semble pouvoir répondre à ton besoin.
    • [^] # Re: OpenLDAP et SASL

      Posté par  (site web personnel) . Évalué à 1.

      À noter que la directive sasl-regexp s'appelle désormais authz-regexp.
    • [^] # Re: OpenLDAP et SASL

      Posté par  . Évalué à 1.

      Cependant, le projet Cyrus-SASL fournit un service nommé saslauthd qui peut être utilisé pour exploiter l'un ou l'autre mécanisme et c'est là où le serpent peut finir par se mordre la queue car il est possible d'interroger un serveur ...LDAP. C'est exactement ce que je fais pour postfix.


      Ah voilà ça ça m'intéresse. Pour l'instant je tombais toujours sur du Kerberos ou sur sasldb. Je ne voulais ni de l'un ni l'autre (pas la structure pour l'un, pas envie d'une base séparée pour l'autre).

      Je vais aller me renseigner un peu sur saslauthd. C'est peut être la clé
  • # Des détails!

    Posté par  . Évalué à 1.

    Je rajoute un peu de détails histoire de mieux cibler ce que je désire faire.


    J'ai donc un annuaire LDAP qui est à la base de mon système de messagerie (Postfix + LDAP + Dovecot).

    Et je veux permettre à mes utilisateurs d'avoir accès aux informations de l'annuaire où qu'ils soient. Si dans le cas d'un accès uniquement interne (dans les locaux) j'aurai pu très bien autoriser l'accès anonyme, là il s'agit d'accès internet. Je voudrai donc que mes utilisateurs accède à l'annuaire via du LDAP sur SSL et après authentification.
    Tout ça pour quoi? Pour que tout le monde puisse configurer son Evolution/Thunderbird/CeQu'ilVeut pour récupérer le carnet d'adresse de la boite.
    • [^] # Re: Des détails!

      Posté par  . Évalué à 1.

      Ta demande est enfin plus claire ;)

      Dans Thunderbird, l'utilisateur saisit son identifiant LDAP cn=uid,ou=User,dc=domain,dc=tld lorsqu'il configure l'accès à l'annuaire.
      Thunderbird ne lui demandera ensuite que son mot de passe pour se connecter à l'annuaire (il n'aura pas à entrer son identifiant à chaque fois).
      • [^] # Re: Des détails!h

        Posté par  . Évalué à 1.

        Le problème n'est pas tellement de rentrer son login et mot de passe pour moi. Mes utilisateurs connaissent forcément leur couple login/password (webmail et accès divers) et ont l'habitude de l'utiliser.

        C'est surtout que le mapping login<->DN d'un utilisateur n'est pas si simple que le cas décrit. Mes utilisateurs sont regroupés dans différents n½uds et en fonction de leur situation géographique. L'arbre doit faire bien 5 ou 6 niveaux (en dehors du rootdn). Et leur demander de retenir leur DN complet mettrait un peu de confusion à chaque fois qu'un service serait publié: Quel login utilisé? Le DN ou l'identifiant simple?
        J'aimerai vraiment éviter à mes utilisateurs de manipuler ce DN et à fortiori d'en avoir tout simplement conscience.
        • [^] # Re: Des détails!h

          Posté par  (site web personnel) . Évalué à 1.

          Sans parler des mutations internes entre services...
        • [^] # Re: Des détails!h

          Posté par  . Évalué à 0.

          Pourquoi ne pas proposer un outil maison pour résoudre ta problématique ?

          Imaginons une page php où l'utilisateur peut y trouver toutes les informations dont il a besoin.

          Cette page nécessite l'authentification préalable de l'utilisateur avec son couple login/passwd et apache va s'authentifier sur le LDAP. Au passage il bind plusieurs DN pour s'arrêter finalement sur le bon....
          • [^] # Re: Des détails!

            Posté par  . Évalué à 1.

            C'est contourné le problème.

            Je veux arriver au point où tout ce que je peux mettre à disposition via un même système d'authentification. Écrire un outil pour extraire ces informations n'est pas une solution viable pour moi.

            Apache, Dovecot, <cequevousvoulez> y arrivent très bien. Il n'y a donc pas vraiment de raison à ne pas arriver à ce résultat.
            • [^] # Re: Des détails!

              Posté par  (site web personnel) . Évalué à 2.

              Oui, sauf que les clients de messagerie voudront parler LDAP, pas HTTP ou un autre protocole. Je pense qu'il faut creuser la piste SASL.
              • [^] # Re: Des détails!

                Posté par  . Évalué à 1.

                J'suis dessus et autant dire que je galère pas mal.

                La configuration saslauthd ça ça roule, par contre après pour l'interaction avec slapd/SASL autant dire que j'y pige rien. In progress quoi...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.