Salut à tous !
Dans la catégorie "question tordue " ( ), j'en tiens une :
 

La problématique est posée.
 
Ce que je souhaiterais faire :

 
Mon début de solution : un script, que les utilisateurs lancent dès qu'ils ont besoin d'un fichier sur mon serveur "fichiers001" (Windows) :

paf 1er soucis : "mount: seul l'usager ROOT peut faire cela"
 
Si je fais directement un sudo mount -t..., ça passe en demandant d'abord mon mot de passe (root de la machine ou "droits root" par sudoers) puis le mot de passe d'une personne qui sera concernée (par contre il changerait de domaine tout seul ? ). Idem en CIFS.
 
Avec pam_mount, il me demande à l'ouverture de session de taper 2 fois mon mot de passe... donc pas vraiment user friendly le truc
Et en plus gère mal les accès (je ne peux modifier un fichier créé depuis mon poste Ubuntu sur le serveur Windows, alors que depuis Windows je peux le faire, et que sur un serveur Debian je peux le faire aussi).
 
Je ne peux créé de fichier .smbcredentials avec le mot de passe de l'utilisateur en clair.
 
Je ne peux pas installer Likewise, même "que" pour 20 machines (pour rester en conformité logicielle dans l'authentification dans un parc de 1o ooo machines Ubuntu).
 
Aie.
Une idée ? éventuellement autre solution mais qui n'impose pas de changement du serveur Windows (on m'a dit : "ça fait 6 ans qu'il tourne, alors pas touche" )
 
