Chapitre 1 : Interopérabilité

1.1 Introduction.
L'interopérabilité est la capacité à faire fonctionner ensemble des machines (des applications…)
hétérogènes, c'est à dire présentant des caractéristiques différentes sur un ou plusieurs aspects.
En premier lieu, cela peut être des machines fonctionnant sous des systèmes d'exploitation
différents : UNIX et Windows par exemple. Mais cela peut aussi se limiter à faire fonctionner
ensemble des applications différentes (client HTTP avec un serveur FTP...), ou de constructeurs
différents (bases de données Oracle avec MySQL...).
Dans le cadre de ce chapitre, c'est plutôt l'interopérabilité entre les systèmes d'exploitation client et
serveur qui va nous intéresser et principalement l'interaction Windows et UNIX.
Les différences peuvent se situer à plusieurs niveaux :
- En terme de communication
Protocoles réseaux différents (NetBIOS/SMB versus RPC/NFS...)
Systèmes d'adressage et mécanismes de résolution d’adresses différents
- En terme de ressources
Organisation des systèmes de fichiers : autorisations sur les fichiers, gestion des partages...
- En terme de représentation des informations
Codage des informations (CR ou CR+LF pour la séparation des lignes) ; big ou little endian sur des
machines ayant des processeurs différents.

1.2 Principes et types d'interopérabilité.

L'interopérabilité peut se situer à plusieurs niveaux, elle peut concerner un simple accès réciproque
à des données avec nécessité de prise en charge des différences de format jusqu'à une intégration
plus poussée avec des accès transparents entre systèmes, elle peut aussi se limiter à des outils de
conversion permettant de récupérer des informations d'un système pour les intégrer dans un autre.
Actuellement, le support d'échange privilégié entre différents systèmes est le réseau, c'est donc à ce
niveau que les problèmes d'interopérabilité devront être traités, même si les échanges de type média
amovibles pourraient être aussi concernés, en général ceux-ci sont correctement traités depuis assez
longtemps et ne seront pas détaillés dans ce cours.

Comme nous l'avons vu précédemment, une interopérabilité réussie nécessite de résoudre plusieurs
problèmes : protocoles réseaux, format des ressources à partager, authentification et droits basés sur
des données utilisateurs différentes.

Un premier niveau consiste à relier les différents systèmes via des applications normalisées basées
sur des couches réseaux compatibles (actuellement la couche transport TCP/UDP constitue le socle
commun de tous les systèmes de communication réseaux basés sur des ordinateurs conventionnels).

1
Les exemples les plus courants de ce type d'interopérabilité sont l'usage des applications Telnet (ou
leur équivalent sécurisé) ainsi que de FTP. L'usage de telles applications permet de résoudre les
problèmes liés aux échanges de données sur n'importe quel type de systèmes mais ne prennent pas
en compte la conversion des différents formats des ressources et nécessite en général une double
authentification (à la connexion initiale sur le système hôte et au lancement de l'application
Telnet/FTP sur le système cible). De plus l'usage des ressources du serveur nécessite une copie
locale sur le client : ce qui est inconcevable dans le cas d'une véritable utilisation partagée des
ressources.
C'est pourquoi, des outils poussant l'intégration plus avant ont été développés, ils ne peuvent être
que spécifiques à des catégories de machines et de systèmes d'exploitation bien définies. En général
soit l'adaptation est faite au niveau du client soit au niveau du serveur, l'autre machine fonctionnant
sans aucune modification ou ajout.

Cette adaptation se fait en plusieurs étapes, au niveau des protocoles d'échanges couches hautes qui
vont permettre une exploitation intégrée des ressources ainsi qu'au niveau de l'exportation des
ressources initialement reliée à un type d'échange vers un autre type d'échange.

En pratique, il est nécessaire tout d'abord que la machine basée sur un système d'exploitation A
puisse proposer des ressources sous un format compatible avec le système d'exploitation B et
qu'elle puisse aussi les formater suivant un protocole d'échange compatible avec le système
d'exploitation B.

Lorsque l'adaptation est faite au niveau du client, elle doit être présente sur tous les clients ce qui
nécessite plus de modification au niveau du parc de machines. Quoiqu'il en soit la modification du
client est assez souvent plus simple car les fonctionnalités peuvent être réduites et ne viennent pas
interférer avec le fonctionnement global du serveur. C'était en général la solution retenue il y a
quelques années (client NFS pour PC : PCNFS).

2
 Machine A Machine B
(Syst. Exploitation A) (Syst. Exploitation B)
Application Application
Cliente Serveur

Adaptation
S.E. A - S.E. B
Lien logique
Couches Couches
hautes S.E. B hautes
Pile Pile
TCP TCP
/IP /IP

