Installer Samba

Présentation de Samba

Pour autant que notre cas d’école est considéré, Samba est une suite logicielle qui permet de simuler la présence d’un serveur Windows dans votre réseau. Il implémente ainsi le protocole SMB/CIFS, qui est utilisé par les ordinateurs « clients » fonctionnant sous Windows. Vous pouvez donc :

  • partager des fichiers et répertoires
  • donner des droits d’accès assez fins (d’autant plus si vous décidez d’utiliser les ACL – voir plus bas) en lecture et/ou écriture
  • gérer au choix un groupe de travail ou un domaine (au sens Windows du terme : vous avez certainement déjà utilisé une station Windows qui vous demande une ouverture de session au démarrage)
  • partager des imprimantes
  • certainement beaucoup d’autres choses…

Important!

Ma compréhension des choses en une phrase est que Samba vous permet d’atteindre ou de partager vous même des ressources (fichiers, imprimantes) comme si un Windows Server était présent.

Normalement un serveur Windows vous permet de gérer les politiques de sécurité de tous les ordinateurs qui se connectent au domaine. Ainsi, lors de l’ouverture de session, l’administrateur peut empêcher certaines actions sur votre propre station de travail, ou obliger à utiliser telle ou telle configuration (notamment : interdiction d’installer des logiciels, pas d’accès au panneau de configuration, etc…). Je n’ai pas encore creusé l’application avec Samba et il semblerait qu’il faille attendre Samba v4 pour pouvoir gérer un domaine avec Active Directory (qui est le standard actuel chez Microsoft).

En tout état de cause, j’ai choisi une configuration :

  • qui permet la création d’un domaine, avec contrôleur de domaine Samba
  • qui demande que chaque utilisateur soit identifié (avec nom + mot de passe) avant accès
  • qui n’autorise que les connexions à partir du réseau local (192.168….)
  • qui ne stocke pas les roaming profiles : les utilisateurs adorent l’idée de se connecter depuis n’importe quelle station de travail et d’y retrouver leur fond d’écran et la disposition de leurs icônes, mais c’est très consommateur de bande passante à la connexion/déconnexion, d’autant plus si les répertoires ‘Mes Documents’ sont surchargés [expérience inside]
  • qui demande à la station cliente de synchroniser son horloge avec le serveur, et de monter automatiquement quelques répertoires partagés
  • qui partage un répertoire « Racines », accessible à tout utilisateur authentifié. L’accès à chaque sous-répertoire, en lecture ou en lecture/écriture, sera géré par les ACLs
  • qui donne accès à chaque utilisateur authentifié à un répertoire « Personnel », auquel personne d’autre n’a accès

Je n’ai pas testé le partage d’imprimantes par contre.

Le fichier de configuration smb.conf

Voici en lien le fichier smb.conf que j’utilise (c’est un fichier texte, donc sans risque à télécharger a priori).

Note sur les ACL

Les ACLs (Access Control List) pour un système de fichiers définissent les droits d’accès, en lecture et en écriture.

Aucun droit d’accès que vous donneriez dans votre fichier smb.conf ne peut outrepasser les droits donnés par le système de fichiers hôte. Ainsi, si vous déclarez dans smb.conf que tel répertoire est en accès total, alors qu’il est seulement en lecture dans le système de fichiers, vos utilisateurs se verront refuser toute modification.

Linux (qui constitue ici le système hôte) utilise traditionnellement une manière limitée pour définir les droits. Vous ressentirez très vite le besoin d’utiliser les ACLs pour gérer finement vos accès.

Ainsi, j’ai défini une structure de répertoires comme suit :

  • Un répertoire pour les scripts de connection Windows -> /home/partages/z_netlogon | root:smb_admin | 2555
  • Un répertoire général dans /home, pour tous les partages Samba -> /home/partages | root:smb_admin | 2775 // Ce répertoire est en fait une partition séparée, montée avec les ACLs (mount -o acl)
    • Un répertoire pour les Homes de Samba (<> Homes Linux de chaque utilisateur) -> /home/partages/homes | root:smb_admin | 2775
      • Un répertoire Homes Samba pour chaque utilisateur -> /home/partages/homes/utilisateur | utilisateur:smb_admin | 2770 (on met utilisateur comme propriétaire pour permettre la synchro via Unison/ssh)
    • Un répertoire chapeau pour tous partages -> /home/partages/racines | root:smb_admin | 2775

