Informatique
Linux
Programmation
Maintenance
Trucs en vrac

Pam_mount:

Introduction
Remerciements
Situation
Mise en oeuvre
Installation
Modification
Expérimentation suppl.
Déboggage
Mots de passe locaux ou sur le domaine
Liens

Pam_mount

Sous-titre: "Montez avec PAM"

Introduction:

J'ai rédigé ce document à la suite d'une expérimentation motivée par ce qui suit:
J'ai mis en place, en établissements scolaires, des serveurs de fichiers Samba PDC (c'est-à-dire offrant un dossier personnel pour chaque utilisateur avec la facilité d'accès que propose un lecteur réseau,...) pour des clients sous W$9x/W$me.
Ainsi de n'importe quel poste, un utilisateur retrouve ses documents personnels.

Je souhaitais ensuite proposer Linux comme station de travail bureautique et internet et faire en sorte que les utilisateurs retrouvent leurs documents de la même façon que s'ils étaient sous Window$ ("de la même façon" ... que dis-je!? Mieux que s'ils étaient sous Window$).

Le mode natif de partage sous Linux/Unix est NFS, mais je ne voulais pas multiplier les modes de partage.

Je désirais faire du client Linux, un client du domaine Samba.

1er problème: contrairement à w$9x/W$me, Linux est un système qui nécessite des utilisateurs définis.
Il y a un contrôle d'accès et la notion d'utilisateur invité n'est pas présente.
Je ne souhaitais pas devoir re-créer mes utilisateurs sur chaque client Linux avec les problèmes de synchronisation des mots de passe entre les clients et le serveur que cela amènerait.
C'est Winbind qui va permettre de se loguer avec des comptes définis sur le serveur.

2ème problème: Winbind n'offre que l'authentification à distance d'après des comptes définis sur le serveur.
Il n'offre pas l'accès au dossier personnel de l'utilisateur sur le serveur.
Il est certes possible d'effectuer le montage du dossier personnel sur le serveur à la main, mais il faut après s'être logué (avoir fourni son mot de passe), saisir à nouveau son mot de passe pour le montage de la ressource sur le serveur.
C'est PAM et le module pam_mount qui vont permettre d'éviter de ressaisir le mot de passe et de monter automatiquement le dossier personnel localement.

Petite intro sur PAM avec un extrait de man pam:

   Linux-PAM  Est  un  système  de  bibliothèques  qui  gèrent  les tâches
   d'authentification des applications (services)  sur  le  système.   Les
   bibliothèques  fournissent une interface d'abstraction stable (Applica-
   tion Programming Interface - API) qui accorde les privilèges  aux  pro-
   grammes  (comme login(1)  et  su(1))  en  ajournant la réalisation des
   tâches standard d'authentification.

C'est-à-dire que les tâches d'authentification,... sont gérées par un système qui est distinct du logiciel qui l'utilise.
Cela évite de reprogrammer un système d'authentification pour chaque logiciel.
PAM se paramètre par modules avec et permet entre autres de transmettre au module suivant le mot de passe saisi et exploité par un premier module. Cela permet d'éviter de multiples saises de mot de passe (c'est ce qui m'intéresse ici).

PAM permet bien d'autres choses et le propos n'est pas ici de les détailler.
Voir la rubrique Liens pour en apprendre plus.

Remerciements:

J'ai reçu l'aide de plusieurs personnes avant de réussir à faire fonctionner le dispositif samba/winbind/pam/pam_mount.
En premier lieu, Yann CANTIN (les détails de la démarche mise en oeuvre dans le cadre d'AbulAdu m'ont vraiment permis de parvenir à mes fins), mais aussi John Perr, Gilles Simon, Olivier Lécluse, Sylvestre Taburet, Mickaël Monnier,...
Il s'agit là de remerciements pour l'aide obtenue sur des listes de diffusion et cela n'engage en rien leur responsabilité quant à la qualité de ce que je rapporte ici de mes expérimentations.

Situation:

Le serveur est un portable faisant tourner une Mdk9.1 avec un serveur samba2.2.7a
La machine se nomme DeepGlue.MaMaison (ip 192.168.52.182) et le serveur Samba se présente sous le nom LeJoliServeur avec MaMaison pour domaine/groupe de travail.
La configuration PDC de ce serveur n'est pas détaillée ici.

Le client est une machine qui fait tourner une Mdk9.0
Il se nomme DingDong.MaMaison et dispose de l'ip 192.168.52.3

Mise en oeuvre:

Je relate ici l'expérimentation de deux situations:

installation d'une distribution Mdk9.0 destinée à faire un client d'un domaine window$/samba.
modifications sur une distribution Mdk9.0 (installée de façon classique) pour la "transformer" en client d'un domaine windwo$/samba.

Installation:

Il s'agit ici de l'installation d'une Mdk9.0 avec pour objectif de faire l'Authentification sur le Domaine Window$ (c'est une option disponible lors de l'installation).

Sur le serveur Samba DeepGlue, le fichier /etc/samba/smb.conf contient la ligne qui va permettre de créer automatiquement le compte machine pour la machine cliente DingDong que nous allons installer:

 add user script = /usr/sbin/useradd -d /dev/null -g machines -c 'Machine Account' -s /bin/false -M %m$

