À la découverte de Samba 4

1. Introduction

La suite de logiciels Samba est une ré-implémentation en logiciels libres des protocoles réseau clients et serveurs de Microsoft. La notion de liberté est particulièrement chère aux développeurs du projet, car il a été le premier projet d'envergure à adopter cette licence en passant Samba 3.2 sous GPL v3 dès 2007. Jusqu'ici, Samba 3 était capable de couvrir l'ensemble des fonctionnalités d'un réseau de type NT4 avec un certain nombre d'améliorations, comme la possibilité d'utiliser OpenLDAP comme backend de stockage ou encore un fonctionnement en cluster, bien que ces fonctionnalités soient relativement complexes à mettre en œuvre. Samba 3 gère notamment l'authentification en mode serveur maître/esclave (PDC/BDC pour Primary Domain Controler et Backup Domain Controler) et la fourniture des services de partage de fichiers et d'impression.

La compatibilité avec l'Active Directory de Microsoft est cependant limitée à la possibilité de joindre un domaine - au sens domaine de sécurité - et il devenait de plus en plus pressant de rattraper le retard accumulé. En effet, Active Directory est sorti en 2000, Samba 4 a été démarré en 2003 et bien que la version finale commence à pointer le bout de son nez, il aura fallu presque dix ans pour achever le travail titanesque que représente la ré-implémentation de tous les protocoles en jeu.

2. Qu'est-ce que l'Active Directory ?

L'Active Directory consiste en une intégration particulièrement poussée d'un certain nombre de protocoles plus ou moins standardisés dans le but de fournir des services d'authentification, de configuration et d'administration (déploiement de logiciels et de configuration) centralisés. Fonctionnellement, c'est une évolution de ce qu'il était déjà possible de faire auparavant, car les principaux objets stockés dans l'Active Directory sont des utilisateurs, des groupes et des ordinateurs. Techniquement, l'évolution apportée par la migration vers de nouveaux protocoles, permet de partitionner les ressources de manière sécurisée, logique, le tout avec un passage à l'échelle plus important, car stocké dans une base de données répliquée, la NTDS pour NT Directory Services.

2.1 Notion de domaine et de contrôleur de domaine

Chaque serveur hébergeant l'Active Directory ou une partition de celui-ci est appelé un contrôleur de domaine ou DC. Le nom de domaine DNS est par défaut utilisé pour le nommage du domaine Active Directory. Par exemple, si votre domaine DNS interne est reseau.local, alors l'arborescence LDAP de l'Active Directory sera DC=reseau,DC=local. Tout comme le DNS, il est possible de créer un ou plusieurs domaine(s) et sous-domaine(s) au sein de l'AD. L'ensemble des domaines et sous-domaines regroupés au sein d'une même forêt partagent le même schéma Active Directory (et donc LDAP), ainsi que des relations d'approbation entre les domaines. Par défaut, la création d'un domaine ou d'un sous-domaine entraîne la création d'une relation d'approbation d'authentification transitive et bidirectionnelle.

La fonctionnalité « Catalogue Global » au sein d'un contrôleur de domaine permet à celui-ci de contenir une vue partielle des objets des autres domaines, afin de permettre la recherche d'objets situés dans d'autres domaines plus rapidement sans nécessiter une réplication complète du contenu des différents domaines. Contrairement à un réseau NT4/Samba3, chaque contrôleur de domaine est un contrôleur de domaine maître, il n'y a donc plus de notion de contrôleur de domaine secondaire. A noter qu'avec Windows 2008 Server, Microsoft a introduit la notion de contrôleur de domaine en lecture seule. Il assure l'ensemble des fonctions permises par un contrôleur de domaine, à l'exception du fait qu'il est exclu de la réplication multi-maître et ne contient, comme son nom l'indique, qu'une copie en lecture du domaine. Ce type de contrôleur de domaine est en cours de prise en charge par l'équipe Samba.

Cependant, afin d'assurer l'unicité de certaines informations au sein du domaine ou de la forêt, certaines fonctionnalités sont uniques :

• Le rôle d'émulateur de Contrôleur de Domaine Principal, unique au sein d'un domaine, assure la compatibilité descendante pour l'authentification de type NT4.
• Le rôle Maître d'IDentifiants Relatifs, unique au sein d'un domaine, assure l'unicité des identifiants alloués aux autres contrôleurs de domaine (l'équivalent des UID/GID Unix). « Relatif » vient du fait que chaque objet est identifié par un identifiant unique (le SID), qui est la concaténation de l'identifiant de domaine et du RID de l'objet.
• Le rôle Maître d'Infrastructure, assure la consistance des SID/GUID au sein des objets du domaine. En pratique, il gère surtout la consistance de la résolution de nom des objets dans les groupes de l'AD et le déplacement des objets entre domaines.
• Le rôle Maître de Schéma, unique au sein d'une forêt. Gère la consistance et la réplication du schéma au sein de la forêt.
• Le rôle Maître de Nommage de Domaine, gère l'unicité des noms de domaines AD lors de l'ajout ou la suppression de ceux-ci.

