2.4.2 Le même serveur simple en mode share, mais avec des utilisateurs définis sous Linux/Samba

Nous allons définir des utilisateurs et ajouter un partage correspondant au dossier $HOME des utilisateurs.

Création de deux groupes (professeurs et eleves):

[root@DeepGlue steph]# groupadd professeurs [root@DeepGlue steph]# groupadd eleves

Création de deux utilisateurs linux&samba, l'un, martin, dans le groupe professeurs et l'autre, toto, dans le groupe eleves.

[root@DeepGlue steph]# useradd martin -g professeurs [root@DeepGlue steph]# passwd martin Changing password for user martin. New UNIX password: BAD PASSWORD: it is based on a dictionary word Retype new UNIX password: passwd: all authentication tokens updated successfully. [root@DeepGlue steph]# smbpasswd -a martin New SMB password: Retype new SMB password: Password changed for user martin. [root@DeepGlue steph]#

[root@DeepGlue steph]# useradd toto -g eleves [root@DeepGlue steph]# passwd toto Changing password for user toto. New UNIX password: BAD PASSWORD: it is too short Retype new UNIX password: passwd: all authentication tokens updated successfully. [root@DeepGlue steph]# smbpasswd -a toto New SMB password: Retype new SMB password: Added user toto.

Remarques:

1. On aurait pu effectuer des useradd toto,... sans paramètres, mais dans ce cas, le groupe principal de l'utilisateur toto serait un groupe toto créé par la même commande.
   Outre que cela n'a pas d'intérêt, si on créé 400 utilisateurs, avoir 400 groupes n'aura vraiment pas de sens.
   Nous verrons plus loin que ces groupes principaux permettent d'autres traitements intéressants (pour les droits sur les fichiers et dossiers,... jusqu'à la configuration de samba elle-même).
   Le groupe principal d'un utilisateur sera groupe propriétaire par défaut des fichiers/dossiers créés par l'utilisateur.
    

2. Malgré les avertissements comme quoi mes mots de passe sont mal choisis, l'utilisateur root peut imposer un mot de passe en outrepassant ces avertissements (alors qu'un utilisateur cherchant à changer son mot de passe via "passwd" se verrait refuser un mot de passe bidon).
    

3. La commande smbpasswd peut prendre différents paramètres.
   En voici queqlues uns (pour les autres, voir man smbpasswd):
   

   -a ajouter un utilisateur;
   -d désactiver un utilisateur;
   -e activer un utilisateur (précédemment désactivé);
   -x supprimer un utilisateur.

Modification du smb.conf: on ajoute un partage!

#======== Global Settings ========= [global]    workgroup = MaMaison    netbios name = LeJoliServeur    hosts allow = 192.168.52. 127.    security = share #======= Share Definitions ======== [public]    comment = Dossier public    path = /home/samba/public    browseable = yes    public = yes    writable = yes [homes]    comment = Home Directories    browseable = no    writable = yes

Le partage [homes] correspond à un mot réservé.
C'est un partage particulier qui pointe vers le dossier personnel créé lors de l'ajout de l'utilisateur linux.
Le dossier personnel n'est jamais le même d'un utilisateur à l'autre si bien que cette section ne contient pas de path.
(il est même possible de spécifier des chemins spéciaux pour les dossiers personnels des utilisateurs qui sinon sont créés comme sous-dossiers directs de /home).
Ce partage n'est pas listable (sans intérêt, mais si vous souhaitez voir ici l'aspect des partages...), par contre l'utilisateur martin verra le partage [martin] (son $HOME).

Utiliser la commande testparm qui lit le fichier smb.conf et permet de vérifier qu'il n'y a pas d'erreur de syntaxe.

Puis on redémarre le serveur (pour lui faire relire son fichier de configuration, à savoir /etc/samba/smb.conf):

Pour pouvoir voir ce partage [homes], il faut effectuer une configuration du client: Propriétés du Voisinage réseau