Et le compte root a été défini sur samba (avec un mot de passe différent de celui d'accès à Linux, par précaution) pour pouvoir faire intégrer les machines au domaine (pour Linux et w$nt/2k/xp):

[steph@DeepGlue steph]$ su
Password:
[root@DeepGlue steph]# smbpasswd -a root
New SMB password:
Retype new SMB password:
Password changed for user root.
[root@DeepGlue steph]#

Sur la future machine cliente DingDong, qui n'est encore qu'un amas d'électronique ou qui peut-être pire, héberge le virus M$Window$;o):
- Effectuer une Installation en mode Expert, avec les paquetages que vous souhaitez (Client réseau tout de même).
Et lors de la saisie du mot de passe root, n'allez pas trop vite:

Choix du type d'authentification

Dans le champ "Authentification", ne laissez pas "Fichiers locaux", mais sélectionnez "Domaine Window$" (même si votre domaine est en fait un Domaine Samba).

Saisissez le mot de passe root souhaité pour la machine DingDong;

Saisie du mot de passe root

Il vous est ensuite demandé le nom du domaine, le nom du compte administrateur du domaine (c'est à dire le compte samba-root sur DeepGlue) et son mot de passe:

Intégration du domaine

Une fenêtre vous explique ensuite ce qui va être fait et comment faire le travail à la main si pour une raison ou une autre cela échouait.

Information

Le paquetage samba-winbind (qui permet l'authentification distante) est ensuite automatiquement installé:

Je n'ai pas défini d'utilisateurs locaux (en dehors de root qui est toujours local), bien que cela m'ait été proposé.

Et c'est tout on passe à la suite de la configuration post-installation.

Ne jetez pas un oeil à ce stade à vos fichiers /etc/passwd, /etc/shadow et /etc/samba/smbpasswd sur DeepGlue, ils ne contiennent encore aucune information sur DingDong (ne le faites pas, vous dis-je il n'y a rien sur DingDong (ni dingdong), j'ai vérifié... et ce n'était pas bien malin comme vous allez le voir).

Dans la phase de post-installation, une étape importante est la configuration du réseau...
... une fois cette configuration effectuée, on a un peu plus de chance d'intégrer le Domaine Window$;o).
Je n'ai pas contrôlé à quel moment après cette installation, l'intégration au Domaine s'est produite, mais les fichiers /etc/passwd, /etc/shadow et /etc/samba/smbpasswd sur DeepGlue ont bien vu apparaitre une ligne concernant dingdong.
Est-ce juste après la configuration réseau ou au premier boot, je l'ignore.

Remarque:
Au premier démarrage, kdm n'a pas trouvé un seul utilisateur sur le Domaine.
J'ai redémarré le serveur X et tous mes utilisateurs sur le domaine sont apparus.

Cette installation a automatiquement configuré samba et winbind correctement (à un détail prêt, mais la faute m'incombe) sur DingDong.

Voici le fichier /etc/samba/smb.conf créé par défaut sur DingDong:

[global]
    workgroup = MaMaison  
    server string = Samba Server %v
    security = domain  
    encrypt passwords = Yes
    password server = *
    log file = /var/log/samba/log.%m
    max log size = 50
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
    character set = ISO8859-15
    os level = 18
    local master = No
    dns proxy = No
    winbind uid = 10000-20000
    winbind gid = 10000-20000
    winbind separator = +
    template homedir = /home/%D/%U
    template shell = /bin/bash
    winbind use default domain = yes

En voici un exemplaire: smb.conf.mdpdomaine

Comme j'ai eu la mauvaise idée de choisir un nom de domaine "MaMaison" avec des caractères en majuscules/minuscules et que le nom de domaine reconnu est "MAMAISON", il se pose un problème avec la ligne "template homedir = /home/%D/%U" dans le /etc/samba/smb.conf de DingDong.

Voici ce qui se passait:

Mandrake Linux Release 9.0 (dolphin) for i586
Kernel 2.4.19-16mdk on an i686 / tty1
DingDong login: toto
Password:
Creating directory /home/MAMAISON/toto

Permission denied
INIT: Id "1" respawning too fast: disabled for 5 minutes

En effet, lorsqu'on tente de se loguer sur DingDong avec un compte définit sur le domaine MaMaison (sur DeepGlue/LeJoliServeur), il est nécessaire de disposer d'un home local.
Il est automatiquement créé, mais il se présente alors une incompatibilité entre le /home/MaMaison cherché par le samba de DingDong (cf workgroup=MaMaison dans le /etc/samba/smb.conf de DingDong) et le /home/MAMAISON créé d'après le nom du domaine (cf NETBIOS) et le login échoue.

Je me suis donc logué en root et j'ai modifié cette ligne en "template homedir = /home/MaMaison/%U".
"template homedir = /home/%U" aurait également convenu et c'est ce que j'avais fait lors de tests précédents.
J'aurais également pu renommer le dossier en /home/MAMAISON dans l'arborescence du client DingDong.

J'ai ensuite redémarré winbind:

[root@DingDong root]# /etc/init.d/winbind restart

De retour à l'interface graphique: KDM
J'ai pu me loguer sans problème avec un compte défini sur le Domaine MaMaison (c'est-à-dire un utilisateur Linux/Samba défini sur le serveur DeepGlue).
Cependant, je n'avais pas localement les fichiers créés avec ce compte sur DeepGlue (le contenu du home de l'utilisateur sur DeepGlue n'a pas été copié vers DingDong).

Remarques:

(1) Il n'est pas possible (contrairement à NFS) d'avoir l'intégralité du home sur DeepGlue, car SMB ne supporte pas la création de fichiers spéciaux nécessaires à Linux (SMB est un protocole de type window$), notamment les fichiers cachés .DCOPserver_DeepGlue.MaMaison__0 et .DCOPserver_DeepGlue.MaMaison_:0

(2) Lorsque pam_mount sera mis en oeuvre, on n'aura pas une circulation sur le réseau, en début et fin de session, du contenu du home sur DeepGlue vers DingDong, mais juste un montage de la ressource.
C'est-à-dire que l'on travaillera comme sur un lecteur réseau, les transferts ayant lieu pendant la session.
Il est toutefois possible de travailler dans la partie locale du home sur DingDong et de déplacer vers le montage (équivalent du "lecteur réseau") les données lorsque vous le souhaiterez.

Mise en oeuvre de pam_mount:

Nous allons faire en sorte que le home local créé à la volée pour les comptes distants définis sur samba/DeepGlue comporte un point de montage pour le home distant.
Et pour ne pas dépayser les utilisateurs window$, nous allons l'appeler "Mes Documents" (même si à mon goût, il vaut mieux éviter les espaces, accents,... dans les noms de fichiers et de dossiers):

[root@DingDong root]# mkdir "/etc/skel/Mes Documents"

J'ai récupéré l'archive de pam_mount sur http://freshmeat.net/projects/pam-mount/ à l'adresse http://freshmeat.net/redir/pam-mount/20226/url_tgz/pam_mount.tar.gz (cette adresse est squceptible de changer avec de nouvelles versions).

Le fichier pam-mount.tar.gz récupéré sur DeepGlue, j'ai dû renseigner le /etc/hosts de DingDong pour qu'il parvienne à effectuer le montage smb nécessaire à la récupération de l'archive pam-mount.tar.gz sur DingDong (il semble que ce soit nécessaire dans certains cas (résolution de nom netbios qui merdouille)).

[root@DingDong root]# echo "192.168.52.182 DeepGlue" >> /etc/hosts
[root@DingDong root]# smbmount //DeepGlue/public /mnt/disk
Password:
Anonymous login successful
[root@DingDong root]# cp /mnt/public/pam_mount.tar.gz ./
[root@DingDong root]# tar -xvzf pam-mount.tar.gz
...
[root@DingDong root]# cd pam_mount-0.5.14
[root@DingDong pam_mount-0.5.14]# ./configure

Et des erreurs sont apparues lors de la tentative de compilation.
J'ai donc procédé à des installations de paquetages pour satisfaire dépendances et présence des outils de compilation.

[root@DingDong pam_mount-0.5.14]# urpmi gcc

Cela m'a aussi installé:
        binutils-2.12.90.0.15-1mdk.i586
        gcc-3.2-1mdk.i586
        glibc-devel-2.2.5-16mdk.i586
        kernel-headers-2.4.18-41mdk.i586
        libbinutils2-2.12.90.0.15-1mdk.i586

Il me manquait alors encore le fichier pam_modules.h
Une recherche m'a indiqué plusieurs paquetages proposant ce fichier.

[root@DingDong pam_mount-0.5.14]# urpmi pam-devel

Tout est là, on passe à la compilation et à l'installation:

[root@DingDong pam_mount-0.5.14]# ./configure
...
[root@DingDong pam_mount-0.5.14]# make
...
[root@DingDong pam_mount-0.5.14]# make install
...

Dans cette installation le fichier de configuration pam_mount.conf n'a pas été copié vers l'emplacement adéquat.
J'ai donc copié le fichier d'exemple de l'archive vers /etc/security:

[root@DingDong pam_mount-0.5.14]# cp ./config/pam_mount.conf /etc/security/
[root@DingDong pam_mount-0.5.14]# vi /etc/security/pam_mount.conf

Et je l'ai modifié de façon à n'avoir pour seules lignes non commentées que ce qui suit:

#debug 1
mkmountpoint 1
lsof /usr/sbin/lsof

options_require    nosuid,nodev

smbmount /bin/mount -t smbfs
umount   /bin/umount

volume * smb DeepGlue & ~/Mes\ Documents uid=&,gid=&,fmask=0650,dmask=0750 - -

En voici des exemplaires non élagué pam_mount.conf et élagué pam_mount.conf.elague.

La ligne "debug 1" est à commenter une fois que cela fonctionne bien.

J'ai ensuite édité le fichier /etc/pam.d/system-auth qui contenait à l'origine:

#%PAM-1.0

auth       sufficient    /lib/security/pam_winbind.so
auth       required      /lib/security/pam_env.so
auth       sufficient    /lib/security/pam_unix.so likeauth nullok use_first_pass
auth       required      /lib/security/pam_deny.so

account     sufficient   /lib/security/pam_winbind.so
account     required     /lib/security/pam_unix.so

password    required     /lib/security/pam_cracklib.so retry=3 minlen=2  dcredit=0 ucredit=0
password    sufficient   /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required     /lib/security/pam_deny.so

session     required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     required     /lib/security/pam_limits.so
session     required     /lib/security/pam_unix.so

Et je l'ai transformé en:

#%PAM-1.0

auth       required      /lib/security/pam_env.so
auth       sufficient    /lib/security/pam_unix.so likeauth nullok    <Chgt ordre et options>
auth       requisite     /lib/security/pam_winbind.so use_first_pass  <Chgt ordre et options>
auth       sufficient    /lib/security/pam_mount.so use_first_pass    <Ajout>
auth       required      /lib/security/pam_deny.so

account     sufficient   /lib/security/pam_winbind.so
account     required     /lib/security/pam_unix.so

password    required     /lib/security/pam_cracklib.so retry=3 minlen=2  dcredit=0 ucredit=0
password    sufficient   /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required     /lib/security/pam_deny.so

session     required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     required     /lib/security/pam_limits.so
session     required     /lib/security/pam_unix.so
session     required     /lib/security/pam_mount.so                   <Ajout>

Voici quelques explications:
On veille à donner la priorité à l'authentification locale pam_unix pour permettre à root de se loguer quoi qu'il arrive ensuite avec pam_winbind et pam_mount.
Le module pam_unix.so étant sufficient, si il y a authentification sur le compte local, c'est OK pour la partie auth.

Le module pam_winbind récupére le mot de passe saisi à l'étape précédente comme l'indique le paramètre use_first_pass.
De la même façon le mot de passe pour pam_mount est récupéré de la saisie précédente.

Et des détails supplémentaires:

1ère ligne:
Il est nécessaire que tout se passe bien au niveau de pam_env.so (module faisant référence à /etc/security/pam_env.conf où l'on définit les variables d'environnement pour les utilisateurs).
En cas de problème, même root ne se loguerait pas.

2ème ligne:
sufficient: Si l'authentification à la mode unix, c'est-à-dire avec référence à /etc/passwd et /etc/shadow réussit, on a une réponse positive à l'authentification quoiqu'il arrive après (sauf si on a un échec sur les/la ligne qui précède). Mais si c'est un échec, ce n'est pas rédhibitoire.

3ème ligne:
requisite: Si on échoue là (sans réponse positive obtenue sur un sufficient auparavant), on ne va pas plus loin et l'authentification est un échec.
Cela signifie ici que si on n'est pas authentifié avec un compte/mot de passe local, ni avec un compte/mot de passe sur le domaine, c'est un échec.
Si on réussit, on est reconnu sur le domaine et on poursuit la phase d'authentification à la ligne suivante sans donner à ce stade une réponse définitive sur la réussite de l'authentification.

4ème ligne:
sufficient: Si le montage des partages via pam_mount est un succès on obtient à ce stade la validation de la phase d'authentification.
Sinon, ce n'est pas rédhibitoire.
Dans le cas où l'on n'a pas eu de réponse négative sur un required ou requisite jusque là, l'authentification est validée (mais sans le montage du home distant).

5ème ligne:
required: Si un fichier /etc/<<<...à rechercher>>> existe seul root est autorisé à se loguer.
Cela bloque-t-il si on a obtenu une réponse OK sur un sufficient avant?
A tester.

Me gourre-je dans mon analyse?

Il reste encore à passer les phases account, password et session.
Je n'ai pas bien saisi dans quelles circonstances les lignes password interviennent sur un login par exemple.
Il me semblait que cela concernait le changement de mot de passe, donc plutôt sur une commande passwd par exemple.

Attention aux fautes de frappe dans /etc/pam.d/system-auth
Et dans toute votre phase de tests, conservez une console root ouverte et faites des essais de login dans d'autres consoles.
Il peut arriver qu'un "su" ne fonctionne plus, ne vous contentez donc pas d'une console avec un utilisateur non root.
Si toutefois vous rencontriez une situation de blocage, démarrez Lilo avec l'option: "linux single"
Vous pourrez vous loguer sans mot de passe et corriger vos bêtises;o).

Ceci étant fait, vous devez pouvoir vous loguer et obtenir votre home distant dans "~/Mes Documents".

Pensez à commenter la ligne "debug 1" de /etc/security/pam_mount.conf si tout fonctionne.

Remarques:

Voir la rubrique déboggage si les choses ne se passent pas comme prévu.

Modification:

Imaginons maintenant que le client Linux est déjà installé et que l'on n'a pas très envie de refaire l'installation.
Il va simplement falloir faire une partie des modifications à la mains.
La distribution sur DingDong est une Mdk9.0 avec serveurs samba2.2.6pre2 et winbind et mots de passe locaux.

J'ai renseigné le fichier /etc/hosts de DingDong pour une meilleure résolution des noms sur le réseau local:

[root@DingDong root]# echo "192.168.52.182 DeepGlue" >> /etc/hosts

J'ai ensuite effectué des copies de sauvegarde des différents fichiers qui vont être modifiés:

[root@DingDong root]# cp /etc/pam.d/system-auth /etc/pam.d/system-auth.1
[root@DingDong root]# cp /etc/pam.d/system-auth /etc/pam.d/system-auth.1
[root@DingDong root]# cp /etc/samba/smb.conf /etc/smb.conf.1

J'ai remplacé le system-auth du client DingDong correspondant à une installation classique par le modèle sytem-auth-winbind correspondant à une situation d'authentifiaction sur un domaine window$/samba (j'ai effectué d'autres modifs par la suite)

[root@DingDong root]# cp /etc/pam.d/system-auth-winbind /etc/pam.d/system-auth

J'ai également remplacé le smb.conf par défaut du client DingDong par la version client winbind:

[root@DingDong root]# cp /etc/samba/smb-winbind.conf /etc/smb.conf

Et dans ce nouveau /etc/samba/smb.conf, j'ai modifié les lignes:

   workgroup = MaMaison
   netbios name = DingDong
;   template homedir = /home/%D/%U
   template homedir = /home/%U

En voici un exemplaire: smb-winbind.conf.mdplocaux (il mériterait d'être élagué).

Sur DeepGlue, le compte root samba est défini:

[steph@DeepGlue steph]$ su
Password:
[root@DeepGlue steph]# smbpasswd -a root
New SMB password:
Retype new SMB password:
Password changed for user root.
[root@DeepGlue steph]#

Le fichier /etc/samba/smb.conf de DeepGlue contient la ligne "add user script = /usr/sbin/useradd -d /dev/null -g machines -c 'Machine Account' -s /bin/false -M %m$" pour permettre de créer automatiquement le compte machine pour les clients qui vont intégrer le domaine.

J'ai veillé à démarrer samba sur DeepGlue:

[root@DeepGlue steph]# samba start
Starting SMB services:                                         [  OK  ]
Starting NMB services:                                         [  OK  ]
[root@DeepGlue steph]#

Depuis le client DingDong, j'ai demandé à intégrer le domaine MaMaison dont DeepGlue est le Contrôleur Principal:

[root@DingDong steph]# smbpasswd -j MaMaison -r DeepGlue -U root
Password:
Joined Domain MAMAISON.
[root@DingDong steph]#

Les paramètres de la commande sont -j domaine, -r contrôleur du domaine et -U utilisateur administrateur du domaine (du serveur samba).
A la demande du mot de passe, j'ai saisi le mot de passe de l'utilisateur root samba de DeepGlue.

Remarques:

Une fois toutes les machines sur le Domaine intégrées, il est peut-être intéressant au point de vue sécurité de commenter la ligne dans le /etc/samba/smb.conf du serveur DeepGlue et de supprimer le compte root de samba.

Si on ne place pas la ligne indiquée dans le /etc/samba/smb.conf du serveur DeepGlue, l'alternative est la suivante:

Sur DeepGlue:

[root@DeepGlue root]# useradd -g machines -c "Compte Machine" -d /dev/null -s /bin/false dingdong$
[root@DeepGlue root]# smbpasswd -a -m dingdong
Added user dingdong$.
[root@DeepGlue root]#

Et sur DingDong:

[root@DingDong root]# smbpasswd -j MaMaison -r DeepGLue -U root
Password:
Joined Domain MAMAISON.
[root@DingDong root]#

Puis

[root@DingDong root]# /etc/init.d/smb restart
...
[root@DingDong root]# /etc/init.d/winbindd restart
...

Avec samba arrêté sur le client DingDong cela fonctionne quand même, mais winbindd doit tourner.

Un petit test:

Plutôt que d'effectuer les test dans l'interface graphique où les erreurs ne sont pas affichées, j'ai préféré la console:

CTRL+ALT+F1 sur DingDong et j'ai pu me loguer avec un utilisateur défini sur DeepGlue/Samba (sur le domaine MaMaison en somme).

Mandrake Linux Release 9.0 (dolphin) for i586
Kernel 2.4.19-16mdk on an i686 / tty1
DingDong login: toto
Password:
Creating directory '/home/toto'
Creating directory '/home/toto/tmp'
id: ne peut trouver le nom du groupe ID 10000
[toto@DingDong toto]

Remarque: Le login est plus long qu'un login local classique (15-20secondes au jugé).

Au login suivant avec le même compte:

Mandrake Linux Release 9.0 (dolphin) for i586
Kernel 2.4.19-16mdk on an i686 / tty1
DingDong login: toto
Password:
Last login: Thu May 29 11:57:41 on vc/1
id: ne peut trouver le nom du groupe ID 10000
[toto@DingDong toto]

Mise en oeuvre de pam_mount:

Reste à accéder au home de l'utilisateur sur DeepGlue depuis le client DingDong.

Pour cela, quelques actions restent à effectuer sur le client DingDong (aucune sur le serveur DeepGlue):

On ajoute le point de montage pour le home de l'utilisateur sur le domaine:

[root@DingDong root]# mkdir "/etc/skel/Mes Documents"

Il existe aussi des RPM.
Celui que j'ai récupéré nécessitait (pour Mdk9.0) une nouvelle version de libc.so.6:

[root@DingDong root]# urpmi pam_mount-0.5.9-1mdk.i586.rpm
installation de ./pam_mount-0.5.9-1mdk.i586.rpm

L'installation a échoué:
        libc.so.6(GLIBC_2.3) est nécessaire à pam_mount-0.5.9-1mdk
[root@DingDong root]#

Yann CANTIN m'avait envoyé un autre paquet que je n'ai pas testé.

J'ai préféré repartir des sources pour être en mesure de le refaire sur une autre distribution.
Cela m'a quand même après plusieurs erreurs obligé à installer d'autres paquets.

En voici le détail:

[root@DingDong root]# tar -xvzf pam-mount.tar.gz
...
[root@DingDong pam_mount-0.5.14]# urpmi gcc

Cela m'a aussi installé:

        binutils-2.12.90.0.15-1mdk.i586
        gcc-3.2-1mdk.i586
        glibc-devel-2.2.5-16mdk.i586
        kernel-headers-2.4.18-41mdk.i586
        libbinutils2-2.12.90.0.15-1mdk.i586

Il me manquait alors encore le fichier pam_modules.h
Une recherche m'a indiqué plusieurs paquetages proposant ce fichier.

[root@DingDong pam_mount-0.5.14]# urpmi pam-devel

Enfin, tout était en place:

[root@DingDong pam_mount-0.5.14]# ./configure
...
[root@DingDong pam_mount-0.5.14]# make
...
[root@DingDong pam_mount-0.5.14]# make install
...
[root@DingDong pam_mount-0.5.14]#

pam_mount est installé.
Il faut encore le configurer et configurer /etc/pam.d/system-auth pour en tenir compte.

J'ai donc modifié le /etc/pam.d/system-auth qui par défaut contient:

#%PAM-1.0

auth       required      /lib/security/pam_env.so
auth       sufficient    /lib/security/pam_winbind.so
auth       sufficient    /lib/security/pam_unix.so likeauth nullok use_first_pass
auth       required      /lib/security/pam_deny.so

account     sufficient   /lib/security/pam_winbind.so
account     required     /lib/security/pam_unix.so

password    required     /lib/security/pam_cracklib.so retry=3 minlen=2  dcredit=0 ucredit=0
password    sufficient   /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required     /lib/security/pam_deny.so

session     required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     required     /lib/security/pam_limits.so
session     required     /lib/security/pam_unix.so

Et je l'ai modifié pour obtenir:

#%PAM-1.0

auth       required      /lib/security/pam_env.so
auth       sufficient    /lib/security/pam_unix.so likeauth nullok    <Chgt ordre et options>
auth       requisite     /lib/security/pam_winbind.so use_first_pass  <Chgt ordre et options>
auth       sufficient    /lib/security/pam_mount.so use_first_pass    <Ajout>
auth       required      /lib/security/pam_deny.so

account     sufficient   /lib/security/pam_winbind.so
account     required     /lib/security/pam_unix.so

password    required     /lib/security/pam_cracklib.so retry=3 minlen=2  dcredit=0 ucredit=0
password    sufficient   /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required     /lib/security/pam_deny.so

session     required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     required     /lib/security/pam_limits.so
session     required     /lib/security/pam_unix.so
session     required     /lib/security/pam_mount.so                   <Ajout>

Remarques:

Outre l'ajout de ce qui concerne pam_mount, on a changé l'ordre des modules pour pam_unix et pam_winbind et donc adapté les options concernant l'utilisation/réutilisation du mot de passe pour l'authentification.
Est-ce bien utile?
Cela fonctionne aussi en intervertissant les lignes auth pam_winbind et auth pam_unix.
Cela joue-t-il sur le fait qu'un utilisateur local de même nom qu'un utilisateur du Domaine soit défini sur DingDong et qui se logue finalement?
Un test:

[root@DingDong root]# useradd toto -d /home/toto2
useradd: user toto exists

Et pourtant, il n'est pas dans /etc/passwd.
Le compte sur le domaine semble être pris en compte.
Le même test avec un utilisateur défini sur le domaine, mais avec lequel on ne s'est jamais encore logué le confirme.

Rectification:

C'est important d'avoir

auth sufficient /lib/security/pam_unix.so likeauth nullok

avant

auth requisite /lib/security/pam_winbind.so use_first_pass

Dans le cas contraire, l'utilisateur peut se trouver bloqué (interdit de login) en cas d'echec de pam_winbind ou pam_mount si pam_mount est avant pam_unix (?).
Toujours est-il que cela m'est arrivé et que fort heureusement dans une des consoles ouvertes j'étais logué en root, parce qu'un "su" ne passait pas non plus sur une autre des consoles où je m'étais logué avec un autre compte avant de commencer à briculer /etc/pam.d/system.auth pour pam_mount.
(/etc/pam.d/su fait référence à /etc/pam.d/system-auth d'où le blocage du "su").

J'ai ensuite recopié le fichier pam_mount.conf du sous-dossier conf de l'archive pam-mount.tar.gz vers /etc/security/:

[root@DingDong root]# cp ./pam_mount-0.5.14/config/pam_mount.conf /etc/security/

J'ai ensuite édité et modifié ce fichier.
J'ai commenté les lignes:

luserconf .pam_mount.conf
ncpmount /bin/mount -t ncpfs
lclmount /bin/mount -p0
mntcheck # For BSD's (don't have /etc/mtab)

Lorsque tout fonctionnera, vous pourrez aussi commenter la ligne:

debug 1

Yann CANTIN proposait dans le pam_mount.conf d'AbulEdu de placer

pmhelper /usr/sbin/pmhelper

Comme je n'avais pas ce programme, je n'ai pas mis cette ligne.

Et ne laisser en somme que:

#debug 1
mkmountpoint 1
lsof /usr/sbin/lsof

options_require    nosuid,nodev

smbmount /bin/mount -t smbfs
umount   /bin/umount

volume * smb DeepGlue & ~/Mes\ Documents uid=&,gid=&,fmask=0650,dmask=0750 - -

Seule la dernière ligne requiert vraiment des précisions.
La syntaxe est:

volume <user> [smb|ncp|nfs|local] <server> <volume> <mount point> <mount options> <fs key cipher> <fs key path>

Le & remplace le nom de l'utilisateur.

Nous avons donc sur cet exemple:
Une configuration qui concerne tous les utilisateurs: *
Dont le type est smb (montage de partages de type Window$);
Dont le serveur est DeepGlue;
Dont le nom de volume/partage est &, c'est-à-dire le nom de l'utilisateur (on va monter son home en somme);
Dont le point de montage est ~/Mes\ Documents (c'est à dire le sous-dossier "Mes Documents" du home local de l'utilisateur qui peut être situé ailleurs que sous /home/toto mais par exemple dans /home/eleves/toto ou /home/MaMaison/toto pour l'utilisateur toto, d'où l'avantage de la notation ~/ sur /home/) (avec le caractère d'échappement de l'espace dans "Mes Documents");
Dont les options de montage sont uid=& donc uid correspondant à l'utilisateur, gid=& donc gid correspondant à l'utilisateur (remarque: winbind ne permet pas à l'heure actuelle de récupérer les groupes d'appartenance de l'utilisateur, si j'ai bien saisi et c'est un des problèmes qui devraient être réglés avec Samba3),
fmask=0650 est le masque de création des fichiers
et dmask=0750 le masque de création des dossiers,
enfin, je n'ai pas saisi précisément les deux derniers paramètres laissés à "-" (il semble qu'il soit question de système de fichier crypté).

Un autre exemple de ligne de montage automatique d'un partage:

volume * smb DeepGlue public ~/public uid=&,gid=&,fmask=0650,dmask=0750 - -

Penser à créer le dossier /etc/skel/public pour que le point de montage existe dans le home de celui qui se connecte.
Tous les utilisateurs accèdent alors au partage [public] défini sur Samba/DeepGlue dans le sous-dossier public de leur home (soit ~/public).

Remarques:

(1) J'ai eu une bizarrerie avec l'utilisateur toto avec lequel j'avais joué avant la mise en place de pam_mount.
Il n'était pas propriétaire de son sous-dossier "Mes Documents".
J'ai tenté en tant que root un "chown toto /home/toto/Mes\ documents" qui s'est soldé par un échec ("operation not permitted", il me semble (peut-être est-ce en rapport avec le montage qui y a été fait/tenté?)).
Cependant après m'être délogué/relogué en tant que toto, toto était devenu propriétaire de son "Mes Documents".

(2) Deuxième bizarrerie:
J'ai créé sur DingDong un utilisateur local "tata" dont le home était "/home/tata" et le mot de passe "tata".
Apparemment l'uid qui lui a été attribué via "useradd tata" a été 10004.
J'ai créé sur le serveur DeepGlue un utilisateur linux et samba "tutu" avec le mot de passe "tutu" (c'est un moyen mnémotechnique en phase de test;o).
En me loguant en tant que tutu avec le mot de passe tutu sur DingDong, quelle ne fut pas ma surprise de découvrir l'invite suivante:

[tata@DingDong tutu]#

Et de fait les fichiers créés avec ce compte étaient perçus comme ayant pour propriétaire tata.
Il y a donc un problème par rapport aux correspondances uid/nom lorsque l'on a à la fois des utilisateurs locaux et des utilisateurs définis sur le domaine.
Ou alors il faut veiller à spécifier l'uid lors de la création d'un utilisateur local (en dehors de la plage 10000-20000 définie à ligne "winbind uid = 10000-20000" dans le /etc/samba/smb.conf du client DingDong).
La commande

[root@DingDong root]# useradd tata -u 510

m'aurait évité ce problème.

Je n'aboutis pas au même endroit en me loguant sur DingDong avec tata/tata.
Ce n'est bien qu'un problème de résolution des noms d'utilisateurs.

Quelques expérimentations supplémentaires:

Changement de mot de passe:

Depuis DingDong, il est possible de changer son mot de passe de connection au serveur Samba (comme avec Window$):

[titi@DingDong titi]$ smbpasswd -U titi -r DeepGlue
Old SMB password:
New SMB password:
Retype new SMB password:
Password changed for user titi
[titi@DingDong titi]$

Déboggage:

Si cela ne se passe pas comme prévu, depuis la console où vous êtes root (vous en avez bien une, n'est-ce pas?) lancez les commandes suivantes:

[root@DingDong root]# tail /var/log/auth.log

[root@DingDong root]# tail /var/log/syslog

Vous pourriez obtenir des informations sur la cause du problème.

Exemples:

Les fautes de frappe!
J'en ai fait plein (c'est très exagéré).
Et des erreur de syntaxe: pam-mount.so au lieu de pam_mount.so
Dans /var/log/auth.log:
```
May 29 18:07:11 DingDong login(pam_unix)[1741]: check pass; user unknown
May 29 18:07:11 DingDong login(pam_unix)[1741]: authentication failure; logname= uid=0 euid=0 tty=vc/5 ruser= rhost=
May 29 18:07:12 DingDong pam_winbind[1741]: user 'titi' granted acces
May 29 18:07:12 DingDong pam_winbind[1741]: user 'titi' granted acces
May 29 18:07:12 DingDong login(pam_unix)[1741]: session opened for user titi by (uid=0)
May 29 18:07:12 DingDong login[1741]: Module is unknown
```
pam_unix nous dit que l'utilisateur proposé n'est pas un utilisateur local.
pam_winbind nous informe de ce que titi est bien identifié sur le domaine et que le mot de passe convient.
Mais on finit par un "Module is unknown".
Et pour cause un "ls /lib/security/" ne faisait pas apparaitre pam_mount.so
J'avais tout bêtement oublié le "make install" après le "./configure" et le "make", tout occupé que j'étais à passer d'une machine à l'autre pour prendre des notes au fur et à mesure pour ce compte-rendu.
C'est ballot, n'est-ce pas?

Si vous n'avez pas intégré le domaine, vous aurez peut-être dans /var/log/auth.log:

May 29 15:10:52 DingDong login(pam_unix)[5368]: check pass; user unknown
May 29 15:10:52 DingDong login(pam_unix)[5368]: authentication failure; logname= uid=0 euid=0 tty=vc/1 ruser= rhost=
May 29 15:10:52 DingDong pam_winbind[5368]: request failed, PAM error was 4, NT error was NT_STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT
May 29 15:10:52 DingDong pam_winbind[5368]: internal module error (retval = 4, user = `toto'
May 29 15:10:55 DingDong login[5368]: FAILED LOGIN SESSION FROM (null) FOR toto, System error

Et dans /var/log/syslog, les symptomes sont les suivants:

May 29 15:10:52 DingDong winbindd[4939]: [2003/05/29 15:10:52, 0] libsmb/cli_netlogon.c:new_cli_nt_setup_creds(183)
May 29 15:10:52 DingDong winbindd[4939]:  new_cli_nt_setup_creds: request challenge failed
May 29 15:10:52 DingDong winbindd[4939]: [2003/05/29 15:10:52, 0] nsswitch/winbindd_cm.c:cm_get_netlogon_cli(797)
May 29 15:10:52 DingDong winbindd[4939]:   error connecting to domain password server: NT_STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT

Vous ne parvenez alors à vous loguer qu'avec un compte local.
A vérifier sur le serveur par la présence ou non du compte machine dingdong$ dans /etc/passwd, /etc/shadow et /etc/samba/smbpasswd.

Dans /var/log/auth.log:

May 29 18:38:47 DingDong login(pam_unix)[4296]: check pass; user unknown
May 29 18:38:47 DingDong login(pam_unix)[4296]: authentication failure; logname= uid=0 euid=0 tty=vc/2 ruser= rhost=
May 29 18:38:49 DingDong pam_winbind[4296]: request failed, PAM error was 4, NT error was NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND
May 29 18:38:49 DingDong pam_winbind[4296]: internal module error (retval = 4, user = `toto'
May 29 18:38:52 DingDong login[4296]: FAILED LOGIN SESSION FROM (null) FOR toto, System error

Et dans /var/log/syslog:

May 29 18:38:47 DingDong winbindd[3966]: [2003/05/29 18:38:47, 0] nsswitch/winbindd_cm.c:cm_get_netlogon_cli(797)
May 29 18:38:47 DingDong winbindd[3966]:   error connecting to domain password server: NT_STATUS_UNSUCCESSFUL

Cette fois, c'est le serveur Samba qui ne tourne pas sur DeepGlue.

Dans /var/log/auth.log:

May 29 18:41:27 DingDong login(pam_unix)[4302]: check pass; user unknown
May 29 18:41:27 DingDong login(pam_unix)[4302]: authentication failure; logname= uid=0 euid=0 tty=vc/2 ruser= rhost=
May 29 18:41:27 DingDong pam_winbind[4302]: write to socket failed!
May 29 18:41:27 DingDong pam_winbind[4302]: internal module error (retval = 3, user = `titi'
May 29 18:41:30 DingDong login[4302]: FAILED LOGIN SESSION FROM (null) FOR titi, Error in service module

Cette fois c'est le serveur winbind qui est arrêté sur DingDong

J'avais fait un essai avec:

#%PAM-1.0

auth       required      /lib/security/pam_env.so
auth       requisite     /lib/security/pam_winbind.so
auth       sufficient    /lib/security/pam_mount.so use_first_pass
auth       sufficient    /lib/security/pam_unix.so likeauth nullok use_first_pass
auth       required      /lib/security/pam_deny.so

account     sufficient   /lib/security/pam_winbind.so
account     required     /lib/security/pam_unix.so

password    required     /lib/security/pam_cracklib.so retry=3 minlen=2  dcredit=0 ucredit=0
password    sufficient   /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required     /lib/security/pam_deny.so

session     required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     required     /lib/security/pam_limits.so
session     required     /lib/security/pam_unix.so
session     required     /lib/security/pam_mount.so

Cela correspond au point (2).
J'avais oublié le "make install" si bien que /lib/security/pam_mount.so n'était pas à sa place et cela devait bloquer sur la ligne:

session required /lib/security/pam_mount.so

Les symptomes donnaient à penser que tout se passait bien et au moment d'obtenir le shell, j'étais éjecté.

Les erreurs liées à la casse sur le nom de domaine.
Les noms NETBIOS circulant sur le réseau sont en majuscule.
Dans le fichier /etc/samba/smb.conf du client DingDong, il sera donc raisonnable de préciser un nom de domaine en majuscules:

workgroup = MAMAISON

ou alors de modifier la ligne "template homedir = /home/%D/%U"
en "template homedir = /home/MaMaison/%U"
ou encore en "template homedir = /home/%U"

PS: Je n'ai pas fait toutes ces erreurs, mais une partie;o).
Et puis, j'ai quand même effectué trois installations en quelques jours pour tester différentes situations;o).

Mots de passe locaux ou sur le domaine...

Entre une installation avec des mots de passe locaux et des mots de passe sur un domaine window$, assez peu de choses diffèrent sur la Mdk9.0
Les voici:

Le programme login renvoie via pam_stack vers system_auth pour les services auth, account, password et session.

Contenu de /etc/pam.d/login

#%PAM-1.0

auth       required   /lib/security/pam_securetty.so
auth       required   /lib/security/pam_stack.so service=system-auth
auth       required   /lib/security/pam_nologin.so

account    required   /lib/security/pam_stack.so service=system-auth

password   required   /lib/security/pam_stack.so service=system-auth

session    required   /lib/security/pam_stack.so service=system-auth
session    optional   /lib/security/pam_console.so

Ce qui diffère se situe, pour PAM, uniquement au niveau de system-auth.
Avec des mots de passe locaux, le fichier /etc/pam.d/system-auth contient:

#%PAM-1.0

auth       required      /lib/security/pam_env.so
auth       sufficient    /lib/security/pam_unix.so likeauth nullok
auth       required      /lib/security/pam_deny.so

account     required     /lib/security/pam_unix.so

password    required     /lib/security/pam_cracklib.so retry=3 minlen=2  dcredit=0 ucredit=0
password    sufficient   /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required     /lib/security/pam_deny.so

session     required     /lib/security/pam_limits.so
session     required     /lib/security/pam_unix.so

Et une authentification sur un domaine Window$, le fichier /etc/pam.d/system-auth contient:

#%PAM-1.0

auth       required      /lib/security/pam_env.so
auth       sufficient    /lib/security/pam_winbind.so
auth       sufficient    /lib/security/pam_unix.so likeauth nullok use_first_pass
auth       required      /lib/security/pam_deny.so

account     sufficient   /lib/security/pam_winbind.so
account     required     /lib/security/pam_unix.so

password    required     /lib/security/pam_cracklib.so retry=3 minlen=2  dcredit=0 ucredit=0
password    sufficient   /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required     /lib/security/pam_deny.so

session     required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
session     required     /lib/security/pam_limits.so
session     required     /lib/security/pam_unix.so

Pour mettre en place, une authentification sur un domaine Window$ à partir d'une installation classique, il faut, dans un premier temps, installer samba-winbind et modifier /etc/pam.d/system-auth conformément à ce qui est indiqué ci-dessus.

Remarques:

Avec l'installation de Winbind, un sytem-auth-winbind est créé que l'on ait effectué une install avec des mots de passe locaux ou une install avec mdp sur un domaine Window$.
Le /etc/samba/smb.conf créé pour une installation avec mots de passe sur un Domaine Window$ et sans installation du serveur Samba contient:
```
[global]
    workgroup = MaMaison
    server string = Samba Server %v
    security = domain
    encrypt passwords = Yes
    password server = *
    log file = /var/log/samba/log.%m
    max log size = 50
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
    character set = ISO8859-15
    os level = 18
    local master = No
    dns proxy = No
    winbind uid = 10000-20000
    winbind gid = 10000-20000
    winbind separator = +
    template homedir = /home/%D/%U
    template shell = /bin/bash
    winbind use default domain = yes
```
La ligne "template homedir = /home/%D/%U" m'a posé un problème:
Le %D correspond au nom du domaine définit à la ligne "workgroup = MaMaison".
J'avais pris pour mes tests "MaMaison".
Et lors de la création d'un home via pam_mkhomedir pour accueillir localement les données de l'utilisateur du Domaine Window$, le sytème créait "/home/MAMAISON/toto" et samba/winbind recherchait un dossier "/home/MaMaison/toto".
Ce problème de casse, m'a amené à changer "template homedir = /home/%D/%U" en "template homedir = /home/%U".

Dans le cas d'une installation avec des mots de passe locaux, avec l'installation de Winbind, le fichier /etc/samba/smb-winbind.conf nécessite un peu plus d'élaguage si vous ne souhaitez pas mettre en place un serveur samba côté client DingDong.
C'est en effet une copie du fichier smb.conf par défaut avec décommentées les options correspondant au client de domaine.

Penser à redémarrer winbindd sur le client: /etc/init.d/winbindd (re)start

Remarques encore:

Lors de mes tests:
Je n'ai pas installé le serveur samba.
Seuls samba-client, samba-common et samba-winbind ont étét installés (version 2.2.6-1.0.pre2 (version par défaut de Mdk9.0)).
En principe, lors d'une installation avec mots de passe sur le domaine Window$, le mot de passe root/samba du serveur est demandé pour permettre à la machine (ici DingDong) de joindre le domaine (ici MaMaison).
Si on a effectué une installation avec mots de passe locaux, il faut donc effectuer ces actions "à la main" après coup.

Sur le serveur, veiller à disposer d'un administrateur samba:
```
[root@DeepGlue root]# smbpasswd -a root
New SMB password:
Retype new SMB password:
Password changed for user root.
[root@DeepGlue root]#
```
Veiller à ce que le groupe "machines" existe.
Au besoin, effectuer:

[root@DeepGlue root]# groupadd machines

Créer un compte pour la machine DingDong (nom tout en minuscules):
```
[root@DeepGlue root]# useradd -g machines -c "Compte Machine" -d /dev/null -s /bin/false dingdong$
[root@DeepGlue root]# smbpasswd -a -m dingdong
Added user dingdong$.
[root@DeepGlue root]#
```
Depuis le client DingDong, intégrer le domaine (est-ce utile? ou cela n'a-t-il d'effet que conjointement à un "add user script = /usr/sbin/useradd -d /dev/null -g machines -c 'Machine Account' -s /bin/false -M %u" ou "add user script = /usr/sbin/useradd -d /dev/null -g machines -c 'Machine Account' -s /bin/false -M %m$" dans le /etc/samba/smb.conf du serveur DeepGlue?):
```
[root@DingDong root]# smbpasswd -j MaMaison -r DeepGlue -U root
Password:
Joined Domain MAMAISON.
[root@DingDong root]#
```
Test effectué:

Avec "add user script = /usr/sbin/useradd -d /dev/null -g machines -c 'Machine Account' -s /bin/false -M %m$" dans le /etc/samba/smb.conf du serveur DeepGlue, j'ai pu joindre le domaine depuis DingDong via "smbpasswd -j MaMaison -r DeepGlue -U root", alors que sans cela ne donnait rien.

Sur DingDong:
```
[root@DingDong root]# smbpasswd -j MaMaison -r DeepGlue -U root
Password:
Joined Domain MAMAISON.
[root@DingDong root]#
```
Vérification sur le serveur:
```
[root@DeepGlue steph]# cat /etc/passwd | grep dingdong
dingdong$:x:505:421:Machine Account:/dev/null:/bin/false
[root@DeepGlue steph]#
```
```
[root@DeepGlue steph]# cat /etc/samba/smbpasswd | grep ding
dingdong$:505:FF985A4C229CDFC20C6996F40740D1FE:2EDB324B680D781E4FB77C47DD342466:[W         ]:LCT-3ED5D73B:
[root@DeepGlue steph]#
```
Et ceci sans effectuer les manips "useradd -g machines -c "Compte Machine" -d /dev/null -s /bin/false dingdong$"
ni "smbpasswd -a -m dingdong" côté serveur.

Remarque:

Le /etc/samba/smb.conf du serveur DeepGlue ne nécessite pas d'ajustement particulier.
Pour ma part, j'avais:

#======================= Global Settings =====================================
[global]
   workgroup = MaMaison
   netbios name = LeJoliServeur
   server string = Samba Server %v

   printcap name = cups
   load printers = yes
   printing = cups
   printer admin = @adm

   log file = /var/log/samba/log.%m
   max log size = 50
   log level = 3

   hosts allow = 192.168.52. 192.168.12. 10.127. 127.

   guest account = nobody
   map to guest = bad user

   security = user

   encrypt passwords = yes
   smb passwd file = /etc/samba/smbpasswd

   socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

   local master = yes
   os level = 255
   domain master = yes
   preferred master = yes
   domain logons = yes
   logon script = script%U.bat

; add user script = /usr/sbin/useradd -d /dev/null -g machines -c 'Machine Account' -s /bin/false -M %u

   dns proxy = no
   client code page = 850
   character set = ISO8859-1

#============================ Share Definitions ==============================
[homes]
   comment = Home Directories
   browseable = no
   writable = yes

 [netlogon]
   comment = Network Logon Service
   path = /home/samba/netlogon
   guest ok = yes
   writable = yes

[printers]
   comment = All Printers
   path = /var/spool/samba
   browseable = no
# to allow user 'guest account' to print.
   guest ok = yes
   writable = no
   printable = yes
   create mode = 0700
   print command = lpr-cups -P %p -o raw %s -r   #using client side printer drivers.

[print$]
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   write list = @adm root
   guest ok = yes

[pdf-generator]
   path = /var/tmp
   guest ok = No
   printable = Yes
   comment = PDF Generator (only valid users)
   #print command = /usr/share/samba/scripts/print-pdf file path win_path recipient IP doc_name &
   print command = /usr/share/samba/scripts/print-pdf %s ~%u //%L/%u %m %I "%J" &

[public]
   comment = Public Stuff
   path = /home/samba/public
   public = yes
   writable = yes

Liens:

Samba:
La doc officielle au formats:
HTML: http://us2.samba.org/samba/devel/docs/html/Samba-HOWTO-Collection.html
et PDF: http://mirrors.sunsite.dk/samba/docs/Samba-HOWTO-Collection.pdf

Voir aussi les pages réalisées à propos de samba sur ce site: Samba en environnement w$9x/w$me et Samba en environnement w$nt/w$2k/w$xp

Pam_mount: Le site du projet http://freshmeat.net/projects/pam-mount/

A propos de PAM (en français) sur le site de Philippe Chadefaux: http://www.ac-creteil.fr/reseaux/systemes/linux/outils-tcp-ip/Linux-pam.html

Pour les courageux, explorez la doc installée sur votre distribution (le numéro de version peut changer): file:/usr/share/doc/pam-doc-0.75/html/pam.html (la lecture en est très utile)
Ou http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html