Fonctionner avec des Active Directory répliqués

Présentation générale

Active Directory permet d’avoir un ensemble de serveurs d’authentification qui se répliquent pour permettre :

Une redondance (protection contre une panne).
Une meilleure gestion de la charge (plusieurs AD pour répartir les requêtes).
Ou bien de fournir un serveur d’authentification local pour des sites distants.

Note

La consommation de bande passante pour les réplications Active Directory sont globalement négligeables sur les réseaux modernes. En effet l’architecture Active Directory a été imaginée dans les années 90 quand une connexion inter-site ISDN 64kbps était déjà un luxe envié.

La réplication est un des sujets les plus compliqués et les moins compris du fonctionnement Active Directory. Même s’il n’est pas nécessaire de comprendre ces concepts (et que la plupart des sysadmin, même certifiés, ne les maîtrisent pas vraiment), il est quand même important d’en comprendre les bases pour faciliter les diagnostics en cas de problème.

Le fait de mettre des DC sur les sites distants est rarement un choix lié à une problématique de bande passante, mais plutôt une volonté d’assurer une continuité de service même si le réseau WAN est tombé.

Note

Samba-AD est un produit mature qui peut gérer des domaines avec plusieurs dizaines de contrôleur de domaine en réplication sans problème. Le plus gros domaine que Tranquil IT co-administre monte à plus de 140 contrôleurs de domaine en réplication.

Fonctionnement des réplications

Le fonctionnement des réplications en Active Directory est très différent du mode de réplication d”OpenLDAP Syncrepl ou des autres systèmes de réplication :

Les réplications Active Directory fonctionnent sur un mode Pull (le serveur tire les modifications depuis les autres serveurs) et non sur un mode Push (le serveur envoie ses données modifiées).
L’état des réplications est contenu dans l’arbre AD lui même, il n’y a pas de fichier de log qui enregistre l’ensemble des modifications.
Bien que les serveurs AD se répliquent ensemble, ils ne sont pas exactement identiques. En effet il y a des objets et des attributs qui ne sont pas répliqués, comme par exemple l’état des réplications. Si on doit comparer deux AD il faut donc exclure certain attributs pour éviter d’avoir du bruit inutile, et faciliter ainsi une recherche post-incident de réplication par exemple.

Notification vs. polling

Les serveurs Active Directory qui se trouvent sur un même site Active Directory s’envoient mutuellement des notifications quand il y a eu des changements.

Exemple : quand srvads1 a une modification, il envoie une notification à srvads2, srvads2 reçoit la notification de srvads1 et il se connecte à srvads1 pour lui demander les modifications qui ont eut lieu depuis sa dernière réplication.

Cela permet de garantir une propagation rapide des modifications. En effet vu que les postes utilisateurs et les serveurs peuvent se connecter indifféremment aux contrôleurs de domaine d’un même site, il est important que la cohérence entre les AD soit intègre.

Par contre si les serveurs AD sont sur des sites différentes, le serveur distant srvads3 demandera régulièrement à son partenaire de réplication srvads1 s’il y a eu des changement depuis la dernière réplication. Ce mode de fonctionnement est conçu pour économiser de la bande passante.

Fonctionnement des USN

USN est un compteur monotone (qui ne fait qu’augmenter) qui est spécifique à chaque serveur AD (il n’est pas répliqué entre les AD d’un domaine). Le compteur USN est incrémenté de 1 à chaque fois qu’une modification est effectuée sur un objet et la valeur est affecté au champ uSNChanged de l’objet modifié.

Ainsi l’objet avec l’USN le plus élevé est le dernier objet modifié de l’AD. Chaque objet AD a un USN unique sur un même AD. Vu que les USN ne sont pas répliqués, le même objet a une valeur uSNChanged différente sur chaque Active Directory. Vu qu’il n’y a aucun rapport entre les attributs uSNChanged entre deux DC, on peut avoir la même valeur sur deux DC (mais jamais sur le même contrôleur de domaine).

Lorsqu’un AD se réplique avec un autre AD, il stocke la valeur USN max lors de sa dernière réplication avec l’AD distant. Chaque AD stocke une valeur de l”USN max des AD en réplication à la racine de la partition principale (DC=mydomain,DC=lan) dans les attributs repsFrom et repsTo (ce sont des données binaires non lisibles directement) qui sont utilisées pour faire l’affichage du résultat de la commande samba-tool drs showrepl.

