Synchronisation de DC à  DC

plus, j’ai utilisé les
DC sur des sites différents et employé
l’utilitaire ReplMon à  partir de Win2K
Support Tools pour forcer la réplication
intersite.
Tout d’abord, examinons certains
concepts. Win2K utilise deux protocoles
pour supporter la synchronisation
d’AD intersite. Vous pouvez utiliser
RPC sur TCP/IP pour la réplication
intrasite et intersite, ou bien utiliser
SMTP pour la réplication intersite. Mon
réseau utilise RPC sur TCP/IP ; je n’ai
pas activé la réplication SMTP. De plus,
sachez qu’un objet de connexion AD
effectue une réplication « pull » dans
une seule direction. Par exemple, si un
objet de connexion va de DC1 à  DC2,
DC2 tirera les données de DC1 pendant
la réplication.
Fort de cette information, voyons
comment un événement de réplication
se présente sur le réseau. Supposons
que DC2 ait une connexion de réplication
unidirectionnelle à  partir de DC1.
Si j’ajoute un nouvel objet AD sur DC1,
pendant la prochaine réplication intersite,
DC2 déclenchera l’événement de
réplication et tirera la nouvelle information
de DC1.

1. Premièrement, DC2 obtient les tickets
   Kerberos appropriés afin de
   pouvoir s’identifier auprès des ressources
   du domaine, DC1 précisément.
   Comme DC2 est un DC et
   exécute le service KDC (Key Distribution
   Center) Kerberos, il peut
   obtenir un ticket Kerberos valide
   pour le domaine, sans s’aventurer
   sur le réseau.

2. DC2 envoie ensuite une requête
   DNS à  son serveur DNS pour localiser
   une entrée SPN (Service
   Principal Name) pour DC1. L’entrée,
   qui ressemble à  une GUID suivie
   d’un nom DNS (db4dd6e7-9b40-
   4c97-83f5-6e68b1ebcf47._msdcs.
   mycompany.com, par exemple) est
   unique pour chaque serveur et n’est
   pas la même que la GUID objet par
   laquelle AD identifie le serveur. Un
   SPN est ce que son nom indique – il
   identifie un service fonctionnant sur
   un système. Le serveur DNS renvoie
   le nom du serveur auquel ce SPN fait
   référence (le SPN est un alias DNS
   pour le serveur correspondant),
   dans ce cas DC1.

3. Ensuite, DC2 fait une requête de
   mapper de port RPC (port TCP 135)
   à  DC1 pour démarrer une communication
   RPC.

4. DC2 obtient une réponse de DC1 au
   point d’extrémité RPC demandé qui,
   dans ce cas, est pour l’interface
   GUID e3514235-4b06-11d1-ab04-
   00c04fc2dcd2. Cette GUID correspond
   au service réplicateur AD. DC2
   renvoie un port (dans la gamme audessus
   de 1 023) à  utiliser, puis DC1
   déclenche une connexion RPC, avec
   DC2 transmettant les données de
   session Kerberos qu’il a extraites à 
   l’étape 1, vers DC1.

5. DC1 et DC2 échangent ensuite un
   ensemble de requêtes et de réponses
   RPC pour répliquer les données
   de répertoire de DC2 à  DC1. Ce
   trafic est crypté et donc vous ne pouvez
   pas visualiser directement les
   données du répertoire au fil de leur
   mise à  jour. La figure 3 montre la
   preuve d’un événement de réplication
   dans l’entrée event-log des services
   de répertoire. Cette entrée du
   log montre un nouvel objet utilisateur
   appelé Jane Finance en train
   d’être créé sur le serveur de destination.
   Pour visualiser un tel logging de
   réplication d’AD détaillé, vous devez
   le valider sur le registre de votre DC.
   (Pour plus d’instructions, voir l’article
   Microsoft « How to Enable
   Diagnostic Event Logging for Active
   Directory Services », http://support.
   microsoft.com/?kbid=220940.)

La réplication DC est simple et va
droit au but. Pour cet article, j’ai créé
de nouveaux utilisateurs et groupes et
j’ai ajouté un nouvel utilisateur à  un
nouveau groupe. J’ai aussi exécuté plusieurs
scénarios de réinitialisation de
mots de passe. Dans tous les cas,
l’échange entre les DC n’a pas impliqué
plus de 40 paquets et environ 15
Ko de données sur le réseau.
Cet article s’est intéressé à  deux interactions
de réseau AD que les administrateurs
système sont susceptibles
de rencontrer quotidiennement.
Munis de cette information, vous pouvez
régler des problèmes de résolution
de noms DNS et de transport de protocole
au travers de pare-feu et vous assurer
que votre infrastructure est bien
équipée pour un échange de données
rapide et efficace.