Forum général.général Authentification centralisée avec OpenLDAP

Posté par  (site web personnel, Mastodon) .
Étiquettes :
0
3
avr.
2006
Bonjour à tous,

J'ai sous le nez un réseau d'une cinquantaine de machines, principalement sous Fedora, mais également quelques OSX, et probablement des Kubuntu dans un futur proche. Je souhaite installer un serveur LDAP pour centraliser, dans un premier temps, l'authentification des utilisateurs.

J'ai installé, configuré et peuplé OpenLDAP sur une machine utilisée comme serveur, et de cette machine ou d'une autre, je peux faire :

ldapsearch -x -w monpwd -D "uid=toto,ou=People,dc=mondc" -h monserver.mondomaine

Jusque là ca marche comme attendu. Ensuite, je lance authconfig sur l'une des machines sous fedora que j'utilise comme client test, je déclare le serveur ldap, tout semble marcher.

J'essaie ensuite de me connecter sur cette machine avec l'utilisateur toto et le mot de passe monpwd (cet utilisateur toto n'a pas de compte en local et je m'attends donc à ce qu'il soit identifié par le ldap), et c'est là que j'ai un problème:
"su - toto" me revoit un su: user toto does not exist
"ssh toto@monclienttest" ne marche pas, mais je vois dans le /var/log/message:

pam_ldap: error trying to bind as user "uid=toto,ou=People,dc=mondc" (Invalid credentials)

Devant ce problème, plusieurs choses:

- Je ne connais pas LDAP ni PAM et j'ai l'impression qu'il peut y avoir des soucis à des tonnes de niveaux différents. L'une de vos âmes charitables pourrait-elle me donner un petit coup de main pour cerner le problème ?

- ensuite, si vous avez des liens vers des tutoriaux simples et à jours pour mettre en place rapidement une authentification centralisée, ca m'interesse beaucoup. J'ai trouvé toute sorte de howto via google, plus ou moins simple et plus ou moins à jour, mais aucun qui réponde aux deux critères en même temps.

Merci d'avance à tout ceux qui prendront le temps de me décoincer :)

Aurel

  • # Une vague piste...

    Posté par  . Évalué à 3.

    Dans ton 'ldapsearch' tu mets l'options '-x', pour désactiver le SASL:
    " -x Use simple authentication instead of SASL"

    Peut etre que par defaut, ton 'pam_ldap' utilise le SASL, et que que ton serveur ldap répond pas/mal dans ce mode.

    essaye de refaire la commande ldapsearch sans le -x.
    tu devrais récupérer à peu près le même message que dans le fichier
    de logs.

    Si c'est le cas, soit tu dis à pam_ldap de ne pas utiliser SASL, soit tu dis au serveurde l'utiliser.

    • [^] # Re: Une vague piste...

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

      Merci beaucoup pour l'idée :) Si j'enlève le -x, j'ai l'output suivant:

      SASL/DIGEST-MD5 authentication started
      ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
      additional info: SASL(-13): user not found: no secret in database

      Je ne connais pas encore SASL. Si c'est un mécanisme authentification qui conditionne l'accès au LDAP, j'imagine que c'est directement "dans SASL" que je devrais ajouter les différents utilisateurs ? Ou alors c'est le LDAP Manager qui s'authentifie via SASL à l'annuaire LDAP avant de confronter le couple login/password fourni par l'utilisateurs à ceux de la base LDAP ?

      Ou alors je suis totalement à coté de la plaque ? Désolé pour ces questions vraiment "de base" :(

  • # As-tu pensé

    Posté par  . Évalué à 4.

    que la machine client doit pouvoir se connecter sur ldap et donc il te faut un fichier sur celle-ci avec le mot de passe (/etc/ldap.secret) ??? ;-)


    J'ai pas mal travaill é avec OpenLDAP et j'ai mis mes notes perso en lignes http://www.alchimerys.be/FR/unix.php#U1 (tu y trouvera aussi des liens tres interessant)

    • [^] # Re: As-tu pensé

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

      Merci beaucoup, je file y jeter un coup d'oeil et je te plussoie dans la foulée.

    • [^] # Re: As-tu pensé

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

      J'ai mieux compris, vérifié ce que je pouvais, mais je suis malheureusement toujours coincé par ce même message d'erreur. Intuitivement, j'ai l'impression que la connexion au LDAP se fait correctement, mais que tout se passe comme si je donnais un mauvais mot de passe pour l'utilisateur toto. Me gourre-je ? Le cas échéant, est-ce qu'il y a une facon propre de réassigner un mot de passe à toto dans le LDAP afin d'être certain d'éliminer cette source d'erreur ?

      Je demande ca car suivant les liens, j'ai vu des "pam_password md5" et des "pam_password crypt" par exemple.

  • # Mes idées...

    Posté par  . Évalué à 2.

    Généralement quand ca parle de "credentials", ca viens du mot de passe.
    Ce que je te conseil c'est de regarder les logs du serveur LDAP si tu peux :
    - regarder si ton client interroge bien le serveur
    - regarder la reponse du serveur au client, si dans les logs tu as une erreur 49 c'est que le mot de passe est mauvais
    - si tout va bien c'est que ca viens du client

    J'ai fais une doc sur mon site : http://guim.info/article1.php ca concerne une debian, mais ca doit être à peu près pareil.

    Verifies la configuration de PAM, de nsswitch, n'installe pas ou desactive nscd dans un premier temps (sinon il va tout pourrir avec son cache)

    • [^] # Re: Mes idées...

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

      Merci beaucoup !

      Il semble que le problème soit bien lié au mot de passe, car j'ai dans les logs du serveur les outputs suivants :

      1. lorsque j'essaie de me connecter via ssh:
      Apr 4 13:14:42 monserveur slapd[26994]: conn=19 fd=7 ACCEPT from IP=XXX.XXX.XXX.XXX:34260 (IP=0.0.0.0:389)
      Apr 4 13:14:42 monserveur slapd[26994]: conn=19 op=0 BIND dn="cn=Manager,dc=mondc" method=128
      Apr 4 13:14:42 monserveur slapd[26994]: conn=19 op=0 RESULT tag=97 err=49 text=
      Apr 4 13:14:42 monserveur slapd[26994]: conn=19 op=1 UNBIND
      Apr 4 13:14:42 monserveur slapd[26994]: conn=19 fd=7 closed
      Apr 4 13:14:43 monserveur slapd[26994]: conn=20 fd=7 ACCEPT from IP=XXX.XXX.XXX.XXX:34261 (IP=0.0.0.0:389)
      Apr 4 13:14:43 monserveur slapd[26994]: conn=20 op=0 BIND dn="cn=Manager,dc=mondc" method=128
      Apr 4 13:14:43 monserveur slapd[26994]: conn=20 op=0 RESULT tag=97 err=49 text=
      Apr 4 13:14:43 monserveur slapd[26994]: conn=20 op=1 UNBIND
      Apr 4 13:14:43 monserveur slapd[26994]: conn=20 fd=7 closed
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 fd=7 ACCEPT from IP=XXX.XXX.XXX.XXX:34262 (IP=0.0.0.0:389)
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=0 BIND dn="cn=Manager,dc=mondc" method=128
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=0 BIND dn="cn=Manager,dc=mondc" mech=simple ssf=0
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=0 RESULT tag=97 err=0 text=
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=1 SRCH base="ou=People,dc=mondc" scope=1 filter="(&(objectClass=posixAccount)(uid=toto))"
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=2 BIND anonymous mech=implicit ssf=0
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=2 BIND dn="uid=toto,ou=People,dc=mondc" method=128
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=2 RESULT tag=97 err=49 text=
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=3 BIND dn="cn=Manager,dc=mondc" method=128
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=3 BIND dn="cn=Manager,dc=mondc" mech=simple ssf=0
      Apr 4 13:14:43 monserveur slapd[26994]: conn=21 op=3 RESULT tag=97 err=0 text=



      2. lorsque je fais un "su -"
      Apr 4 13:13:21 monserveur slapd[26994]: conn=15 fd=7 ACCEPT from IP=XXX.XXX.XXX.XXX:47876 (IP=0.0.0.0:389)
      Apr 4 13:13:21 monserveur slapd[26994]: conn=15 op=0 BIND dn="cn=Manager,dc=mondc" method=128
      Apr 4 13:13:21 monserveur slapd[26994]: conn=15 op=0 RESULT tag=97 err=49 text=
      Apr 4 13:13:21 monserveur slapd[26994]: conn=15 op=1 UNBIND
      Apr 4 13:13:21 monserveur slapd[26994]: conn=15 fd=7 closed


      Je suis surpris de voir ce que je comprends comme un pb du mot de passe pour le manager dans les deux cas, d'autant plus que la recherche de toto dans le LDAP semble fonctionner malgré tout dans le cas d'une conexion SSH, mais dans ce cas là c'est le mot de passe de l'utilisateur qui semble incorrect. Je précise que le /etc/ldap.secret a bien les droits rw pour root exclusivement, que le mort de passe qu'il contient marche très bien lorsqu'il est utilisé par ldapsearch, et que je n'utilise pas nscd.

      Si jamais vous avez une idée, je vous serais vraiment très reconnaissant.

      Gasp je viens d'essayer en lancant nscd sur le client et hop, ca marche !! Incroyable, je ne comprends vraiment rien !!! :D

  • # il me semblait...

    Posté par  . Évalué à 2.

    ...avoir lu quelque part qu'il fallait simplement modifier le /etc/password et le /etc/group

    pour qu'il aille chercher les utilisateurs/groupes du domain ?

    me souviens plus exactement, mais doit y avoir des infos la dessus sur internet

    • [^] # Re: il me semblait...

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

      J'ai déjà l'impression d'avoir beaucoup googler, sans vraiment de résultat clair. Je crois déjà savoir qu'il faut aussi motifier le /etc/pam.d/system-auth, ainsi que le /etc/nsswitch.conf, ce que j'ai fait, mais sans succès.

      • [^] # Re: il me semblait...

        Posté par  . Évalué à 0.

        La gestion des users/groupes repose sur PAM et NSS

        PAM utilise /etc/pam.d/system-auth (/etc/pam.d/common* sous Debian) et /etc/pam.conf (ou /etc/pam_ldap.conf sous Debian)
        NSS utilise /etc/nsswitch.conf et pam.conf (ou /etc/libnss_ldap.conf sous Debian)

        Il est aussi necessaire d'avoir un fichier /etc/ldap.secret si tu veux que des outils comme passwd puissent acceder a l'annuaire LDAP en tant qu'utilisateur admin de l'annuaire LDAP pour pouvoir changer le mot de passe de l'utilisateur.

        Si tu n'as pas modifie /etc/ldap.conf tel est ton pb.

        Pense aussi a utiliser getent passwd et getent group pour verifier ta conf (pas suffisant mais ca doit au moins lister les utilisateurs et groupes du LDAP).

Suivre le flux des commentaires

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