Attribut whenChanged

L’attribut whenChanged n’est pas répliqué d’un AD à l’autre. La valeur de cet attribut correspond au moment quand l’objet a été modifié, soit par un appel extérieur (modification LDAP faite par un administrateur, un poste utilisateur, une application, etc.) ou bien par une réplication.

C’est à dire que sur l’AD où la modification a été faite, l’attribut whenChanged aura le timestamp du moment de la modification, alors que les autres AD auront le timestamp correspondant au moment où il a été répliqué.

Suppression des objets et attributs tombstoneLifetime

Comme précisé précédemment, l’état des réplications est stocké dans l’arbre AD lui même. Se pose alors le cas des objets supprimés. Si l’on supprime définitivement un objet de l’arbre LDAP, il n’aura plus d’USN et donc on ne pourra pas répliquer la suppression.

Pour résoudre ce problème les développeurs de l’AD ont utilisé le concept de poubelle où les objets sont déplacés quand ils sont supprimés : le conteneur CN=Deleted Obects,DC=mydomain,DC=lan. Quand une entrée LDAP est supprimée plusieurs choses se passent :

L’attribut ISDELETED est rajouté avec la valeur 1.
Les attributs qui ne sont pas nécessaires à la réplication de la suppression sont supprimés (members, memberOf, adresse, mail, etc).
L’objet est déplacé dans le conteneur CN=Deleted Objects.
Le DN de l’objet, et donc son CN pour les utilisateurs et les groupes, est renommé en le suffixant avec 0ADEL: et son objectGUID. Par exemple, lors de sa suppression l’objet CN=dcardon aurait comme nouveau DN :
```
DN: CN=dcardon\0ADEL:<object_guid>,CN=Deleted Objects,DC=mydomain,DC=lan
```

Note

Avec Active Directory 2003 Microsoft a introduit un nouveau concept pour aider à la restauration d’un objet supprimé : la corbeille Active Directory. La corbeille permet de récupérer un objet supprimé et de le remettre dans l’arborescence normale.

Cette fonctionnalité n’est pour l’instant pas encore supportée dans Samba-AD.

Gestion des conflits de réplication

Lorsqu’un même objet a été modifié sur deux contrôleurs de domaine, lors de la réplication, cela va poser des problèmes de réconciliation. Active Directory a différentes méthodes pour réconcilier des entrées en conflit. Par exemple si un attribut mail a été modifié sur deux AD en même temps, c’est l’entrée avec le timestamp le plus récent qui sera conservé.

Note

pour les réplications, ce ne sont pas des timestamps qui sont utilisés pour faire les comparaisons entre les différents AD mais les USN. Les timestamps ne sont utilisé ici que pour faire la réconciliation quand des modifications sont en conflit lors des réplications.

Si l’AD ne peut ou ne veut pas prendre de décision sur quelle valeur conserver, comme par exemple un même compte créé sur deux AD en même temps, l’entrée qui aura le timestamp le plus élevé sera renommé selon la norme suivante :

CN=dcardon\0ACNF:<object_guid>,OU=company_users,DC=testing,DC=lan

Cela permet d’éviter qu’il y ait des DN en conflit et permet de finir la réplication (on ne peut pas avoir deux objets avec le même DN dans un arbre AD). Par contre ça ne garantit pas l’unicité du samAccountName. En effet pour gérer ce cas de figure, les ingénieurs Microsoft n’ont pas mis d’index unique sur l’attribut samAccountName.

Le renommage des samAccountName pour éviter les doublons est le rôle d’une autre tâche récurrente qui valide l’unicité de cet attribut, et renomme les attributs en conflit. Cette tâche récurrente n’est pas actuellement implémentée sous Samba-AD. Toutefois ce cas de figure arrive très rarement.

Les objets en conflit peuvent apparaître dans les différentes partitions de l’AD notamment au niveau des partitions DNSDomainZones et ForestDNSZones. Les entrées renommées OACNF dans la console DNS peuvent être normalement supprimées sans incidence.

