Un contrôleur de domaine Windows Server enregistre l’événement Services d’annuaire 2095 lorsqu’il rencontre une restauration USN

  • Article

Cet article explique comment détecter et récupérer si un contrôleur de domaine Windows Server est restauré de manière incorrecte à l’aide d’une installation basée sur une image du système d’exploitation.

Produits concernés : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 875495

Remarque

Cet article est destiné uniquement aux agents de support technique et aux professionnels de l’informatique. Si vous recherchez de l’aide pour résoudre un problème, contactez la Communauté Microsoft.

Résumé

Cet article décrit un échec de réplication Active Directory silencieux provoqué par une restauration de numéro de séquence de mise à jour (USN). Une restauration USN se produit lorsqu’une version antérieure d’une base de données Active Directory est incorrectement restaurée ou collée sur place.

Lorsqu’une restauration USN se produit, les modifications apportées aux objets et aux attributs qui se produisent sur un contrôleur de domaine ne sont pas répliquées sur d’autres contrôleurs de domaine dans la forêt. Étant donné que les partenaires de réplication croient disposer d’une copie à jour de la base de données Active Directory, les outils de surveillance et de résolution des problèmes tels que Repadmin.exe ne signalent aucune erreur de réplication.

Les contrôleurs de domaine consignent l’événement Des services d’annuaire 2095 dans le journal des événements des services d’annuaire lorsqu’ils détectent une restauration USN. Le texte du message d’événement dirige les administrateurs vers cet article pour en savoir plus sur les options de récupération.

Exemple d’entrée de journal de l’événement 2095

Log Name:      <Service name> Service  
Source:        Microsoft-Windows-ActiveDirectory_DomainService  
Date:          <DateTime>
Event ID:      2095  
Task Category: Replication  
Level:         Error  
Keywords:      Classic  
User:          <USER NAME>  
Computer:      SERVER.contoso.com  
Description:

During an Active Directory Domain Services replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers.

Because the remote DC believes it is has a more up-to-date Active Directory Domain Services database than the local DC, the remote DC will not apply future changes to its copy of the Active Directory Domain Services database or replicate them to its direct and transitive replication partners that originate from this local DC.

If not resolved immediately, this scenario will result in inconsistencies in the Active Directory Domain Services databases of this source DC and one or more direct and transitive replication partners. Specifically the consistency of users, computers and trust relationships, their passwords, security groups, security group memberships and other Active Directory Domain Services configuration data may vary, affecting the ability to log on, find objects of interest and perform other critical operations.

To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or contact your Microsoft product support.

The most probable cause of this situation is the improper restore of Active Directory Domain Services on the local domain controller.

User Actions:

If this situation occurred because of an improper or unintended restore, forcibly demote the DC.

Les rubriques suivantes expliquent comment détecter et récupérer à partir d’une restauration USN dans un contrôleur de domaine Windows Server.

Méthodes prises en charge pour sauvegarder Active Directory sur des contrôleurs de domaine qui exécutent Windows Server 2012 et versions ultérieures

Windows Server 2012 ajoute la prise en charge de l’ID de génération Hyper-Visor (GenID). Cela permet à l’invité virtuel de détecter les volumes de disque qui ont un nouvel ID et de répondre au nouveau GenID. Dans Active Directory, les services d’annuaire réagissent comme si le contrôleur de domaine avait été restauré à partir d’une sauvegarde. Il génère ensuite un nouvel ID d’appel. En utilisant le nouvel ID d’appel, la base de données instance peut entrer la réplication en toute sécurité dans la forêt.

Il s’agit de l’un des scénarios abordés dans Configuration et déploiement de contrôleurs de domaine virtualisés.

Méthodes prises en charge pour sauvegarder Active Directory sur les contrôleurs de domaine qui exécutent Windows Server 2003 ou des versions ultérieures de Windows Server

Sur le cycle de vie d’un contrôleur de domaine, vous devrez peut-être restaurer ou « restaurer » le contenu de la base de données Active Directory à un point correct connu dans le temps. Ou, vous devrez peut-être restaurer des éléments du système d’exploitation hôte d’un contrôleur de domaine, y compris Active Directory, à un point correct connu.