Lien physique

Si l'adaptation est faite au niveau du serveur, elle ne doit être faite qu'une fois, mais avec beaucoup
plus d'attention car le bon fonctionnement du serveur conditionne le fonctionnement de
l'infrastructure complète.

Machine A Machine B
(Syst. Exploitation A) (Syst. Exploitation B)
Application Application
Cliente Serveur

Adaptation
Lien logique S.E. A - S.E. B
Couches Couches
hautes hautes S.E. A
Pile Pile
TCP TCP
/IP /IP

Lien physique

Actuellement, la gestion du parc de machines clientes étant de plus en plus normalisée c'est cette
solution qui est retenue car elle conduit à une gestion plus centralisée. On retrouve dans ce cadre
des solutions comme Samba (Serveur UNIX, Client Windows).

3
En fait, une machine cliente ou serveur possédant, pour un constructeur donné, des systèmes
d'exploitation assez semblables, les 2 solutions peuvent être mises en place avec les mêmes
technologies, c'est le cas par exemple de Windows Server for UNIX pour Microsoft.

1.3 Samba

1.3.1 Objectif et rôle de Samba.

L'objectif principal de Samba et de mettre à disposition des ressources d'un système sous Linux
pour des clients fonctionnant sous Windows 95, NT, XP, W7...
Samba peut avoir pour rôle de partager uniquement un système de fichiers pour des machines
clientes Windows, ou encore une imprimante. Mais il peut aussi remplacer en grande partie un
contrôleur de domaine Windows Serveur afin de gérer une infrastructure complète de machines
clientes Windows.
Toutefois, il est basé sur une approche DOS de la gestion des machines Windows en particulier
relativement aux droits sur les ressources. Dans les versions récentes, un module supplémentaire
permet d'étendre cette gestion des droits de manière plus fine que celle habituellement utilisée sous
UNIX en ajoutant une gestion des ACL Windows.
D'un autre point de vue, Samba peut-être utilisé pour permettre à une machine Linux de se
connecter en tant que client sur une machine Windows fournissant une ressource.

1.3.2 Constitution de Samba

L'implémentation actuelle est basée sur 2 démons : smbd (Server Message Block Daemon) et
nmbd (NetBIOS Name Server Daemon !).

Le démon nmbd gère l'aspect réseau couche haute, c'est à dire les protocoles NetBIOS over TCP/IP,
concernant la déclaration des machines et la résolution des noms.

Le démon smbd gère l'ensemble de la conversion des ressources du format UNIX vers un format
compatible avec des partages Windows, ainsi que l'authentification et les autorisations. Il intègre
aussi une gestion minimum de domaines Windows

1.3.3 Configuration de Samba

Le fonctionnement de Samba est principalement défini par un fichier de configuration nommé

smb.conf.

Ce fichier comporte plusieurs sections dont une principale : [global], et des sections permettant de
définir des ressources exportées [homes], [printers]...

[global] : permet de définir le fonctionnement général du serveur Samba, définition du nom de

domaine, du mode de fonctionnement du serveur, des ordinateurs (@IP) accrédités pour accéder au
système, ...

4
[homes] : permet de spécifier des répertoires personnels pour chaque utilisateur d'une connexion via
le serveur Samba
[printers] : configuration du partage d'imprimante

Les autres sections, créées par l'utilisateur, permettent de définir les propriétés des partages
supplémentaires.

Au sein des sections, chaque ligne définit un attribut et sa valeur, séparée par le signe « = ».
attribut = valeur

Une ligne commençant par un # est un commentaire. Généralement, les lignes modifiées ne sont
pas supprimées mais mises en commentaire, ce qui permet de revenir à la configuration initiale en
cas de problème. Un fichier de configuration par défaut est fourni à l’installation de Samba, il
possède de nombreux commentaires et peut être difficilement lisible. Habituellement en production,
on crée un fichier synthétique (avec peu de commentaires) en gardant l’initial pour conserver la
syntaxe des commandes (l’aide en ligne man smb.conf permet d’avoir la signification de chaque
option).
Un utilitaire « testparm » permet de vérifier globalement la syntaxe du fichier, car plusieurs
directives ont de nombreuses variantes d’écriture. Il doit être utilisé à chaque modification de
configuration.

a) Partie globale du fichier de configuration :

Cette partie contient le nom du serveur (netbiosname), de son domaine ou groupe de travail
(workgroup), et les rôles qu'il assure (local master, domain master...).

Un exemple est donné ci-dessous :

[global]
workgroup = ISTASE
server string = istapc83
password server = 192.168.1.83
local master = No
domain master = No
encrypt passwords = true
netbios name = ISTAPC83
name resolve order = host bcast
wins server = 192.168.1.45
NIS homedir = No

b) Partie liée à un partage

Cette partie permet de définir la ressource partagée (système de fichiers UNIX, imprimante) via la
directive "path", le type d'accès à la ressource (writable, readable...), le nom du partage vu en
exportation...
Un exemple est donné ci-dessous :

[appli_partage]
path = /home/export/appli

5
 comment = applications partagées
writeable= no

c) Gestion des utilisateurs sous Samba

Afin de contrôler l'accès aux ressources UNIX, il est nécessaire de définir des utilisateurs qui
puissent être associés d'un côté aux machines Windows, de l'autre aux ressources UNIX. Ceci est
fait en deux étapes :
- création d'utilisateurs locaux sur la machine UNIX (adduser, useradd...) ce qui va permettre de
définir des droits relativement aux ressources locales.
- création d'une base de données utilisateurs Windows sur la machine UNIX. Cette base ne devra
contenir que des utilisateurs déjà définis sous UNIX pour pouvoir y associer des droits locaux.

La création de la 2ème catégories d'utilisateurs ne peut se faire qu'avec une commande spécifique :
smbpasswd qui va créer et peupler un fichier smbpasswd (choix discutable !) ou une base de
données plus évoluée suivant la configuration du serveur.
Suivant par qui est utilisé cette commande, elle n'a pas le même mode de fonctionnement. Si elle
est lancé par un utilisateur standard, elle lui sert seulement à modifier son mot de passe. Si le super-
utilisateur lance cette commande, il va pouvoir ajouter ou supprimer des utilisateurs directement
dans le fichier smbpasswd. L'utilisateur doit déjà exister dans le fichier /etc/passwd pour pouvoir
être ajouté dans smbpasswd, ceci pour les raisons exposées préalablement.

d) Droits sur les ressources.

Un des points qui illustre parfaitement les difficultés de mise en oeuvre d'une interopérabilité en
multi-environnement est la différence de gestion des droits sous Windows et sous UNIX.
En effet, les droits de base sous UNIX sont liée à 3 critères (lecture, écriture, exécution) et ceci
pour 3 entités (propriétaire, groupe, les autres) alors que sous Windows les droits sont de 2
catégories, les droits simples (issus du DOS) : lecture seule, archive, fichier caché et les droits liés
aux ACL (access list) qui sont très détaillés.

e) Serveur Samba en contrôleur principal de domaine

Pour vraiment émuler un serveur Windows, Samba doit pouvoir prendre le rôle de contrôleur
principal de domaine (contrôle de l'authentification lors de la connexion sur une machine cliente).
Ce rôle est associé à de nombreuses autres fonctionnalités sous Windows (scripts de connexion,
initialisation de la base de registres...) dont certaines seront supportées par Samba.

1.3.4 Mise en oeuvre pratique de Samba

a) démarrage
Suivant la version de Linux, le démarrage manuel de samba peut s'effectuer par les commandes
systemctl :
systemctl restart smbd
systemctl restart nmbd

6
Le lancement peut aussi se faire directement par un script sous /etc/init.d (ancienne méthode) :
/etc/init.d/samba

Remarque : sur un serveur de production, généralement on lance samba au démarrage du système

Linux, par exemple en mettant un lien commençant par la lettre S dans un répertoire /etc/rcxxx.d
vers le script /etc/init.d/samba (où xxx représente le niveau de démarrage en général rc2.d)

Le fichier de configuration est relu automatiquement à une périodicité donnée. Pour éviter les
problèmes lors d'un changement dans un fichier de configuration, on travaille sur un fichier
temporaire dont on peut tester la syntaxe par la commande :
testparm smbtmp.conf [hostname/hostip]
(le paramètre facultatif hostname, hostip demande à testparm de vérifier si la machine spécifiée
peut accéder correctement aux services indiqués).

La commande smbstatus permet de suivre les connections actives sur le serveur et donc de vérifier
le bon fonctionnement du serveur.

b) Fichier de configuration minimum (partage simple d’un répertoire)

La section [global] doit au moins contenir les informations permettant d’identifier le poste dans le
système NetBios et donner les droits d’accès aux ressources.

[global]

workgroup = WORKGROUP

# This will prevent nmbd to search for NetBIOS names through DNS.
dns proxy = no

#### Debugging/Accounting ####

# Use a separate log file for each machine that connects
log file = /var/log/samba/log.%m
# Cap the size of the individual log files (in KiB).
max log size = 1000

# We want Samba to log a minimum amount of information to syslog.

Everything
# should go to /var/log/samba/log.{smbd,nmbd} instead.
syslog = 0
log level = 2
# Do something sensible when Samba crashes: mail the admin a backtrace
panic action = /usr/share/samba/panic-action %d

####### Authentication #######

server role = standalone server

# This option controls how unsuccessful authentication attempts are
mapped
# to anonymous connections
security = user
guest account = nobody
map to guest = bad user

7
Il faut bien entendu adapter le nom du groupe de travail en fonction des besoins. La gestion des
logs est celle recommandée par défaut : on utilise donc des fichiers séparés situés dans le
répertoire /var/log/samba. Les trois dernières directives vont permettre d’autoriser la connexion par
des utilisateurs n’ayant pas de compte sur le serveur (lors de l’accès au partage une tentative de
connexion est déclenchée, si celle-ci ne se passe pas correctement -couple login/password correct-
on bascule sur le compte nobody qui doit avoir normalement des droits réduits).

Un partage de répertoire simple se fait de la manière suivante :

[partage_libre]
path = /home/partage
comment = test
guest only = yes
guest ok = yes

On retrouve le nom NetBios du partage entre crochets, le répertoire UNIX via la directive « path ».
L’accès est autorisé pour le compte invité nobody et seulement pour lui.

c) Fichier de configuration avec un partage contrôlé par des droits d’accès pour certains
utilisateurs et actions à réaliser.

La section {global] doit être complétée par les directives d’authentification (elles sont présentes par
défaut.

# For encrypted passwords, Samba will need to know what

# password database type you are using.
passdb backend = tdbsam
obey pam restrictions = yes

# Sync the Unix password with the SMB password when the encrypted SMB
# password in the passdb is changed.
unix password sync = yes

# For Unix password sync to work on a Debian GNU/Linux system,

# the following parameters must be set
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\
spassword:* %n\n *password\supdated\ssuccessfully* .

# This boolean controls whether PAM will be used for password changes
# when requested by an SMB client instead of the program listed in
# 'passwd program'. The default is 'no'.
pam password change = yes

Une fois modifié le fichier de configuration, il faut créer les utilisateurs, ceci se fait en 2 étapes :
- création des utilisateurs UNIX (commande habituelle useradd)
- création des utilisateurs correspondant pour Samba (via la commande smbpasswd -a)

Attention, samba doit être actif lors de la création des utilisateurs car smbpasswd utilise l’interface
serveur nmbd pour modifier les mots de passe.

8
Enfin, il faut définir le partage sécurisé dans une nouvelle section :

[partage_secure]
path = /home/partage2
comment = secure share
valid users = tptest

On n’autorise ici l’accès qu’à un seul utilisateur tptest. Si la liste était vide, tous les utilisateurs
valides auraient pu se connecter.

d) Fichiers de configuration pour élever le serveur au rang de contrôleur de domaine et

actions à réaliser

Il faut ajouter des directives dans la section [global].

[global]
domain logons = Yes
# ce serveur est le controleur du domaine
domain master = True
# explorateur maitre de domaine
local master =yes
server role = classic primary domain controller

Attention la directive « server role » doit être modifiée et non pas rajoutée car la présence de deux
directives contradictoires conduit à des problèmes potentiels. De ce fait, il faut toujours vérifier par
testparm que les modifications ont bien été prises en compte.

La connexion a un serveur NetBios nécessitant l’utilisation d’un partage générique nommé

« netlogon », il faut le créer dans une nouvelle section de partage avec les droits nécessaires.

[netlogon]
comment = Network Logon Service
path = /home/samba/netlogon
guest ok = yes
read only = yes
browseable = no

Ce partage doit être accessible même en nobody car au moment de la connexion l’utilisateur n’est
pas forcément reconnu. Ce répertoire contenant principalement des scripts de démarrage, il doit être
en lecture seule sinon c’est un trou de sécurité important. Une sécurité supplémentaire (mais peu
efficace) empêche le listage de ce répertoire pour rendre plus difficile la lecture des scripts de
démarrage d’un autre utilisateur.

En fonctionnement de type contrôleur de domaine, il y a deux connexions successives de la part de

la machine qui se raccorde au domaine (comme nous l’avons vu lors du TP sur Windows Server) :
- connexion de la machine avec un compte spécial (sans répertoire associé)
- connexion de l’utilisateur avec un compte réel

Ceci est nécessaire dans le fonctionnement de Windows car les règles de la base de registres
s’appliquant à la machine et à l’utilisateur s’additionnent pour définir le comportement global
(HKLM : HKEY LOCAL MACHINE et HKLU : HKEY LOCAL USER se complètent).

9
Il faut donc créer des comptes machines spécifiques qui correspondent aux noms NetBios des
machines suivis d’un $. Ces comptes doivent être aussi présents sous UNIX sans répertoire de
travail :
useradd -d /dev/null MACHINE$ (pour une machine s’appelant MACHINE)

Il faut de même la rajouter dans la base samba :

smbpasswd -a -m MACHINE$

Une fois tout cela fait, il faut raccorder la machine en allant dans les propriétés de la machine
Windows : modifier nom de l’ordinateur puis préciser le nom de domaine qui doit correspondre à la
directive workgroup (bizarrement) du fichier de configuration smb.conf. Une authentification avec
un compte administrateur du serveur est alors nécessaire (remarque : la dé-raccordement d’un
domaine peut se faire avec un compte local, ce qui est logique en cas de suppression du serveur).
Le changement n’est pris en compte qu’après redémarrage (c’est une caractéristique sympathique
de Windows…).

Attention : Samba simule un serveur Windows mais n’implémente pas toutes les versions des
protocoles SMB/CIFS. Il est souvent nécessaire de paramétrer la machine cliente pour que celle-ci
utilise un protocole supporté par Samba. On doit donc modifier certaines clefs de la base de
registres dont :
HKLM\SYSTEM\CCS\Services\LanManWorkStation\Parameters (avec CCS CurrentControlSet)

Où on doit ajouter 2 valeurs de type DWord (32 bits)

DomainCompatibilityMode = 1
DNSNameResolutionRequired = 0

e) Ajout des différentes fonctionnalités d’un serveur de compte

Pour que l’utilisateur connecté bénéficie de tous les services d’un serveur de compte, il faut ajouter
plusieurs éléments de configuration

Création de répertoire utilisateur

Chaque utilisateur doit posséder un répertoire sur le serveur, plutôt que de créer chaque répertoire
séparément ce qui deviendrait fastidieux pour un grand nombre d’utilisateurs, nous allons utiliser
un partage particulier : le partage [homes].

[homes]
comment = Home Directories
browseable = no
read only = yes
create mask = 0700
directory mask = 0700
valid users = %U

Nous contrôlons l’accès à ce répertoire via une variable d’environnement qui donne l’accès au
répertoire utilisateur au seul propriétaire (variable %U). De même, il n’est pas nécessaire de
préciser le répertoire côté UNIX si celui-ci correspond au répertoire utilisateur UNIX associé
(l’information se situe alors dans le fichier /etc/passwd).

10
A la connexion, le répertoire utilisateur se connectera automatiquement avec une lettre déterminée
(en général Z : si elle n’est pas utilisée).

Gestion du montage automatique

Dans certaines configurations de serveur, on peut définir manuellement le répertoire de montage

automatique et la lettre associée via deux directive dans la section globale, ce qui influencera la
commande « net use /home ».
logon home = \\%L\%U
si l’on veut monter le répertoire associé au nom de l’utilisateur.

et
logon drive = U :
pour modifier la lettre de montage.

Définition d’un script de connexion

A la connexion, on peut avoir besoin d’exécuter des opérations supplémentaires (montage de

répertoires supplémentaires, configuration additionnelle…). Ces opérations sont réalisées via des
scripts qui doivent se situer dans le partage [netlogon]. Ce qui est logique puisque ces fichiers sont
stockés sur le serveur mais sont exécutés sur la machine cliente, ils doivent donc être accessibles
inconditionnellement. Une seule directive globale permet de définir ce script :

logon script = script.bat

Aucun chemin n’est donné car le script se situe dans le partage [netlogon]

Gestion des profils utilisateurs

Enfin pour compléter les fonctionnalités, il est nécessaire de sauvegarder les profils itinérants sur le
serveur. Pour cela deux possibilités existent, soit le stockage dans un répertoire spécifique à tous les
profils, soit un stockage dans le partage utilisateur. La première méthode permet un contrôle plus
fin des profils, alors que la deuxième permet de comptabiliser plus facilement les profils dans le
quota utilisateur : en effet maintenant beaucoup d’applications stockent des données dans le profil
(cache Internet…) en particulier dans le sous répertoire AppData.
Les directives sont alors :

logon path = \\%L\%U\profile

Pour placer les profils dans le répertoire profile du compte utilisateur

ou :
logon path = \\%L\profiles\%U
Pour placer chaque profil utilisateur dans un répertoire spécifique de l’export « profiles » qui doit
donc être déclaré.

Il faut bien entendu gérer correctement les droits sur ces répertoires pour que le mécanisme
fonctionne correctement : la mise au point est quelquefois délicates car les essais nécessitent une
connexion/déconnexion qui peut prendre du temps si les profils sont mal gérés (!).

11
f) Debuggage de Samba

Les causes de non fonctionnement ou de fonctionnement partiel sont fréquentes en multi-

environnement. Samba propose plusieurs étages de vérification, mais les retours restent complexes
à interpréter.
Non démarrage de Samba ou démarrage sans prendre en compte les modifications

Comme évoqué plus haut, il est absolument nécessaire de vérifier la syntaxe du fichier smb.conf à
l’aide de l’utilitaire testparm. Un usage simple permet de vérifier que les sections sont lues
correctement. Pour une vérification plus complète de la configuration on utilise « testparm -v » qui
va afficher toutes les valeurs des paramètres de samba (on peut alors filtrer avec la commande grep
pour récupérer juste les lignes d’intérêt). Ceci doit se faire avant lancement.

Après lancement il faut vérifier que les démons smbd et nmbd ont bien été lancés (on utilise la
commande ps aux). En cas de problème, la lecture des fichiers de log (/var/log/samba/log/smbd
et /var/log/samba/nmbd) peut être nécessaire. On peut faire varier le détail des retour de log via la
directive « log level = xx ». Le niveau de log utilisable est au maximum de 3 (après les
informations ne sont plus utilisables).

Démarrage mais difficulté avec l’accès aux ressources

La commande « smbstatus » permet de vérifier que des connexions NetBios ont bien été mises en
place, ce qui est un préalable à l’utilisation des ressources.

L’utilisation de Wireshark peut aussi apporter certains éléments de réponse (ou au minimum de
compréhension), mais le caractère verbeux des protocoles NetBios/SMB-CIFS rend difficile une
interprétation complète des échanges.

On peut aussi mettre en place côté client Windows des rapports de log plus détaillés comme nous
l’avons vu dans le chapitre sur les services Windows en particulier par la clef :
HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon en positionnant la valeur :
UserEnvDebugLevel = 00030002

La commande « net use » permet aussi côté client de vérifier la bonne connexion des ressources.

Problème de gestion des utilisateurs et raccordement des machines au domaine

Lors de difficulté de connexion, il est souhaitable de vérifier la bonne constitution de la base de

données Samba (construite avec smbpasswd). Cette base de données n’est plus directement lisible
avec les paramètres par défaut des nouvelles versions de Samba.
Deux commandes fournissent ces informations : pdbedit et tdbdump.

La commande « tdbdump » va fournir une extraction brute des données contenues dans les fichiers
de type tdb de la base de données son usage est :
tdbdump « nom de fichier »
(en général tdbdump /var/lib/samba/private/passdb.tdb pour les utisateurs)

pdbedit permet d’avoir un retour plus ou moins détaillé suivant les options (-L ; -v) du contenu de
la base des utilisateurs.

12
Les erreurs les plus fréquentes sont :
- un mauvais nom de machines (oubli du $ à la fin)
- utilisateurs ou machines associés à un ancien domaine (erreur fréquente lors des essais multiples)
- utilisateurs ou machines non déclarés (bien pensé à créer un utilisateur root pour connecter au
domaine)

La commande pdbedit permet aussi de gérer les utilisateurs comme smbpasswd mais de manière
plus complète, elle permet entre autre de détruire des utilisateurs associés à un autre domaine mais
qui sont encore présents dans la base.

1.4 Windows Services for UNIX

Depuis quelques années (1999), Microsoft propose aussi des services réseaux permettant de relier
un environnement de machines UNIX avec des serveurs Windows : Windows Services for UNIX
(SFU). Au fur et à mesure des versions, plusieurs évolutions ont eu lieu :
- Prise en charge de NFS plus complète en lien avec Active Directory
- Environnement complet d'applications et de scripts (technologie Interix)
- Internationalisation