(éventuellement à déplacer en "pro", mais vu que mes clients sont de l'Ubuntu, et que je souhaite scripter ...)

Pas d'idée ?

essaies la commande  
 

 
edit: autant pour moi, je n'ai pas vu que tu avais déjà essayé.
 
Je ne comprends pas bien l'histoire du changement de domaine. En ajoutant dans le fichier /etc/fstab, l'option user sur ton montage, tu peux autoriser d'autres utilisateurs que root.  
 
Chez nous, les machines linux sont intégrées au domaine, ça simplifie énormément les problèmes d'authentification.

Justement, mon soucis c'est que la machine est déjà sur le même domaine, enfin presque car étant dans un "sous-domaine" Kerberos lié à mon domaine Active Directory
Et je me sers d'Active Directory pour gérer mes droits d'accès pour les utilisateurs (tel user à ça, ça et ça, tel autre à ça, ça et ça,...) et gérer les quotas (j'ai pas envie de fusiller mes sauvegardes parce que 20 utilisateurs sur 100 sont "illimités" en espace disque , donc exit un montage avec un user "générique" avec un fichiers .smbcredentials avec son login et mot de passe valable que pour ce serveur).
 
Et j'ai beau configurer dans tous les sens le pam_mount, il me demande toujours 2 fois le mot de passe de l'utilisateur. Si ce dernier se trompe au 1er, la session ne s'ouvre pas (là ok, normal), mais s'il se trompe au 2ème la session s'ouvre mais pas le montage  
Et le "1234" ou "azerty" comme mot de passe ça le fera pas pour ne pas se tromper

 
bah vas y postes ta conf ...

Juste la partie modifiée de mon pam_mount.conf.xml qui contient mon montage ou la totale ? ( y'a du lourd )
Pour la base de PAM, on (ceux qui ont crée la base et l'ont déployé) s'est servi en grande partie d'une méthode identique à celle d'ubuntu-fr, avec juste une configuration personnalisée correspondant aux services d'identification.
 
De mon côté j'ai voulu partir sur la méthode expliquée ici (à Configuration de pam_mount) mais dans le sens "client ubuntu -> serveur Windows" :

Avec l'option guest, le montage m'est refusé (avec un fichier "lisez-moi" avec un message disant que le montage n'est pas accessible, blablabla...)
A cela s'ajoute un problème de droits (même en 666 je ne peux pas écrire sur un fichier dans mon serveur, bien qu'ayant la place et les droits dessus en lecture/écriture ), alors quite à ré-inventer la roue, j'en ferais pas une "carrée" et qui roule, elle !  
 
Comme par hasard, c'est le genre de problème souvent trouvé avec PAM (recherche Google sur la question posée à la connexion : "re enter password for pam_mount" ). J'ai déjà fouillé tous les fichiers de config à la recherche de "sufficient", ils sont déjà tous en "required" au minimum
La solution de mettre session sufficient pam_localuser.so avant le @include common_pammount change rien.
etc etc...

nan c'est la conf PAM qui m'intéresse ...
 
la ligne qui contient "pam_mount"
Pour ne pas re-saisir le mot de passe, il y a une option magique de PAM : try_first_pass

déjà tenté, try_first_pass et use_first_pass
 
bon, je rajoute quelques trucs :  
mon GDM (etc/gdm)

le common-pammount :

le try_fisrt_pass sur la ligne "session" ne sert à rien
 
fais voir ton common-auth

Le common-auth :

hum ... le [default=done] du pam_ccreds ne m'inspire pas trop ... je me demande s'il n'arrêterait pas l'exécution de la pile pam
 
perso je rajouterai le pam_mount au milieu, dans le common-auth :

j'ai essayé, toujours la même chose, toujours mon "reenter password for pam_mount"

"reenter password for pam_mount" c'est toi qui écrit ça comme ça, ou c'est ce qui s'écrit sur la console ou l'écran de login lors de l'identification ?

C'est ce qui est marqué sur l'écran de login, et la phrase je la retrouve dans le pam_mount.conf.xml à la toute fin :

bon, bah soit pam_mount est codé avec la pied, soit y'a un soucis avec ta conf PAM
 
parce que ça devrait clairement pas te redemander le mot de passe ...
avec le "use_first_pass", le mot de passe est transmis à chaque module sur toute la chaîne "auth" (bon, je suppose que je n'apprends rien là)
 
du coup, je pense que pour ceux qui disaient sur leurs forums "c'est bon j'ai trouvé" ça devait juste être à force de tatonner avec leur conf pam qu'ils ont fini par la faire marcher ...
 
là je suis désolé mais je ne peux plus trop grand chose pour toi, la conf PAM c'est (pour moi du moins) assez subtile, et il n'est vraiment facile de tester qu'avec la conf sous la main (ce que je n'ai pas) ...

D'où mon choix de trouver une solution alternative à pam_mount

j'ai bien compris, mais comme j'ai déjà essayé de te l'expliquer, y'a pas 36 solutions ...
 
* soit tu mets le mot de passe dans un fichier => tu ne veux pas
* soit tu passes par PAM pour profiter du fait que cet l'utilisateur lui même qui va saisir son mot de passe => tu n'arrives pas à configurer pam_mount
* soit tu passes par une identification "transparente" à la Kerberos => tu ne veux/peux pas
 
après si tu veux, on peut toujours appeler le génie de la lampe ...

je met quoi comme couple identifiant/mot de passe ?
-> celui d'un utilisateur local du serveur, et je perds tout moyen de contrôler qui met quoi dessus et je désactive les quota ?  
-> celui de l'utilisateur en lui-même, mais alors n'importe qui (enfin presque) peut trouver le mot de passe de mes utilisateurs ?  

ben ce n'est pas que je n'y arrive pas, c'est que c'est infaisable (si tu avais fait une recherche Google sur les termes du message qui m'est renvoyé, tu ne dirais pas ça)

ben justement, c'est ce que je souhaite mon client ubuntu s'identifie déjà sur un "sous-domaine" lié au domaine de mon serveur...
 
si c'est pour critiquer et ne pas faire avancer les choses, autant ne rien mettre s'il te plaît

tu es parano ou quoi ? est ce que j'ai dis quelque part que tu ne voulais pas pour de mauvaises raisons ? je fais un constat de la situation, point.
 

tu disais toi même avoir trouvé des posts ou la conclusion était "ça marche"
 

arrête la mauvaise foi s'il te plait ...
je t'ai donné comme info (dans le fil que tu as supprimé ...) que la commande mount.cifs avait une option -sec=krb5 qui permet justement de passer par une identification kerberos.
Tu veux quoi de plus, que je te dise explicetement écris un script à tel endroit avec tel contenu ...
Faut tester, et ça dépend complètement de ton installation !!

Je ne fais que constater aussi, sur d'autres sites de mon travail, ils sont arrivés à la même conclusion que toi, avec la création d'un utilisateur local sur le serveur, avec éventuellement un encryptage par gpg (sans passphrase). Résultat bof bof pour les raisons que je t'ai citées. Chose que je ne peux me permettre dans l'environnement où je bosse (sécurité, gros sous, etc... au bout d'un moment, si on n'est pas carré sur l'identification, "oh ben zut on a perdu 3ooo€ de matos" ).
Cela m'étonne même qu'ils n'aient pas déjà eu des problèmes  
 

Et si tu les avais lu, tu te demanderais si :
- soit ce sont des mythos ( youhou j'ai inventé le mouvement perpétuel)
- soit ils ont changés de principe de fonctionnement, pour faire un utilisateur local sur leur serveur.
 
Pour ceux que j'avais contacté pour exposer un peu quels réglages ils ont fait, pour tous ceux qui m'ont répondu (pas les mythos donc, qui mettent "RTFM" ) c'est le choix "utilisateur local" qu'ils ont pris... à contre-coeur.
 
Sur mon système l'option -sec=krb5 n'est pas reconnu seul le NTLM (par défaut quoi) permet de m'authentifier par rapport au serveur sur le domaine où travaille habituellement mes machines Ubuntu. Pour l'avoir testé dans un autre environnement (cad machine ubuntu sur serveur Debian), l'option -sec=krb5 ne permet pas de connaître le propriétaire des fichiers autres que les siens  
Et j'avais préféré supprimer le fil car cela partait (comme maintenant) sur des questions totalement autres

 
Bon, là ok ... si tu ne nous dis pas tout aussi
Je ne pouvais pas deviner tout ça !!!
 
Bah du coup, je sèche ...

pam_mount, j'en avais fait mais sur une authentification non-kerberos. C'est pas un problème entre pam_mount et kerberos en fait ?
 
Tu as essayé d'authentifier tes users avec kerberos, ssns faire d'automontage ? Tu peux récupérer des tickets avec kinit ? Si oui, tu dois pouvoir faire un montage post login, sans demande de mot de passe ?

Sans mes "bricolages" (avec l'insertion de pam_mount), ça le fait déjà.
 
Pour le kinit, il me redemande mon mot de passe (d'utilisateur du réseau)
En faisant klist, j'ai pourtant déjà un ticket qui doit expirer 10h après la connexion (la création du ticket)  
 
De plus je peux sans soucis faire un montage vers un serveur Debian sans redemande du mot de passe, mais pas sur ce pù$1n de serveur Windows    
 
Mon krb5.conf :

Normalement le ticket krb devrait te donner accès à la ressource réseau sans demande de mot de passe, c'est juste ? Si oui alors peut-être que le serveur d'authentification et le serveur de fichier ne sont pas dans le même "realm" ? Je connais pas encore assez krb pour debbuger en ligne de commande, navré.

Justement, je l'indiquais au début :

Donc "virtuellement" ils sont ensembles, puis que pour aller sur Kerberos ce dernier doit aller chercher ses billes (identifiants) sur AD
 
Je vais mettre "Résolu" aussi, jouer le "RTFM" etc etc...  
Ils se contenteront de mettre 2 fois leur mot de passe au démarrage, et basta  
 
(Sinon petite connerie : kinit redemande le mot de passe de l'utilisateur, c'est une action normale chez lui n'empêche que j'ai déjà mon ticket )

 
Nan ça c'est normal ...
La philosophie de base de Linux c'est que chaque commande doit faire un truc simple mais le faire bien
kinit c'est pour "initialiser" Kerberos donc pour récupérer un ticket, il se fout complètement que tu en aies déjà un ...
 
et ensuite ce n'est (forcément) le mot de passe de l'admin qu'il te demande, c'est le mode passe de l'utilisateur que tu lui donnes :
kinit user@real.tld
 
Par défaut, sans utilisateur spécifié, c'est effectivement l'admin ...
 
Si tu veux tester la validité de ton ticket acquis, tu as klist par exemple ..

C'est un peu une porte grande ouverte que tu as enfoncé  

   
Un klist me donne directement mon ticket, crée au login de l'utilisateur  
 
Mais bon, je clos toute recherche dessus, pas que cela m'enchante, mais bon je vais pas y passer 3 semaines j'ai passablement d'autres choses à voir au boulot :