On modifie le mode d'ouverture de session pour pouvoir saisir un nom d'utilisateur et un mot de passe lors du démarrage (ou de la re-connexion). Onglet Configuration/Ouverture de session principale: Client pour les réseaux Micro$oft <(lors du stage, veiller à ce qu'auparavant, ils soient en Ouverture de session Window$ (et ou faire l'expérience en Ouverture de session window$: on ne voit pas de partage [homes] (remarque: il suffit de cliquer sur Déconnecter pour se voir proposer de changer d'identité))).>

Lors de la connexion du client, il faut saisir le nom de l'utilisateur et le mot de passe. On note qu'il n'y a pas moyen d'éviter de ressaisir le mot de passe lors de la première connexion (mise en antémémoire du mot de passe). (voir plus bas).

Dans l'Explorateur Window$, le partage [martin] apparait. Il s'agit du dossier $HOME de l'utilisateur martin (stocké dans /home/martin).

Mais si on clique sur le partage [martin], un mot de passe nous est à nouveau demandé (alors qu'on l'a déjà fourni lors du login). De plus, par défaut, Enregistrer votre mot de passe dans votre liste de mots de passe est coché (il s'agit de la mise en antémémoire des mots de passe). C'est une facilité, mais une énorme faille de sécurité, car cela créée un fichier .PWL dans C:\windows\ Des logiciels de crackage de mots de passe auront tôt fait de dévoiler des couples utilisateur/mot_de_passe car ces .PWL sont épouvantablement mal protégés. Il sera utile de passer une clé de registre pour régler le problème: supprimer_mise_en_antememoire_des_mots_de_passe.reg

Autre remarque: Le dossier [martin] n'est pas vide (afficher les fichiers cachés). Il s'agit de fichiers utiles lors de la connexion "physique" sur le serveur en tant qu'utilisateur de linux. Pour éviter cela, il est possible de passer des paramètres à useradd: Cela permet même de créer des dossiers types pour les différents utilisateurs. Créer un dossier /etc/skelprof et un dossier /etc/skeleleve, Y placer des fichiers dossiers différents (nous verrons plus loin ce qu'il peut être intéressant de placer dans ces dossiers types). Créez ensuite vos utilisateurs avec les paramètres suivants: useradd titi -g eleves -m -k /etc/skeleleve ... useradd tartempion -g professeurs -m -k /etc/skelprof ... Vous pourrez constater que leur dossier personnel contient une copie du contenu du dossier /etc/skeleve ou /etc/skelprof selon le cas.

Ces utilisateurs sont toutefois des utilisateurs linux standards, donc autorisés à se connecter sur le serveur "physiquement" ou via telnet/ssh.
Ils pourraient y faire des âneries (limitées par leurs droits toutefois).

Il est possible de s'en prémunir:
Il suffit pour cela de leur fournir comme shell, un shell particulier.
useradd titi -g eleves -m -k /etc/skeleleve -s /bin/false
...
useradd tartempion -g professeurs -m -k /etc/skelprof -s /bin/false
...

Faites l'expérience (créez l'utilisateur et définissez lui un mot de passe) et tentez de vous connecter en tant que ce nouvel utilisateur dans une console (CTRL+ALT+F1 ou CTRL+ALT+F2,...).
Le login devrait se solder par un échec.
Un test équivalent:

[steph@DeepGlue steph]$ su toto Password: [steph@DeepGlue steph]$

En saisissant le mot de passe de toto, je retombe sous mon compte.

Remarque sur le partage [public]: Problèmes de droits:
En mode security=share, tous les fichiers et dossiers créés dans le dossier [public](que ce soit par un utilisateur déclaré dans smbpasswd ou non) ont pour propriétaire nobody et pour groupe propriétaire nogroup.
Dans ces conditions, chaque utilisateur peut supprimer les fichiers et dossiers créés par son voisin.

Ressources:
Le fichier smb.conf (avec les fins de lignes UNIX): smb.conf.version2 (qu'il faudra renommer en smb.conf)