2.2 Les types d'objets principaux

Les objets de l'Active Directory sont stockés dans un annuaire compatible LDAP. Il est donc interrogeable naturellement via les ports LDAP (389/TCP), LDAPS (636/TCP), ainsi qu'un port spécial, le port catalogue global (3268/TCP). Ce port permet de requêter en LDAP un contrôleur de domaine pour des objets se situant sur l'ensemble de la forêt. L'Active Directory ayant pour but premier la gestion de l'authentification, des autorisations et du contrôle d'accès, les types d'objets principaux sont donc tout à fait classiques dans ce type de configuration. On va donc retrouver :

• Les unités d'organisation, qui sont des conteneurs permettant de hiérarchiser les autres objets que l'on va retrouver. Elles sont utilisées pour classer structurellement les objets en fonction de leur rôle au sein d'une organisation (services, sites, etc.), soit pour affecter des droits. Bien entendu, ces deux rôles principaux ne sont pas mutuellement exclusifs.
• Les comptes utilisateurs.
• Les comptes d'ordinateur, permettant tout comme au niveau utilisateur d'auditer et d'authentifier l'accès aux ressources du domaine au niveau ordinateur.
• Les groupes. Il existe trois étendues de groupes : locale, globale et universelle, permettant d'affecter des autorisations respectivement pour uniquement le domaine local, tout domaine ou sous-domaine, ou toute la forêt. Deux types de groupes existent, les groupes de sécurité pour l'affectation d'autorisations et les groupes de distribution, qui servent surtout pour les applications de messagerie. Notez que contrairement aux groupes POSIX, l'Active Directory prend en charge les groupes incluant d'autres groupes.

3. Mise en place d'un domaine sous Samba 4

La maquette utilisée pour cette mise en place se base sur une Debian testing. Ce choix est voulu pour simplifier cet article. Le DNS est un élément clé d'une architecture Active Directory. Les clients notamment recherchent les contrôleurs de domaine via des requêtes DNS de type srv, afin de localiser un contrôleur de domaine et un certain nombre de mises à jour DNS dynamiques se font via Kerberos. Or, l'équipe Samba a remonté un certain nombre de patchs à l'équipe des développeurs Bind pour une meilleure prise en charge de cette fonctionnalité, qui nécessite une version de Bind plus récente que celle de la Debian stable. Afin de rester concentré sur la partie Samba, je n'ai préféré pas alourdir la mise en place du contrôleur de domaine par la compilation de Bind en version 9.8 au minimum.

3.1 Préparation du serveur

Quelques paquets seront nécessaires, soit à la compilation de Samba, soit à son bon fonctionnement. On peut tous les installer en une fois de cette façon :

Ensuite, le système de fichiers et le montage de vos partitions doit prendre en charge les ACL et les attributs étendus. Il vous faudra donc modifier le fichier /etc/fstab en conséquence. Exemple :

Pour éviter de redémarrer le serveur pour les partitions actives, il est possible de les remonter avec les options adéquates de cette façon :

Enfin, le protocole d'authentification par défaut de l'Active Directory étant Kerberos v5, il est important que les horloges soient à l'heure. Nous avons donc installé le serveur NTPD lors des pré-requis. Il faut donc indiquer le serveur NTP source et le firewall du réseau devra autoriser les requêtes NTP vers l'extérieur. Cela revient à définir le paramètre serveur du fichier /etc/ntpd.conf. Ce paramètre peut être multivalué. Je vous recommande d'utiliser fr.pool.ntp.org afin d'avoir une liste de serveurs sources fiables et disponibles.

Petite note supplémentaire, en cas d'utilisation d'une autre distribution, il se peut que Avahi et son mécanisme de résolution mdns soit prioritaire dans le mécanisme de résolution de noms et que si, comme moi, vous utilisez un nom de domaine DNS avec .local comme suffixe, il faudra paramétrer le fichier /etc/nsswitch.confde la sorte :

3.2 Compilation et installation

Cet article se base sur la dernière version bêta lors de sa rédaction, c'est-à-dire la bêta 5. La compilation du logiciel revient à faire un simple ./configure && make && make install habituel. Une seule dépendance est requise, ldb qui est une base de données avec une API proche de l'API LDAP et qui sert de backend de stockage à Samba. Je vous invite également, pour plus de commodité, à ajouter le chemin vers les binaires Samba au PATH de votre shell. Je supposerai d'ailleurs que c'est le cas pour la suite, afin de simplifier les commandes.

