17/09/2024

Découverte de la réplication Active Directory

Pour finir ce cours d’introduction aux services d’annuaire Active Directory, nous allons évoquer le processus de réplication qui a lieu au sein d’un environnement Active Directory, notamment au niveau des contrôleurs de domaine.

II. À quoi sert la réplication Active Directory ?

De manière générale, lorsqu'il est question de "redondance", cela implique de répliquer les données afin qu'elles soient identiques sur les différents membres d'un groupe. C’est le même principe pour les contrôleurs de domaine, puisqu’ils doivent se répliquer pour maintenir à jour l'annuaire Active Directory et ses composantes.

La réplication Active Directory est un processus essentiel pour maintenir la cohérence et la mise à jour des informations à travers les différents contrôleurs de domaine. Elle permet d'assurer que chaque contrôleur dispose des mêmes données, et surtout, de données à jour.

Un dysfonctionnement du processus de réplication peut avoir une incidence sur le bon fonctionnement de vos services et entrainer une certaine incohérence. Par exemple, un nouvel utilisateur est visible sur le contrôleur de domaine à partir duquel il a été créé, mais pas sur un autre contrôleur de domaine.

III. Quelles sont les informations répliquées ?

Voici une liste des informations qui seront répliquées par l'intermédiaire du processus de réplication AD :

  • Base annuaire Active Directory

Si un utilisateur est créé, modifié ou supprimé, il faut synchroniser les changements auprès des autres contrôleurs de domaine. De la même manière, si l’on intègre un nouvel ordinateur dans le domaine, cela créera un objet « ordinateur » supplémentaire dans l’annuaire, il est donc nécessaire de synchroniser ce changement.

Le protocole "RPC over IP" (Remote Procedures Call over Internet Protocol) est utilisé pour répliquer la base d’annuaire.

  • Les stratégies de groupes et les scripts

Une nouvelle stratégie de groupe créée, un paramètre modifié dans une GPO existante, ou encore la suppression d’une GPO, sont autant d’opérations qui impliquent un changement, et donc la nécessité de répliquer des données.

  • DNS

Comme nous l’avons vu dans un module précédent, le DNS joue un rôle important dans une architecture Active Directory. Pour assurer la continuité de service, nous utilisons au moins deux serveurs DNS (chaque contrôleur de domaine assumera cette fonction). Ceci implique que les enregistrements des zones soient répliqués entre les serveurs DNS, pour que les informations retournées soient identiques.

Imaginez, si un serveur DNS n’est pas à jour et qu’il retourne une mauvaise adresse IP à une requête client, cela générera des problèmes de communication au sein de l’infrastructure.

Remarque : les zones DNS correspondantes à l'Active Directory sont stockées dans l'annuaire. Elles bénéficient donc du processus de réplication.

Maintenant, vous savez ce qui doit être répliqué et pourquoi cela doit être répliqué, cherchons à répondre à une autre question : à quelle fréquence la réplication se déclenche-t-elle ?

IV. Les types de réplication

Il existe deux types de réplication dans Active Directory : la réplication intrasite et la réplication intersite. La configuration des sites et des paramètres de réplication s'effectue à partir de la console "Sites et services Active Directory".

En effet, un domaine intègre une notion de "site Active Directory" qui influence la topologie de réplication de l'environnement dans sa globalité. Dans la grande majorité des cas, les sites Active Directory sont le reflet des sites géographiques de l'entreprise et vont donc permettre de regrouper les contrôleurs de domaine par emplacement géographique.

Lorsque 2 contrôleurs de domaine sont associés au même site Active Directory, nous parlons de réplication intrasite. À l'inverse, lorsque 2 contrôleurs de domaine sont associés à des sites différents, nous parlons de réplication intersites, et dans ce cas, le délai de réplication sera plus long.

A. Réplication intrasite

Cette réplication a lieu entre les contrôleurs de domaine associé à un même site Active Directory. Elle se déclenche immédiatement après une modification importante. Par exemple, lorsqu'un objet comme un compte d'utilisateur est modifié, la notification est envoyée aux contrôleurs de domaine dans les 15 secondes (pour le premier contrôleur de domaine à notifier).

Après la première notification, les contrôleurs répliquent l'information à intervalles de 30 secondes pour les autres contrôleurs partenaires, ce qui permet une mise à jour rapide au sein du site. Si aucune modification n'est détectée, l'annuaire est scruté toutes les heures pour s'assurer qu'il n'y a pas eu de changement non notifié.

Les contrôleurs de domaine dans un même site ont souvent une connexion réseau rapide et fiable fournie par le réseau local (LAN). Ainsi, la réplication intrasite est un processus rapide grâce à cette bande passante.

