Forum Linux.debian/ubuntu Problème LDAP

• # debconf ?

  Posté par Raphaël SurcouF (site web personnel) le 29 décembre 2007 à 00:32. É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 Jean Parpaillon (site web personnel) le 07 janvier 2008 à 15:38. É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 Arthur Accroc le 29 décembre 2007 à 09:31. É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 Jean Parpaillon (site web personnel) le 07 janvier 2008 à 15:47. É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.