Administration de Windows

Guide de réplication Active Directory

Laura E. Hunter

 

Vue d'ensemble:

• Transition vers Active Directory
• Maintien de la cohérence
• Gestion de la résolution des conflits
• Modifications apportées à Windows Server 2008

Avant l'arrivée de Windows 2000 Server et d'Active Directory, de nombreux environnements d'entreprise s'appuyaient sur Windows NT pour l'infrastructure de serveur et la gestion des identités et des

accès. À l'époque de son lancement, Windows NT® 4.0 constituait une solution solide dans l'offre de systèmes d'exploitation réseau (NOS), mais présentait un certain nombre d'inconvénients qui rendaient difficile le déploiement dans une grande entreprise.

Pour commencer, Windows NT utilisait un espace de noms plat pour enregistrer les ressources réseau, ce qui signifiait qu'il n'existait pas de bonne méthode de séparation des ressources en sous-ensembles plus petits ou de configuration d'une administration granulaire. Vous ne pouviez pas, par exemple, configurer un conteneur départemental pour les ressources de votre service de marketing ou configurer un administrateur local disposant des droits de réinitialisation des mots de passe pour les utilisateurs de ce département uniquement. Ainsi, la sécurité de Windows NT était en général soit très forte, soit inexistante ; pour déléguer des tâches administratives à un technicien du support des ordinateurs de bureau, vous deviez souvent accorder bien plus d'autorisations que vous ne le souhaitiez.

De plus, Windows NT stockait toutes ses informations dans une base de données de gestionnaire de comptes de sécurité (SAM) dont la capacité était limitée à 40 Mo. Si votre base de données SAM dépassait ce maximum recommandé (entre 25 000 et 40 000 objets, selon votre configuration), vous deviez fractionner votre environnement en plusieurs domaines distincts, ce qui compliquait l'administration du réseau et l'attribution d'accès aux ressources aux utilisateurs. Chaque domaine NT contenait un contrôleur de domaine principal (PDC) unique, lequel contenait la seule copie en lecture/écriture de la base de données SAM. Bien qu'il fût possible de déployer un ou plusieurs contrôleurs de domaine de sauvegarde (BDC), ces BDC étaient en lecture seule et ne pouvaient pas exécuter de mises à jour requérant une opération d'écriture, telles que la modification du mot de passe d'un utilisateur.

Enfin, Windows NT s'appuyait sur la résolution de nom NetBIOS, qui était basée sur la diffusion et générait souvent un trafic élevé lorsque les utilisateurs recherchaient des ressources réseau, en particulier s'ils utilisaient une connexion WAN lente ou lourdement utilisée.

Apparition d'un nouveau modèle

En 2000, Microsoft lançait Windows® 2000, qui comprenait une révision substantielle de ses produits NOS précédents. Le nouveau service NOS, Active Directory®, était aussi différent de Windows NT que vous pouviez l'imaginer. Au lieu de s'appuyer sur un espace de noms plat, Active Directory était construit sur la norme X.500, qui créait une structure organisationnelle hiérarchique ; vous pouviez dès lors organiser les ressources en plusieurs unités d'organisation dans un seul domaine et déléguer l'administration de chaque unité à un niveau basé sur les tâches.

Le nouveau modèle de réplication multimaître représentait une autre divergence importante par rapport à Windows NT. Terminé le PDC inscriptible unique et ses BDC associés ; dans Active Directory, chaque contrôleur de domaine avait la possibilité d'écrire dans la base de données Active Directory.

Cependant, bien que ce nouveau modèle offrît beaucoup plus de flexibilité en termes de prise en charge des environnements de grande taille et/ou décentralisés, il créait également de nouvelles difficultés au niveau de la conservation de l'intégrité d'Active Directory. Si John Smith et Jane Dow modifient un même objet depuis des bureaux distants, que se passe-t-il si ces modifications sont contradictoires ? Le modèle de réplication Active Directory définit les méthodes de communication des mises à jour à tous les contrôleurs de domaine dans un environnement, ainsi que la gestion des conflits générés par cette possibilité de modification multimaître depuis pratiquement n'importe où.

Mécanique de la réplication Active Directory