Dans le répertoire Racines sont créés des répertoires, qui ont chacun leurs ACLs en fonction des accès que l’on souhaite donner. Ainsi un répertoire Restricted pourrait avoir ces ACLs :

# file: Restricted/
# owner: root
# group: smb_admins
# flags: -s-
group:smb_g_rw_restricted:rwx
default:group:smb_g_rw_restricted:rwx

Seuls les utilisateurs du groupe smb_g_rw_restricted pourraient accéder.

Un répertoire Datasheets, accessible en lecture seule à la plupart des utilisateurs pourrait avoir ces ACLs :

# file: Datasheets/
# owner: root
# group: smb_admins
# flags: -s-
group:smb_g_ro_datasheets:r-x
group:smb_g_rw_datasheets:rwx
default:group:smb_g_ro_datasheets:r-x
default:group:smb_g_rw_datasheets:rwx

Seuls les membres du groupe smb_g_ro_datasheets pourraient accéder, et encore seulement en lecture. Pour les mises à jour du contenu, il faudrait se connecter avec un membre du groupe smb_g_rw_datasheets.

Important!

En théorie, ces accès peuvent être définis à partir de l’explorateur Windows classique, pour peu que vous soyez connectés avec un compte administrateur du répertoire sur le Domaine.

Warning!

Le répertoire Racines est considéré (à juste titre) comme un seul et unique système de fichiers. Les ACLs par défaut sont attribuées à chaque nouveau fichier dans le répertoire (elles sont héritées). Un problème se pose quand on déplace un fichier (par exemple, de Restricted à un répertoire plus ouvert) : la commande mv (move) emporte les ACLs. Dans notre exemple, le fichier ne resterait accessible qu’aux membres du groupe smb_g_rw_restricted, bien qu’il soit dans un répertoire accessible à tous. Parmi les solutions envisageables : un script qui tourne régulièrement et qui redéfinit les ACLs de tous les fichiers en fonction du répertoire auxquels ils appartiennent (bof), l’utilisation des Virtual Files Systems de Samba (solution non testée, à confirmer), l’utilisation d’OpenLDAP pour gérer une base de données des autorisations (non testée également, mais utile sûrement à plus d’un titre).

Je vous recommande chaudement la lecture de cet article, long mais vraiment très utile.

Conclusions

Utiliser Samba pour partager des ressources permet à divers systèmes d’exploitation de se connecter. Des ordinateurs sous Windows bien sûr, mais également des stations Linux, puisque la plupart des distributions savent se présenter à un partage SMB/CIFS.

Mon choix d’une configuration à base de domaine, plutôt qu’un simple groupe de travail n’est pas forcément le meilleur, surtout si on ne cherche pas à gérer finement les politiques de sécurité du domaine. Le fait est que je n’ai pas suffisamment le loisir de me pencher sur ce point.

Plus sérieusement, le Domaine permet une gestion centralisée de tous les comptes (authentification et autorisation), dans un contexte de Single Sign On (SSO). Mais je n’ai pas encore trouvé un utilitaire lié à Samba pour faciliter cette gestion : l’outil PdbEdit en ligne de commandes est particulièrement indigeste. Là encore, lier Samba à OpenLDAP peut être une bonne piste.

Un invité de passage dans mon entreprise imaginaire ne pourra pas se connecter au domaine, sauf à reconfigurer son ordinateur. Mais ce serait le cas avec un Groupe de travail aussi bien qu’avec un Domaine. Pour partager des fichiers avec lui, un espace FTP publique peut peut-être s’avérer utile (à moins que n’ayez une autre suggestion ?).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *