<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc">
<chapter id="ServerType">
<chapterinfo>
&author.tridge;
&author.jelmer;
&author.jht;
</chapterinfo>
<title>Types de serveur et modes de sécurité</title>
<para>
Samba peut être configuré en différents types de serveur, et ce chapitre apporte des informations à ce sujet. Un
administrateur de réseau Microsoft qui souhaite migrer vers Samba ou l'utiliser voudra connaître la signification,
dans le contexte de Samba, des termes qui sont familiés pour l'administrateur MS Windows. Ceci signifie qu'il est essentiel
de définir également comment les modes de sécurité fonctionnent avant d'expliquer plus en détails comment configurer le serveur soi-même.
</para>
<para>
Ce chapitre donne une vue générale des capacités de Samba concernant les modes de sécurité et comment ces
derniers s'associent aux serveurs MS Windows et aux clients.
</para>
<para>
Une question qui revient souvent est : <quote>Pourquoi utiliser Samba ?</quote>. La plupart des chapitres
comportent une section qui met en évidence ses caractéristiques et ses avantages. Nous espérons que les informations
proposées permettront de répondre à cette question. Attention tout de même : nous voulons être juste et crédible,
ainsi même les caractéristiques de Samba qui ne sont pas bonnes seront prises en compte. La concurrence peut
parfois fournir de meilleures prestations.
</para>
<sect1>
<title>Caractéristiques et avantages</title>
<para>
Deux hommes marchaient sur un chemin de terre, lorsque soudain l'un d'eux heurta du pied un petit caillou rouge.
Il se fit mal à l'orteil et le caillou se coinça dans sa sandale. Il l'enleva en proférant de furieux jurons de colère à la hauteur
de sa douleur. L'autre homme regarda le caillou et dit, <quote>C'est un grenat.
Je peux le transformer en une pierre précieuse qui fera un jour le bonheur d'une princesse !</quote>
</para>
<para>
La morale de cette histoire : deux hommes, deux points de vue très différents sur le même caillou.
Que ça vous plaise ou non, Samba est comme ce caillou. Traitez-le comme il faut et il pourra vous apporter
beaucoup de bonheur, mais si on vous oblige à l'utiliser et que vous n'avez pas de temps à lui consacrer pour découvrir ses secrets,
il peut être une source de désagrément.
</para>
<para>
Au départ, Samba était un projet qui visait à fournir une interopérabilité entre des clients MS Windows 3.x
et un serveur UNIX. Il a beaucoup évolué depuis ses modestes débuts et il fournit à présent des
caractéristiques et des fonctionnalités qui conviennent à un déploiement à grande échelle.
Il possède également quelques défauts. Dans les sections comme celle-ci, nous vous parlerons de ces avantages comme de ces inconvénients.
</para>
<para>
Alors, quels sont les avantages des fonctionnalités mentionnés dans ce chapitre ?
</para>
<itemizedlist>
<listitem><para>
Samba-3 peut remplacer un contrôleur de domaine MS Windows NT4.
</para></listitem>
<listitem><para>
Samba-3 offre une excellente interopérabilité avec des domaines de même
type que MS Windows NT4, ainsi que, dans sa configuration de base, avec les domaines Microsoft Active Directory.
</para></listitem>
<listitem><para>
Samba-3 autorise les trusts d'inter-domaines de type NT4.
</para></listitem>
<listitem><para>
Samba possède des modes de sécurité permettant une authentification plus souple
que celle disponible avec les contrôleurs de domaine MS Windows NT4.
</para></listitem>
<listitem><para>
Samba-3 autorise l'utilisation simultanée de plusieurs backends de la base de données des comptes.
(les mots de passe cryptés qui sont stockés dans la base de données des comptes sont dans
des formats spécifiques au réseau Windows).
</para></listitem>
<listitem><para>
Les backends de la base de données des comptes peuvent être répartis et dupliqués
en utilisant diverses méthodes. Cela donne à Samba-3 une plus grande souplesse
que MS Windows NT4 et dans bien des cas son utilité apparaît beaucoup plus importante
que les domaines Active Directory avec MS Windows 200x.
</para></listitem>
</itemizedlist>
</sect1>
<sect1>
<title>Types de serveurs</title>
<para>
Les administrateurs de réseaux Microsoft font souvent allusion à trois différents types de serveurs :
</para>
<itemizedlist>
<listitem><para>Contrôleur de domaine</para>
<itemizedlist>
<listitem><para>Contrôleur de domaine primaire (PDC [Primary Domain Controller])</para></listitem>
<listitem><para>Contrôleur de domaine de sauvegarde (BDC [Backup Domain Controller])</para></listitem>
<listitem><para>Contrôleur de domaine ADS</para></listitem>
</itemizedlist>
</listitem>
<listitem><para>Serveur membre du domaine</para>
<itemizedlist>
<listitem><para>Serveur du domaine Active Directory</para></listitem>
<listitem><para>Serveur de domaine de type NT4</para></listitem>
</itemizedlist>
</listitem>
<listitem><para>Serveur autonome</para></listitem>
</itemizedlist>
<para>
Les chapitres traitant du contrôle de domaine(<link linkend="samba-pdc">Le contrôle de domaine</link>),
du contrôle de domaine de sauvegarde (<link linkend="samba-bdc">Le contrôle de domaine de sauvegarde</link>), et
de l'appartenant aux domaines (<link linkend="domain-member">L'appartenance aux domaines</link>) apportent
des informations pertinentes concernant la configuration de Samba par rapport aux rôles de chacun de ces serveurs.
Nous vous conseillons fortement de lire attentivement ces chapitres car ils posent les bases nécessaires à la mise en place de la sécurité du domaine Samba.
</para>
<para>
Un serveur autonome est indépendant au niveau de la source de son backend de compte.
Reportez-vous à <link linkend="StandAloneServer">Les serveurs autonomes</link> afin d'avoir une meilleure idée
de ce qu'est une configuration pour un serveur <emphasis>autonome</emphasis>.
</para>
</sect1>
<sect1>
<title>Les modes de sécurité de Samba</title>
<para>
Dans cette section, nous décrivons à quoi servent les des modes de sécurité de Samba. Une bonne compréhension de
la manière dont Samba implémente chaque mode de sécurité ainsi que de la manière de configurer les clients MS Windows pour chaque mode
permettra d'éviter en grande partie les plaintes des utilisateurs et le découragement des administrateurs.
</para>
<para>
Les réseaux Microsoft Windows utilisent un protocole qui s'appelait au départ le protocole Server Message Block (SMB).
Depuis 1996 à peu près, ce protocole est plus connu sous le nom de protocole de systèmes de fichiers Internet
communs (Common Internet Filesystem (CIFS)).
</para>
<para>
Dans le monde des réseaux SMB/CIFS, il n'y a que deux types de sécurité : <emphasis>le niveau utilisateur</emphasis> et
<emphasis>le niveau espace partagé</emphasis>. Nous parlerons d'eux sous le terme général de <emphasis>niveaux de sécurité</emphasis>. En
implémentant ces deux niveaux de sécurité, Samba nous apporte une souplesse qui n'apparaît pas dans les serveurs MS Windows
NT4/200x. En fait, Samba implémente la sécurité du <emphasis>niveau de l'espace partagé</emphasis> d'une seule façon, en revanche
l'implémentation de la sécurité au <emphasis>niveau utilisateur</emphasis> peut se faire de quatre façons. Nous regroupons ces
implémentations de niveaux de sécurité sous l'appellation : <emphasis>modes de sécurité</emphasis>. Il s'agit des modes
<emphasis>espaces partagés</emphasis>, <emphasis>utilisateurs</emphasis>, <emphasis>domaines</emphasis>, <emphasis>ADS</emphasis>,
et <emphasis>serveurs</emphasis>. Ils sont décrits dans ce chapitre.
</para>
<para>
Un serveur SMB informe le client du niveau de sécurité en vigueur pour le serveur au moment de l'ouverture d'une session.
Il y a deux choix possibles : le niveau espace partagé et le niveau utilisateur. La façon dont le client essaiera de s'authentifier
dépendra du niveau auquel il accède. Cela n'aura pas directement d'influence (en tout cas elle sera minime) sur la façon dont le serveur
de Samba s'occupe de la sécurité. Cela peut vous paraître étrange, mais cela cadre parfaitement avec la philosophie client/serveur de SMB.
Dans SMB, tout est à l'initiative et sous le contrôle du client, et le serveur ne peut qu'informer le client
de ce qui est disponible et si une action est autorisée ou non.
</para>
<para>
La notion de <literal>client</literal> fait référence à tous les acteurs, qu'il s'agisse d'un poste de travail Windows,
d'un serveur Windows, d'un autre serveur Samba, ou de toute application cliente SMB ou CIFS de base
(par exemple, <command>smbclient</command>) qui utilise des services fournis par un serveur SMB/CIFS.
</para>
<sect2>
<title>Sécurité du niveau utilisateur</title>
<para>
Nous traitons de la sécurité du niveau utilisateur en premier car c'est la plus simple. Dans la sécurité du niveau utilisateur, le client envoie
une requête d'ouverture de session directement en suivant le protocole. Cette requête comporte un nom d'utilisateur et un mot de passe.
Le serveur peut soit accepter soit rejeter cette combinaison nom d'utilisateur/mot de passe. A ce stade, le serveur n'a aucune idée de l'espace partagé
auquel le client va tenter d'accéder ; par conséquent, pour décider d'accepter ou de rejeter la requête il ne peut se baser que sur :
</para>
<orderedlist>
<listitem><para>le nom d'utilisateur/mot de passe.</para></listitem>
<listitem><para>le nom de la machine cliente.</para></listitem>
</orderedlist>
<para>
Si le serveur accepte l'identification du nom d'utilisateur/mot de passe, le client s'attend à pouvoir monter des espaces partagés (en
utilisant une <emphasis>connexion à l'arbre</emphasis>) sans devoir indiquer son mot de passe à nouveau. On s'attend à ce que tous les
droits d'accès seront tels qu'ils ont été établis lors de la mise en place de l'identité nom d'utilisateur/mot de passe
lors de l'<emphasis>ouverture de la session</emphasis> initiale.
</para>
<para>
Il est également possible pour le client d'envoyer plusieurs requêtes d'<emphasis>ouverture de session</emphasis>.
Lorsque le serveur répond, il donne au client un <emphasis>uid</emphasis>, utilisé comme
étiquette d'authentification pour ce nom d'utilisateur/mot de passe. Le client peut de cette façon
entretenir plusieurs contextes d'authentification (WinDD est un exemple d'application fonctionnant ainsi).
</para>
<para>
Les noms des comptes d'utilisateurs du réseau Windows ne sont pas sensibles à la casse, ce qui veut dire que
les caractères majuscules ou minuscules du nom du compte sont considérés comme équivalents. On dit qu'ils préservent
la casse, mais qu'ils n'y sont pas sensibles. Les systèmes Windows et LanManager antérieurs à la version 3.10 de Windows NT
ont des mots de passes insensibles à la casse, et ne la préservent pas forcément. Tous les systèmes de la famille
Windows NT traitent les mot de passes en préservant la casse, et en y étant sensibles.
</para>
<sect3>
<title>Exemple de configuration</title>
<para>
Le paramètre de &smb.conf; qui règle la sécurité du niveau utilisateur est :
</para>
<para><smbconfblock>
<smbconfoption name="security">user</smbconfoption>
</smbconfblock></para>
<para>
Il s'agit du paramétrage par défaut depuis Samba-2.2.x.
</para>
</sect3>
</sect2>
<sect2>
<title>Sécurité du niveau de l'espace partagé</title>
<para>
Concernant la sécurité du niveau de l'espace partagé, le client s'authentifie séparément pour chaque espace partagé.
Il envoie un mot de passe avec chaque requête de connexion à l'arbre (montage de l'espace partagé),
mais cette manoeuvre ne s'accompagne pas de l'envoi explicite d'un nom d'utilisateur. Le client s'attend à ce
qu'un mot de passe soit associé à chaque espace partagé, indépendamment de l'utilisateur. Cela signifie que
Samba doit trouver quel nom d'utilisateur le client veut probablement utiliser, le serveur SMB n'envoie pas de manière
explicite le nom d'utilisateur. Quelques serveurs SMB commerciaux tels que NT associent en fait les mots de passe
directement avec les espaces partagés dans la sécurité du niveau d'espace partagé, en revanche Samba utilise toujours
le schéma de l'authentification UNIX où il s'agit de la combinaison nom d'utilisateur/mot de passe qui est
authentifiée, et non la combinaison espace partagé/mot de passe.
</para>
<para>
Pour faire le parallèle avec les réseaux MS Windows, pensez à MS Windows 9x/Me
où on peut créer un dossier partagé doté d'un accès en lecture seule ou avec tous les droits, avec ou sans
mot de passe.
</para>
<para>
Beaucoup de clients envoient une requête d'ouverture même si une sécurité au niveau de l'espace partagé
a été mise en place pour le client. Ils envoient normalement un nom d'utilisateur valide mais pas de mot de passe.
Samba enregistre ce nom d'utilisateur dans une liste de noms d'utilisateurs potentiels. Lorsque le client émet
ensuite une requête de connexion à l'arbre, il ajoute également à cette liste le nom de l'espace partagé auquel
ils tentent de se connecter (utile pour les répertoires personnels) ainsi que n'importe quel utilisateur apparaissant dans
la liste du paramètre utilisateur <smbconfoption name="user"/> du fichier &smb.conf;. Le mot de passe est ensuite vérifé
par rapport à chacun des noms d'utilisateurs potentiels. S'il y en a un qui correspond, le client
est authentifié en tant que cet utilisateur.
</para>
<para>
Si la liste des noms d'utilisateurs potentiels n'est pas fournie, Samba fait appel au
système UNIX afin de trouver le compte utilisateur qui possède le mot de passe correspondant à celui
fourni par la base de données du compte standard. Sur un système n'étant pas équipé d'un Name Service Switch (NSS),
de telles recherches émaneront de la base de données de <filename>/etc/passwd</filename>. Sur des systèmes équipés
de NSS, la recherche se fera au niveau des bibliothèques spécifiées dans le fichier <filename>nsswitch.conf</filename>.
Les entrées de ce fichier dans lesquelles les biliothèques sont spécifiées sont :
<screen>
passwd: files nis ldap
shadow: files nis ldap
group: files nis ldap
</screen>
Dans l'exemple décrit ici (qui a peu de chances dêtre utilisé dans la pratique) la recherche se fera sur
<filename>/etc/passwd</filename> et <filename>/etc/group</filename> ; si rien n'a été trouvé, elle se fera
au niveau du NIS, puis de LDAP.
</para>
<sect3>
<title>Exemple de configuration</title>
<para>
Le paramètre de &smb.conf; configurant la sécurité au niveau de l'espace partagé est :
</para>
<para><smbconfblock>
<smbconfoption name="security">share</smbconfoption>
</smbconfblock></para>
</sect3>
</sect2>
<sect2>
<title>Mode sécurité domaine (sécurité au niveau utilisateur)</title>
<para>
Ce mode instaure un mécanisme pour le stockage de tous les comptes des utilisateurs et des
groupes dans un référentiel de comptes, partagé et central. Le référentiel des comptes centralisé est partagé
entre les contrôleurs (de la sécurité) des domaines. Les serveurs qui agissent en tant que contrôleurs de domaines
fournissent des services d'authentification et de validation à toutes les machines qui sont impliquées au niveau de la
sécurité pour le domaine. Un contrôleur de domaine primaire (PDC) est un serveur qui est chargé de maintenir
l'intégrité de la base de données des comptes. Les contrôleurs de domaines de sauvegarde (BDC) ne fournissent
que des services de connexion au domaine et d'authentification. Généralement, les BDC seront plus
réactifs pour répondre aux requêtes de connexion réseau qu'un PDC.
</para>
<para>
Lorsque Samba fonctionne en mode <smbconfoption name="security">domaine</smbconfoption>, le serveur de Samba
a un compte lié à la sécurité du domaine (un compte pour la machine), ce qui fait que toutes les requêtes
d'authentification sont transmises aux contrôleurs de domaine. En d'autres termes, cette configuration donne au
serveur Samba le statut de serveur membre du domaine, y compris lorqu'il agit en tant que contrôleur
de domaine. Toutes les machines participant à la sécurité domaine doivent avoir un compte machine dans la base de données
de la sécurité.
</para>
<para>
Dans le mode sécurité du domaine, l'architecture sous-jacente pour la sécurité utilise la sécurité au niveau
utilisateur. Même les machines membres du domaine doivent s'identifier au démarrage. Le compte machine
est composé d'une entrée dans la base de données des comptes, dont le nom est le nom NetBIOS de la machine
et dont le mot de passe est généré aléatoirement et connu à la fois des contrôleurs de domaine et de la machine
membre. Si le compte machine ne peut pas être validé au démarrage, les utilisateurs ne pourront pas se connecter
au domaine par cette machine car elle n'apparaîtra pas fiable. On appelle le compte machine un compte
dapprobation machine.
</para>
<para>
Il y a trois configurations possibles pour les membres du domaine :
</para>
<orderedlist>
<listitem><para>Primary domain controller (PDC) - il n'y en a qu'un par domaine.</para></listitem>
<listitem><para>Backup domain controller (BDC) - il peut y en avoir plusieurs par domaine.</para></listitem>
<listitem><para>Domain member server (DMS) - il peut y en avoir plusieurs par domaine.</para></listitem>
</orderedlist>
<para>
Nous consacrerons un chapitre à chacune. Pour l'instant, nous allons nous intéresser
à une configuration de DMS de base.
</para>
<sect3>
<title>Exemple de configuration</title>
<para><emphasis>
Samba en tant que serveur membre du domaine (DMS)
</emphasis></para>
<para>
Pour cette méthode, il faut ajouter les paramètres suivants dans le fichier &smb.conf; :
<smbconfblock>
<smbconfoption name="security">domain</smbconfoption>
<smbconfoption name="workgroup">&example.workgroup;</smbconfoption>
</smbconfblock>
</para>
<para>
Pour que cela marche, le serveur Samba doit rejoindre le domaine de sécurité
de MS Windows NT. Voici ce quil faut faire pour cela :
</para>
<procedure>
<step><para>sur le contrôleur de domaine MS Windows NT, ajoutez un compte machine
pour le serveur Samba en utilisant Server Manager.
</para></step>
<step><para>sur le système UNIX/Linux exécutez :</para>
<para><screen>&rootprompt;<userinput>net rpc join -U administrator%password</userinput></screen></para>
</step>
</procedure>
<note><para>
Samba-2.2.4 et les versions suivantes de la série Samba 2.2.x peuvent rejoindre automatiquement un domaine style Windows NT4
en exécutant simplement :
<screen>
&rootprompt;<userinput>smbpasswd -j <replaceable>NOM_DU_DOMAINE</replaceable> -r <replaceable>NOM_DU_PDC</replaceable> \
-U Administrator%<replaceable>mot_de_passe</replaceable></userinput>
</screen>
On peut réaliser la même chose avec Samba-3 en exécutant :
<screen>
&rootprompt;<userinput>net rpc join -U Administrator%<replaceable>mot_de_passe</replaceable></userinput>
</screen>
Avec Samba-3, il n'est pas nécessaire de spécifier le <replaceable>NOM_DU_DOMAINE</replaceable> ou le
<replaceable>NOM_DU_PDC</replaceable>, puisquil les retrouve à partir des configurations du fichier &smb.conf;.
</para></note>
<para>
L'utilisation de ce mode d'authentification nécessite qu'il y ait un compte UNIX standard pour chaque
utilisateur afin de leur attribuer un UID une fois que le compte a été authentifié par le contrôleur du
domaine Windows. Ce compte peut être bloqué afin d'empêcher les ouvertures de session par des clients
autres que MS Windows en attribuant par exemple un shell invalide à l'entrée de <filename>/etc/passwd</filename>.
La meilleure façon de rendre un shell invalide à un compte utilisateur est de lui attribuer un shell
<filename>/bin/false</filename>.
</para>
<para>
Les contrôleurs de domaine peuvent se trouver à tout endroit où cela peut s'avérer pratique.
Nous vous conseillons très fortement d'avoir un BDC sur chaque segment de réseau physique, et si le PDC
est sur un segment de réseau distant, l'utilisation de Wins (voir <link
linkend="NetworkBrowsing">Network Browsing</link> pour plus d'informations) est quasiment indispensable.
</para>
<para>
Une possibilité autre que l'attribution d'UID aux utilisateurs Windows sur un serveur membre Samba est décrite
à <link linkend="winbind">Winbind</link>, <link linkend="winbind">Winbind: Use of Domain Accounts</link>.
</para>
<para>
Pour plus d'informations concernant l'appartenance aux domaines : <link linkend="domain-member">Domain Membership</link>.
</para>
</sect3>
</sect2>
<sect2>
<title>Mode de sécurité ADS (sécurité au niveau utilisateur)</title>
<para>
Samba-2.2 ainsi que Samba-3 peuvent rejoindre un domaine Active Directory dont le mode de sécurité style NT4 est basée sur RPC.
Cela est possible si le domaine fonctionne en mode natif. En mode natif, Active Directory
autorise tout à fait les membres du domaine de type NT4. Ce qui va à l'encontre de ce à quoi l'on pourrait s'attendre.
</para>
<para>
Si vous utilisez Active Directory, en démarrant avec Samba-3 vous pouvez rejoindre en tant que membre AD natif.
A quoi cela pourrait-il servir ? Votre politique de sécurité pourrait interdire l'utilisation des protocoles
d'authentification compatibles avec NT. Toutes vos machines sont sous Windows 2000 et supérieur et utilisent toutes Kerberos.
Dans ce cas, Samba, en tant que domaine de type NT4, ne pourrait fonctionner sans des données d'authentification
compatibles avec NT. Dans le mode membre-AD, Samba peut accepter des étiquettes Kerberos.
</para>
<para>
Les sites qui utilisent les services répertoires ADS (Active Directory Services) de Microsoft Windows devraient mesurer l'importance
des termes : opération ADS en <literal>mode natif</literal> et <literal>en mode mixte</literal>. Le terme
<literal>domaine</literal> est utilisé pour décrire une architecture de sécurité basée sur Kerberos (comme celle
utilisée par Microsoft ADS).
</para>
<sect3>
<title>Exemple de configuration</title>
<para><smbconfblock>
<smbconfoption name="realm">votre_domaine_kerberos</smbconfoption>
<smbconfoption name="security">ADS</smbconfoption>
</smbconfblock></para>
<para>
Le paramètre suivant peut être nécessaire :
</para>
<para><smbconfblock>
<smbconfoption name="password server">votre_serveur_kerberos</smbconfoption>
</smbconfblock></para>
<para>
Reportez-vous à <link linkend="domain-member">Domain Membership</link>, et à
<link linkend="ads-member">Samba ADS Domain Membership</link> pour plus d'informations
concernant ce choix de configuration.
</para>
</sect3>
</sect2>
<sect2>
<title>Sécurité serveur (sécurité au niveau utilisateur)</title>
<para>
Le mode sécurité serveur est un vestige de lépoque où Samba navait pas la capacité
d'agir comme serveur membre du domaine. Il est fortement recommandé de ne pas
utiliser cette fonctionnalité. Ce mode possède beaucoup d'inconvénients, entre autres :
</para>
<itemizedlist>
<listitem><para>risque dinaccessibilité de certains comptes sur des serveurs de mots de passe MS Windows NT4/200x.</para></listitem>
<listitem><para>risque que le serveur de mots de passe ne soit pas celui spécifié.</para></listitem>
<listitem><para>ne fonctionne pas avec Winbind, qui est particulièrement utile pour stocker les profils à distance.</para></listitem>
<listitem><para>ce mode peut ouvrir des connexions au serveur de mots de passe et les laisser ouvertes pendant de longues périodes.</para></listitem>
<listitem><para>la sécurité sur le serveur Samba est sévèrement compromise lorsque le serveur de mots de passe distant s'arrête brutalement.</para></listitem>
<listitem><para>avec ce mode il n'y a PAS de compte sécurité dans le domaine auquel le serveur de mots de passe appartient, pour le serveur Samba.</para></listitem>
</itemizedlist>
<para>
Dans ce mode, le serveur Samba informe le client qu'il adopte une sécurité au niveau
utilisateur. Le client ouvre ensuite une session comme décrit précédemment. Le serveur Samba prend le
nom d'utilisateur/mot de passe que le client envoie et tente de se connecter au <smbconfoption name="password server"/> serveur de mots de passe
en envoyant exactement le même nom d'utilisateur/mot de passe qu'il a obtenu du client. Si ce serveur est en mode sécurité utilisateur
et accepte le mot de passe, alors Samba accepte la connexion du client. Ce paramètre permet
au serveur Samba d'utiliser un autre serveur SMB comme <smbconfoption name="password server"/> serveur de mots de passe.
</para>
<para>
Il faut aussi noter qu'au départ de tout cela, lorsque le serveur indique au client quel est son
niveau de sécurité, il informe également le client s'il supporte le cryptage. Si c'est
le cas, il fournit au client une clé de cryptage aléatoire. Le client doit ensuite envoyer tous les
mots de passe dans un format crypté. Samba est par défaut compatible avec ce type de cryptage.
</para>
<para>
Le paramètre <smbconfoption name="security">server</smbconfoption> signifie que Samba informe les clients qu'il
est en cours d'exécution en <emphasis>mode utilisateur</emphasis>, alors qu'en fait il fait passer toutes les
requêtes d'authentification à un autre serveur en mode utilisateur. Cela nécessite un paramètre supplémentaire
<smbconfoption name="password server"/> pointant vers le vrai serveur d'authentification. Le vrai serveur
d'authentification peut être un autre serveur Samba ou un serveur windows NT, ce dernier étant, d'origine, compatible
avec les mots de passe cryptés.
</para>
<note><para>
Lorsque Samba est en cours d'exécution en <emphasis>mode sécurité serveur</emphasis>, il est primordial
que le paramètre <emphasis>password server</emphasis> ait bien le nom exacte de la machine NetBIOS du serveur
d'authentification cible. Samba ne peut pas le retrouver en effectuant des recherches sur le nom du NetBIOS
car le choix du serveur d'authentification est arbitraire et ne peut pas être retrouvé à partir du nom de
domaine. Le mode sécurité serveur correspond essentiellement à ce qui sappellait avant le mode groupe de
travail [workgroup].
</para></note>
<sect3>
<title>Exemple de configuration</title>
<para><emphasis>
Utilisation de MS Windows NT en tant que serveur d'authentification
</emphasis></para>
<para>
Pour cette méthode, il faut ajouter les paramètres suivants dans le fichier &smb.conf; :
</para>
<para><smbconfblock>
<smbconfoption name="encrypt passwords">Yes</smbconfoption>
<smbconfoption name="security">server</smbconfoption>
<smbconfoption name="password server">"nom_NetBIOS_du_DC"</smbconfoption>
</smbconfblock></para>
<para>
Il y a deux façons de vérifier si la combinaison du nom d'utilisateur et du mot de passe
est valide ou non. La première utilise l'information de retour fournie lors du processus d'envoi de messages
d'authentification, l'autre utilise simplement un code d'erreur.
</para>
<para>
L'inconvénient de ce mode de configuration est que, pour des raisons de sécurité, Samba
va envoyer au serveur de mots de passe un faux nom d'utilisateur et un faux mot de passe,
et si le serveur distant ne parvient pas à rejeter la fausse combinaison nom d'utilisateur/mot de passe,
un autre mode d'identification ou de validation est utilisé. Lorsquun site rejette des mots de passe,
après un certain nombre déchecs de tentatives dauthentification, laccès utilisateur sera bloqué.
</para>
<para>
Pour l'utilisation de ce mode d'authentification, un compte standard UNIX est nécessaire
pour l'utilisateur. Ce compte peut être bloqué afin d'empêcher que des clients non-SMB/CIFS
puissent ouvrir une session.
</para>
</sect3>
</sect2>
</sect1>
<sect1>
<title>Vérification des mots de passe</title>
<para>
Les clients MS Windows peuvent avoir recours à des mots de passe cryptés dans le cadre
d'un modèle d'authentification en question/réponse (également connu sous le nom de NTLMv1 et NTLMv2), soit seul ou soit
en chaînes de caractères pour une simple authentification par mot de passe. Il faut savoir
qu'avec le protocole SMB, le mot de passe est transmis à travers le réseau en texte clair
ou chiffré, mais pas les deux pour la même demande d'authentification.
</para>
<para>
Quand on utilise des mots de passe cryptés, un mot de passe saisi par l'utilisateur
peut être chiffré de deux manières différentes :
</para>
<itemizedlist>
<listitem><para>un hachage MD4 d'unicode de la chaîne du mot de passe.
C'est ce que l'on appelle le hachage NT.
</para></listitem>
<listitem><para>le mot de passe est converti en majuscules, puis
complété ou tronqué à 14 octets. Cette chaîne est ensuite ajoutée
aux 5 octets des caractères NULL et coupée en deux pour former deux
clés DES [Data Encryption Standard] de 56 bits afin de chiffrer une valeur "magique" de 8 octets.
Les 16 octets qui en résultent représentent le hachage de LanMan.
</para></listitem>
</itemizedlist>
<para>
MS Windows 95 antérieur au Service Pack 1 et Microsoft Windows NT des versions 3.x et 4.0 antérieur
au Service Pack 3 utilisent les deux modes d'authentification par mot de passe. Aucune des versions de
MS Windows qui suivent ne prend en charge les mots de passe en clair par défaut.
</para>
<para>
Les clients MS Windows ont l'habitude dabandonner le mapping réseau qui est
resté inactif pendant au moins 10 minutes. Lorsque l'utilisateur tente d'utiliser la
connexion vers lunité mappée qui a été abandonnée, le client rétablit la connexion à
l'aide d'une copie en cache du mot de passe.
</para>
<para>
Lorsque Microsoft a changé le mode mot de passe par défaut, il n'a plus été possible
de mettre en cache le mot de passe en clair. Cela signifie que lorsqu'on change
le paramètre du registre de façon à réactiver l'utilisation des mots de passe
en clair, tout semble fonctionner, mais lorsque le mapping de connexion au service abandonné tente
de reprendre, une erreur apparaîtra si le serveur d'authentification distant
n'est pas compatible avec les mots de passe cryptés. Il n'est vraiment pas conseillé
de réactiver le mot de passe en texte clair pour ces clients-là.
</para>
<para>
On peut utiliser les paramètres suivants pour contourner le problème de la mise en majuscules des
noms d'utilisateurs et des mot de passe des clients Windows 9x/Me avant leur transmission
au serveur SMB lors d'une authentification en texte clair :
</para>
<smbconfblock>
<smbconfoption name="password level"><replaceable>entier</replaceable></smbconfoption>
<smbconfoption name="username level"><replaceable>entier</replaceable></smbconfoption>
</smbconfblock>
<para>
Par défaut, Samba convertit en minuscules le nom d'utilisateur avant de chercher
l'utilisateur dans la base de données des comptes du système local. Comme les
noms d'utilisateurs UNIX contiennent par convention uniquement des caractères minuscules,
le paramètre <smbconfoption name="username-level"/> est rarement nécessaire.
</para>
<para>
Cependant, les mots de passe sur les systèmes UNIX utilisent souvent à la fois les minuscules
et les majuscules. Cela signifie que pour qu'un utilisateur, client Windows 9x/Me, se connecte à un
serveur Samba utilisant l'authentification en texte clair, le <smbconfoption name="password level"/>
doit être réglée sur le nombre maximal de lettres majuscules qui <emphasis>pourraient</emphasis>
apparaître dans un mot de passe. Notez que si l'OS du serveur utilise la version DES traditionnelle
de crypt(), un <smbconfoption name="password level"/> de valeur 8 rendra les mots de passe
insensibles à la casse pour les utilisateurs de Windows. Cela rendra également les temps de
connexion plus longs car Samba devra calculer les permutations de la chaîne du mot de passe et
les essayer une par une jusqu'à ce qu'il en trouve une qui corresponde (ou que toutes les
combinaisons échouent).
</para>
<para>
La meilleure solution à adopter est d'activer les mots de passe cryptés
partout où l'on utilise Samba. La plupart des tentatives pour appliquer le
changement de registre dans le but de réactiver les mots de passe en texte clair finira par énerver l'utilisateur.
</para>
</sect1>
<sect1>
<title>Erreurs fréquentes</title>
<para>
Nous faisons tous des erreurs. Ce nest pas grave de faire des erreurs pour autant qu'elles soient
faites aux bons endroits et au bon moment. On tolère rarement une erreur provoquant une perte de productivité ;
toutefois, on peut s'attendre à ce que des erreurs soient commises dans un laboratoire dessai et de
développement.
</para>
<para>
Ici, nous nous penchons sur les erreurs et les méprises courantes qui ont fait l'objet de discussions
sur les listes de diffusion de Samba. On peut en éviter beaucoup en se préparant correctement
avant de se lancer dans une implémentation de Samba. Certaines sont le résultat d'une méconnaissance de langlais,
dont beaucoup dexpressions sont relativement vagues, et peuvent prêter à confusion
pour ceux dont l'anglais n'est pas la langue maternelle.
</para>
<sect2>
<title>Quest-ce qui fait de Samba un serveur ?</title>
<para>
Pour certains, la nature du mode de sécurité de Samba est évidente, alors quen fait ce nest pas du tout ça.
On peut supposer que <smbconfoption name="security">server</smbconfoption> signifie que Samba agira en
tant que serveur. Pas du tout ! Ce paramètre signifie que Samba va essayer d'utiliser un autre
serveur SMB comme seule source d'authentification de l'utilisateur.
</para>
<para>
Samba est un serveur quel que soit le mode de sécurité choisi. Lorsque Samba est utilisé en dehors
du contexte de sécurité domaine, il est préférable de laisser le mode de sécurité à la valeur par
défaut. Par défaut, Samba-3 utilise le mode de sécurité utilisateur.
</para>
</sect2>
<sect2>
<title>Qu'est-ce qui donne à Samba le statut de contrôleur de domaine ?</title>
<para>
Le paramètre de &smb.conf; <smbconfoption name="security">domain</smbconfoption> ne permet pas réellement
à Samba de se comporter comme un contrôleur de domaine. Ce paramètre signifie que nous voulons que
Samba soit un membre du domaine. Vous pouvez vous reporter à <link linkend="samba-pdc">Samba as a PDC</link>
pour plus d'informations.
</para>
</sect2>
<sect2>
<title>Qu'est ce qui permet à Samba d'être membre du domaine ?</title>
<para>
Devinez ! Beaucoup d'autres ont trouvé. Mais quoi que vous fassiez, ne pensez pas que
<smbconfoption name="security">user</smbconfoption> permet à Samba d'agir en tant que membre du domaine.
Vous pouvez lire le manuel du fabricant avant l'échéance de la garantie. Vous pouvez vous reporter au
<link linkend="domain-member">Domain Membership</link> pour plus d'informations.
</para>
</sect2>
<sect2>
<title>Pertes répétées de la connexion au serveur de mots de passe</title>
<para><quote>
Pourquoi server_validate() préfère-t-il abandonner plutôt que de rétablir sa connexion au serveur de
mots de passe ? Bien que je ne sois pas un expert du protocole SMB, peut-être que le processus
du serveur de cluster transmet à son client la clé de session qu'il reçoit du serveur de mots de passe,
ce qui signifie que le hachage du mot de passe soumis par le client ne fonctionnerait pas pour une
connexion ultérieure dont la clé de session serait différente. Donc server_validate() n'a pas d'autres choix
que d'abandonner.
</quote></para>
<para>
En effet. C'est pourquoi le mode <smbconfoption name="security">server</smbconfoption> est au mieux une
vilaine bidouille. Veuillez utiliser le mode <smbconfoption name="security">domain</smbconfoption> ; le
mode <smbconfoption name="security">server</smbconfoption> sappelle également authentification
d'intercommunication.
</para>
</sect2>
<sect2>
<title>Le serveur autonome est converti en contrôleur de domaine &smbmdash;, maintenant que les comptes utilisateurs ne fonctionnent pas</title>
<para><quote>
Lorsque j'essaie de me connecter au DOMAINE, le relevé dactivités [event log] indique <emphasis>identités DOMAINE/noms
d'utilisateur essayés; identités DOMAINE/noms d'utilisateur effectives [tried credentials DOMAIN/username; effective credentials SERVER/username]</emphasis>.
</quote></para>
<para>
Généralement, cela est dû au fait qu'un compte utilisateur ou machine, créé avant le serveur Samba, est configuré
pour être un contrôleur de domaine. Les comptes créés avant que le serveur ne devienne un contrôleur de domaine seront
des comptes <emphasis>locaux</emphasis> et seront authentifiés de la même manière qu'un membre du domaine
SERVEUR, tout comme les comptes d'utilisateurs locaux dans Windows 2000 et ultérieur. Les comptes créés après
que le serveur Samba ne soit devenu un contrôleur de domaine seront des comptes <emphasis>de domaine</emphasis> et
seront authentifiés en tant que membre du domaine DOMAINE.
</para>
<para>
Cela peut être vérifié à l'aide de la commande <command>pdbedit -L -v nom_utilisateur</command>. Si la
réponse est DOMAIN, le compte est un compte de domaine, et si la réponse est SERVER, le compte est
un compte local.
</para>
<para>
Le moyen le plus simple pour résoudre ce problème consiste à supprimer et recréer le compte ; cela peut toutefois
poser des problèmes avec les profils utilisateurs existants. On peut aussi utiliser
<command>pdbedit -u nom_utilisateur -I DOMAIN</command>. Il peut également être nécessaire de changer le
User SID [Security Identifier] et le Primary Group SID afin qu'ils correspondent au domaine.
</para>
</sect2>
</sect1>
</chapter>