Voici les méthodes prises en charge que vous pouvez utiliser pour restaurer le contenu d’Active Directory :

  • Utilisez un utilitaire de sauvegarde et de restauration prenant en charge Active Directory qui utilise des API fournies par Microsoft et testées par Microsoft. Ces API ne font pas autorité ou restaurent une sauvegarde de l’état du système. La sauvegarde restaurée doit provenir de la même installation du système d’exploitation et du même ordinateur physique ou virtuel en cours de restauration.

  • Utilisez un utilitaire de sauvegarde et de restauration prenant en compte Active Directory qui utilise les API du service de cliché instantané de volume Microsoft. Ces API sauvegardent et restaurent l’état du système du contrôleur de domaine. Le service de cliché instantané de volume prend en charge la création de clichés instantanés uniques dans le temps d’un ou plusieurs volumes sur des ordinateurs exécutant Windows Server 2003, Windows Server 2008 ou Windows Server 2008 R2. Les clichés instantanés à un point dans le temps sont également appelés instantanés. Pour plus d’informations, recherchez « Service de cliché instantané de volume » dans Support Microsoft.

  • Restaurez l’état du système. Évaluez si des sauvegardes d’état système valides existent pour ce contrôleur de domaine. Si une sauvegarde valide de l’état du système a été effectuée avant la restauration incorrecte du contrôleur de domaine, et si la sauvegarde contient des modifications récentes qui ont été apportées sur le contrôleur de domaine, restaurez l’état du système à partir de la sauvegarde la plus récente.

Comportement classique qui se produit lorsque vous restaurez une sauvegarde d’état système prenant en charge Active Directory

Les contrôleurs de domaine Windows Server utilisent des noms usN avec les ID d’appel pour suivre les mises à jour qui doivent être répliquées entre les partenaires de réplication dans une forêt Active Directory.

Les contrôleurs de domaine source utilisent des noms usn pour déterminer les modifications qui ont déjà été reçues par le contrôleur de domaine de destination qui demande des modifications. Les contrôleurs de domaine de destination utilisent des noms usn pour déterminer les modifications qui doivent être demandées aux contrôleurs de domaine source.

L’ID d’appel identifie la version ou l’instanciation de la base de données Active Directory qui s’exécute sur un contrôleur de domaine donné.

Quand Active Directory est restauré sur un contrôleur de domaine à l’aide des API et des méthodes que Microsoft a conçues et testées, l’ID d’appel est correctement réinitialisé sur le contrôleur de domaine restauré. Les contrôleurs de domaine dans la forêt reçoivent une notification de la réinitialisation de l’appel. Par conséquent, ils ajustent leurs valeurs supérieures en filigrane en conséquence.

Logiciels et méthodologies qui provoquent des restaurations USN

Lorsque les environnements, programmes ou sous-systèmes suivants sont utilisés, les administrateurs peuvent contourner les vérifications et validations que Microsoft a conçues pour se produire lorsque l’état du système du contrôleur de domaine est restauré :

  • Démarrage d’un contrôleur de domaine Active Directory dont le fichier de base de données Active Directory a été restauré (copié) en place à l’aide d’un programme de création d’images tel que Norton Ghost.

  • Démarrage d’une image de disque dur virtuel précédemment enregistrée d’un contrôleur de domaine. Le scénario suivant peut entraîner une restauration USN :

    1. Promouvoir un contrôleur de domaine dans un environnement d’hébergement virtuel.
    2. Créez une version instantané ou alternative de l’environnement d’hébergement virtuel.
    3. Laissez le contrôleur de domaine poursuivre la réplication entrante et la réplication sortante.
    4. Démarrez le fichier image du contrôleur de domaine que vous avez créé à l’étape 2.

  • Microsoft Virtual PC 2004, Microsoft Virtual Server 2005 et EMC VMWARE sont des exemples d’environnements d’hébergement virtualisés à l’origine de ce scénario. D’autres environnements d’hébergement virtualisés peuvent également provoquer ce scénario.

  • Pour plus d’informations sur les conditions de prise en charge des contrôleurs de domaine dans les environnements d’hébergement virtuel, consultez Éléments à prendre en compte lorsque vous hébergez des contrôleurs de domaine Active Directory dans des environnements d’hébergement virtuel.

  • Démarrage d’un contrôleur de domaine Active Directory situé sur un volume où le sous-système de disque se charge à l’aide d’images précédemment enregistrées du système d’exploitation sans nécessiter une restauration de l’état du système Active Directory.

    • Scénario A : démarrage de plusieurs copies d’Active Directory situées sur un sous-système de disque qui stocke plusieurs versions d’un volume

      1. Promouvoir un contrôleur de domaine. Localisez le fichier Ntds.dit sur un sous-système de disque qui peut stocker plusieurs versions du volume qui héberge le fichier Ntds.dit.
      2. Utilisez le sous-système de disque pour créer un instantané du volume qui héberge le fichier Ntds.dit pour le contrôleur de domaine.
      3. Continuez à laisser le contrôleur de domaine charger Active Directory à partir du volume que vous avez créé à l’étape 1.
      4. Démarrez le contrôleur de domaine enregistré à l’étape 2 par la base de données Active Directory.

    • Scénario B : Démarrage d’Active Directory à partir d’autres lecteurs dans un miroir défectueux

      1. Promouvoir un contrôleur de domaine. Localisez le fichier Ntds.dit sur un lecteur mis en miroir.
      2. Arrêtez la miroir.
      3. Poursuivez la réplication entrante et la réplication sortante à l’aide du fichier Ntds.dit sur le premier lecteur du miroir.
      4. Démarrez le contrôleur de domaine à l’aide du fichier Ntds.dit sur le deuxième lecteur du miroir.

