Un minimum de pré-requis sont nécessaires à la bonne compréhension de ce cours :

1.1.1 Théorique

Les connaissances nécessaires sont :

• Connaissances de base en réseau (TCP/IP)

• Connaissances de base en Linux et Windows

1.1.2 Pratique

Les pré-requis fonctionnels sont :

• au moins deux ordinateurs reliés en réseau,

• une distribution GNU/Linux opérationnelle,

• les packages Samba, installés ou non.

Samba a été créé par Andrew Tridgell (actuellement chef de file de l'équipe de développement du projet Samba) en 1991. Il travaillait sur le développement d'un programme de gestion de fichiers basé sur le protocole propriétaire SMB (Server Message Block) implémenté par Microsoft et IBM. Le nom de Samba à été trouvé grâce à la commande UNIX suivante:

grep -i s.*m.*b /usr/dict/words 
résultat: salmonberry samba sawtimber scramble

En d'autre termes SAMBA est l'implémentation libre (sous liscence GNU General Public License) du protocole de communication SMB

Concrètement, Samba vous permet de :

• partager des systèmes de fichiers,

• partager une imprimante sur un serveur Unix avec des clients Windows/Unix,

• jouer le rôle de contrôleur de domaine Windows 2000/NT,

• fournir un serveur WINS (Windows Internet Name Service).

Le protocol SMB étant propriétaire, tout le travail a été fait en faisant du reverse engineering, c'est à dire en observant le fonctionnement du protocole SMB entre des clients et serveur Windows, et en analysant les binaires Windows.

Samba est composé de deux daemons fournissant des services :

• smbd est un daemon qui prend en charge le partage de fichiers, d'imprimante, et l'authentification des clients SMB,

• nmbd est un daemon qui supporte les services NetBios et WINS.

1.3.1 Le protocole NetBios

La communication réseau via le protocole SMB et assez différente d'une communication classique TCP/IP utilisée par des protocoles comme FTP ou Telnet. Nous allons commencer par voir les concepts de base du protocole SMB puis nous verrons quelques implémentations que Microsoft en a fait, enfin nous exposerons les situations qui sont ou non propices à l'utilisation du serveur Samba.

1.3.1.1 Comprendre NetBIOS

En 1984, IBM créa une simple API (Application Programming Interface) pour mettre en réseau ses ordinateurs : Network Basic Input/Output System (NetBIOS). L'API NetBIOS permet aux applications de se connecter et de partager des données entre elles de manière rudimentaire.

Considérez l'API NetBIOS comme une extension de l'API BIOS qui contient du code de bas niveau permettant d'effectuer les opérations sur le système de fichier local. Au début NetBIOS à été mis en oeuvre sur les réseaux de type TokenRing, puis sur des réseaux IPX de Novell.

Le protocole TCP utilise des nombres pour représenter les adresses des machines (192.168.0.2) tandis que NetBIOS nutilise que des noms. Certains problèmes ce sont posés lorsque l'on essaya de faire cohabiter les deux protocoles, c'est à cet effet que les RFC 1001 et 1002 (documents de standardisation) furent publiés et décrivent comment NetBIOS doit fonctionner sur un réseau de type TCP/UDP. Ce protocole est communément appelé NBT (NB over TCP/IP).

Ces documents continuent aujourd'hui à régir toutes les implémentations y compris celles de Microsoft ou même Samba.

1.3.1.2 Récupérer un nom NetBIOS

Dans le monde de NetBIOS, lorsqu'un ordinateur se connecte, il effectue une requête d'enregistrement de son nom NetBIOS. Cependant il est impossible que deux ordinateurs du même groupe de travail aient le même nom. Deux approches permettent de s'assurer que ce cas ne se produise jamais :

• Utiliser un NBNS (NetBIOS Name Server) pour garder une trace de toutes les machines qui ont enregistré un nom NetBIOS sur le réseau.

• Autoriser chaque ordinateur du réseau à défendre son enregistrement dans le cas ou un autre ordinateur essaye denregistrer le même.

Voici l'illustration de l'echec dune requête d'enregistrement avec ou sans NBNS :

Comme nous l'avons vu avant, il doit y avoir un moyen de résoudre un nom NetBIOS à partir d'une adresse IP. Les deux différentes approches possibles sont :

• Chaque ordinateur renvoie son, IP lorsqu'il entend une requête de type broadcast de son nom NetBIOS.

• Utiliser un NBNS pour résoudre les noms NetBIOS vers des adresses IP.

Il semble logique d'affirmer que la mise en place dun NBNS permet de grandement accroître les performances du réseau en évitant un déluge de broadcast (communication en Point to Point) inutile pour le simple enregistrement de nom. Pour savoir comment une machine windows va réagir pour l'enregistrement et la résolution de nom on pourra tapper ipconfig /all dans un terminal MS-DOS et rechercher la ligne contenant Node-Type.

Voici les valeurs que vous pourrez trouver :

1.3.1.3 Type et nom des ressources

Le protocole NetBIOS permet non seulement à une machine de s'identifier au sein d'un réseau par son nom mais aussi d'expliciter le type de service qu'elle peut éventuellement fournir.

Par exemple la station mixtec peut indiquer quelle n'est pas juste une station de travail mais est aussi un serveur de fichiers et peut recevoir des message de Windows Messenger.

Ces informations peuvent être fournies en ajoutant un 16ème byte à la fin du nom de machine (qui ne peut contenir que 15 caractères).

Pour connaître toutes les informations disponible sur un ordinateur utilisant le protocole NetBIOS sur le réseau on pourra saisir :

C:\>nbtstat -a toltec

NetBIOS Remote Machine Name Table
Name               Type         Status
---------------------------------------------
TOLTEC          <00>  UNIQUE      Registered
TOLTEC          <03>  UNIQUE      Registered
TOLTEC          <20>  UNIQUE      Registered
... 

Voici la signification de la plupart des codes ressources :

1.3.2 Le protocole SMB

Nous allons dans cette section décrire plus en détail le protocole SMB lui-même.

D'un point de vue haut niveau le protocole SMB est relativement simple. Il inclus un jeu de commandes nécessaire aux diverses opération relatives aux fichiers et aux imprimantes partagées. Par exemple on pourra :

• Ouvrir et fermer des fichiers

• Créer et supprimer des fichiers et des répertoires

• Lire et écrire des fichiers

• Chercher des fichiers

• Gérer les files dimpression

Chaque opération peut être encodée en un message SMB et transmis depuis et vers un serveur. Ces commandes sont au format Server Message Blocks.

1.3.2.1 Le format SMB

Le protocole SMB est dans 99% du temps un protocole de requête/réponse. En effet, dans la majeure partie du temps, un client envoie une requête SMB au serveur et celui-ci renvoi une réponse SMB au client.

Un message SMB nest pas si complexe. Regardons sa structure interne d'un peu plus près. On peut la séparer en deux grandes partie : une entête de taille fixe et une chaîne de commande fixe de longueur très variable en fonction du message.

Voici les différents champs d'une entête de message :

Le champ COM identifie la commande à exécuter. Toutes les commandes ne doivent ne remplissent pas tous les champs à chaque requête. Prenons par exemple la première demande de connexion d'un client vers un serveur, le client ne pourra fournir un identificateur darborescence (TID), la valeur de ce champ sera alors NULL. D'autres champs peuvent être égal à 0 lorsqu'ils ne sont pas utilisés.

Juste après l'entête se trouve un nombre variable de bytes qui constitue une commande ou une réponse SMB. Chaque commande comme Open File (COM=SMBopen) ou Get Print (COM=SMBsplretq) possède son propre jeu de paramètres et de données. Comme pour l'entête tous les champs nont pas forcément à être remplis.

De part son évolution le jeu de commandes SMB se trouve de plus en plus enrichi. Cependant il garde une compatibilité ascendante, ainsi des entités utilisant différentes versions du protocole pourrons communiquer entre elles. Voici à titre indicatif l'ensemble des dialectes du protocole SMB :

1.3.2.2 Une connection SMB simple

Le client et le serveur doivent accomplir trois étapes afin d'établir une connexion à une ressource.

• Etablir une session NetBIOS

• Déterminer le dialecte du protocole à employer

• Définir les paramètres de session et établir la connexion à la ressource.

Chaque étape peut être observée grâce au programme d'écoute réseau tcpdump légèrement modifié et disponible sur le site de Samba dans le répertoire samba/ftp/tcpdump-smb.

Le programme s'utilise comme d'habitude, pensez juste à ajouter l'option -s 1500 pour vous assurez de récupérer l'intégralité du paquet et non pas quelques bytes inutilisables.

Voici plus en détail chaque étape scrutée avec notre tcpdump :

1.3.2.2.1 Etablissement de la session NetBIOS

Lorsqu'un utilisateur fait une requête d'accès à un disque réseau ou envoie une impression dans la file d'attente d'une imprimante partagée, NetBIOS se charge de la connectivité au niveau de la couche session du modèle OSI. Le résultat est un canal bidirectionnel entre le client et le serveur. Deux messages suffisent à l'établissement d'une connexion entre les deux entités.

• Le client envoie une requête d'ouverture de session, voici le rapport de tcpdump :

  >>> NBT Packet
  NBT Session Request
  Flags=0x81000044
  Destination=TOLTEC      NameType=0x20 (Server)
  Source=MAYA             NameType=0x00 (Workstation)

• Le serveur répond en accordant une session au client :

  >>> NBT Packet
  NBT Session Granted
  Flags=0x82000000

A partir de là un canal de communication est ouvert entre le client et le serveur.

1.3.2.2.2 Détermination du dialecte à employer et établissement de la connexion

Le client envoie maintenant un message au serveur afin de négocier le dialecte du protocole SMB à employer. La commande encapsulée dans le message est SMBnegprot, le client envoie au serveur la liste des dialectes qu'il comprend et vice versa :

1.3.2.2.2.1 Envoi de la requête client

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=154

SMB PACKET: SMBnegprot (REQUEST)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5315
UID           =  0
MID           =  257
Word Count    =  0
Dialect=PC NETWORK PROGRAM 1.0
Dialect=MICROSOFT NETWORKS 3.0
Dialect=DOS LM1.2X002
Dialect=DOS LANMAN2.1
Dialect=Windows for Workgroups 3.1a
Dialect=NT LM 0.12

1.3.2.2.2.2 Réponse du serveur

Le serveur répond en fournissant l'index de la valeur supportée (0xFF si aucun protocole n'est valide).

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=84

