wiki:InsiaAdminSysSamba

Sommaire

Administration système - Samba

1. Présentation

Samba est une suite logicielle qui implémente un support client et surtout serveur pour les protocoles d'échanges de fichier SMB et CIFS développées principalement par Microsoft.

La première version de Samba, bien qu'intimiste, fut écrite en 1992. Samba a connu un vif succès depuis au moins sa version 2.0 (1998) où son serveur fut mesuré comme plus performant par rapport à Windows NT4 à matériel égal et sous forte charge. La version stable actuelle (2006/2007) est la 3.0, et la version 4.0 - une ré-écriture complète architecturée autour de CIFS - est prévue courant de l'année 2007.

Serveur

Un composant serveur de type SMB/CIFS peut proposer plusieurs services:

Service Ports Démon
Partage de fichiers 139/TCP, 445/TCP smbd
Centralisation des autorisations idem smbd
Maintenance de liste de services sur un réseau (fichiers, imprimantes) idem smbd
Résolution de noms en adreses réseau (WINS) - winbind

Il y a donc au plus trois démons qui assurent l'ensemble des services. On peut en voir tourner un nombre variable, le modèle de concurrence étant semblable au "prefork" de Apache, où on utilise plusieurs processus et un seul thread par processus pour répondre aux clients.

Client

Il existe trois clients classiques livrés avec Samba:

  • smbclient: imite le client FTP standard, mais permet de se connecter à un service SMB *
  • smbtree: affiche la liste de ressources du réseau
  • nmblookup: effectue une résolution de nom via WINS

Et surtout il existe un système de fichier (smbfs), donc une implémentation côté noyau - principalement maintenue pour Linux. Ceci permet donc de monter dans le VFS Unix toute ressource SMB.

2. Protocoles

SMB et CIFS

Le protocole s'appelait initialement SMB pour Server Message Block et s'implémentait au-dessus de sa propre couche de transport (NetBIOS). Il s'agissait d'un mécanisme simple et léger pour fonctionner sous DOS et partager des ressources sur un réseau local en "redirigeant" simplement les accès disques vers des accès réseau équivalent.

Ce protocole a évolué de manière plus ou moins rocambolesque pour adopter les nouvelles technologies, notamment en supportant les transport NetBEUI puis TCP/IP.

CIFS a été conçu comme la généralisation et la mise au propre de SMB. Ce protocole n'est pas compatible bien qu'il a été développé comme son successeur. Samba 3 supporte partiellement CIFS, et Samba 4 est architecturé autour de CIFS, considérant SMB comme un élément historique (mais toujours aussi bien supporté).

Il reste encore des notions originelles (NetBIOS) dans les nouveaux protocoles, notamment concernant le nommage et l'adressage des noeuds du réseau, bien que l'évolution de CIFS tendent vers des standards (remplacement de WINS par un DNS dynamique par exemple).

NMB

Il s'agit du système de nommage décentralisé associé à SMB.

Chaque noeud dans le réseau possède un nom, idéalement unique, qui est une chaîne de 16 caractères max appelé son "nom NetBIOS". Chaque client soumet au réseau entier, à intervalle régulier, un message contenant son nom ainsi que son adresse (IP dans notre cas); en termes techniques, il s'agit d'un broadcast et limite donc automatiquement l'effet au réseau local.

Chaque client peut alors enregistrer cette information et maintenir une liste de ses voisins disponibles, contenant leur nom ainsi que l'adresse pour les joindre. En pratique, un des noeuds du réseau est choisi automatiquement ("élu" pour être plus précis) pour être l'autorité sur la liste des noeuds et des ressources qu'ils proposent, afin de favoriser une vue cohérente de la liste globale des ressources vues par chaque client au même instant.