Même s’il n’est pas prévu, chacun de ces scénarios peut entraîner la restauration des contrôleurs de domaine vers une version antérieure de la base de données Active Directory par des méthodes non prises en charge. La seule façon prise en charge de restaurer le contenu d’Active Directory ou l’état local d’un contrôleur de domaine Active Directory consiste à utiliser un utilitaire de sauvegarde et de restauration prenant en charge Active Directory pour restaurer une sauvegarde de l’état du système qui provient de la même installation du système d’exploitation et du même ordinateur physique ou virtuel en cours de restauration.

Microsoft ne prend en charge aucun autre processus qui prend une instantané des éléments de l’état système d’un contrôleur de domaine Active Directory et copie les éléments de cet état système dans une image de système d’exploitation. À moins qu’un administrateur n’intervienne, ces processus entraînent une restauration USN. Avec cette restauration USN, les partenaires de réplication directe et transitive d’un contrôleur de domaine restauré de manière incorrecte ont des objets incohérents dans leurs bases de données Active Directory.

Effets d’une restauration USN

Lorsque des restaurations USN se produisent, les modifications apportées aux objets et aux attributs ne sont pas répliquées par les contrôleurs de domaine de destination qui ont déjà vu l’USN.

Étant donné que ces contrôleurs de domaine de destination pensent qu’ils sont à jour, aucune erreur de réplication n’est signalée dans les journaux des événements du service d’annuaire ou par les outils de surveillance et de diagnostic.

La restauration USN peut affecter la réplication de n’importe quel objet ou attribut dans n’importe quelle partition. L’effet secondaire le plus fréquemment observé est que les comptes d’utilisateur et d’ordinateur créés sur le contrôleur de domaine de restauration n’existent pas sur un ou plusieurs partenaires de réplication. Ou bien, les mises à jour de mot de passe qui proviennent du contrôleur de domaine de restauration n’existent pas sur les partenaires de réplication.