SMB PACKET: SMBnegprot (REPLY)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  0
Proc ID       =  5315
UID           =  0
MID           =  257
Word Count    =  17
NT1 Protocol
DialectIndex=5
[...]

Dans cet exemple le serveur choisi donc le dialect NT LM 0.12 qui d'après notre tableau précedent correspond au standard Windows NT 4.0.

1.3.2.2.2.3 Définition des paramètres de session et établissement de la connexion à la ressource

Enfin pendant la dernière étape, les paramètres de session et de connexion sont échangés grâce à la commande SMBSesssetupX.

Parmis les paramètres on trouve :

• Le nom du compte et le mot de passe (quand il y en à un)

• Le nom du groupe de travail (workgroup)

• La taille maximum des données qui peuvent être transférées

• Le nombre de requêtes en attente dans la file

Le résultat de tcpdump est le suivant :

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=150

SMB PACKET: SMBsesssetupX (REQUEST)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x10
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5315
UID           =  1
MID           =  257
Word Count    =  13
Com2=0x75
Res1=0x0
Off2=120
MaxBuffer=2920
MaxMpx=50
VcNumber=0
SessionKey=0x1380
CaseInsensitivePasswordLength=24
CaseSensitivePasswordLength=0
Res=0x0
Capabilities=0x1
Pass1&Pass2&Account&Domain&OS&LanMan=  
JAY METRAN Windows 4.0 Windows 4.0

