J'ai donc un serveur ldap qui fait l'authentification du parc client ldap sous mandrake 10.1.
 
Toute l'authentification marche au poil, mais les clients ne peuvent pas verouiller la session ou lancer l'écran de veille verouiller, sous peine de ne pas pouvoir se déverouiller.
 
Quelqu'un sait d'où provient ce problème?
 
Merci par avance.

Allez un petit effort

Up de soutien pour un probleme bizarrr !
Encore un coup de pam j'en suis sur

j'ai trouvé la soluce, j'ai testé tout à l'heure, mais une fois relogué, il faut tué le process en console pour avoir de nouveau accès au X
 
Simple non

Heu moyen moins quand meme
Prevois de distribuer une notice a chaque utilisateur

Yep

il ressemble à ça ton /etc/pam.d/xscreensaver ?
 

Justement, sur les mandrakes 10.1 qu'on a déployé, il n'y a pas de xscreensaver, mais kscreensaver

 
Sur le site de mandrake dans un errata de la 9.1, on trouve ceci :

source : http://www.mandrakelinux.com/en/91errata.php3
 
le problème c'est que maintenant (10.X) /etc/pam.d/xscreensaver et /etc/pam.d/kscreensaver3 sont identiques, ils utilisent system-auth, donc le problème est encore ailleurs
 
Je tenterais de mettre de côté le kscreensaver3 et en recréer un avec ceci :

 
donc ne pas faire directement appel à system-auth... ou alors installer xscreensaver (en utilisant la même chose qu'au dessus pour le pam.d/xscreensaver) et l'utiliser à la place de kscreensaver... regarde aussi du côté de /etc/pam.d/kde3
 
Pour comparaison, je suis sous fedora avec auth ldap sur un serveur du LAN et ça fonctionne avec ça :
/etc/pam.d/system-auth :

 
/etc/pam.d/xscreensaver :

 
/etc/pam.d/kde :

 
la reprise après lock ou écran de veille fonctionne sans problème, l'auth se fait bien sur le serveur ldap
 
la solution n'est peut-être pas là, mais ça pourra peut-être aider

Je regarderais ca
 
J'ai déjà essayé de changé le pam system-auth en mettant en dur dans le kscreensaver pam_ldap, mais la ca s'authentifie et ca crash le screen saver (obligé de passer en console pour killer l'applis )

Après test, ca ne fonctionne pas avec la mandrake 10.1

Klaimant> fais un bug report alors stp
http://qa.mandrakesoft.com

 
 
Je vais le faire

http://qa.mandrakesoft.com/show_bug.cgi?id=14874
 
Ca fait un moment que je l'ai fait, c'est normal qu'il soit toujours en unconfirmed ?

il faut que quelqu'un y jette un oeil et le confirme.
 
Avec la sortie de la 10.2 les dev sont un peu overbookés.

 
 
Moi j'ai pas l'air d'un glandu au boulot

je pense que tu devrais utiliser systhem-auth pour kscreensaver ...

 
 
Déjà essayé, et ca plante pareille

peux tu poster le contenu de /etc/pam.d/kscreensaver et aussi donner le contenu des logs lorsque l'utilisateur essaie de s'auth/dévérouiller l'écran

/etc/pam.d/kscreensaver :

 
Et on obtient dans les logs au dévérouillage :

 
J'ai essayé de modifier kscreensaver pour virer les options :

 
Et là kscreensaver plante et me demande poliement de le tuer en me donnant son PID et dans les logs :

 
J'ai mis les droits sur /etc/ldap.conf en 600 (mdp oblige) je vais allez vérifié si en 660 çà passe mieux !
 
 
Merci en tout les cas

Chmod 644 et ca fonctionne, mais maintenant ca me pose un gros problème de sécurité pour le mot de passe du proxy user.
 
J'avance un peu

donc avec systhem-auth cela marche et c'est la lecture du ldap.conf qui pose problème ...
 

 
Oui, mais les autres applis KDE, kdm, kcontrol n'accède pas à ldap.conf "directement" et donc n'ont pas besoin d'avoir l'accès en écriture pour other en 644.
 
C'est pas très clair si ??
 
Merci.

pour "corriger" ce probleme de sécurité, j'au vu quelque part qu'il fallait créer un user servant seulement à authentifier sur le ldap, et le mettre dans le ldap.conf. Comme ça, meme si quelqu'un decrypte le pass dans ldap.conf, il ne peut pas faire grand chose avec cet user bridé

ça peut se faire comme ça :
 
soit l'arborescence de la base LDAP mondomaine.org suivante :
 

 
-rw-r--r-- root root /etc/ldap.conf

 
ici l'utilisateur "nssldap" sert d'utilisateur pour l'authentification unix
 
-rw------- root root /etc/ldap.secret

 
tout le monde peut lire /etc/ldap.conf, mais seul root a accès à /etc/ldap.secret

le binddn
 
j'ai regardé dans le bouquin O'Reilley, et en effet il faut faire un chmod a+r sur /etc/ldap.conf
 
ensuite eux il font les auth de manière anonyme, donc aucun mdp n'est mis dans ldap.conf

J'ai déjà un proxy user, mais son mot de passe est en clair dans le ldap.conf.
 
Je testerais avec le fichier ldap.secret demain

ldap.secret sert uniquement pour le mot de passe de l'admin si tu as specifié un rootbinddn, pas pour le proxy user.
 
Tant pis, faudra vivre avec l'idee que le password du proxy user se balade en clair sur notre reseau    
 
C bizarre quand meme que nscd fasse pas son job. C'est le seul service (l'ecran de veille) qui reagit comme ca  

 
Certes glandu !
 
Mais si tu regardes bien ce que dis le monsieur rootbinddn cn=nssldap,ou=UNIX,dc=mondomaine,dc=org  
 
Il spécifie le cn=nssldap, donc on peut essayer de fainter ldap  

Pis de toute facon, vu qu'on utilise TLS, le password proxy user ne se balade pas en clair, faut deja se logguer (on se rassure comme on peu )

 
tiens t'es la toa    
hum, oué pourquoi pas... Ca doit marcher je pense. Enfin bon, c pas la mort de laisser ldap.conf en 644 ... Je pense que c'est c negligeable...

 
 
C'est pas propre, si on commence comme çà, où va finir le service info je vous le demande

DTC    
 
C pas que "c'est pas propre", c'est que ca a ete prévu pour marcher comme ca stout

 
 
c'est quoi ces admins
 
   
 
 
 
 
 

On fait ce qu'on peut avec nos moyens et nos emmerdes Monsieur

moyens financiers je précise

 
Où moyen humain, vu l'état de mon collègue  

La guerre est ouverte
En attendant, on s'en sort plutot bien , enfin je pense  

Ouais "on" !!

Bon j'ai testé la manip, si je mets le rootbinddn ca fonctionne partout normalement, sauf que le "BUG" avec le kscreensaver reviens