> Tech > Synchronisation de DC à  DC

Synchronisation de DC à  DC

Tech - Par iTPro - Publié le 24 juin 2010
email

Voyons maintenant le processus de réplication entre deux DC AD. Il est moins compliqué que le processus de logon mais il suscite néanmoins quelques observations intéressantes. Là  encore, j'ai désactivé tout le trafic NetBIOS afin que le processus que je décris soit une synchronisation DC basée sur IP pur. De

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.

Téléchargez gratuitement cette ressource

Cloud hybride : 4 Stratégies de réussite

Cloud hybride : 4 Stratégies de réussite

Que vous souhaitiez développer ou renforcer votre approche du Cloud hybride, évaluer les meilleures options ou encore enrichir votre processus de prise de décision, découvrez dans ce Guide, 4 stratégies de Cloud hybride alignées avec vos objectifs business & technologiques.

Tech - Par iTPro - Publié le 24 juin 2010