SMB PACKET: SMBtconX (REQUEST) (CHAINED)
smbvwv[]=
Com2=0xFF
Off2=0
Flags=0x2
PassLen=1
Passwd&Path&Device=
smb_bcc=23
smb_buf[]=\\TOLTEC\SPIRIT

Il n'est pas nécessaire de comprendre l'intégralité du résultat, on remarquera juste que l'hexadécimal contenu dans le champs Com2 de la commande SMBsesssetupX représente le code de la commande SMBTconX, qui elle-même recherche le nom de la ressource dans la variable smb_buf.

Dans cet exemple cette variable contient la chaîne \\TOLTEC\SPIRIT qui est le chemin absolu dun partage situé sur toltec.

Le TID (Tree ID ou identifiant d'arborescence) est toujours égal à 0 à ce moment de la transaction.

Enfin le serveur envoie un TID au client lui indiquant que l'utilisateur à bien été autorisé à accéder à la ressource désirée, et qu'il peut l'utiliser

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=85

SMB PACKET: SMBsesssetupX (REPLY)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  1
Proc ID       =  5315
UID           =  100
MID           =  257
Word Count    =  3
Com2=0x75
Off2=68
Action=0x1
[000] Unix Samba 2.2.6
[010] METRAN

SMB PACKET: SMBtconX (REPLY) (CHAINED)
smbvwv[]=
Com2=0xFF
Off2=0
smbbuf[]=
ServiceType=A:

Le champs ServiceType contient le champ A ce qui indique qu'il sagit d'un partage de fichier.

Les champs possibles sont :

• A : fichier ou disque

• LPT1 : sortie en file (impression)

• COMM : modem ou imprimante directement connecté

• IPC : tube nommé

Maintenant qu'un TID à été assigné, le client peut utiliser la ressource comme il l'aurait fait localement.

1.4.1 Nouveautés depuis Samba 2.2

1.4.1.1 PDC pour clients de type Windows 2000/XP

Jusque là Samba pouvais servir de PDC (Primary Domain Controler) à un ensemble de machines Windows 95/98/Me et NT, à partie de la 2.2, le serveur Samba peut également agir comme PDC au sein dun réseau Windows 2000/XP.

1.4.1.2 Support du Microsoft Dfs

Microsoft Dfs permet de regrouper aux yeux des utilisateurs un ensemble de ressources situées sur des serveurs différents dans un même répertoire sur un serveur. Ceci simplifie beaucoup la vie des utilisateurs. Ce protocole est supporté à partie de Samba 2.2 .

1.4.1.3 Support d'impression Windows NT/2000

Support du protocole d'impression RFC.

1.4.1.4 ACLs

Samba peut comprendre et donc traduire en conséquence les ACL UNIX et Windows Nt/2000/XP.

1.4.1.5 Intégration de Winbind

Winbind permet aux utilisateurs dont les login sont stockés sur un serveur Windows de s'authentifier sur un système Unix. Ceci permet une uniformisation de l'environnement de logon qui est bien plus facilement administrable que deux systèmes que l'on doit régulièrement synchroniser.

1.4.1.6 Extensions CIFS Unix

Les extensions CIFS d'UNIX permettent à samba de supporter le système d'attributs de fichiers Unix et ainsi de servir de remplacement à un serveur NFS. L'avantage étant que l'authentification se fait par utilisateur et non pas par Ip, ce qui garanti une meilleure sécurité.

1.4.2 Nouveautés depuis Samba 3

1.4.2.1 Authentification Kerberos 5 et LDAP

Ceci permet une intégration dans un réseau Active Directory.

1.4.2.2 Support de l'Unicode

Permet de simplifier l'internationalisation des langues.

L'installation est tout ce qu'il y a de plus classique :

2.1.1 Depuis les sources

2.1.2 Sur une Debian

# apt-get install samba

2.1.3 Sur une Gentoo

Pour savoir si Samba est installé :

# emerge -s samba

Si le champs Latest Version contiens not installed alors Samba n'est pas installé. Dans ce cas :

# emerge samba

Pour démarrer Samba, il suffit de lancer smbd et nmbd

2.2.1 En utilisant init

Il suffit de créer un script de démarrage des deux daemons, et de l'appeler au démarrage dans les scripts d'init.

2.2.2 En utilisant inetd

Commencer par verifier que /etc/services contiens bien :

netbios-ns      137/tcp    #NETBIOS Name Service
netbios-ns      137/udp    #NETBIOS Name Service
netbios-dgm     138/tcp    #NETBIOS Datagram Service
netbios-dgm     138/udp    #NETBIOS Datagram Service
netbios-ssn     139/tcp    #NETBIOS Session Service
netbios-ssn     139/udp    #NETBIOS Session Service
	

Verifier ensuite que /etc/inetd.conf contiens bien les lignes suivantes et éventuellement les décommenter :

netbios-ssn    stream  tcp     nowait  root    /usr/sbin/smbd  smbd
netbios-ns     dgram   udp     wait    root    /usr/sbin/nmbd  nmbd

Il ne reste plus qu'a redémarrer inetd grâce à la commande :

# killall -HUP inetd

Désormais Samba sera démarré par inetd uniquement lorsqu'un client tentera de se connecter au serveur.

2.2.3 xinetd

xinetd est le successeur de inetd. Il a le même rôle mais dispose de fonctionalités bien plus puissantes.
Pour le configurer il faut créer deux fichier netbios-ssn et netbios-ns dans /etc/xinetd.d/.

netbios-ssn :

service netbios-ssn
{
  socket_type = stream
  protocol = tcp
  wait = no
  user = root
  server = /usr/sbin/smbd
  disable = no
}

netbios-ns :

service netbios-ns
{
  socket_type = dgram
  protocol = udp
  wait = no
  user = root
  server = /usr/sbin/nmbd
  disable = no
}

Puis relancer xinetd grâce à :

# killall -HUP xinetd

3. Configuration

3.1 smb.conf

# killall -HUP smbd nmbd

[nom_de_section]
parametre = valeur
parametre2 = valeur2

[global]
netbios name = kiwi
workgroup = LABO-UNIX
server string = jewom-samba-server
log file = /var/log/samba/%m.log
lock directory = /var/lock/samba

[homes]
	    comment = Home Directories
	    browseable = no
	    writable = yes

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

[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
guest ok = no
writable = no
printable = yes

3.2 Gestion des utilisateurs

# smbpasswd -a toto
New SMB password:
Retype new SMB password:
Added user toto.

3.3 SWAT

swat            901/tcp                 # samba web configuration tool

# killall -HUP inetd

3.4 Utilisation de Samba en Controlleur de domaine

[global]

;Le nom du serveur
netbios name = toltec
;Le nom du groupe de travail
workgroup = METRAN
encrypt passwords = yes


domain master = yes
local master = yes
preferred master = yes
os level = 65

security = user
domain logons = yes

;Dit à Samba où il doit placer les profiles itinérants de                 
;Windows NT/2000/XP
logon path = \\%L\profiles\%u\%m
logon script = logon.bat

logon drive = H:

; Permet de spécifier la location des profiles itinérants de
; Windows 95/98/Me 
logon home = \\%L\%u\.win_profile\%m

time server = yes

; instead of jay, use the names of all users in the Windows NT/2000/XP
; Administrators group who log on to the domain
domain admin group = root jay

; Ce script fonctionne sour RedHat mais peut mal tourner sous 
;dautres OS.
add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u

[netlogon]
path = /usr/local/samba/lib/netlogon
writable = no
browsable = no

[profiles] 
; you might wish to use a different directory for your
; Windows NT/2000/XP roaming profiles
path = /home/samba-ntprof
browsable = no
writable = yes
create mask = 0600
directory mask = 0700

[homes]
read only = no
browsable = no
guest ok = no
map archive = yes

# mkdir /usr/local/samba/lib/netlogon
# chmod 775 /usr/local/samba/lib/netlogon
# mkdir /home/samba-ntprof
# chmod 777 /home/samba-ntprof

# killall -HUP smbd nmbd

4. Jeu de commandes

4.1 winbindd

4.2 findsmb

4.3 net

4.4 nmblookup

4.5 pdbedit

4.6 smbcacls

4.7 smbclient

4.8 smbgroupedit

4.9 smbmount/smbumount

4.10 smbpasswd

4.11 smbsh

4.12 smbspool

4.13 testparm

testparm /etc/samba/smb.conf

testparm /etc/samba/smb.conf machine

4.14 wbinfo