Dans ces exemples, nous aborderons uniquement la réplication intrasite. En général, la réplication intrasite est conçue pour répliquer des modifications rapidement sur des contrôleurs de domaine d'un même site, et est exécutée à l'aide de la notification de modification. Dans le cas de la réplication intrasite, DC1 notifie DC2 des modifications à répliquer, de sorte que DC2 puisse extraire ces modifications de DC1. De même, DC2 notifie DC1 lorsque des modifications ont été apportées, de sorte que DC1 puisse extraire ces modifications de DC2. Comme vous pouvez le voir, toute réplication Active Directory se fait par des opérations d'extraction et non par des opérations d'envoi.

Active Directory peut s'étendre à des centaines de milliers ou même des millions d'objets. Il est donc nécessaire de découper la base de données Active Directory en sections, appelées des contextes de nommage. Au minimum, chaque contrôleur de domaine stocke trois contextes de nommage dans sa copie locale de la base de données Active Directory.

Contexte de nommage de schéma Ce contexte de nommage est répliqué dans chaque contrôleur de domaine de la forêt. Il contient des informations sur le schéma Active Directory, qui à son tour définit les différentes classes et attributs d'objet dans Active Directory.

Contexte de nommage de configuration Également répliqué dans tous les contrôleurs de domaine de la forêt, ce contexte de nommage contient les informations de configuration se rapportant à la disposition physique d'Active Directory, ainsi que des informations sur les spécificateurs d'affichage et les quotas Active Directory de la forêt.

Contexte de nommage de domaine Ce contexte de nommage est répliqué dans tous les contrôleurs de domaine d'un seul domaine Active Directory. Le contexte de nommage suivant contient les données Active Directory les plus utilisées : les utilisateurs, groupes, ordinateurs et autres objets qui résident effectivement dans un domaine Active Directory particulier.

Afin d'améliorer le trafic de réplication, chaque contexte de nommage est répliqué séparément de sorte qu'un contexte de nommage rarement modifié, tel que le contexte de nommage de schéma, n'utilise pas de bande passante de réseau, requise par le contexte de nommage de domaine, qui de son côté change plus fréquemment.

Dans la mesure où les modifications d'annuaire peuvent être apportées depuis n'importe quel contrôleur de domaine Active Directory, la réplication Active Directory doit suivre deux types d'opérations d'écriture. Le premier concerne les écritures d'origine, c'est-à-dire lorsqu'une modification particulière est apportée directement sur un contrôleur de domaine particulier. Par exemple, si vous vous connectez à DC1 et modifiez le mot de passe d'un utilisateur, cette modification équivaut à une écriture d'origine sur DC1. Active Directory doit également suivre les écritures répliquées. Comme vous pouvez l'imaginer, cela signifie qu'une modification particulière a été répliquée depuis un autre contrôleur de domaine. La modification considérée comme une écriture d'origine sur DC1 est considérée comme une écriture répliquée lorsque cette modification est répliquée dans DC2, DC3 et autres contrôleurs de domaine à travers le domaine.

Les contrôleurs de domaine Active Directory gèrent la transmission des modifications d'annuaire à l'aide de métadonnées de réplication. Cela signifie que, outre la communication des données réelles qui ont été modifiées d'un contrôleur de domaine à un autre (la description de John Smith a été modifiée en Directeur de RH), Active Directory transmet des informations supplémentaires sur cette modification pour permettre aux contrôleurs de domaine de gérer la réplication de la manière la plus efficace, par exemple, le contrôleur de domaine d'origine de la modification, l'heure de la modification et d'autres éléments d'information clé.