Ces mécanismes dynamiques, en offrant une architecture décentralisée et donc potentiellement opérationnelle "sans configuration" posent plusieurs problèmes:

  • les temps de rafraîchissement des informations (temps cumulés des broadcasts de chaque client, temps d'élection des mainteneur de liste, etc) font que la vue du réseau semble peu réactive
  • il n'existe pas par défaut de mécanisme permettant au serveur de décider du nom du client
  • la résolution des conflits (qui arrivent souvent) est quasi inexistante

Kerberos

Microsoft utilise une version légèrement adaptée, et donc non standard, de la fameuse suite de protocoles de sécurité et d'authentification Kerberos. Ce protocole est largement implémenté et utilisé, et fourni une solution de cryptage et d'authentification forte, distribuée pour un ensemble d'utilisateurs sur un réseau complexe. Le cryptage utilise des protocoles classiques et publics (DES, IDEA, etc).

Les mécanismes de sécurité et de cryptage sont utilisés par défaut depuis Windows 2000 côté Microsoft.

3. Architecture

Ressources

Un noeud implémentant un serveur SMB peut partager des ressources de plusieur type:

  • Disque: un partage de fichier au sens classique
  • Impression: il s'agit d'un canal permettant de contrôler la file d'impression et l'abonnement aux imprimantes auxquelles à accès le noeud
  • IPC: un partage créant un cannal de communication pour transporter des commandes (DCOM)

Certaines ressources sont dites cachées ou administratives: dans ce cas leur nom finit par le caractère $, et elles ne sont pas listées via les outils et commandes classiques de Windows (explorateur, net /view, etc). La plupart existent par défaut sur une machine "fraîchement installée", avec un niveau de sécurité requis équivalent à l'administrateur local. Exemples:

Ressource Description
IPC$ Canal pour l'échange de commandes et informations de sécurité (DCOM, Kerberos)
ADMIN$ Partage du "System Folder" (aka. "C:\Windows")
PRINT$ Partage du spooler d'impression
FAX$ Partage du spooler de fax
C$ Partage du premier disque

Domaine

Afin de pouvoir faire co-exister plusieurs réseaux dinstincts d'un point de vue logique, mais physiquement reliés au même sous-réseau, SMB introduit le concept de domaine. Ainsi toute machine possède en plus de son nom un domaine, qui est également un identifiant alphanumérique.

Sauf requête explicite, une machine communiquera par défaut avec celles de son domaine. Le domaine par défaut est en général appelé WORKGROUP.

Un domaine peut servir également à fédérer des machines au-delà d'un seul sous-réseau, et servir à centraliser l'authentification et les autorisations via un noeud spécial appelé contrôleur de domaine.

Modèle de sécurité

Il existe plusieurs modèles pour décider des règles d'accès au ressources:

  • Share: l'autorisation requise dépend seulement d'un mot de passe (optionnel) associé à la ressource donnée
  • User: l'autorisation dépend de la fourniture d'un identifiant et d'un mot de passe
  • Domain: du point de vue du client fonctionne comme user, mais le serveur ira vérifier l'information auprès d'un serveur de confiance (appelé le PDC ou BDC)
  • ADS: du point de vue du client fonctionne comme user, mais le serveur ira vérifier l'information auprès de son référent Active Directory Service en utilisant les protoles LDAP et Kerberos

Le premier modèle (share) n'est quasiment plus utilisée, et est même devenu indisponible depuis Windows XP.

Le second modèle est le plus traditionnel et le plus simple. Dans ce cas le serveur Samba maintient lui-même la liste des identifiants et des mots de passe.

Les derniers modèles utilisent une authentification distribuée. Ceci implique en particulier que le serveur qui partage la ressource doit lui-même être enregistré auprès de son autorité pour pouvoir déléguer le travail d'authentification et d'autorisation.

Interopérabilité

Les sémantiques des sytèmes de fichiers Unix et Windows sont assez différentes. Il n'y a pas toujours de relation triviale entre les deux. L'élément le plus décisif et l'utilisation d'un hash (cryptage assymétrique) de mot de passe non compatible avec le modèle Unix: pour cette seule raison, il faut maintenir deux versions cryptées d'un mot de utilisateur (un pour Unix, un pour SMB). De manière générale, il faut souvent maintenir des informations spécifiques au modèle SMB pour chaque utilisateur.

Samba doit doit donc maintenir une base de donnée utilisateur redondante, et si possible la synchroniser avec la base de donnée Unix (par ex: /etc/passwd, LDAP, etc). Samba peut lui-même maintenir sa base d'utilisateurs SMB via plusieurs backends (fichiers, tables de hachage, LDAP, MySQL, etc).

L'idée est de reproduire au plus près les mécanismes de sécurité possibles (utilisateur, groupe, attributs simples) à l'aide des mécanismes natifs d'Unix afin qu'ils soient naturellement gérés et sécurisés par le système d'exploitation du serveur. Les fonctionnalités qui ne peuvent être gérées par le système de fichier Unix (ACLs, etc) doivent - et son dans une certaine mesure - gérés par Samba.

4. Configuration

Samba se configure quasiment exclusivement à l'aide d'un seul fichier de configuration smb.conf. Il est largement documenté via sa page de manuel associée. Il utilise la syntaxe du type "Windows INI", où les expressions "clé = valeur" sont rangées dans des "[sections]".

Globales

La première section est la section globale: elle permet de configurer des propriétés uniques du serveur ainsi que des valeurs par défaut pour les sections suivantes.

[global]
workgroup      = SRT3
netbios name   = LE_PROF
server string  = Ceci est une ressources Samba
security       = share
passdb backend = tdbsam, guest
os level       = 64
invalid users  = root
name resolve order = lmhosts bcast hosts
log file       = /var/log/samba/%m.log
max log size   = 1000

Ressources

Toutes les autres sections désignent des ressources, dont certaines sont spéciales (voir plus loin). Par exemple pour créer un partage public en lecture seul visible en tant que Public depuis le postes clients:

[Public]
path = /home/pub
read only = yes
guest ok = yes
comment = Espace public de telechargement

Et pour créer un espace disponible en écriture mais requiérant une authentification:

[Privatif]
path = /home/private
read only = no
guest ok = no
comment = Espace de travail reserve

Ressource personnelle

Il est possible de créer une ressource particulière qui prend automatiquement le nom de l'utilisateur qui s'authentifie, ceci permettant ainsi de créer un "home" - cad. une ressource spécifique à l'utilisateur et automatiquement disponible lorsqu'il s'identifie. Il suffit que cette ressource s'appelle homes:

[homes]
path = /home/%u
read only = no
guest ok = no
comment = Bienvenue a la maison

Gestion des comptes

Pour ajouter un utilisateur à la base locale (ici au format tdbsam), le plus simple est d'être en root sur le serveur où tourne Samba (ceci peut aussi être fait à distance dans certaines conditions):

# smbpasswd -a utilisateur
(saisie du mot de passe)

Si vous devez effectuer des correspondances entres noms Unix et Windows (typiquement root et Administrateur):

# /etc/samba/smbusers: le format est Unix_ID = Windows_ID
root = Administrateur

Et n'oubliez pas de déclarer ce fichier dans smb.conf ainsi:

user name map = /etc/samba/smbusers

Test client

Pour lister les ressources d'une machine particulière:

$ smbclient -L //machine

Et bien sûr vous pouvez utiliser smbtree pour tenter de listes toutes les ressources d'un sous-réseau. Enfin pour accéder à une ressource particulière, avec authentification facultative:

$ smbclient -U login //machine/ressource

Pour vérifier qu'une machine est présente et répond à un nom particulier (nom NetBIOS et non DNS):

$ nmblookup machine

Informations serveur

Il est possible d'avoir une vue d'ensemble des ressources en cours d'utilisation et de la charge de Samba à l'aide de la commande smbstatus.

Note: redémarrer Samba a un effet très peu transparent sur les clients en général, sauf pour smbfs qui le gère très bien.

Last modified 13 years ago Last modified on Mar 19, 2007, 12:30:06 AM