Forum Linux.debian/ubuntu Problème LDAP

Posté par  (site web personnel) .
Étiquettes :
-1
28
déc.
2007
Bonjour,
Je me bat depuis 5 jours avec LDAP, et pour l'instant il est plus fort que moi. J'espère donc qu'une âme charitable trouvera la réponse à mes problèmes.

J'ai donc installé openldap (slapd) sur une Debian Etch. Afin d'utiliser l'authentification SASL avec ldaps, je stocke les mots de passe en CLEARTEXT. Pour l'instant slapd est accessible en ldap:// et ldaps://.

J'arrive à faire mes requêtes ldapsearch avec l'utilisateur admin et avec les utilisateurs autres, en ldap et en ldaps. Jusque-là, tout va bien :-) En plus, les ACLs sont respectées : typiquement, tous les champs userPassword sont accessible depuis admin, un utilisateur lambda peut voir son mot de passe mais pas les autres, que du classique.

Ensuite, j'ai voulu configurer nss et pam sur cet annuaire.
Si je fait 'getent passwd', j'ai bien mes utilisateurs ldap.

Par contre, nss et pam ne peuvent pas accéder au champ userPassword et donc je ne peux pas logger un utilisateur LDAP sur la machine. J'ai systématiquement:

Authentication service cannot retrieve authentication info