Topologie de réplication

Gérer les connexions de réplication, rôle du KCC

Pour que les réplications se passent bien dans un domaine, il est important que chaque contrôleur soit connecté à chaque autre contrôleur à travers un ou plusieurs hop. Si une modification est effectuée sur srvads1, elle peut être répliquée sur srvads2 qui la répliquera sur srvads3. Même si srvads1 et srvads3 ne se répliquent pas directement, la modification sera propagée par transitivité.

Le rôle d’interconnecter les AD est celui du KCC, le vérification de la consistance de la connaissance. C’est un nom qui reflète bien son rôle. Le KCC utilise les informations configurées par l’administrateur dans la console Site et Services Active Directory pour choisir sa stratégie d’interconnexion d’AD. Toutefois, si la configuration définie par l’administrateur ne permet pas au KCC d’avoir un réseau complètement connecté, le KCC peut prendre des décisions qui peuvent être en désaccord avec ce que l’administrateur avait défini.

Par défaut le KCC fera au moins une connexion de réplication avec un autre AD du même site, et avec au moins un AD d’un site distant vers lequel il doit faire des réplications.

En pratique nous conseillons de définir des topologies de réplication en étoile avec un site de réplication au centre et des sites de réplication autour qui ne se réplique qu’avec le site de réplication. Cette méthode simple évitera des boucles (voir paragraphe sur le sujet).

On peut définir la notion de tête de pont sur un site distant pour que le KCC choisisse ce contrôleur de domaine tête de pont par défaut pour gérer les réplications avec le site distant.

En fonction du nombre de contrôleurs dans le domaine, il peut être intéressant d’avoir un site dédié aux réplications.

Boucle de réplication

La topologie de réplication peut faire que l’on ait des boucles de réplication. C’est à dire, par exemple, que le serveur A se réplique avec B et C, et que B et C se réplique entre eux. On peut donc avoir une modification sur A qui est propagée à B qui est à nouveau propagée à C qui la propage à nouveau au serveur A.

Dans ce cas de figure le protocole de réplication a un mécanisme pour reconnaitre ces informations de réplication en doublon et les ignorer.

Répliquer le répertoire SYSVOL

Le répertoire SYSVOL d’un Active Directory contient les fichiers de définition des GPO ainsi que les scripts d’ouverture de session NetLogon du domaine. Le répertoire SYSVOL doit être disponible sur l’ensemble des serveurs AD d’un domaine avec le même contenu.

La réplication de l’arbre LDAP DRS est un protocole complètement différent de celui utilisé pour la réplication du répertoire SYSVOL.

Pour assurer la réplication du répertoire SYSVOL, Microsoft a mis en place deux protocoles :

FRS : protocole intégré à AD depuis AD2k jusqu’à AD2k16 (sauf dernière version octobre 2019).
DFS-R : protocole intégré à AD depuis AD2k8.

Actuellement Samba-AD ne support ni FRS ni DFS-R. Il n’y a pas de méthodologie officielle Samba pour faire la réplication du répertoire SYSVOL. Il existe différentes méthodes. Vous pouvez utiliser la méthode Tranquil IT.

Le protocole DFS-R utilisé pour le répertoire SYSVOL est le même que celui utilisé pour répliquer des partages de fichiers entre serveurs de fichiers Microsoft. C’est une extension du protocole DFS. Samba supporte le protocole DFS, mais pas le protocole DFS-R.

Cas des contrôleurs de domaine en lecture seule

A partir d’Active Directory 2008, il est possible d’avoir des serveurs Active Directory en lecture seule RODC. Comme sont nom l’indique, ces contrôleurs de domaine ne permettent pas de faire des modifications des données localement. Les modifications sont redirigées vers un contrôleur de domaine normal (que l’on appellera dans cette documentation par abus de langage RWDC).

Toutefois, comme il a été précisé un peu plus tôt dans cette documentation, les données du statut de réplication sont stockées elles même dans l’AD. Cela implique que l’AD n’est pas entièrement en lecture seule. En effet certains attributs sont quand même en lecture / écriture. L’attribut instanceType définit si l’attribut est en lecture / écriture (valeur 4) ou en lecture seule (valeur 2).