Windows SFU fonctionne sous les plateformes (Windows 2000 Pro et Server, Windows XP, et
Windows Server 2003/2008), il a surtout été testé côté UNIX sur des plate-formes propriétaires
(Solaris, HPUX, AIX) qui constituent sa part de marché potentielle. Plusieurs niveaux d'inter-
opérabilité peuvent être envisagés :
- une simple utilisation réciproque des ressources UNIX/Windows (à l'image de Samba)
- l'utilisation d'outils Windows Server (MMC) pour gérer les ressources partagées
- une gestion commune des comptes utilisateur
- une intégration plus complète au niveau du portage des applications et des modes de
fonctionnement.

Utilisation réciproques des ressources

Ce service peut se décomposer en plusieurs outils dont :

- Client for NFS : qui va permettre à des postes clients ou serveurs Windows d'accéder à des
ressources UNIX sous NFS.
- Server for NFS : qui va, à l'inverse, permettre à des clients NFS d'accéder à des ressources sous
Windows, mais via NFS (c'est en quelque sorte l'inverse de Samba)
- Gateway for NFS : qui va permettre, à un serveur Windows, de servir de passerelle entre une
infrastructure Windows et une infrastructure UNIX sans ajouter de logiciel sur les ordinateurs
Windows.
- Server for PCNFS : qui va permettre à Windows d'émuler un serveur PCNFSD gérant entre autre
l'authentification.

Outils Windows Server pour gérer les ressources :

En fait, ce service inclut des outils assez standard :

- Client et serveur Telnet (versions différentes de ceux déjà existants depuis Windows 2000)
- Console MMC de gestion des services Windows SFU

13
- Outil de script PERL pour automatiser les tâches de gestion et d'administration

Simplification de la gestion des comptes.

Ce service permet de faire cohabiter de différentes manières un contrôleur de domaine Windows

avec une architecture basée sur NIS :
- Utilitaire de migration de NIS vers Active Directory (outil qui paraît assez logique
commercialement parlant pour Microsoft).
- NIS Server : permet d'émuler un Serveur NIS à partir d'un contrôleur de domaine Windows en
intégrant les domaines NIS à Active Directory.
- Gestion commune de l'authentification entre les 2 systèmes (mise en correspondance des noms
d'utilisateurs et synchronisation des mots de passe).

Intégration d'applications

Afin de pas perdre les connaissances et les développements mis en oeuvre sous UNIX, Windows
SFU propose un sous-système intégré (Interix) et un kit de développement pour porter directement
les scripts (Shell, Perl...) et les applications (après recompilation) écrites dans des langages de
programmation standard (C, C++, Fortran...).

14
 TP OptionRX1

1.5 TP n°5 : Configuration de serveurs Samba

Objectifs du TP:
Installation et paramétrage sous Linux d’un serveur Samba
Ressources nécessaires au TP
2 PC clients Windows et un PC serveur Linux.

Partie 1 : Partage de fichiers simple (UNIX-Windows) via Samba

Phase 1 : Configuration des PC

1. Configurer l’adresse IP, le masque, le nom de l’ordinateur : PCx (x numéro du PC).
2. Configurer les propriétés réseau des PC client pour permettre la connexion au
serveur Samba en cochant le client pour réseau Microsoft.
3. Définir un groupe de travail sur les PC client : tpreseau
Phase 2 : Configuration du PC serveur sous Linux Debian pour un partage non sécurisé
1. Toute la mise en œuvre de samba repose sur le fichier /etc/samba/smb.conf que vous
éditerez.
2. Modifier ou ajouter (s'ils n'existent pas) les champs dans la section [global] qui vont
permettre un usage d’un partage sans authentification avec le même workgroup que les
machines clientes.
3. Ajouter une section définissant un nouveau partage sans authentification de nom
[partage_libre], le répertoire UNIX correspondant sera /home/partage.
Ne pas oublier de créer ce répertoire d’y mettre un fichier texte à l’intérieur pour tester le
partage.
4. Tester la syntaxe du fichier /etc/samba/smb.conf grâce à l'utilitaire testparm et
éventuellement déceler des fautes de saisie (testparm /etc/samba/smb.conf).
5. Lancer le service par le script /etc/init.d/samba start. Que donne la commande ps ?
6. Pouvez-vous accéder au répertoire partagé sur le serveur à partir d’un PC client (voisinage
réseau) ? Editer le fichier déposé dans le répertoire, pouvez-vous le sauvegarder ?
7. Rendre le partage accessible en écriture :
Ajouter la ligne suivante dans la section définissant le partage
writeable = yes (autorisation d’écriture pour samba)
Est-ce suffisant pour permettre l’écriture sur la ressource ?
8. Modifier les propriétés UNIX du répertoire et des fichiers pour permettre la modification.
Tester la sauvegarde du fichier modifié.
9. Outils de suivi du fonctionnement de Samba :
- Visualisez le contenu des différents fichiers journaux sous le répertoire
/var/log/samba. Il en existe un pour chaque deamon et un par connexion NetBIOS.
- Sur le serveur, lancez la commande smbstatus pour visualiser les connexions
actives.
Important: pour la suite du TP, observer au fur et à mesure du travail, le suivi des
connexions des clients Windows, avec les indications du nom de l'utilisateur, de la
machine cliente et de son numéro IP, la date et l'heure. Vous pouvez aussi suivre les
échanges de trames entre les machines pour bien comprendre le fonctionnement

15
Phase 3 : Configuration du PC serveur sous Linux Debian pour un partage sécurisé

Pour l’utilisation de samba, il est nécessaire de créer des comptes pour les utilisateurs
sur le serveur. Cette procédure est effectuée en 2 étapes, création des comptes UNIX, puis
création des comptes Samba (en général on effectue une simple synchronisation des comptes
entre les 2 systèmes)

1. Création de comptes utilisateurs UNIX

Créer le groupe tpsamba et l’utilisateur tptest. Utiliser les commandes groupadd et
useradd (avec paramètres pour tenir compte du groupe).

2. Ensuite créer les comptes samba et définir les mots de passe pour samba par la commande :
smbpasswd –a <nom utilisateur>

3. Définir un nouveau partage (partage_sec) avec un accès limité à l’utilisateur précédent avec
une authentification.
4. Comment se fait l’accès sur la ressource de la phase 2 (partage_libre) ?
5. Créer un autre utilisateur tptest2 ainsi qu’un partage (partage_sec2) associé à celui-ci,
vérifier les droits d’accès respectifs des utilisateurs sur les divers répertoires.

Partie 2 : Emulation d’un contrôleur de domaine Windows via Samba

Phase 1 : Configuration du contrôleur principal de domaine PDC

1. Modifier la section [global] du fichier /etc/samba/smb.conf afin de valider Samba en

contrôleur principal de domaine (server role = classic primary domain controller).
2. Création du partage [netlogon]
Ce partage est destiné à recevoir les fichiers de configurations nécessaires au moment
de la connexion (scripts…). Il se situera dans le répertoire /home/samba/netlogon.

Phase 2 : Raccorder les machines Windows au contrôleur principal de domaine PDC

1. La première étape est d'ajouter la machine sur le contrôleur de domaine

2. Créez un compte root pour samba avec le même mot de passe qu’UNIX.
3. Rajoutez un compte UNIX pour la machine cliente avec la commande:
useradd –d /dev/null MACHINE$
4. Ajouter la machine cliente dans la base samba
smbpasswd -a -m MACHINE$
5. Puis définir le mot de passe qui correspond au nom de la machine cliente
smbpasswb MACHINE$ (le mot de passe sera MACHINE)

Paramétrer le client Windows

Poste de travail / Propriétés
Onglet nom de l'ordinateur /Modifier
Membre du Domaine ……………
Login: root passwd: admintest

Et bien sûr ... redémarrer !

Résultats et tests

16
 Vous devez constater que la boîte d'invite à la connexion est modifiée : le 3ème champ
Domaine y est ajouté. Se connecter en tant qu’utilisateur tptest. Observations : bureau,
voisinage réseau ?

Phase 3 : Création du répertoire personnel de chaque utilisateur (répertoire home)

1. Créer un nouvel utilisateur : tptest1.
2. Créer un répertoire personnel pour chaque utilisateur sous /home/samba.

La section [homes] du fichier smb.conf permet de définir l'accès au répertoire personnel de

chaque utilisateur.
Modifiez ce fichier afin que chaque utilisateur du système ait accès à son répertoire home et
qu’il soit le seul à pouvoir lire et écrire des fichiers.
3. Connectez-vous au serveur à partir du PC client. Avez-vous accès à votre répertoire
utilisateur ? Si oui, sous quelle lettre ? Sinon, montez-le par la commande net use.
4. Pour simplifier cette commande net use (net use /home) : définir un attribut imposant le
sous-répertoire utilisateur.
logon home = \\%L\%U
5. Pour changer la lettre du disque utilisateur sur le client
logon drive = U:
Reconnectez-vous à chaque fois pour tester.

Phase 4 : Mise en œuvre des scripts de connexion et des profils de chaque utilisateur
1. Créer un répertoire public [appli] accessible en lecture pour seulement tptest et tptest1.

read list = tptest,tptest1

2. Définir un script de connexion (script.bat) dans lequel vous montez un deuxième disque
réseau en F : pour le partage public [appli].
Le fichier script.bat doit se situer dans le répertoire défini par netlogon

3. La dernière étape importante est la gestion centralisée des profils utilisateurs. Pour cela
créer un sous-répertoire utilisateur (./profile) où seront stockés les profils utilisateurs
(attention aux droits car le serveur écrit des informations dans ce répertoire). Puis définir un
attribut pour préciser au serveur que ce répertoire se situe sous le compte utilisateur :
logon path = \\%L\%U\profile
Tester le bon fonctionnement en vous reconnectant, interpréter les messages que
renvoie la machine Windows lors de la première connexion/déconnexion.
Vous pouvez de la même manière gérer vos profils utilisateur dans un répertoire
spécifique par exemple : /home/samba/profiles. Tester.

Phase 6 : Désinstallation (Phase obligatoire)

1. Sauvegarder les configurations que vous avez modifiées. Vous devez être capable à la fin
du TP de reconstruire toutes les configurations très rapidement. Pour cela vous devez
sauvegarder les fichiers de configurations modifiés ainsi que créer les scripts nécessaires
pour reconstruire les modifications que vous avez effectuées.
2. Bien penser à dé-raccorder les machines au domaine et à les remettre dans un
workgroup simple, car sinon à la prochaine connexion, une authentification de type
domain sera lancée et celle-ci échouera si le serveur samba n’est pas lancé.

17