Dans les Parties 3 et 4, nous avons vu comment créer des objets AD tels que des utilisateurs, des groupes et des OU. La création d'objets AD se fait par des actions d'administration sur un contrôleur de domaine (DC) particulier. Cependant, de telles informations sur les objets nouvellement créés doivent être rapidement mises à la disposition de tous les autres DC afin que les actions de gestion puissent être effectuées sans problème depuis n'importe quel DC.
La réplication AD permet la disponibilité d'informations AD mises à jour dans tous les DC. Ce blog vous aidera à comprendre la réplication AD en détail.
Alors, qu'est-ce que la réplication AD ?
Dans son sens le plus simple, la réplication est le concept de modification d'objets AD sur un DC, puis de réplication et de visibilité sur tous les autres DC de la forêt AD.
Pourquoi la réplication AD est-elle nécessaire ?
Vous vous demandez peut-être ce que l'on entend par modification d'un objet AD et pourquoi un tel modèle de réplication est nécessaire.
L'environnement AD connaît de nombreuses modifications constantes qui se produisent en temps réel. Ces changements doivent être mis à jour dans la base de données AD pour une utilisation et une gestion futures.
Voici quelques exemples de ces changements :
L'ajout de nouveaux utilisateurs ou ordinateurs dans l'AD.
Une modification des attributs AD stockés, comme le renommage d'un objet AD
Le déplacement d'objets AD entre des OU ou des groupes AD
La suppression d'objets AD.
Afin de s'assurer que la nature dynamique de tout environnement AD est maintenue et que ses avantages sont utilisés efficacement, la réplication dans l'AD est une nécessité critique qui forme l'épine dorsale des services AD.
Concepts AD fondamentaux nécessaires pour comprendre la réplication AD
L'objectif principal d'un environnement contrôlé par l'AD est d'avoir un contrôle centralisé et de gérer efficacement tous les utilisateurs et ordinateurs.
La conception de la topologie logique AD imite la structure de l'organisation de l'entreprise. Elle est conçue pour prendre en compte les réseaux physiques TCP/IP sur lesquels l'AD est mis en place.
Dans un environnement AD actif :
L'installation AD DS implique d'avoir un ou plusieurs serveurs d'authentification et d'autorisation appelés contrôleur de domaine (DC) desservant les différents clients du domaine AD.
Chaque DC peut être identifié par un objet serveur dans l'AD, ainsi que par un objet enfant Windows NT Directory Services (NTDS) associé. Ces objets NTDS stockent à leur tour les connexions enfant et garantissent que les modifications apportées aux objets AD (utilisateurs, ordinateurs, groupes ou OU) sur un DC unique sont répliquées selon un planning à tous les autres DC récepteurs.
Les sites AD comprennent des sous-réseaux qui couvrent une gamme d'adresses IP utilisées par l'entreprise. Un ou plusieurs DC opérant dans ces sites définis auront l'autorité sur les objets AD présents dans ces sites individuels. La configuration correcte de ces sites AD joue un rôle énorme pour s'assurer qu'il n'y a pas d'erreurs dans l'établissement d'une topologie de réplication efficace.
Active Directory Sites and Services est un outil de gestion accessible depuis le Server Manager. Il permet aux administrateurs de configurer les sites et sous-réseaux appropriés, et d'établir des liens entre les sites pour la réplication.
Comment fonctionne la réplication ?
Procédure de réplication | Explication |
La réplication se produit toujours entre deux ou plusieurs DC. | Tous les DC disposent d'un programme d'arrière-plan intégré, appelé Knowledge Consistent Checker (KCC), qui crée automatiquement des connexions entre les sites, établit les liens entre les sites associés et sélectionne les serveurs relais, dont nous parlerons bientôt plus en détail. |
La réplication dans l'AD se fait au niveau des attributs. | Chaque principe de sécurité, tel qu'un utilisateur ou un groupe AD, est identifié par un ID de sécurité (SID) et un ID relatif (RID). Les objets AD tels que les ordinateurs ou les imprimantes se voient également attribuer un identifiant unique global (GUID). Seul l'attribut qui subit la modification ainsi que le GUID de l'objet AD modifié sont partagés entre les DC ou les partenaires de réplication choisis. Cela permet d'économiser la bande passante du réseau et d'assurer un trafic réseau optimal et l'achèvement en temps voulu du processus de réplication. Le numéro de version sur le GUID/SID est mis à jour de manière incrémentale pour chaque modification qui se produit. |
La réplication est rendue possible grâce aux liens de site. | Les liens de site établissent des connexions entre les sites AD de manière à représenter les réseaux physiques de l'entreprise. Une configuration sans faille des objets de liens de sites dans l'AD permet de déterminer l'intervalle de réplication, la fréquence de réplication dans cet intervalle et les chemins de réplication préférés entre les sites AD requis. La planification et le coût des liaisons de sites impliquent l'attribution de priorités sous la forme de valeurs numériques. Cela détermine en fin de compte le meilleur chemin de réplication à prendre entre les DC. Un administrateur prend généralement cette décision au cours du processus de configuration des liens de site et de la configuration du KCC. |
Toute erreur dans la réplication AD se produit généralement en raison d'une configuration incorrecte des sites et sous-réseaux AD, ou si le KCC ne fonctionne pas correctement, ou en raison d'erreurs dans les intégrations liées à l'AD-DNS (traitées dans la [Partie 2]() de cette série).
Types de réplication AD
Il existe deux types de réplication AD : intra-site et inter-site.
Réplication intra-site
Les DC d'un site AD sont disposés selon une topologie en cercle, c'est-à-dire que chaque DC est connecté à deux autres DC par défaut. Il n'est pas nécessaire d'intervenir manuellement pour créer ces liens entre les sites. Voir la figure 1.
La figure 1 montre la topologie en cercle des DC au sein d'un site.
Le KCC, responsable de la configuration de ces liens de site et de la création de la topologie de réplication par le biais d'un algorithme de génération de topologie, fait appel à un appel de procédure à distance, c'est-à-dire RPC over IP, pour communiquer avec la base de données AD et ainsi activer le processus de réplication. Ce protocole permet une communication rapide des changements requis à tous les autres DC du site grâce à l'interaction du KCC avec l'agent du système d'annuaire de la base de données AD sur le DC.
Au fur et à mesure que les changements sont autorisés sur un DC particulier, une notification de changement est envoyée aux autres DC de ce site. Ces autres DC sont les partenaires de réplication qui répondent à cette notification ou mise à jour de changement. Ils envoient une demande de changement dirigée vers le DC source. Le premier partenaire de réplication directe est alors choisi par le DC source et reçoit les modifications ou les données de réplication requises.
Chaque DC est configuré par les administrateurs pour attendre une courte période avant d'envoyer la mise à jour des changements et les données de réplication ultérieures à chaque partenaire de réplication directe. Comme le montre la figure 2, le délai par défaut de 15 secondes est respecté sur tous les Windows Server 2003 et versions supérieures afin de garantir que le trafic réseau est contrôlé et que les conflits ou les erreurs de réplication sont évités.
La figure 2 montre des DC du site A présentant une notification de changement commençant dans un délai d'attente de 15 secondes.
Dans ces sites bien connectés et dotés de vitesses de réseau élevées, la réplication entre tous les DC d'un site est généralement achevée dans la minute qui suit le lancement de la première notification de changement par le DC source. Le DC source envoie les données de réplication à tous les autres partenaires de réplication en temps voulu, avec un décalage par défaut de trois secondes entre chaque DC.
Lorsqu'il y a plus de DC dans le site, plus de liens de site sont automatiquement configurés par le KCC pour assurer que la réplication est toujours effectuée efficacement dans le site. La figure 3 ci-dessous illustre cette situation.
La figure 3 montre la topologie de réplication modifiée dans le site A, montrant l'inclusion de plus de DC.
Réplication inter-site
La réplication entre les sites se produit avec l'identification et l'implication de serveurs bridgehead désignés, comme le montre la figure 4. Ces serveurs sont sélectionnés automatiquement par le KCC ou peuvent être configurés manuellement par l'administrateur. Ils représentent les serveurs choisis pour permettre le passage des données AD entre les sites.
La figure 4 montre les serveurs bridgehead établissant le chemin pour la réplication inter-site entre les sites A et B.
La réplication inter-site se fait aussi, principalement, par RPC over IP. Toutefois, lorsque la communication RPC over IP rencontre des problèmes, le SMTP peut également être utilisé. Les transferts de sites SMTP sont généralement moins fiables et ne sont pas utiles pour gérer toutes les exigences de réplication dans l'AD. Les modifications apportées aux stratégies de groupe, par exemple, ne sont pas gérées par ce protocole. Le SMTP ne peut être utilisé pour la réplication inter-domaine que lorsque des données AD de schéma ou de configuration doivent être répliquées. La réplication des données AD lorsque le SMTP est utilisé se fait par le biais d'e-mails.
La réplication entre les sites est configurée pour se produire à un intervalle de temps standard de 180 minutes, comme le montre la figure 5. Ce décalage peut être configuré manuellement à différents intervalles. Il est fixé à ce niveau par défaut pour tenir compte des vitesses de réseau inférieures qui peuvent affecter le trafic réseau entre deux sites AD.
La figure 5 montre la réplication inter-site entre les sites A et B. Ici, l'intervalle de temps entre l'initiation de la réplication est de 180 minutes entre les serveurs bridgehead désignés.
Une fois que le serveur bridgehead a reçu les données répliquées, les notifications de changement et les informations de réplication ultérieures sont communiquées à tous les autres DC de chacun des sites concernés et sont complétées.
Réplication dans des circonstances pratiques
Voyons maintenant un exemple pratique de réplication intra-site et inter-site.
Supposons qu'un nouvel utilisateur soit créé sur le site A. Les informations concernant ce nouvel utilisateur créé sur le site A seront d'abord répliquées sur tous les DC du site. Ces informations seront ensuite répliquées vers les DC du site B.
La réplication intra-site se déroule comme ceci : Le DC source du site A, le DC serveur 1, responsable de l'autorisation de la création de ce nouvel utilisateur termine la modification. Après cela, il initie la réplication intra-site vers les autres DC de ce site.
La réplication inter-site commence ensuite : Le serveur bridgehead désigné sur le site A communique alors cette nouvelle mise à jour de la création de l'utilisateur au serveur bridgehead d'un autre site B, conformément au planning de réplication défini pour la réplication inter-site. Les informations mises à jour sur l'utilisateur sont ensuite répliquées vers les autres DC du site B.
Ce processus de réplication se poursuit entre les différents sites d'un environnement AD et est répété chaque fois qu'une modification de changement est initiée sur l'un des DC source dans n'importe quel site de la configuration AD.
La réplication, comme vous pouvez le constater, est l'un des aspects les plus importants de l'Active Directory. Nous avons maintenant appris à creuser plus profondément et à mieux comprendre l'AD, et ainsi les interrelations entre les différents aspects de l'AD vont commencer à devenir claires. Restez connectés pour en savoir plus !