14.3. Types de serveurs Samba et fichier smb.conf
La configuration de Samba est une opération assez simple. Toutes les modifications apportées à Samba ont lieu dans le fichier de configuration /etc/samba/smb.conf. Bien que le fichier par défaut smb.conf soit bien documenté, il n'aborde pas des sujets complexes tels que LDAP, Active Directory et les nombreuses implémentations de contrôleurs de domaines.
Les sections suivantes décrivent les différentes manières selon lesquelles un serveur Samba peut être configuré. Gardez bien à l'esprit vos besoins et les modifications devant être apportées au fichier smb.conf pour effectuer une configuration réussie.
14.3.1. Serveur autonome
Un serveur autonome peut être le serveur d'un groupe de travail ou un membre de l'environnement d'un groupe de travail. Un serveur autonome n'est pas un contrôleur de domaine et ne joue aucun rôle dans un domaine. Les exemples suivants illustrent plusieurs configurations de sécurité anonyme au niveau du partage et un exemple de configuration de sécurité au niveau de l'utilisateur. Pour obtenir de plus amples informations sur les modes de sécurité au niveau du partage ou au niveau de l'utilisateur, reportez-vous à la Section 14.4.
14.3.1.1. Anonyme en lecture-seule
Le fichier smb.conf suivant montre un extrait du fichier de configuration nécessaire pour permettre l'implémentation d'un partage de fichiers anonyme en lecture-seule. Le paramètre security = share rend un partage anonyme. Notez bien que les niveaux de sécurité pour un seul serveur Samba ne peuvent pas être mélangé. La directive de sécurité (security) est un paramètre global pour Samba qui se trouve dans la section de configuration [global] du fichier smb.conf.
[global] workgroup = DOCS netbios name = DOCS_SRV security = share [data] comment = Documentation Samba Server path = /export read only = Yes guest only = Yes |
14.3.1.2. Anonyme en lecture/écriture
Le fichier smb.conf suivant montre un extrait du fichier de configuration nécessaire pour permettre l'implémentation d'un partage de fichiers anonyme en lecture/écriture. Pour permettre le partage anonyme de fichiers en lecture/écriture, donnez à la directive read only (lecture-seule) la valeur no. Les directives force user et force group sont également ajoutées pour appliquer les règles de propriété à tout fichier ajouté et spécifié comme appartenant au partage.
 | Remarque |
