A la découverte de Samba 4 (Publié dans GNU/Linux France Magazine 153)

En gestation depuis environ une dizaine d’années auprès de ses développeurs, Samba4 vise à remplacer Samba3 qui lui assurait les fonctions d’un domaine de type NT4. Rentrons au cœur des réseaux Active Directory alors que la sortie d’une version se profile à l’horizon.

1. Introduction

La suite de logiciels Samba est une réimplémentation en logiciels libres des protocoles réseau client et serveur 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 oeuvre. Samba3 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 celle-ci est appelé un contrôleur de domaine ou DC. Le nom de domaine DNS est par défaut utilisée 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 sous domaine au sein de l’AD. L’ensemble des domaines et sous-domaine 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’objet 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 permiss 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, il assure la compatibilité descendante pour l’authentification de type NT4.
• Le rôle Maître d’IDentifiants Relatifs, unique au sein d’un domaine, il 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 Domain, 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, global 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 Samba4

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 :

apt-get -y install build-essential libacl1-dev libattr1-dev \
   libblkid-dev libgnutls-dev libreadline-dev python-dev \
   python-dnspython gdb pkg-config libpopt-dev libldap2-dev \
   bind9utils dnsutils libtool git xsltproc libpam0g-dev \
   attr acl psmisc bind9 ntp libtalloc2 libtalloc-dev

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 :

/dev/sda1	/               ext3    user_xattr,acl,errors=remount-ro 0       1

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 :

mount -o remount,rw,acl,user_xattr /

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 nom et que si comme moi vous utilisez un nom de domaine DNS avec .local comme suffixe, il faudra paramétrer le fichier /etc/nsswitch.conf de la sorte :

 hosts:  files dns

3.2 Compilation et installation

Cet article se base sur la dernière version beta lors de sa rédaction, c’est à dire la beta5. 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ée 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.

wget ftp://ftp.samba.org/pub/ldb/ldb-1.1.9.tar.gz
tar -zxvf ldb-1.1.9.tar.gz && cd ldb-1.1.6
./configure && make && make install

wget ftp://ftp.samba.org/pub/samba/samba4/samba-4.0.0beta5.tar.gz
tar -zxvf samba-4.0.0beta5.tar.gz && cd samba-4.0.0beta5
./configure && make && make install

echo "export PATH=$PATH:/usr/local/samba/bin/:/usr/local/samba/sbin/:" >> ~/.bashrc && source ~/.bashrc

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… correspondants 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énomé 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.

# provision 
Realm [DOMAIN.LOCAL]: 
 Domain [DOMAIN]: 
 Server Role (dc, member, standalone) [dc]: 
Administrator password: 
Retype password: 
Looking up IPv4 addresses
Looking up IPv6 addresses
No IPv6 address will be assigned
Setting up share.ldb
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Adding DomainDN: DC=domain,DC=local
Adding configuration container
Setting up sam.ldb schema
Setting up sam.ldb configuration data
Setting up display specifiers
Adding users container
Modifying users container
Adding computers container
Modifying computers container
Setting up sam.ldb data
Setting up well known security principals
Setting up sam.ldb users and groups
Setting up self join
Adding DNS accounts
Creating CN=MicrosoftDNS,CN=System,DC=domain,DC=local
Creating DomainDnsZones and ForestDnsZones partitions
Populating DomainDnsZones and ForestDnsZones partitions
See /usr/local/samba/private/named.conf for an example configuration include file for BIND
and /usr/local/samba/private/named.txt for further documentation required for secure DNS updates
Setting up sam.ldb rootDSE marking as synchronized
Fixing provision GUIDs
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf
Once the above files are installed, your Samba4 server will be ready to use
Server Role:           active directory domain controller
Hostname:              srv-dc1
NetBIOS Domain:        DOMAIN
DNS Domain:            domain.local
DOMAIN SID:            S-1-5-21-2813939429-2675192644-3843174914
A phpLDAPadmin configuration file suitable for administering the Samba 4 LDAP server has been created in /usr/local/samba/private/phpldapadmin-config.php.

3.4 Paramétrage du serveur DNS

Le stockage des données de la zone DNS domain.local étant réalisées 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 :

include "/usr/local/samba/private/named.conf";

Puis dans le fichier /etc/bind/named.conf.options, on indique le chemin vers 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.

options {
   [...]
   tkey-gssapi-keytab "/usr/local/samba/private/dns.keytab";
}

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 soucis de simplification de l’installation. Le but est de permettre de répondre facilement aux quatres méthodes de mises à 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.conf avant de relancer samba.

       server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc, dnsupdate, s3fs, dns
        allow dns updates = True
        dns forwarder = 8.8.8.8
        dns recursive queries = yes

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)

netdom /domain:domain.local /user:administrateur /password:secret MEMBER PC-JAMBON /joindomain

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 Admins 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, fournie des 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.conf vers le premier contrôleur de domaine.

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