Le premier article de réplication de métadonnées que nous aborderons est le numéro de séquence de mise à jour (USN). Chaque contrôleur de domaine maintient un numéro de séquence de mise à jour qui lui est propre. Lorsqu'une modification est apportée à Active Directory depuis ce contrôleur de domaine, le numéro de séquence de mise à jour est incrémenté de 1. Ainsi, si un contrôleur de domaine a un USN de 1 000 à 11h00 du matin et de 1005 à 11:30 heures du matin, vous savez que 5 modifications ont été apportées à la base de données Active Directory sur ce contrôleur de domaine. La nature exacte de ces modifications est sans importance en ce qui concerne le numéro de séquence de mise à jour ; vous auriez pu modifier 5 objets différents, créer 5 objets, supprimer 5 objets ou n'importe quelle autre combinaison. Le numéro de séquence de mise à jour du contrôleur de domaine augmentera toujours de 5. De plus, les numéros de séquence de mise à jour sont internes à un seul contrôleur de domaine spécifique et n'ont aucune importance lorsqu'ils sont comparés à d'autres contrôleurs de domaine. Un contrôleur de domaine d'un domaine pourrait apporter une modification à 11h30 du matin et attribuer un USN de 1051, et un second contrôleur de domaine du même domaine pourrait apporter une modification précisément au même moment et attribuer un USN de 5084. Bien que ces deux contrôleurs de domaine aient clairement des numéros de séquence de mise à jour radicalement différents pour une modification apportée environ au même moment, il n'est pas important de savoir comment ces modifications sont répliquées ; le numéro de séquence de mise à jour d'un contrôleur de domaine n'a aucune signification pour les autres contrôleurs de domaine en termes de comparaison des modifications.

Mais ceci n'est pas le seul moyen d'incrémenter un numéro de séquence de mise à jour de contrôleur de domaine. N'oubliez pas qu'une modification apportée à la base de données Active Directory peut consister en une écriture d'origine ou en une écriture répliquée. Le numéro de séquence de mise à jour sur un contrôleur de domaine est incrémenté par les deux types d'opération d'écriture, ce qui signifie qu'il est incrémenté lorsque des modifications sont répliquées depuis un autre contrôleur de domaine. Il est clair que les contrôleurs de domaine doivent avoir un moyen de suivre les modifications déjà répliquées pour éviter d'envoyer la base de données entière à chaque réplication. Pour empêcher cela, chaque contrôleur de domaine Active Directory maintient une valeur de référence appelée HWMV (High Watermark Vector) pour les autres contrôleurs de domaine avec lesquels il effectue la réplication. Chaque contrôleur de domaine pourra associer cette valeur HWMV à l’identificateur global unique (GUID) du contrôleur de domaine distant pour empêcher la confusion si un contrôleur de domaine distant est renommé ou supprimé de l'annuaire.

Commençons par un exemple simple, dans lequel vous disposez de deux contrôleurs de domaine configurés dans le domaine contoso.com, dc1.contoso.com et dc2.contoso.com. Puisqu'il n'y a que deux contrôleurs de domaine dans le domaine contoso.com, DC1 et DC2 effectuent la réplication entre eux seulement. (Notez qu'il s'agit ici d'un exemple simplifié qui n'illustre pas toutes les possibilités de la réplication Active Directory ; nous approfondirons cet exemple à mesure que nous avançons).

Précisons en outre que l'USN actuel de DC1 est 3000, que l'USN actuel de DC2 est 4500, et que ces deux contrôleurs de domaine sont entièrement à jour l'un par rapport à l'autre lorsque nous commençons notre exemple :

Étape 1 : DC1 et DC2 sont à jour l'un par rapport à l'autre. DC1 a une valeur HWMV pour DC2 de 4500, et DC2 a une valeur HWMV pour DC1 de 3000, comme illustré à la figure 1.

Figure 1** État actuel de deux contrôleurs de domaine **

Étape 2 : Un administrateur crée un objet sur DC1, et l'USN de DC1 est incrémenté à 3001, comme illustré à la figure 2. Notez que le HWMV de DC1 n'a pas changé sur DC2, car DC1 pas encore notifié DC2 que des modifications sont en attente.

Figure 2** Un nouvel objet est ajouté. **

Étape 3 : DC1 notifie DC2 que des modifications sont disponibles. DC2 initie alors la réplication avec DC1 pour demander les mises à jour disponibles. Dans le cadre de cette requête, DC2 envoie à DC1 la valeur HWMV qu'il a stockée pour DC1, comme illustré à la figure 3.

Figure 3** Notification de modification **(Cliquer sur l'image pour l'agrandir)