Note : Ces deux valeurs peuvent être modifiées dans le registre, Replicator notify pause after modify (secs) pour le premier déclenchement de notification, et la valeur Replicator notify pause between DSAs (secs) pour les délais de notification suivants. Tout cela au niveau de la clé « HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters ».

cours-active-directory-27

Cependant, il existe des cas de « réplication urgente » où l’on n’observera aucune latence. C’est le cas, par exemple, lorsqu’on désactive un utilisateur, change un mot de passe… Et d'autres actions liées à la sécurité.

B. Réplication intersite

La réplication intersite se fait entre des contrôleurs de domaine situés dans des sites AD différents, et donc généralement, sur des emplacements physiques différents. Par défaut, cette réplication est programmée toutes les 15 minutes, mais ce délai peut être ajusté dans la configuration du lien entre les deux sites.

Cette différence s'explique en raison de la distance physique et des connexions réseau plus lentes entre les sites. Par exemple, il peut s'agir de 2 sites interconnectés avec une liaison VPN.

Active Directory permet de configurer la réplication intersite à travers des liens entre les sites. Ces liens incluent des informations telles que le coût (valeur numérique représentant la préférence ou la qualité de la connexion) et la planification (fréquence des réplications).

Bien que tout cela soit configurable manuellement, le vérificateur de cohérence des connaissances (KCC - Knowledge Consistency Checker) est responsable de la génération automatique de la topologie de réplication. Le KCC analyse régulièrement les contrôleurs de domaine et les sites Active Directory pour s'assurer que la réplication est optimisée et que tous les contrôleurs de domaine sont correctement connectés. Il ajuste les connexions de réplication si des modifications sont apportées à l'infrastructure, comme l'ajout ou la suppression d'un site ou d'un contrôleur de domaine.

Note : lors de la création d’un premier domaine, il y a toujours un site par défaut nommé « Default-First-Site-Name » qui est créé et qui contient le contrôleur de domaine venant d’être installé. Un lien par défaut est également créé et nommé « DEFAULTIPSITELINK ».

Propriétés du site par défaut
Propriétés du site par défaut
  • Le serveur "Tête de pont"

Dans le cadre de la réplication intersite, un contrôleur de domaine tête de pont est désigné pour gérer la réplication entre deux sites. Ce contrôleur de domaine agit comme un point central pour la réception et l'envoi des modifications de réplication. La sélection de la tête de pont est faite automatiquement par Active Directory. Il est recommandé de laisser ce processus en mode automatique.

Remarque : avec la réplication intersites, il y a une notion de coût. Le coût est une valeur numérique qui représente la préférence pour un lien spécifique. Par exemple, un lien entre deux sites avec un coût de 100 sera préféré à un lien avec un coût de 200. Ceci permet à l'AD de définir le meilleur schéma de réplication.

C. Les protocoles de réplication

Active Directory utilise des protocoles de réplication spécifiques pour assurer la synchronisation des données entre les contrôleurs de domaine au sein d'un site (réplication intrasite) et entre différents sites (réplication intersite). Ces protocoles permettent de transférer efficacement les modifications des objets AD tout en tenant compte du réseau et des latences potentielles.

Pour les réplications intrasite, l'AD utilise le protocole "RPC over IP", un protocole qui permet la communication entre les contrôleurs de domaine de manière efficace et sécurisée. Il permet de faire transiter des objets modifiés, comme des utilisateurs, des groupes, des mots de passe ou des enregistrements DNS, sous forme compressée pour économiser la bande passante.

Comme pour les réplications intrasite, l'AD utilise généralement le protocole "RPC over IP" pour les réplications intersite. Il utilise des mécanismes de compression des données pour minimiser l'impact sur la bande passante, ce qui est important pour les connexions à faible débit.

Dans certains cas spécifiques, notamment lorsque la réplication intersite est réalisée entre des sites avec des liens de communication peu fiables ou avec une forte latence, le protocole SMTP peut être utilisé pour répliquer les données Active Directory. Cependant, il n’est pas en mesure de répliquer le répertoire « SYSVOL », il peut seulement répliquer des éléments précis : mises à jour du schéma, la configuration ou encore les données du catalogue global.

Vous l’aurez compris, le protocole "RPC over IP" est au cœur de la réplication entre les contrôleurs de domaine, aussi bien en intrasites qu’en intersites. Le SMTP joue un rôle secondaire pour des réplications spécifiques sur des liaisons lentes.

V. Conclusion

Cette conclusion clôture ce chapitre et ce cours d'introduction sur les services de domaine Active Directory. Par son aspect théorique, ce cours vous permettra d’avoir une approche plus sereine quant à la mise en place d’un domaine et d’un annuaire Active Directory. Que ce soit pour une maquette, ou un cas concret en entreprise. Les notions acquises par ce cours représentent une base solide pour aborder la suite.

author avatar
Florian BURNEL Co-founder of IT-Connect
Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.