root@srv-dc2:~# samba-tool domain join domain.local DC -Uadministrator@domain.local --realm=DOMAIN.LOCAL
Finding a writeable DC for domain 'domain.local'
Found DC srv-dc1.domain.local
Password for [administrator@domain.local]:
workgroup is DOMAIN
realm is domain.local
checking sAMAccountName
Adding CN=SRV-DC2,OU=Domain Controllers,DC=domain,DC=local
Adding CN=SRV-DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
Adding CN=NTDS Settings,CN=SRV-DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
Adding SPNs to CN=SRV-DC2,OU=Domain Controllers,DC=domain,DC=local
Setting account password for SRV-DC2$
Enabling account
Calling bare provision
No IPv6 address will be assigned
Provision OK for domain DN DC=domain,DC=local
Starting replication
Schema-DN[CN=Schema,CN=Configuration,DC=domain,DC=local] objects[402/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=domain,DC=local] objects[804/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=domain,DC=local] objects[1206/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=domain,DC=local] objects[1550/1550] linked_values[0/0]
Analyze and apply schema objects
Partition[CN=Configuration,DC=domain,DC=local] objects[402/1614] linked_values[0/0]
Partition[CN=Configuration,DC=domain,DC=local] objects[804/1614] linked_values[0/0]
Partition[CN=Configuration,DC=domain,DC=local] objects[1206/1614] linked_values[0/0]
Partition[CN=Configuration,DC=domain,DC=local] objects[1608/1614] linked_values[0/0]
Partition[CN=Configuration,DC=domain,DC=local] objects[1614/1614] linked_values[28/0]
Replicating critical objects from the base DN of the domain
Partition[DC=domain,DC=local] objects[98/98] linked_values[23/0]
Partition[DC=domain,DC=local] objects[307/209] linked_values[23/0]
Partition[DC=DomainDnsZones,DC=domain,DC=local] objects[40/40] linked_values[0/0]
Partition[DC=ForestDnsZones,DC=domain,DC=local] objects[18/18] linked_values[0/0]
Committing SAM database
Sending DsReplicateUpdateRefs for all the partitions
Setting isSynchronized and dsServiceName
Setting up secrets database
Joined domain DOMAIN (SID S-1-5-21-2813939429-2675192644-3843174914) as a DC

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 le 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 :

*/5 * * * * root rsync -azvp --delete /usr/local/samba/var/locks/sysvol root@srv-dc2:/usr/local/samba/var/locks/sysvol

3.9 Ajout d’un serveur membre

Je ne reviendrai pas sur les étapes de préparation du serveur ni sur l’installation de Samba4 qui est inchangé 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é.

root@srv-member:~# samba-tool domain join domain.local member -U administrator --realm=domain.local
Password for [WORKGROUP\administrator]:
Joined domain DOMAIN (S-1-5-21-2813939429-2675192644-3843174914)

A noter que depuis la beta4, 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 :

root@srv-member:~# samba-tool domain dcpromo domain.local DC -U administrator