Étape 4 : DC1 envoie à DC2 la modification qui correspond à l'USN 3001, c'est-à-dire l'objet qui a été créé sur DC1 à l'étape 2. DC2 met à jour son propre USN à 4501 et son HWMV pour DC1 à 3001, comme illustré à la figure 4.

Figure 4** Modifications et mises à jour **(Cliquer sur l'image pour l'agrandir)

Jusque-là, tout va bien. Mais, maintenant, il y a un problème. DC2 a une modification qu'il a besoin de répliquer. S'il ne fallait pour continuer que des USN et des valeurs HWMV, à ce stade, DC2 contacterait DC1 pour répliquer la même modification dans DC1 que DC1 vient de répliquer dans DC2. Cela créerait un cycle de réplication infini et utiliserait de plus en plus de bande passante. Pour éviter cela, nous devons ajouter d'autres pièces au puzzle. La première est le vecteur de mise à jour (vecteur UTD ou simplement UTDV).

L'UTDV est une autre métadonnée de réplication, utilisée pour le blocage de la propagation, c'est-à-dire que le but est d'empêcher qu'une même modification n'utilise inutilement de la bande passante par des réplications répétées à l'infini sur le réseau. Chaque contrôleur de domaine maintient une table d'UTDV pour chaque autre contrôleur de domaine qui stocke une réplication du contexte de nommage en question. Pour le contexte de nommage de domaine, chaque contrôleur de domaine d'un domaine maintient un UTDV pour chaque contrôleur de domaine du domaine. Pour le contexte de nommage de configuration et de schéma, l'UTDV est maintenu pour chaque contrôleur de domaine de la forêt. La table d’UTDV assure le suivi non seulement de l'USN le plus élevé que chaque contrôleur de domaine a reçu de ses partenaires de réplication, mais également de la valeur d'USN la plus élevée qu'il a reçue de chaque contrôleur de domaine qui réplique un contexte de nommage donné. Pour faciliter cela, chaque modification répliquée inclut également les informations suivantes :

• Le GUID du contrôleur de domaine qui réplique la modification. Il peut s'agir d'une modification qui est répliquée en tant qu'écriture d'origine ou qu'écriture répliquée.
• L'USN du contrôleur de domaine qui réplique la modification. Encore une fois, il peut s'agir d'une modification répliquée en tant qu'écriture d'origine ou qu'écriture répliquée.
• Le GUID du contrôleur de domaine d'origine de la modification. Si ce GUID est identique au GUID du contrôleur de domaine qui réplique la modification, il s'agit alors d'une écriture d'origine. Dans le cas contraire, la table d'UTDV entre en jeu.
• L'USN du contrôleur de domaine d'origine de la modification. Si cet USN est identique à l'USN du contrôleur de domaine qui réplique la modification, il s'agit alors d'une écriture d'origine. Dans le cas contraire, la table d'UTDV est utilisée.

Pour mieux illustrer ce processus, nous augmentons la complexité de notre exemple en ajoutant un troisième contrôleur de domaine, DC3. Dans le cas présent, DC1, DC2 et DC3 sont tous des partenaires de réplication mutuels ; DC1 réplique avec DC2 et DC3, DC2 avec DC1 et DC3, et DC3 avec DC1 et DC2 :

Étape 1 : DC1, DC2 et DC3 sont à jour les uns par rapport aux autres.

Étape 2 : DC3 exécute une écriture d'origine unique en réinitialisant le mot de passe pour le compte utilisateur jsmith. DC3 notifie DC1 et DC2 que des modifications sont disponibles. DC1 et DC2 extraient l'écriture d'origine de DC3, puis mettent à jour leurs tables HWMV et UTDV pour DC3, comme illustré à la figure 5.

Figure 5** Mise à jour des tables HWMV et UTDV **(Cliquer sur l'image pour l'agrandir)

Étape 3 : C'est ici qu'entre en jeu le vecteur de mise à jour. DC2 notifie DC1 que des modifications sont disponibles. DC1 contacte alors DC2 et demande les nouvelles modifications en envoyant à DC2 les informations suivantes :

• Valeur HWMV de DC1 pour DC2, dans ce cas 4501.
• Table d'UTDV de DC1 (illustrée à la figure 6), indiquant l'USN d'origine le plus élevé qu'il a reçu de tous les contrôleurs de domaine, y compris DC3.