3.3 Création du domaine

La commande provision est l'équivalent de la commande dcpromo.exe sur un DC Windows Server. Elle se charge de générer le domaine avec les comptes par défaut et les fichiers de configuration Bind, Kerberos, etc., correspondant au nom retenu pour le domaine. Par convention, j'ai créé un domaine avec un TLD .local. Le provisionning du domaine vous demandera le mot de passe du compte administrateur (dénommé « administrator ») et devra répondre à des exigences de complexité (chiffres, majuscules, minuscules et signes de ponctuation), sans quoi vous serez honoré d'une belle exception Python.

3.4 Paramétrage du serveur DNS

Le stockage des données de la zone DNS domain.local étant réalisé par Samba, la configuration de Bind est relativement simplifiée.

Dans un premier temps, on définit le stockage des zones devant passer par le plugin Bind-dlz (Dynamically Loadable Zones) à charger via le fichier /etc/bind/named.conf.local :

Puis, dans le fichier /etc/bind/named.conf.options, on indique le chemin vers la keytab. Une keytab est une clé Kerberos cryptée et stockée sur disque, permettant dans ce cas précis à Bind de s'authentifier sur le KDC de façon transparente, sans nécessiter d'entrer un mot de passe. Ce point est nécessaire, car la plupart des mises à jour dynamiques des zones passent par TSIG-GSSAPI.

Cette clé devra bien entendu être uniquement accessible par Bind, un chown root:bind /usr/local/samba/private/dns.keytab, suivi d'un chmod 0640 s'impose donc. Pensez à redémarrer le service bind pour que ces changements soient pris en compte.

Notez qu'un serveur DNS, dont la vocation n'est bien entendu pas de concurrencer Bind, est en développement par l'équipe Samba. La motivation est bien expliquée par le créateur de Samba, Andrew Trdigell, dans un post sur son blog qui va au-delà du souci de simplification de l'installation. Le but est de permettre de répondre facilement aux quatre méthodes de mise à jour du DNS qui existent sur un réseau Active Directory, soit les mises à jour DDNS signées via TSIG (Kerberos), les mises à jour faites par les contrôleurs de domaines en lecture seule via les MSRPC, les réplications de l'AD inter-contrôleurs de domaine via le DRS et enfin, les modifications réalisées en LDAP, backend de stockage par défaut.

Pour les plus aventureux qui souhaiteraient tester, voici ce qu'il faut indiquer dans le fichier /usr/local/samba/etc/smb.confavant de relancer Samba :

3.5 Démarrage et arrêt

Pour démarrer l'ensemble des processus, rien de plus simple, il suffit de lancer la commande samba. Pour l'arrêter, un killall samba suffit. Je laisse donc au lecteur la rédaction d'un script d'init qui sera donc d'une simplicité déconcertante, Debian fournissant en outre le modèle de script/etc/init.d/skeleton.

3.6 Intégrer un poste au domaine

Pour intégrer un poste Windows à un domaine AD, il faut obligatoirement une version professionnelle, les versions familiales n'étant pas prises en charge. Que ce soit en IP fixe ou en DHCP, le poste client devra parvenir à résoudre votre zone DNS. Enfin, et ceci est une contrainte inhérente au protocole Kerberos, il ne doit pas y avoir un décalage d'horloge de plus de cinq minutes entre le KDC et le client. Il ne reste plus qu'à intégrer les postes comme suit (ou bien graphiquement si ça vous chante) :

3.7 Administration graphique

Le projet Samba tentant de reproduire au plus proche le comportement des différents composants de l'Active Directory, les outils graphiques édités par Microsoft sont parfaitement fonctionnels et compatibles sur une infrastructure Samba. Il est donc également possible de gérer les stratégies de groupes depuis la console MMC appropriée si elle est installée sur un poste Windows. La connexion au domaine devra être effectuée avec un compte disposant des droits admin du domaine. Sur un poste sous Windows XP, il faudra donc installer le kit de ressources techniques pour Windows 2003 Server SP1, ainsi que l'adminpak. Les postes sous Windows Vista ou Windows Seven, quant à eux, nécessiteront les Remote Server Administration Tools.

3.8 Un second contrôleur de domaine

Comme je le disais plus haut, un domaine Active Directory n'est pas limité à un contrôleur de domaine, contrairement aux domaines Samba3/NT4. Autant donc profiter de cette possibilité pour assurer une redondance du système d'authentification. L'installation du second serveur se déroule de façon similaire à celle du premier. Je vous recommande donc également une Debian testing, qui fournit les dépendances citées plus haut. La procédure de compilation et d'installation est strictement similaire lorsque l'on ajoute un contrôleur de domaine à un domaine existant. Cependant, il ne faudra pas lancer la commande provision, mais simplement démarrer samba. Comme le serveur DNS est installé dans un second temps, il faudra que le second serveur puisse résoudre votre domaine AD via le DNS, en principe, en faisant pointer le fichier /etc/resolv.confvers le premier contrôleur de domaine.