Alors, dans libnss-ldap.conf, j'avais pas mis de bindn, pensant que pour le mot de passe, ça se faisait avec le rootbinddn. Du coup, effectivement, nss se logge en anonyme sur LDAP et n'a pas accès aux mots de passe. Donc j'ai créé un utilisateur bidon qui a accès en lecture aux mots de passe et je l'ai mis dans libnss-ldap.conf (et pam_ldap.conf également, tant qu'à faire).

Toujours rien. NSS et PAM me retournent toujours:

Authentication service cannot retrieve authentication info



Une idée ?
  • # debconf ?

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

    Peux-tu nous donner (sauf mot de passe évidemment), le résultat de la commande suivante :
    $ debconf-show libnss-ldap

    En outre, peux-tu activer, si ce n'est déjà fait le niveau 256 (ou stats) des logs de slapd via la directive loglevel afin d'en savoir plus sur les erreurs au niveau d'openldap.
    • [^] # Re: debconf ?

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

      Voilà ma config de libnss-ldap


      jean@bohort:/etc$ sudo debconf-show libnss-ldap
      * libnss-ldap/rootbindpw: (password omitted)
      libnss-ldap/bindpw: (password omitted)
      * libnss-ldap/dblogin: false
      libnss-ldap/override: true
      * shared/ldapns/base-dn: dc=site,dc=com
      * shared/ldapns/ldap-server: ldap://127.0.0.1/
      * libnss-ldap/confperm: false
      * libnss-ldap/rootbinddn: cn=admin,dc=site,dc=com
      * shared/ldapns/ldap_version: 3
      libnss-ldap/binddn: cn=proxyuser,dc=example,dc=net
      * libnss-ldap/nsswitch:
      * libnss-ldap/dbrootlogin: true


      J'ai un utilisateur "test" dans ma base ldap dont voici les attributs d'après ldapsearch:

      # test, people, site.com
      dn: uid=test,ou=people,dc=site,dc=com
      homeDirectory: /home/test
      loginShell: /bin/bash
      uidNumber: 20010
      objectClass: top
      objectClass: person
      objectClass: organizationalPerson
      objectClass: inetOrgPerson
      objectClass: posixAccount
      objectClass: shadowAccount
      cn: Test Test
      uid: test
      sn: Test
      givenName: Test
      gidNumber: 20010
      mail: test@site.com
      userPassword:: XXXXXXXXXXXXXXXXXXXXXXXXX



      Voilà le log de slapd quand je tente un "su - test" :


      conn=14 fd=11 ACCEPT from IP=127.0.0.1:43278 (IP=0.0.0.0:389)
      conn=14 op=0 BIND dn="cn=admin,dc=site,dc=com" method=128
      conn=14 op=0 BIND dn="cn=admin,dc=site,dc=com" mech=SIMPLE ssf=0
      conn=14 op=0 RESULT tag=97 err=0 text=
      conn=14 op=1 SRCH base="ou=people,dc=site,dc=com" scope=1 deref=0 filter="(&(objectClass=shadowAccount)(uid=test))"
      conn=14 op=1 SRCH attr=uid userPassword shadowLastChange shadowMax shadowMin shadowWarning shadowInactive shadowExpire shadowFlag
      <= bdb_equality_candidates: (uid) index_param failed (18)
      conn=14 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
      conn=15 fd=15 ACCEPT from IP=127.0.0.1:43279 (IP=0.0.0.0:389)
      conn=15 op=0 BIND dn="cn=admin,dc=site,dc=com" method=128
      conn=15 op=0 BIND dn="cn=admin,dc=site,dc=com" mech=SIMPLE ssf=0
      conn=15 op=0 RESULT tag=97 err=0 text=
      conn=15 op=1 SRCH base="ou=people,dc=site,dc=com" scope=1 deref=0 filter="(uid=test)"
      <= bdb_equality_candidates: (uid) index_param failed (18)
      conn=15 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
      conn=15 op=2 BIND anonymous mech=implicit ssf=0
      conn=15 op=2 BIND dn="uid=test,ou=people,dc=site,dc=com" method=128
      slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
      conn=15 op=2 BIND dn="uid=test,ou=people,dc=site,dc=com" mech=SIMPLE ssf=0
      conn=15 op=2 RESULT tag=97 err=0 text=
      conn=15 op=3 BIND anonymous mech=implicit ssf=0
      conn=15 op=3 BIND dn="cn=admin,dc=site,dc=com" method=128
      conn=15 op=3 BIND dn="cn=admin,dc=site,dc=com" mech=SIMPLE ssf=0
      conn=15 op=3 RESULT tag=97 err=0 text=
      conn=15 op=4 UNBIND
      conn=15 fd=15 closed
      conn=14 fd=11 closed (connection lost)




      Remarque: je ne comprend pourquoi il y a des BIND en admin...


      Merci énormément pour l'aide, en tous cas.

      Jean

      "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

  • # Pistes

    Posté par  . Évalué à 1.

    Afin d'utiliser l'authentification SASL avec ldaps

    Je précise tout d'abord que je n'ai jamais utilisé SASL pour quoi que ce soit. J'ai déjà configuré (au boulot) un annuaire LDAP avec authentification de machines clientes dessus (et TLS pour empêcher tout sniffage de mot de passe sur le réseau), mais je ne sais pas quel impact supplémentaire a l'utilisation de SASL. Donc en particulier, ce que je vais te dire n'en tient pas compte.

    As-tu un intérêt à utiliser SASL au delà de la connexion au serveur LDAP ?
    Parce que je pense que la plupart des gens se contentent de TLS et que ça marche relativement facilement; en plus, comme ça n' a pas d'impact sur le mécanisme en général, tu peux commencer par mettre au point sans lui et l'ajouter quand le reste fonctionne.

    je stocke les mots de passe en CLEARTEXT.

    Pas glop !
    S'il n'est pas possible d'avoir un mot de passe chiffré avec SASL, c'est une bonne raison de ne pas l'utiliser.

    J'arrive à faire mes requêtes ldapsearch avec l'utilisateur admin et avec les utilisateurs autres, en ldap et en ldaps.

    ldaps, c'est normalement du SSL. Quel est l'intérêt d'utiliser SASL en plus (en fait, c'est une vrai question, l'intérêt de SASL m"échappe d'un point de vue général, alors qu'il doit bien y en avoir un) ? ou est-ce utilisé à la place ?

    En plus, les ACLs sont respectées : typiquement, tous les champs userPassword sont accessible depuis admin, un utilisateur lambda peut voir son mot de passe mais pas les autres, que du classique.

    Ce qui signifie que l'authentification sur le serveur LDAP fonctionne correctement.
    Note que si un des tes utilisateur en laisse un autre sur son compte 5 mn, celui-ci récupère son mot de passe en clair ! Il est normalement possible dans les ACL d'autoriser uniquement l'authentification et l'écriture pour le mot de passe, sans la lecture.
    Au passage, évite les regexps dans les ACL, cela grève les perfs d'OpenLDAP.

    Si je fait 'getent passwd', j'ai bien mes utilisateurs ldap.

    Donc nss est bien configuré.

    Par contre, nss et pam ne peuvent pas accéder au champ userPassword

    Ils n'ont pas à accéder au champ userPassword. À supposer qu'ils y accèdent, comme il n'est pas dans un format Unix, ils ne sauront pas quoi en faire.

    Le principe est que pamldap avec pam bien configuré teste avec une authentification sur le serveur LDAP si l'utilisateur et le mot de passe sont valides dessus, et considèrent si c'est le cas que l'utilisateur a le droit d'accéder à la machine cliente. Il s'agit d'un bind LDAP avec le dn de l'utilisateur et le mot de passe fourni, précédé d'une recherche avec la conf par défaut de ldap.conf (anonyme pour moi, mais ce n'est peut être pas forcément le cas, je n'ai pas de ldap.conf sous le coude pour vérifier) sur le nom d'utilisateur pour déterminer son dn. Il faut que ces deux opérations soient possibles.

    Pour moi, le problème vient donc de ta configuration de PAM (le plus probable, il est très pointilleux : pour situer, ça m'est arrivé souvent qu'un fichier de conf qui fonctionne parfaitement avec une version ne fonctionne plus avec une version ultérieure) ou de ton ldap.conf (ou alors ça fonctionne mal à cause de SASL). Note que si ça n'a pas changé, ldapsearch et autres utilisent /etc/openldap/ldap.conf et toutes les autres applis dont PAM /etc/ldap.conf . Moi, pour éviter des problèmes incompréhensibles, je remplace systématiquement l'un des fichiers par un lien sur l'autre.
    Tu devrais tracer les requêtes sur ton serveur pour voir si ton client fait bien les bonnes requêtes et si elles se déroulent correctement.

    Je ne peux pas te donner un exemple de configuration (je suis en vacances), mais éventuellement, si tu peux tester avec une installation de Fedora sur une machine cliente, son installateur graphique a l'avantage de générer une configuration de l'authentification sur LDAP directement fonctionnelle (avec TLS, bon, pour SASL...), ça te ferait une base pour ta configuration de PAM (voire ton ldap.conf).

    Sinon, pour tous tes problèmes de LDAP, la liste ldap-fr ( http://listes.cru.fr/sympa/info/ldap-fr ) peut être un meilleur endroit que LinuxFr pour obtenir des réponses.

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Pistes

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

      Tout d'abord, merci beaucoup pour ta réponse complète.

      Par rapport à SASL, j'ai suivi un tutoriel, mais effectivement je vois de moins en moins l'intérêt. Je l'ai d'ailleurs désactivé dans mes essais ultérieurs mais ça n'a rien changé.

      J'en ai profité pour utiliser MD5 pour les passwords, ce qui me semblait quand même mieux.

      Je remettrais TLS et/ou SSL après quand ldap normal marchera ce qui n'est toujours pas le cas, grrrrr.

      Quant à la config de nss et pam, je suis sous Debian et il me semble qu'ils n'utilisent pas ldap.conf mais leur propre fichier, respectivement /etc/libnss-ldap.conf et /etc/pam_ldap.conf. Certains tutoriels conseillent, d'ailleurs, de créer un lien depuis /etc/ldap/ldap.conf vers ces fichiers.... Je suis un peu perdu, j'avoue.


      Bon, j'ai répondu au message précédent avec plus d'info sur ma config et des logs. Si tu veux bien encore m'aider, je te renvoie vers ces informations supplémentaires, sinon merci déjà pour ton aide encore une fois.

      "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

Suivre le flux des commentaires

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