Les étapes suivantes montrent la séquence d’événements susceptibles d’entraîner une restauration USN. Une restauration USN se produit lorsque l’état du système du contrôleur de domaine est restauré dans le temps à l’aide d’une restauration de l’état système non prise en charge.

  1. Un administrateur promeut trois contrôleurs de domaine dans un domaine. (Dans cet exemple, les contrôleurs de domaine sont DC1, DC2 et DC2, et le domaine est Contoso.com.) DC1 et DC2 sont des partenaires de réplication directe. DC2 et DC3 sont également des partenaires de réplication directe. DC1 et DC3 ne sont pas des partenaires de réplication directe, mais reçoivent des mises à jour d’origine transitivement via DC2.

  2. Un administrateur crée 10 comptes d’utilisateur qui correspondent aux USN 1 à 10 sur DC1. Tous ces comptes sont répliqués vers DC2 et DC3.

  3. Une image disque d’un système d’exploitation est capturée sur DC1. Cette image contient un enregistrement d’objets qui correspondent aux USN locaux 1 à 10 sur DC1.

  4. Les modifications suivantes sont apportées dans Active Directory :

    • Les mots de passe des 10 comptes d’utilisateur créés à l’étape 2 sont réinitialisés sur DC1. Ces mots de passe correspondent aux USN 11 à 20. Les 10 mots de passe mis à jour sont répliqués vers DC2 et DC3.
    • 10 nouveaux comptes d’utilisateur qui correspondent aux USN 21 à 30 sont créés sur DC1. Ces 10 comptes d’utilisateur sont répliqués vers DC2 et DC3.
    • 10 nouveaux comptes d’ordinateur qui correspondent aux USN 31 à 40 sont créés sur DC1. Ces 10 comptes d’ordinateur sont répliqués vers DC2 et DC3.
    • 10 nouveaux groupes de sécurité correspondant aux USN 41 à 50 sont créés sur DC1. Ces 10 groupes de sécurité sont répliqués vers DC2 et DC3.

  5. DC1 subit une défaillance matérielle ou logicielle. L’administrateur utilise un utilitaire de création d’images de disque pour copier l’image du système d’exploitation créée à l’étape 3. DC1 commence maintenant par une base de données Active Directory qui connaît les noms usn 1 à 10.

    Étant donné que l’image du système d’exploitation a été copiée sur place et qu’aucune méthode prise en charge pour restaurer l’état du système n’a été utilisée, DC1 continue d’utiliser le même ID d’appel que celui qui a créé la copie initiale de la base de données et toutes les modifications jusqu’à USN 50. DC2 et DC3 conservent également le même ID d’appel pour DC1, ainsi qu’un vecteur usn 50 pour DC1. (Un vecteur à jour est le status actuel des dernières mises à jour d’origine qui se produisent sur tous les contrôleurs de domaine pour une partition de répertoire donnée.)

    À moins qu’un administrateur n’intervienne, DC2 et DC3 ne répliquent pas les modifications qui correspondent aux usN 11 à 50 locaux qui proviennent de DC1. En outre, selon l’ID d’appel utilisé par DC2, DC1 a déjà connaissance des modifications qui correspondent à USN 11 à 50. Par conséquent, DC2 n’envoie pas ces modifications. Étant donné que les modifications apportées à l’étape 4 n’existent pas sur DC1, les demandes d’ouverture de session échouent avec une erreur « accès refusé ». Cette erreur se produit soit parce que les mots de passe ne correspondent pas, soit parce que le compte n’existe pas lorsque les comptes plus récents s’authentifient de manière aléatoire auprès de DC1.

  6. Les administrateurs qui surveillent l’intégrité de la réplication dans la forêt notent les situations suivantes :

    • L’outil Repadmin /showreps en ligne de commande signale que la réplication Active Directory bidirectionnelle entre DC1 et DC2 et entre DC2 et DC3 se produit sans erreur. Cette situation rend toute incohérence de réplication difficile à détecter.

    • Les événements de réplication dans les journaux des événements du service d’annuaire des contrôleurs de domaine qui exécutent Windows Server n’indiquent pas d’échecs de réplication dans les journaux des événements du service d’annuaire. Cette situation rend toute incohérence de réplication difficile à détecter.

    • Utilisateurs et ordinateurs Active Directory ou l’outil d’administration Active Directory (Ldp.exe) affichent un nombre différent d’objets et de métadonnées d’objet lorsque les partitions d’annuaire de domaine sur DC2 et DC3 sont comparées à la partition sur DC1. La différence est l’ensemble des modifications qui correspondent aux modifications USN 11 à 50 à l’étape 4.

      Remarque

      Dans cet exemple, le nombre d’objets différents s’applique aux comptes d’utilisateur, aux comptes d’ordinateur et aux groupes de sécurité. Les différentes métadonnées d’objet représentent les différents mots de passe de compte d’utilisateur.

    • Les demandes d’authentification utilisateur pour les 10 comptes d’utilisateur créés à l’étape 2 génèrent parfois une erreur « accès refusé » ou « mot de passe incorrect ». Cette erreur peut se produire car il existe une incompatibilité de mot de passe entre ces comptes d’utilisateur sur DC1 et les comptes sur DC2 et DC3. Les comptes d’utilisateur qui rencontrent ce problème correspondent aux comptes d’utilisateur créés à l’étape 4. Les comptes d’utilisateur et les réinitialisations de mot de passe à l’étape 4 n’ont pas été répliqués sur d’autres contrôleurs de domaine dans le domaine.

  7. DC2 et DC3 commencent à répliquer les mises à jour d’origine entrantes qui correspondent à des numéros USN supérieurs à 50 à partir de DC1. Cette réplication se déroule normalement sans intervention administrative, car le seuil de vecteur de mise à jour précédemment enregistré, USN 50, a été dépassé. (USN 50 était le vecteur USN à jour enregistré pour DC1 sur DC2 et DC3 avant que DC1 ne soit mis hors connexion et restauré.) Toutefois, les nouvelles modifications qui correspondent aux USN 11 à 50 sur le DC1 d’origine après la restauration non prise en charge ne seront jamais répliquées sur DC2, DC3 ou leurs partenaires de réplication transitive.