Figure 6 Table UTDV

Tous les contrôleurs de domaine qui répliquent ce contexte de nommage	UTDV
<GUID de DC2>	4501
<GUID de DC3>	7002

Sur la base de la valeur HWMV de 4501, DC2 voit qu'il n'a pas répliqué la modification en question dans DC1 (voir la figure 7).

Figure 7 Une modification doit être répliquée

Propriété	Valeur	GUID du contrôleur de domaine local	USN local	GUID du contrôleur de domaine d'origine	USN d'origine
Propriété Password de jsmith	%#FH%2rfg2	<GUID de DC2>	4501	<GUID de DC3>	7002

Cependant, sur la base de la table d'UTDV que DC1 a transmise avant le début de la réplication, DC2 détermine que DC1 ne requiert pas cette modification, puisque DC1 a déjà reçu cette modification de DC3. À ce stade, DC1 met simplement à jour son entrée HWMV pour DC2 afin de refléter l'USN incrémenté, comme illustré à la figure 8. Toutefois, pour conserver la bande passante, les données ne sont pas transmises en ligne.

Figure 8** Blocage de la propagation **(Cliquer sur l'image pour l'agrandir)

Étape 4 : Ce même blocage de la propagation a lieu lorsque DC2 notifie DC3 que des modifications sont disponibles, et lorsque DC1 notifie DC2 et DC3. Les trois contrôleurs de domaine mettent à jour leurs entrées HWMV respectives pour leurs partenaires de réplication, comme illustré à la figure 8, mais les données réelles ne sont pas transmises à nouveau puisqu'elles ont déjà été transmises à chaque contrôleur de domaine à l'étape 2.

Résolution des conflits dans un environnement multimaître

Jusqu'à présent, nos exemples représentaient des situations où un seul administrateur apportait des modifications à un contrôleur de domaine à la fois et où personne d'autre n'intervenait. Dans la réalité, nous savons que ce cas est rare. Les mises à jour appliquées à un objet Active Directory pouvant venir de n'importe quel contrôleur de domaine du domaine, que se passe-t-il si deux administrateurs effectuent des mises à jour contradictoires depuis deux contrôleurs de domaine différents ? Trois types de conflits peuvent survenir dans un environnement Active Directory, et chacun de ces conflits utilise une méthode de résolution différente.

Modifications de propriétés contradictoires . Ce conflit survient si deux administrateurs mettent à jour le même objet de façon contradictoire : un administrateur définit une description de l'utilisateur sur « Marketing », alors qu'un autre sur un contrôleur de domaine différent la définit sur « Ventes et marketing ».

Création d'objets contradictoires . Ce conflit survient si deux administrateurs créent un objet avec le même nom à la même heure, par exemple deux utilisateurs nommés jsmith.

Transfert d'un objet dans un conteneur supprimé . Ce type de conflit est beaucoup plus rare et survient si un administrateur crée ou déplace un objet dans un conteneur, tel qu'une UO, en même temps qu'un autre administrateur sur un contrôleur de domaine différent supprime ce conteneur.

Pour résoudre les deux premiers types de conflit, il est temps de présenter deux autres éléments de métadonnées de réplication qui sont essentiellement utilisés pour la résolution des conflits. La valeur versionID est attribuée à chaque attribut individuel sur un objet, avec une valeur de début de 1 lorsque l'objet est créé. La valeur versionID est incrémentée de 1 lorsqu'un attribut individuel est modifié depuis un contrôleur de domaine quelconque. Ainsi, si l'attribut de description d'un utilisateur particulier est mis à jour de sa valeur par défaut (vide ou <not set>) à « Service de marketing » l'attribut de description aura une valeur de versionID de 2. Si la description est modifiée plus tard en « Service de ventes et marketing », l'attribut de description aura une valeur de versionID de 3, et ainsi de suite. Cette valeur versionID est associée à chaque entrée de réplication, avec les autres éléments de métadonnées que nous avons déjà présentés.

