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.mondomaineJusque 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 bergamote23 . Évalué à 3.
" -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 aurel . Évalué à 2.
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 spotty . Évalué à 4.
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 aurel . Évalué à 2.
[^] # Re: As-tu pensé
Posté par aurel . Évalué à 2.
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 ultimat . Évalué à 2.
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 aurel . Évalué à 2.
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:
2. lorsque je fais un "su -"
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 NeoX . Évalué à 2.
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 aurel . Évalué à 2.
[^] # Re: il me semblait...
Posté par Quentin Delance . Évalué à 0.
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.