Les services de partages de fichiers sont désormais gérés par un build des démons samba3 (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é de Samba 4.

4. Jouons un peu avec la ligne de commande

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

Comme tout bon programme Unix, Samba4 est entièrement administrable en ligne de commande. 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ètres.

Prenons connaissance du domaine que nous avons mis en place :

root@srv-dc1:~# samba-tool domain info 192.168.1.250
Forest           : domain.local
Domain           : domain.local
Netbios domain   : DOMAIN
DC name          : srv-dc1.domain.local
DC netbios name  : SRV-DC1
Server site      : Default-First-Site-Name
Client site      : Default-First-Site-Name
root@srv-dc1:~# samba-tool domain level show
Domain and forest function level for domain 'DC=domain,DC=local'

Forest function level: (Windows) 2003
Domain function level: (Windows) 2003
Lowest function level of a DC: (Windows) 2008 R2

root@srv-dc1:~# samba-tool fsmo show
InfrastructureMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
RidAllocationMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
DomainNamingMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
SchemaMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local3.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, fournie des 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.conf vers le premier contrôleur de domaine.
On peut donc désormais intégrer le domaine en tant que DC aditionnel :
root@srv-dc2:~# samba-tool domain join domain.local DC -Uadministrator@domain.local --realm=DOMAIN.LOCAL
Finding a writeable DC for domain 'domain.local'
Found DC srv-dc1.domain.local
Password for [administrator@domain.local]:
workgroup is DOMAIN
realm is domain.local
checking sAMAccountName
Adding CN=SRV-DC2,OU=Domain Controllers,DC=domain,DC=local
Adding CN=SRV-DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
Adding CN=NTDS Settings,CN=SRV-DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
Adding SPNs to CN=SRV-DC2,OU=Domain Controllers,DC=domain,DC=local
Setting account password for SRV-DC2$
Enabling account
Calling bare provision
No IPv6 address will be assigned
Provision OK for domain DN DC=domain,DC=local
Starting replication
Schema-DN[CN=Schema,CN=Configuration,DC=domain,DC=local] objects[402/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=domain,DC=local] objects[804/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=domain,DC=local] objects[1206/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=domain,DC=local] objects[1550/1550] linked_values[0/0]
Analyze and apply schema objects
Partition[CN=Configuration,DC=domain,DC=local] objects[402/1614] linked_values[0/0]
Partition[CN=Configuration,DC=domain,DC=local] objects[804/1614] linked_values[0/0]
Partition[CN=Configuration,DC=domain,DC=local] objects[1206/1614] linked_values[0/0]
Partition[CN=Configuration,DC=domain,DC=local] objects[1608/1614] linked_values[0/0]
Partition[CN=Configuration,DC=domain,DC=local] objects[1614/1614] linked_values[28/0]
Replicating critical objects from the base DN of the domain
Partition[DC=domain,DC=local] objects[98/98] linked_values[23/0]
Partition[DC=domain,DC=local] objects[307/209] linked_values[23/0]
Partition[DC=DomainDnsZones,DC=domain,DC=local] objects[40/40] linked_values[0/0]
Partition[DC=ForestDnsZones,DC=domain,DC=local] objects[18/18] linked_values[0/0]
Committing SAM database
Sending DsReplicateUpdateRefs for all the partitions
Setting isSynchronized and dsServiceName
Setting up secrets database
Joined domain DOMAIN (SID S-1-5-21-2813939429-2675192644-3843174914) as a DC

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 le 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 :
*/5 * * * * root rsync -azvp --delete /usr/local/samba/var/locks/sysvol root@srv-dc2:/usr/local/samba/var/locks/sysvol

3.9 Ajout d'un serveur membre
Je ne reviendrai pas sur les étapes de préparation du serveur ni sur l'installation de Samba4 qui est inchangé 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é. 
root@srv-member:~# samba-tool domain join domain.local member -U administrator --realm=domain.local
Password for [WORKGROUP\administrator]:
Joined domain DOMAIN (S-1-5-21-2813939429-2675192644-3843174914)
A noter que depuis la beta4, 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 :
root@srv-member:~# samba-tool domain dcpromo domain.local DC -U administrator
Les services de partages de fichiers sont désormais gérés par un build des démons samba3 (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é de Samba 4.

4. Jouons un peu avec la ligne de commande
4.1 samba-tool, le couteau suisse de l'administrateur
Comme tout bon programme Unix, Samba4 est entièrement administrable en ligne de commande. 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ètres.
Prenons connaissance du domaine que nous avons mis en place :
root@srv-dc1:~# samba-tool domain info 192.168.1.250
Forest           : domain.local
Domain           : domain.local
Netbios domain   : DOMAIN
DC name          : srv-dc1.domain.local
DC netbios name  : SRV-DC1
Server site      : Default-First-Site-Name
Client site      : Default-First-Site-Name
root@srv-dc1:~# samba-tool domain level show
Domain and forest function level for domain 'DC=domain,DC=local'

Forest function level: (Windows) 2003
Domain function level: (Windows) 2003
Lowest function level of a DC: (Windows) 2008 R2

root@srv-dc1:~# samba-tool fsmo show
InfrastructureMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
RidAllocationMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
DomainNamingMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
SchemaMasterRole owner: CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local

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) :

root@srv-dc1:~# samba-tool domain passwordsettings set --min-pwd-length=7 --max-pwd-age=365
Minimum password length changed!
Maximum password age changed!
All changes applied successfully!
root@srv-dc1:~# samba-tool domain passwordsettings show
Password informations for domain 'DC=domain,DC=local'

Password complexity: on
Store plaintext passwords: off
Password history length: 24
Minimum password length: 7
Minimum password age (days): 1
Maximum password age (days): 365

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

root@srv-dc1:~# samba-tool group add "Taverne de Moe"
Added group Taverne de Moe
root@srv-dc1:~# samba-tool user create h.simpson Spr1ngfi3l --given-name=Homer --surname=SIMPSON --must-change-at-next-login --company="Centrale Nucléaire" --script-path login.bat
User 'h.simpson' created successfully
root@srv-dc1:~# samba-tool user create b.gumble Spr1ngfi3l --given-name=Barney --surname=GUMBLE --must-change-at-next-login --company="Duff" --script-path login.bat
User 'b.gumble' created successfully
root@srv-dc1:~# samba-tool group addmembers "Taverne de Moe" h.simpson,b.gumble 
Added members to group Taverne de Moe
root@srv-dc1:~# samba-tool group listmembers "Taverne de Moe"
h.simpson
b.gumble

Comme vous le voyez, il est extrêmement facile d’automatiser l’administration de son contrôleur de domaine via la ligne de commande. J’invite le lecteur à lancer la commande samba-tool sans paramètres 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 sauvegarde 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 telle. En cas de crash du système ou de corruption des bases LDB de Samba4, 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 samba4, 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 a être curieux est jeter un oeil aux différent scripts présent 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 :

# ./samba_backup  

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

5. Conclusion

Notre escapade à la découverte du fonctionnement de l’Active Directory et sans mise en place au travers de Samba4 s’arrête là. Bien qu’il y ai encore beaucoup à dire, nous avons pu voir dans quelle mesure le projet avec 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 on déjà basculé en production des serveur Samba 4.

Julien Morot
Sysadmin passionné par les logiciels libres depuis 1998.