La valeur versionID peut être également utilisée pour réduire le trafic de réplication. Par exemple, si un administrateur sur DC2 a apporté plusieurs modifications à un attribut (peut-être qu'il a fait une faute de frappe dans la modification plusieurs fois), si bien que DC2 a des écritures d'origine correspondant aux valeurs versionID 2, 3, 4 et 5, DC2 répliquera uniquement l'écriture qui correspond à la dernière valeur versionID, c'est-à-dire à versionID 5. Les modifications précédentes étant tout simplement remplacées, cela représente un raccourci pour réduire l'utilisation superflue de la bande passante.

Chaque modification apportée à Active Directory inclut également le second élément de métadonnées supplémentaire utilisé pour la résolution des conflits : l'horodatage, qui indique le moment où la modification a été effectuée.

L'attribut d'horodatage est également utilisé comme mesure dynamique de la l'intégrité de la réplication Active Directory. Si un contrôleur de domaine n'a pas vu de modification avec un horodatage relativement récent en provenance d'un contrôleur de domaine particulier, il commence à générer des messages d'erreur indiquant qu'il pourrait exister un problème au niveau du contrôleur de domaine en question.

Comment ces deux attributs sont-ils utilisés dans la résolution des conflits ? Examinons chaque type de conflit séparément.

Résolution des modifications de propriétés contradictoires

Considérons l'exemple de l'objet utilisateur jsmith du domaine contoso.com. Un administrateur sur DC1 modifie la description de jsmith en « Marketing ». Presque simultanément, un administrateur sur DC3 modifie la même description d'utilisateur en « Ventes et marketing ». À ce stade, les informations de DC1 et DC3 sur l'attribut de description de jsmith se présentent comme illustré à la figure 9.

Figure 9 Modifications presque simultanées

Serveur	Propriété	Valeur	VersionID	Horodatage	GUID du contrôleur de domaine local	USN local	GUID du contrôleur de domaine d'origine	USN d'origine
DC1	Propriété Description de jsmith	« Marketing »	2	2007-06-07 14:03:25	<GUID de DC1>	3003	<GUID de DC1>	3003
DC3	Propriété Description de jsmith	« Ventes et marketing »	2	2007-06-07 14:04:57	<GUID de DC3>	7003	<GUID de DC3>	7003

Si DC2 reçoit les deux modifications simultanément, il devra déterminer la modification « gagnante ». L'ordre de résolution des conflits est le suivant :

1. La modification qui présente la valeur de versionID la plus élevée sera acceptée comme la modification « gagnante » ; la modification « perdante » sera remplacée. En l'occurrence, la valeur de versionID est 2 pour les deux enregistrements, nous devons donc passer au critère de résolution suivant.
2. Si les deux enregistrements présentent la même valeur de versionID, la modification qui présente la valeur d'horodatage la plus récente sera acceptée comme la modification « gagnante » ; la modification « perdante » sera remplacée. En l'occurrence, l'horodatage de l'écriture d'origine de DC3 est ultérieur, la description de jsmith sera donc définie sur « Ventes et marketing ». Dans le cas, rare, où la valeur de versionID et la valeur d'horodatage sont identiques, nous appliquons un troisième critère définitif :
3. Si les deux enregistrements ont les mêmes valeurs de versionID et d'horodatage, l'écriture par le contrôleur de domaine avec le GUID le plus bas sera gagnante ; l'écriture du GUID le plus élevé sera remplacée. Donc si le GUID de DC1 est 1234567890 et le GUID de DC3 est 2345678901, l'écriture d'origine de DC1 est gagnante si la valeur de versionID et la valeur d'horodatage sont identiques.

Vous pensez probablement que ce serait plus judicieux de laisser l'horodatage faire loi. Mais cela n'est pas aussi simple. Si l'horodatage était le critère de résolution des conflits principal dans Active Directory, tout ce qu'un administrateur malveillant devrait faire pour propager ses modifications serait de retarder l'horloge sur un contrôleur de domaine particulier pour toujours faire passer ses modifications.

Résolution de la création d'objets contradictoires

Dans le cas où deux objets sont créés avec le même nom, Active Directory utilise les mêmes trois critères décrits dans la section précédente pour déterminer l'objet « gagnant ». Contrairement à la section précédente, toutefois, l'objet « perdant » n'est pas remplacé. Au lieu de cela, l'objet perdant est renommé avec les caractères CNF (pour conflit), suivis de deux points et du GUID de l'objet « perdant ». Cela permet aux administrateurs de déterminer plus méthodologiquement l'objet à retenir et l'objet à supprimer.

Résolution du transfert d'un objet dans un conteneur supprimé

Comme mentionné précédemment, la résolution du transfert d'un objet dans un conteneur supprimé est un conflit relativement rare qui survient uniquement dans l'un des deux scénarios suivants. Dans le premier scénario, un administrateur sur un contrôleur de domaine crée un objet dans un conteneur particulier, par exemple l'UO Formation, au même moment qu'un administrateur sur un autre contrôleur de domaine supprime l'UO Formation. Le second scénario peut survenir lorsqu'un administrateur sur un contrôleur de domaine déplace un objet dans un conteneur au même moment qu'un administrateur sur un autre contrôleur de domaine supprime ce conteneur.

Dans ce cas, la résolution est assez simple : Active Directory déplace l'objet « orphelin » dans un conteneur spécial d'Active Directory conçu à cet effet, le conteneur LostAndFound situé à la racine de chaque domaine Active Directory. Pour le domaine de contoso.com, le conteneur LostAndFound se trouverait sur le chemin LDAP suivant : LDAP://cn=LostAndFound,dc=contoso,dc=com. Si vous ne voyez pas le conteneur LostAndFound lorsque vous ouvrez le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory, cliquez simplement sur Affichage | Fonctionnalités avancées.

Protection contre la fonction de restauration du numéro de séquence de mise à jour (USN)

L'une des situations les plus graves que vous puissiez rencontrer dans un environnement Active Directory est également la plus simple à éviter une fois vous en comprenez la cause et comment la traiter. La restauration du numéro de séquence de mise à jour (USN) est une condition d'erreur qui peut arrêter complètement la réplication sur votre réseau. Elle est provoquée par un contrôleur de domaine resté hors connexion trop longtemps puis remis en service, ou par la restauration d'un contrôleur de domaine à l'aide d'une méthode non prise en charge.

Une cause sous-jacente de la restauration du numéro de séquence de mise à jour concerne la méthode de suppression des objets dans l'environnement multimaître Active Directory. Lorsqu’un objet est supprimé sur un contrôleur de domaine, au lieu d'être simplement supprimé, il est désactivé (objet tombstone) afin de pouvoir être répliqué dans d'autres contrôleurs de domaine, les avertissant ainsi de la suppression. En particulier, un objet tombstone possède un attribut isDeleted qui est défini sur TRUE. Afin de réduire la taille de l'objet tombstone, la plupart des valeurs contenues dans l'objet, comme la description, les informations personnelles et l'appartenance de groupe d'un objet utilisateur, sont supprimées (pour plus d'informations sur ce processus, voir l'article de Gil Kirkpatrick « Réanimation des objets tombstone d'Active Directory », disponible en ligne à l'adresse technetmagazine.com/issues/2007/09).

La restauration du numéro de séquence de mise à jour peut survenir parce que ces objets tombstone ne subsistent pas indéfiniment. Ils sont complètement purgés de la base de données Active Directory après 60 ou 180 jours par défaut (selon la version de Windows Server® que vous exécutiez lors de la création de votre environnement Active Directory). Cette période de 60 à 180 jours est appelée durée de vie de désactivation. Tous les contrôleurs de domaine doivent être capables d'effectuer une réplication au moins une fois pendant cette période sans quoi ils deviennent pire qu'inutiles : ils créent une opportunité pour la restauration du numéro de séquence de mise à jour. Essentiellement, la restauration du numéro de séquence de mise à jour survient lorsqu'un contrôleur de domaine est tellement périmé qu'il a « manqué » un ou plusieurs objets tombstone et est incapable de mettre à jour sa copie locale de la base de données Active Directory sur celle des autres contrôleurs de domaine. Pour éviter cela, tout contrôleur de domaine qui est resté hors connexion plus longtemps que la durée de vie de désactivation ne doit pas être remis en marche ; il doit être reconstruit entièrement après suppression des métadonnées de l'ancien contrôleur de domaine d'Active Directory en suivant les étapes indiquées dans l'article de la Base de connaissances de Microsoft 216498 (support.microsoft.com/kb/216498).

La restauration du numéro de séquence de mise à jour survient également lorsqu'un contrôleur de domaine a été restauré par une méthode non prise en charge, en général en utilisant un outil de clonage de disque ou de capture d'image. Lorsque cela se produit, la base de données Active Directory restaurée ne se rend pas compte qu'elle « revient en arrière », car la méthode de restauration n'était pas compatible avec Active Directory. Dans Windows 2000 et dans la version préliminaire initiale de Windows Server 2003, il était difficile de détecter la restauration du numéro de séquence de mise à jour. Toutefois, Windows Server 2003 SP1, ainsi que le prochain Windows Server 2008 sont dotés de contrôles intégrés pour la détection des contrôleurs de domaine incorrectement restaurés. Dans ces versions de système d'exploitation plus récentes, un contrôleur de domaine enregistre les ID d'événement 1115, 2095, 2103 et 2110 dans le journal des événements des services d'annuaire. Le texte de ces événements, ainsi que les étapes nécessaires pour une récupération après restauration du numéro de séquence de mise à jour, sont disponibles dans l'article de la Base de connaissances 875495 (support.microsoft.com/kb/ 875495) pour Windows Server 2003. (Les informations sur la restauration du numéro de séquence de mise à jour dans Windows 2000 sont disponibles dans l'article de la Base de connaissances 885875, à l'adresse support.microsoft.com/kb/ 885875.)

Mise à jour du modèle multimaître dans 2008

Dans la version à venir de Windows Server 2008, Microsoft a apporté une modification mineure au modèle multimaître en introduisant le contrôleur de domaine en lecture seule (RODC). Le RODC est essentiellement conçu pour les déploiements de succursale, ou pour tout autre scénario sans équipe informatique dédiée. Il est nécessaire dans ces cas d'effectuer des étapes supplémentaires pour assurer l'intégrité d'un contrôleur de domaine particulier. Nous pourrions consacrer un article entier aux détails techniques du RODC, mais nous nous limiterons ici aux points importants que vous devez connaître.

Comme le nom l'indique, la copie de la base de données Active Directory qui réside sur un RODC est en lecture seule. Vous pouvez vous connecter à un RODC pour lire presque toutes les informations dont vous avez besoin, mais vous ne pouvez pas exécuter d'opération d'écriture.

De plus, un RODC n'exécute pas de réplication sortante. Cela représente une différence fondamentale avec le modèle de réplication multimaître que nous avons abordé jusqu'ici. Un RODC reçoit les réplications entrantes depuis d'autres contrôleurs de domaine Windows Server 2008 inscriptibles, mais il ne réplique aucune information vers d'autres contrôleurs de domaine. Cela crée une couche supplémentaire de sécurité, si bien que même si un utilisateur malveillant pouvait modifier Active Directory depuis le RODC, ces modifications ne se propageraient pas au reste de votre environnement.

Le plus intéressant est peut-être le fait que, par défaut, le RODC ne réplique pas les mots de passe utilisateur. Lorsque la base de données Active Directory est répliquée en entrée dans un RODC depuis un contrôleur de domaine inscriptible, tous les objets utilisateur sont répliqués sans les informations de mot de passe de l'utilisateur. Cela fournit encore une autre couche de sécurité dans un environnement de succursale, si bien que si un contrôleur de domaine « s'envole », il n'existe aucune information de mot de passe sur le disque dur du contrôleur de domaine. Dans l'ensemble, l'application de ces modifications à l'idée d'origine de la réplication Active Directory multimaître a créé un modèle beaucoup plus solide pour sécuriser les contrôleurs de domaine dans les succursales ou autres sites distants.

Laura E. Hunter a remporté quatre fois la récompense MVP de Microsoft pour la mise en réseau Windows Server. Elle travaille depuis dix ans dans l'industrie informatique et est l'auteur ou co-auteur de nombreux livres, articles et livres blancs, notamment Active Directory Cookbook, Second Edition (O'Reilly, 2006).

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.