Bien que les symptômes mentionnés à l’étape 6 représentent certains des effets qu’une restauration USN peut avoir sur les comptes d’utilisateur et d’ordinateur, une restauration USN peut empêcher tout type d’objet dans une partition Active Directory de se répliquer. Ces types d’objets sont les suivants :

  • Topologie et planification de la réplication Active Directory

  • L’existence de contrôleurs de domaine dans la forêt et les rôles que ces contrôleurs de domaine détiennent

    Remarque

    Ces rôles incluent le catalogue global, les allocations d’identificateur relatif (RID) et les opérations master rôles. (Les rôles master d’opérations sont également appelés opérations de master unique flexibles ou FSMO.)

  • L’existence de partitions de domaine et d’application dans la forêt

  • L’existence de groupes de sécurité et leurs appartenances actuelles aux groupes

  • Enregistrement DNS dans les zones DNS intégrées à Active Directory

La taille du trou USN peut représenter des centaines, des milliers, voire des dizaines de milliers de modifications apportées aux utilisateurs, aux ordinateurs, aux approbations, aux mots de passe et aux groupes de sécurité. (Le trou USN est défini par la différence entre le nombre USN le plus élevé qui existait lors de la restauration de la sauvegarde de l’état du système et le nombre de modifications d’origine qui ont été créées sur le contrôleur de domaine restauré avant sa mise hors connexion.)

Détecter une restauration USN sur un contrôleur de domaine Windows Server

Étant donné qu’une restauration USN est difficile à détecter, un contrôleur de domaine Windows Server 2003 SP1 ou version ultérieure enregistre l’événement 2095 lorsqu’un contrôleur de domaine source envoie un numéro USN précédemment reconnu à un contrôleur de domaine de destination sans modification correspondante de l’ID d’appel.

Pour empêcher la création de mises à jour uniques d’origine d’Active Directory sur le contrôleur de domaine restauré de manière incorrecte, le service Net Logon est suspendu. Lorsque le service Net Logon est suspendu, les comptes d’utilisateur et d’ordinateur ne peuvent pas modifier le mot de passe sur un contrôleur de domaine qui ne répliquera pas ces modifications en sortie. De même, les outils d’administration Active Directory favorisent un contrôleur de domaine sain lorsqu’ils effectuent des mises à jour des objets dans Active Directory.

Sur un contrôleur de domaine, les messages d’événement qui ressemblent à ce qui suit sont enregistrés si les conditions suivantes sont remplies :

  • Un contrôleur de domaine source envoie un numéro USN précédemment reconnu à un contrôleur de domaine de destination.
  • Il n’y a aucune modification correspondante dans l’ID d’appel.

Ces événements peuvent être capturés dans le journal des événements du service d’annuaire. Toutefois, elles peuvent être remplacées avant d’être observées par un administrateur.

Vous pouvez soupçonner qu’une restauration USN s’est produite. Toutefois, vous ne voyez pas les événements de corrélation dans le journal des événements du service d’annuaire. Dans ce scénario, case activée pour l’entrée de Registre Dsa non accessible en écriture. Cette entrée fournit la preuve légale qu’une restauration USN s’est produite.

  • Sous-clé de Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
  • Entrée de Registre : Dsa non accessible en écriture
  • Valeur : 0x4

La suppression ou la modification manuelle de la valeur d’entrée de Registre Dsa Non accessible en écriture place le contrôleur de domaine de restauration dans un état définitivement non pris en charge. Par conséquent, ces modifications ne sont pas prises en charge. Plus précisément, la modification de la valeur supprime le comportement de quarantaine ajouté par le code de détection de restauration USN. Les partitions Active Directory sur le contrôleur de domaine de restauration seront en permanence incohérentes avec les partenaires de réplication directe et transitive dans la même forêt Active Directory.

Récupérer à partir d’une restauration USN

Il existe trois approches pour récupérer à partir d’une restauration USN.

References