|---|---|
Bien qu'il soit possible d'avoir un serveur anonyme en lecture/écriture, un tel choix n'est pas recommandé. Tous fichiers placés dans l'espace de partage, indépendemment de l'utilisateur, sont assignés à la combinaison utilisateur/groupe telle qu'elle est spécifiée dans le fichier smb.conf par un utilisateur (force user) et un groupe (force group) génériques. |
[global] workgroup = DOCS netbios name = DOCS_SRV security = share [data] comment = Data path = /export force user = docsbot force group = users read only = No guest ok = Yes |
14.3.1.3. Serveur d'impression anonyme
Le fichier smb.conf suivant montre un extrait du fichier de configuration nécessaire pour implémenter un serveur d'impression anonyme. Comme nous l'avons montré, le fait de donner à browsable la valeur no, n'inclut pas l'imprimante dans la liste Voisinnage réseau de Windows. Bien que n'apparaissant pas lors de la navigation, la configuration explicite de l'imprimante est possible. Grâce à la connexion à DOCS_SRV en utilisant NetBIOS, le client peut avoir accès à l'imprimante s'il fait également partie du groupe de travail DOCS. On suppose également que le client a installé le pilote d'impression local approprié puisque la directive use client driver a la valeur Yes. Dans ce cas, le serveur Samba n'a aucune responsabilité quant au partage de pilotes d'impression avec le client.
[global] workgroup = DOCS netbios name = DOCS_SRV security = share printcap name = cups disable spools= Yes show add printer wizard = No printing = cups [printers] comment = All Printers path = /var/spool/samba guest ok = Yes printable = Yes use client driver = Yes browseable = Yes |
14.3.1.4. Fichier en lecture/écriture et serveur d'impression sécurisés
Le fichier smb.conf suivant montre un extrait du fichier de configuration nécessaire pour implémenter un serveur d'impression sécurisé en lecture/écriture. Le fait de donner à la directive security la valeur user force Samba à authentifier les connexions client. Remarquez bien que le partage [homes] n'a pas de directive force user ou force group, contrairement au partage [public]. Le partage [homes] utilise les informations relatives à l'utilisateur authentifié pour la création de tout fichier, contrairement aux directives force user et force group dans [public].
[global] workgroup = DOCS netbios name = DOCS_SRV security = user printcap name = cups disable spools = Yes show add printer wizard = No printing = cups [homes] comment = Home Directories valid users = %S read only = No browseable = No [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes [printers] comment = All Printers path = /var/spool/samba printer admin = john, ed, @admins create mask = 0600 guest ok = Yes printable = Yes use client driver = Yes browseable = Yes |
14.3.2. Serveur membre d'un domaine
Un membre d'un domaine, bien qu'étant semblable à un serveur autonome, est connecté à un contrôleur de domaine (soit Windows, soit Samba) et soumis aux règles de sécurité de ce domaine. Le serveur du département d'une entreprise exécutant Samba et ayant un compte machine sur contrôleur de domaine principal (ou PDC, Primary Domain Controller) est un exemple de serveur membre d'un domaine. Tous les clients du département continuent à s'authentifier auprès du PDC et les profiles du bureau ainsi que les fichiers des politiques réseau sont inclus. La différence est que le serveur du département a la capacité de contrôler les partages au niveau de l'impression et du réseau.
14.3.2.1. Serveur membre du domaine Active Directory
Le fichier smb.conf suivant montre un extrait du fichier de configuration nécessaire pour implémenter un serveur membre du domaine Active Directory. Dans notre exemple, Samba non seulement authentifie les utilisateurs pour les services exécutés localement, mais il est également un client de Active Directory. Assurez-vous que le paramètre de votre zone (realm) kerberos apparaît bien tout en lettres majuscules (par exemple, realm = EXAMPLE.COM). Étant donné que Windows 2000/2003 a besoin de Kerberos pour l'authentification de Active Directory, la directive realm est nécessaire. Si Active Directory et Kerberos sont exécutés sur des serveurs différents, il se peut que la directive password server soit nécessaire pour permettre la distinction entre les deux.
[global] realm = EXAMPLE.COM security = ADS encrypt passwords = yes # Optional. Use only if Samba cannot determine the Kerberos server automatically. password server = kerberos.example.com |
Pour qu'un serveur membre fasse partie d'un domaine Active Directory, il est nécessaire d'effectuer les étapes suivantes :
Configuration du fichier smb.conf sur le serveur membre
Configuration de Kerberos, y compris le fichier /etc/krb5.conf, sur le serveur membre
Création du compte machine sur le serveur du domaine Active Directory
Association du serveur membre au domaine Active Directory
Pour créer le compte machine et faire partie de Active Directory de Windows 2000/2003, Kerberos doit tout d'abord être initialisé pour le serveur membre souhaitant faire partie du domaine Active Directory. Pour créer un ticket administratif pour Kerberos, tapez la commande suivante en étant connecté en tant que super-utilisateur (ou root) sur le serveur membre :
root# kinit administrator@EXAMPLE.COM |
La commande kinit est un script d'initialisation de Kerberos qui référence le compte administrateur de Active Directory et la zone Kerberos (realm). Étant donné que Active Directory a besoin de tickets Kerberos, kinit obtient et met en cache un ticket d'émission de tickets (ou TGT, ticket-granting ticket) Kerberos pour l'authentification client/serveur. Pour obtenir de plus amples informations sur Kerberos, le fichier /etc/krb5.conf et la commande kinit, reportez-vous au Chapitre 19.
Pour faire partie d'un serveur Active Directory (windows1.example.com), tapez la commande suivante en étant connecté en tant que super-utilisateur (ou root) sur le serveur membre :
root# net ads join -S windows1.example.com -U administrator%password |
Étant donné que la machine windows1 a été trouvée automatiquement dans la zone Kerberos appropriée (la commande kinit a abouti), la commande net établit la connexion avec le serveur Active Directory utilisant le compte administrateur et le mot de passe requis. Ainsi, le compte machine est créé sur le serveur Active Directory et les permissions sont accordées pour que le membre du domaine Samba puisse faire partie du domaine.
| Remarque |
|---|---|
Étant donné que security = ads est utilisé, et non pas security = user, il n'est pas nécessaire d'utiliser un mot de passe secondaire (backend) tel que smbpasswd. Des clients plus anciens ne prenant pas en charge security = ads sont authentifiés comme si security = domain avait été configuré. Ce changement ne touche pas les fonctionnalités et autorise des utilisateurs locaux qui nétaient pas inclus auparavant dans le domaine. |
14.3.2.2. Serveur membre d'un domaine basé sur Windows NT4
Le fichier smb.conf suivant montre un extrait du fichier de configuration nécessaire pour implémenter un serveur membre d'un domaine basé sur Windows NT4. Devenir un serveur membre d'un domaine basé sur Windows NT4 revient en fait comme à se connecter à un Active Directory. La différence essentielle réside dans le fait que les domaines basés sur NT4 n'utilisent pas Kerberos dans leur méthode d'authentification, ce qui simplifie le fichier smb.conf. Dans ce cas, le serveur membre de Samba joue le rôle d'une machine intermédiare vers le serveur de domaine basé sur NT4.
[global] workgroup = DOCS netbios name = DOCS_SRV security = domain [homes] comment = Home Directories valid users = %S read only = No browseable = No [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes |
Le fait d'avoir Samba comme un serveur membre d'un domaine peut être utile dans de nombreuses situations. Dans certains cas le serveur Samba peut être utilisé à d'autres fins que le partage de fichiers et d'impression. Il peut s'avérer utile de transformer Samba en serveur membre d'un domaine, dans des situations où des applications exclusivement Linux doivent être utilisées dans l'environnement du domaine. Il est utile pour les administrateurs d'effectuer un suivi de toutes les machines faisant partie du domaine, même s'il n'est pas basé sur Windows. Dans le cas où le matériel du serveur basé sur Windows deviendrait obsolète, il est relativement facile de modifier le fichier smb.conf pour convertir le serveur en PDC basé sur Samba. Si les serveurs basés sur Windows NT sont mis à niveau vers Windows 2000/2003, le fichier smb.conf est facilement modifiable pour inclure les changements d'infrastructure.dans Active Directory, si nécessaire.
 | Important | |
|---|---|---|
Après avoir configuré le fichier smb.conf, intégrez le domaine avant de démarrer Samba en tapant la commande suivante en étant connecté en tant que super-utilisateur :
|
Notez bien que l'option -S, qui précise le nom d'hôte du serveur de domaine, ne doit pas obligatoirement être spécifiée dans la commande net rpc join. Samba utilise le nom d'hôte spécifié par la directive workgroup dans le fichier smb.conf plutôt que de demander à ce qu'il soit spécifié explicitement.
14.3.3. Contrôleur de domaine
Un contrôleur de domaine dans Windows NT joue essentiellement le même rôle qu'un service d'information réseau (ou NIS, Network Information Service) dans un environnement Linux. Les contrôleurs de domaine et les serveurs NIS hébergent tous les deux des bases de données d'informations utilisateurs/groupes sur les hôtes, ainsi que sur les services apparentés. Les contrôleurs de domaine sont principalement utilisés pour la sécurité, y compris l'authentification des utilisateurs accédant aux ressources du domaine. Le service qui maintient l'intégrité de la base de données relative aux utilisateurs/groupes s'appelle gestionnaire des comptes de sécurité (ou SAM, Security Account Manager). La base de données de SAM est stockée de manière différente dans des systèmes Windows et Linux basés sur Samba, si bien que la réplication de SAM ne peut se faire et que les plates-formes ne peuvent pas être mélangées dans un environnement PDC/BDC.
Dans un environnement Samba, il ne peut y avoir qu'un seul PDC et aucun ou plusieurs BDC.
| Important |
|---|---|
Samba ne peut pas exister dans l'environnement d'un contrôleur de domaine mélangé Samba/Windows (Samba ne peut pas être un BDC d'un PDC Windows ou vice versa). Autrement, les PDC et BDC de Samba peuvent coexister. |
14.3.3.1. Contrôleur de domaine principal (PDC, Primary Domain Controller) utilisant tdbsam
L'implémentation la plus simple et la plus courante d'un PDC Samba utilise le backend de la base de données de mot de passe nommé tdbsam. Conçu dans l'intention de remplacer le backend smbpasswd désormais un peu passé, tdbsam est doté de nombreuses améliorations qui sont examinées en revue de manière détaillée dans la Section 14.5. La directive passdb backend contrôle le backend spécifique devant être utilisé pour le PDC.
[global] workgroup = DOCS netbios name = DOCS_SRV passdb backend = tdbsam security = user add user script = /usr/sbin/useradd -m %u delete user script = /usr/sbin/userdel -r %u add group script = /usr/sbin/groupadd %g delete group script = /usr/sbin/groupdel %g add user to group script = /usr/sbin/usermod -G %g %u add machine script = \ /usr/sbin/useradd -s /bin/false -d /dev/null \ -g machines %u # The following specifies the default logon script # Per user logon scripts can be specified in the user # account using pdbedit logon script = logon.bat # This sets the default profile path. # Set per user paths with pdbedit logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U domain logons = Yes os level = 35 preferred master = Yes domain master = Yes idmap uid = 15000-20000 idmap gid = 15000-20000 [homes] comment = Home Directories valid users = %S read only = No browseable = No writable = Yes [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes [netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon/scripts admin users = ed, john, sam guest ok = No browseable = No writable = No # For profiles to work, create a user directory under the # path shown. mkdir -p /var/lib/samba/profiles/john [Profiles] comment = Roaming Profile Share path = /var/lib/samba/profiles read only = No browseable = No guest ok = Yes profile acls = Yes # Other resource shares ... ... |
| Remarque |
|---|---|
Si vous avez besoin de plus d'un contrôleur de domaine ou avez plus de 250 utilisateurs, n'utilisez pas un backend d'authentification tdbsam. Dans ces cas particuliers, il est plutôt recommandé d'utiliser LDAP. |
14.3.3.2. Contrôleur de domaine principal (PDC, Primary Domain Controller) utilisant LDAP
L'implémentation la plus performante et la plus flexible d'un PDC Samba se manifeste par sa capacité à avoir un backend pour les mots de passe avec LDAP, qui est est très modulable. Les serveurs de base de donnés LDAP peuvent être utilisés à des fins de redondance et de fail-over en raison de leur réplication sur le BDC Samba. Les groupes de PDC et BDC de LDAP dotés d'une capacité de répartition de charge (load balancing) sont parfaits pour un environnement d'entreprise. D'autre part, les configurations LDAP sont par essence complexes à configurer et à maintenir. Si SSL doit être incorporé à LDAP, le degré de complexité est aussitôt multiplié. Malgré tout, avec une planification précise et prudente, LDAP représente une solution idéale pour des environnements d'entreprise.
Prêtez attention à la directive passdb backend ainsi qu'aux spécifications de suffixe avec LDAP. Bien que la configuration de Samba pour LDAP soit relativement simple, l'installation de OpenLDAP elle n'est pas si simple. LDAP devrait être installé et configuré avant que toute configuration de Samba n'ait lieu. Remarquez également que Samba et LDAP ne doivent pas forcément être sur le même serveur pour pouvoir fonctionner. Il est d'ailleurs fortement recommandé de les séparer dans un environnement d'entreprise.
[global] workgroup = DOCS netbios name = DOCS_SRV passdb backend = ldapsam:ldap://ldap.example.com username map = /etc/samba/smbusers security = user add user script = /usr/sbin/useradd -m %u delete user script = /usr/sbin/userdel -r %u add group script = /usr/sbin/groupadd %g delete group script = /usr/sbin/groupdel %g add user to group script = /usr/sbin/usermod -G %g %u add machine script = \ /usr/sbin/useradd -s /bin/false -d /dev/null \ -g machines %u # The following specifies the default logon script # Per user logon scripts can be specified in the # user account using pdbedit logon script = scripts\logon.bat # This sets the default profile path. # Set per user paths with pdbedit logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U domain logons = Yes os level = 35 preferred master = Yes domain master = Yes ldap suffix = dc=example,dc=com ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Group ldap idmap suffix = ou=People ldap admin dn = cn=Manager ldap ssl = no ldap passwd sync = yes idmap uid = 15000-20000 idmap gid = 15000-20000 ... # Other resource shares ... ... |
| Remarque |
|---|---|
L'implémentation de LDAP dans ce fichier smb.conf suppose qu'un serveur LDAP opérationnel a été installé avec succès sur ldap.example.com. |
14.3.3.3. Contrôleur de domaine secondaire (BDC, Backup Domain Controller) utilisant LDAP
Un BDC est une partie intégrale de toute solution Samba/LDAP en entreprise. Les fichiers smb.conf existant entre le PDC et le BDC sont quasiment identiques, à l'exception de la directive domain master. Assurez-vous que la valeur du PDC est bien Yes et que celle du BDC est No. Si vous avez plusieurs BDC pour un PDC, la directive os level est utile pour définir la priorité d'élection du BDC. Plus la valeur est élevée, plus la priorité du serveur est élevée pour les connexions clients.
| Remarque |
|---|---|
Un BDC peut soit utiliser la base de données LDAP du PDC, soit avoir sa propre base de données LDAP. Cette exemple utilise la base de données LDAP du PDC comme on le voit dans la directive passdb backend. |
[global] workgroup = DOCS netbios name = DOCS_SRV2 passdb backend = ldapsam:ldap://ldap.example.com username map = /etc/samba/smbusers security = user add user script = /usr/sbin/useradd -m %u delete user script = /usr/sbin/userdel -r %u add group script = /usr/sbin/groupadd %g delete group script = /usr/sbin/groupdel %g add user to group script = /usr/sbin/usermod -G %g %u add machine script = \ /usr/sbin/useradd -s /bin/false -d /dev/null \ -g machines %u # The following specifies the default logon script # Per user logon scripts can be specified in the # user account using pdbedit logon script = scripts\logon.bat # This sets the default profile path. # Set per user paths with pdbedit logon path = \\%L\Profiles\%U logon drive = H: logon home = \\%L\%U domain logons = Yes os level = 35 preferred master = Yes domain master = No ldap suffix = dc=example,dc=com ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Group ldap idmap suffix = ou=People ldap admin dn = cn=Manager ldap ssl = no ldap passwd sync = yes idmap uid = 15000-20000 idmap gid = 15000-20000 ... # Other resource shares ... ... |