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.
Bonjour,
Je tente de mettre en place un samba4 en m’inspirant de tuto sur le net.
Le votre est plutôt bien expliqué.
Néanmoins, j’ai un souci à l’étape d’ajout des variables samba dans le PATH.
J’ai beau avoir ajouté les variables dans le fichier ~/.bashrc, la commande “provision” ne va fonctionner que si je suis dans le répertoire samba ….
#root@smb4:~# pwd
/root
#provision
root@smb4:~# provision
-bash: provision : commande introuvable
#/usr/local/samba/bin/samba-tool domain provision
OK
Ai-je fait une erreur ??
Merci.
Aucune erreur, la CLI samba a simplement évoluée depuis la version 4.0.0beta5 de l’article, donc tu as bien réglé ton anomalie tout seul 🙂
Merci.
Je pense avoir capté. J’ai correctement ajouté les variables au PATH mais comme la commande a évolué, il faut taper “samba-tool domain provision” … j’ai testé en étant directement sur “/” et ça passe 😉
Merci !
Bonjour,
Est-il possible de détailler la partie DNS ?
En effet, j’ai un gros point de blocage à ce niveau là …
D’après ce que j’ai cru comprendre, il faut que le serveur DNS soit sur la même machine que le samba4 … hors, actuellement, nous avons 2 DNS (maître / esclave) sur deux VM.
Est-ce possible de configurer le serveur DNS (ici Bind9_DLZ) sur la même machine que le samba4 et d’avoir en 2nd et troisième, les 2 DNS existants ?
Merci.
Bonjour,
La partie DNS sera mieux expliquée sur le site de Samba. Ce qu’il faut savoir c’est que la gestion des domaines AD est de préférence traitée par le DNS interne. Il est aussi recommandé pour son domaine AD d’utiliser un sous-domaine d’un domaine résolvable et que l’on possède. Dans tous les cas, il est possible de répliquer un DNS Samba sur un DNS Bind. Il faut de toute façon un serveur DNS en pluus que celui fourni par Samba car celui-ci ne fait que DNS autoritatif mais pas résolveur.
https://wiki.samba.org/index.php/Samba_Internal_DNS_Back_End#Limitations
https://wiki.samba.org/index.php/Category:DNS
https://wiki.samba.org/index.php/BIND9_DLZ_DNS_Back_End