Forum Linux.debian/ubuntu soucis d'authentification sur apache et ldap

Posté par metabox le 18 avril 2006 à 18:17.

Étiquettes : aucune

avr.

2006

bonjour,

j'ai mis en place un controlleur LDAP, je me log sans soucis a partir d'un client windows.

Sous le client Linux j'ai installé les paquets libnss et libpam (configuré comme sur le serveur), modifié le fichier /etc/nsswitch.conf comme ceci :



passwd:         compat ldap

group:          compat ldap

shadow:         compat ldap

hosts:          files dns mdns

networks:       files

protocols:      db files

services:       db files

ethers:         db files

rpc:            db files

netgroup:       nis

et modifié les fichiers /etc/pam.d/common-auth, /etc/pam.d/common-password et /etc/pam.d/common-account en ajoutant cette option :



sufficient pam_ldap.so

et malgré ca, quand j'arrive pour me loguer sur le domaine, en mettant mon nom de user ldap, il me dit authentication failure"....le seul moment ou je peux me logguer sur le domaine c'est quand je suis root sur la machine locale, en faisant un "su mon_user_ldap" :(

savez vous d'ou cela pourrait il venir !?

Et autre soucis, qui a mon avis est lié a l'authentification linux :

j'ai mis une restriction d'acces sur le server web, en mettant ce fichier .htaccess :



AuthType Basic

AuthName "LDAP auth against user"

AuthLDAPEnabled on

AuthLDAPUrl ldap://127.0.0.1/dc=domain,dc=com

<LIMIT GET POST>

    Require valid-user

et la PAREIL, il me demande mon pass/login, et le seul autorisé a acceder au contenu est mon user root !

Savez vous d'ou pourrait venir ce probleme, comment remedier a ca ?

Merci d'avance de votre aide. :)

# pas vraiment la reponse...

Posté par NeoX le 18 avril 2006 à 20:44. Évalué à 1.

pour la premiere partie de la question il faut surement jouer avec le fichier de configuration de GDM/KDM/XDM pour lui dire de s'authentifier via LDAP

pour la 2e, je ne vois pas.

par contre je vais surveiller les reponses car ca m'interesse

pour le boulot on a un serveur de domain windows.
pour toi il semblerait que ce soit la meme machine.

a suivre donc.
- [^] # Re: pas vraiment la reponse...
  
  Posté par metabox le 19 avril 2006 à 03:58. Évalué à 1.
  
  je n'ai meme pas modifié de fichier /etc/pam.d/gdm ou autre,car je n'ai meme pas installé d(interface graphique sur le client, c'est au moment du prompt de login et quand je suis avec un user lambda que ca ne passe pas :(
  
  une idée quelqu'un ??
# identification ldap

Posté par Sytoka Modon (site web personnel) le 19 avril 2006 à 09:25. Évalué à 2.

Sur une debian, il n'y a pas besoin de modifier pam pour prendre en compte l'identification ldap ! Il suffit en effet de modifier comme tu l'as fait le fichier /etc/nsswitch.conf et de configurer le fichier /etc/libnss-ldap.conf

Comme on est obliger de modifier ces fichiers pour que le systeme connaisse son identité (commande id), il est absolument inutile de rajouter une ligne ldap dans pam, ou si cela est nécessaire, merci de me dire pourquoi car j'ai 20 machines qui fonctionne parfaitement sans ! Bref, pam c'est bien mais ce n'est pas encore suffisant, ce nsswitch traine encore...

Au niveau d'apache, cela n'a rien a voir. Apache tourne sous son identité propre et il n'y a aucun besoin que l'identification sous apache ai un quelconque rapport avec celle du système. Les deux problèmes sont donc dissociés à 100%. A mon avis, tu as une erreur dans ta configuration ldap au niveau d'apache.

Bon courage
- [^] # Re: identification ldap
  
  Posté par metabox le 19 avril 2006 à 15:00. Évalué à 1.
  
  donc j'ai bien retenté de modifier le nsswitsh.conf et libnss-ldap.conf, mais toujours sans succes, le seul moment ou je peux me logguer c'est quand je suis root... :(
# tentative de réponse

Posté par ultimat le 19 avril 2006 à 09:29. Évalué à 1.

Sur une debian, j'installe les paquets :
libpam-ldap libldap2 libnss-ldap

Après dans le fichier /etc/libnss-ldap.conf, je met un truc du genre :

host machin.exemple.org
base dc=exemple,dc=org
ldap_version 3

Dans le fichier /etc/pam_ldap.conf :

host machin.exemple.org
base dc=exemple,dc=org
ldap_version 3
pam_password md5

Si tu as nscd, eteind le pour faire les tests.

Toute ma doc est là : http://guim.info/article1.php si ca peut aider
- [^] # Re: tentative de réponse
  
  Posté par metabox le 19 avril 2006 à 15:06. Évalué à 1.
  
  malheuresement j'ai suivi a la lettre ton tuto, et je n'arrive toujours pas a m authentifier autrement qu en root :(:( . j ai essayé avant d aller modifier les fichiers pam.d et apres, meme resultat....
  Je pense que le probleme vient plus du serveur, vu que ca bug aussi au niveau d Apache...mais je ne vois pas du tout ou :(:( quelqu un aurait il une idée ???
  - [^] # Re: tentative de réponse
    
    Posté par ultimat le 19 avril 2006 à 18:46. Évalué à 1.
    
    les entrées que tu as dans le ldap héritent des classe posixAccount et shadowAccount ?
    - [^] # Re: tentative de réponse
      
      Posté par metabox le 19 avril 2006 à 19:21. Évalué à 1.
      
      euh qu'entends tu par heriter classe posixAccount et shadowAccount ?
      j'ai juste installer ldap+samba, sans rien modifier de spécial
      - [^] # Re: tentative de réponse
        
        Posté par ultimat le 19 avril 2006 à 21:29. Évalué à 1.
        
        comment ajoutes tu tes utilisateurs ?
        tu passes par smbpasswd ?
        
        [^] # Re: tentative de réponse
        
        Posté par metabox le 20 avril 2006 à 03:35. Évalué à 1.
        
        bien en fait j'ai crée mes users en passant par l interface web LAM, donc je ne sais pas ce qu'il execute exactement...
        
        mais j'ai pu remarqué que mon user ROOT etait dans les classes d objets :
        
        person (structural)
        organizationalPerson (structural)
        inetOrgPerson (structural)
        sambaSamAcoount
        posix Account
        shadowAccount
        
        et que mon user TEST_LDAP est dans ces classes la :
        
        sambaSamAcoount
        posix Account
        shadowAccount
        inetOrgPerson (structural)
        
        cela pourrait t il etre la cause du soucis ? comment faire pour modifier ces valeurs a la mano?
        
        [^] # Re: tentative de réponse
        
        Posté par metabox le 20 avril 2006 à 14:34. Évalué à 1.
        
        RE bonjour,
        
        donc concernant l'authentification du server WEB par l'annuaire LDAP, cela vient bien des OBJECTCLASS.
        
        avec un user crée sous l'interface LAM, il met le user juste dans ces objectclass :
        sambaSamAcoount
        posix Account
        shadowAccount
        inetOrgPerson (structural)
        
        avec un user crée avec SMBLDAP-USERADD, il me met direct dans ces objectclass suivantes, ce qui me permet de m'authentifier pour acceder au serveur web....
        person (structural)
        organizationalPerson (structural)
        inetOrgPerson (structural)
        sambaSamAcoount
        posix Account
        shadowAccount
        
        Seriez vous comment faire pour ajouter direct ces objectclass lors de la création d'un user avec LAM !?
        
        et je n'ai toujours pas réglé mon soucis à partir d'un client linux....si quelqu'un a une idée..
        
        [^] # Re: tentative de réponse
        
        Posté par ultimat le 20 avril 2006 à 17:47. Évalué à 2.
        
        désolé j'ai jamais utilisé LAM.
        
        Verifie que dans la base ldap le login de l'utilisateur est dans l'attributs nommé "uid" et son mot de passe dans "userPassword". S'il manque un des 2 attributs, ce sera mauvais signe.
        
        Sinon j'ai pas vraiment d'autres idées.
        
        [^] # Re: tentative de réponse
        
        Posté par metabox le 21 avril 2006 à 03:30. Évalué à 1.
        
        oui j'ai bien verifié mes uid et password, ils sont renseignés de la meme maniere pour root et pour les autres....vraiment je ne vois pas pourquoi je ne peux pas loguer sur le domaine autre qu en etant root sur la machine locale, c est assez fou.

Suivre le flux des commentaires

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