On peut donc désormais intégrer le domaine en tant que DC additionnel :

Il restera donc ensuite à réaliser le paramétrage de Bind de façon tout à fait similaire au premier DC et adapter la résolution du second serveur afin qu'il s'interroge lui-même pour résoudre les enregistrements du domaine. Veuillez noter un point cependant, le partage sysvol, qui contient les stratégies de groupe et les scripts de connexion appliqués sur les postes ou les utilisateurs du domaine, est répliqué via un protocole, le DRS, dont l'implémentation est encore jeune. Il faudra donc penser à mettre en place une tâche cron régulière qui réalisera un rsync régulier de ce partage, après avoir préalablement mis en place un échange de clés SSH :

3.9 Ajout d'un serveur membre

Je ne reviendrai pas sur les étapes de préparation du serveur ni sur l'installation de Samba 4, qui sont inchangées par rapport aux deux serveurs précédents. Cependant, dans le but de cloisonner les services réseau, il peut être utile de déléguer la gestion de certains services, comme le partage de fichiers, à un serveur dédié :

A noter que depuis la bêta 4, il est permis de proprement promouvoir un serveur membre en contrôleur de domaine sans perdre le SID du compte d'ordinateur de cette façon :

Les services de partage de fichiers sont désormais gérés par un build des démons Samba 3 (nmpd et smbd) intégré à Samba 4. La littérature fleurit assez sur le sujet sur le net, de fait je ne m'y attarderai pas afin de rester ciblé sur les réelles nouveautés de Samba 4.

4. Jouons un peu avec la ligne de commandes

4.1 samba-tool, le couteau suisse de l'administrateur

Comme tout bon programme Unix, Samba 4 est entièrement administrable en ligne de commandes. La commande samba-tool permet de réaliser l'ensemble des tâches courantes d'administration d'un réseau Microsoft Windows. La syntaxe de la commande est très bien détaillée dans l'aide contextuelle. Les paramètres additionnels sont documentés en indiquant le paramètre -H à la sous-commande désirée sans indiquer de paramètre.

Prenons connaissance du domaine que nous avons mis en place :

Modifions la stratégie de sécurité de mot de passe pour, par exemple, exiger 8 caractères (contre 7), mais n'exiger qu'une modification de mot de passe annuelle (contre tous les 42 jours par défaut) :

Créons un groupe et ajoutons deux nouveaux utilisateurs à ce groupe :

Comme vous le voyez, il est extrêmement facile d'automatiser l'administration de son contrôleur de domaine via la ligne de commandes. J'invite le lecteur à lancer la commande samba-tool sans paramètre pour prendre connaissance de l'étendue des possibilités offertes (gestion des utilisateurs, groupes, sites, de la zone DNS, de la réplication, etc.).

4.2 Sauvegarder Samba

Tout bon administrateur système se pose bien évidemment la question de la sauvegarde. La sauvegarde des données étant acquise, enfin je l'espère, voyons comment sauvegarder la partie système. La mise en place d'un second contrôleur de domaine, comme nous l'avons fait, permet déjà de sauvegarder l'Active Directory en tant que tel. En cas de crash du système ou de corruption des bases LDB de Samba 4, il est donc possible de remonter l'AD sur le serveur. Il reste néanmoins plus simple dans certains cas de ne réaliser qu'une restauration de ce dont on a besoin. Dans les sources de Samba 4, dans le répertoire source4/scripting/bin/ est présent un script déjà réalisé nommé samba_backup. J'invite par ailleurs le lecteur à être curieux et à jeter un œil aux différents scripts présents dans ce répertoire. Par défaut, le script sauvegarde dans le répertoire /usr/local/backups et conserve un historique de 90 jours. Le script s'utilise de cette façon :

Il restera donc à planifier la tâche via l'habituelle crontab et à externaliser les sauvegardes sur un autre support.

Conclusion

Notre escapade à la découverte du fonctionnement de l'Active Directory et sa mise en place au travers de Samba 4 s'arrête là. Bien qu'il y ait encore beaucoup à dire, nous avons pu voir dans quelle mesure le projet avait avancé de manière impressionnante et avoir un premier aperçu de sa mise en place. L'équipe Samba n'est pas encore prête à lancer une mouture finale du logiciel, car des écueils subsistent encore çà et là, mais après tout, certains admins téméraires ont déjà basculé en production des serveurs sur Samba 4.