Partager via

Un contrôleur de domaine Windows Server journalise 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.

Numéro de base de connaissances d’origine : 875495

Note

Cet article est destiné uniquement aux agents de support technique et aux professionnels de l’informatique. Si vous recherchez de l’aide sur un problème, demandez à 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 en 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 qu’ils disposent d’une copie à jour de la base de données Active Directory, de la supervision et des outils de résolution des problèmes tels que Repadmin.exe ne signalent aucune erreur de réplication.

Les contrôleurs de domaine enregistrent l’événement Directory Services 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 d’é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 les contrôleurs de domaine exécutant 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 Directory réagissent comme si le contrôleur de domaine a été restauré à partir d’une sauvegarde. Il génère ensuite un nouvel ID d’appel. En utilisant le nouvel ID d’appel, l’instance de base de données peut entrer à nouveau en toute sécurité la réplication dans la forêt.

Il s’agit de l’un des scénarios abordés dans le déploiement et la configuration du contrôleur de domaine virtualisé.

Méthodes prises en charge pour sauvegarder Active Directory sur les contrôleurs de domaine exécutant Windows Server 2003 ou 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 bon moment connu. 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 bon point 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 les API fournies par Microsoft et testées par Microsoft. Ces API ne font pas autorité ou restaurent avec autorité 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 ou multiples 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. Vérifiez s’il existe des sauvegardes de l’état du système valides pour ce contrôleur de domaine. Si une sauvegarde d’état système valide a été effectuée avant la restauration incorrecte du contrôleur de domaine restauré et si la sauvegarde contient des modifications récentes 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 sources utilisent des 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 USN pour déterminer quelles modifications doivent être demandées auprès des contrôleurs de domaine sources.

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é.

Lorsque Active Directory est restauré sur un contrôleur de domaine à l’aide des API et 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 de la forêt reçoivent la notification de la réinitialisation d’appel. Par conséquent, ils ajustent leurs valeurs de filigrane élevée 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 les 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 d’imagerie 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 un instantané ou une autre version de l’environnement d’hébergement virtuel.
    3. Laissez le contrôleur de domaine continuer à répliquer et à répliquer sortant.
    4. Démarrez le fichier image du contrôleur de domaine que vous avez créé à l’étape 2.

  • Les exemples d’environnements d’hébergement virtualisés qui provoquent ce scénario incluent Microsoft Virtual PC 2004, Microsoft Virtual Server 2005 et EMC VMWARE. 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 Les é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 de restauration de l’état système d’Active Directory.

    • Scénario R : 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. Recherchez 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 rompu

      1. Promouvoir un contrôleur de domaine. Recherchez le fichier Ntds.dit sur un lecteur en miroir.
      2. Arrêtez le miroir.
      3. Passez à 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 de 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 méthode prise en charge pour 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 provenant 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 pas en charge tout autre processus qui prend un 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. Sauf si un administrateur intervient, ces processus entraînent une restauration USN. Cette restauration USN entraîne la restauration directe et transitive des partenaires de réplication d’un contrôleur de domaine restauré de manière incorrecte avec des objets incohérents dans leurs bases de données Active Directory.

Effets d’une restauration USN

Quand une restauration d’USN se produit, les modifications apportées aux objets et attributs ne sont pas répliquées en entrée par les contrôleurs de domaine de destination qui ont déjà vu l’USN.

Étant donnée 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 de répertoire ou via les outils de supervision et de diagnostics.

La restauration du nombre de séquences de mise à jour (USN) peut affecter la réplication d’un objet ou d’un attribut dans n’importe quelle partition. L’effet secondaire le plus fréquemment observé est l’absence, sur un ou plusieurs partenaires de réplication, des comptes d’utilisateurs et d’ordinateurs créés sur le contrôleur de domaine de restauration ; Dans certains cas, les mises à jour de mot de passe provenant 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 qui peuvent 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 d’é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 sur DC2 et DC3.

  3. Une image de disque d’un système d’exploitation est capturée sur DC1. Cette image a 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 de tous les 10 comptes d’utilisateur créés à l’étape 2 sont réinitialisés sur DC1. Ces mots de passe correspondent aux codes USN 11 à 20. Tous les 10 mots de passe mis à jour sont répliqués sur DC2 et DC3.
    • 10 nouveaux comptes d’utilisateur correspondant aux USN 21 à 30 sont créés sur DC1. Ces 10 comptes d’utilisateur sont répliqués sur 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 sur DC2 et DC3.
    • 10 nouveaux groupes de sécurité qui correspondent aux USN 41 à 50 sont créés sur DC1. Ces 10 groupes de sécurité sont répliqués sur DC2 et DC3.

  5. DC1 rencontre une défaillance matérielle ou une défaillance logicielle. L’administrateur utilise un utilitaire d’imagerie de disque pour copier l’image du système d’exploitation créée à l’étape 3 en place. DC1 commence maintenant par une base de données Active Directory qui a connaissance des USN 1 à 10.

    Étant donné que l’image du système d’exploitation a été copiée en place et qu’une méthode prise en charge pour restaurer l’état du système n’a pas é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 apportées à USN 50. DC2 et DC3 conservent également le même ID d’appel pour DC1, ainsi qu’un vecteur à jour usN 50 pour DC1. (Un vecteur à jour est l’état actuel des dernières mises à jour d’origine sur tous les contrôleurs de domaine pour une partition d’annuaire donnée.)

    Sauf si un administrateur intervient, DC2 et DC3 ne répliquent pas les modifications qui correspondent au USN local 11 à 50 provenant de DC1. En outre, selon l’ID d’appel que DC2 utilise, 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 ou parce que le compte n’existe pas lorsque les comptes plus récents s’authentifient de façon 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 aucun échec 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 différentes 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.

      Note

      Dans cet exemple, le nombre d’objets différent s’applique aux comptes d’utilisateur, aux comptes d’ordinateur et aux groupes de sécurité. Les métadonnées d’objet différentes 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 occasionnellement une erreur « accès refusé » ou « mot de passe incorrect ». Cette erreur peut se produire, car une incompatibilité de mot de passe existe 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 du domaine.

  7. DC2 et DC3 commencent à répliquer des mises à jour d’origine entrantes qui correspondent aux nombres USN supérieurs à 50 à partir de DC1. Cette réplication se poursuit normalement sans intervention administrative, car le seuil de vecteur de mise à jour enregistré précédemment, USN 50, a été dépassé. (USN 50 était le vecteur USN à jour enregistré pour DC1 sur DC2 et DC3 avant que DC1 n’ait été 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 vers DC2, DC3 ou leurs partenaires de réplication transitifs.

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 n’importe quelle partition Active Directory de répliquer. Ces types de données incluent :

  • La topologie et le calendrier de réplication d’Active Directory

  • L’existence de contrôleurs de domaine dans la forêt et les rôles qu’ils occupent

    Note

    Ces rôles incluent le catalogue global, les allocations d’identificateur relatif (RID) et les rôles maîtres des opérations. (Les rôles de maître d’opérations sont également appelés opérations de base 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 leur appartenance à des groupes actuels

  • Inscription des enregistrements 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 pour les utilisateurs, les ordinateurs, les approbations, les mots de passe et les 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 sauvegarde de l’état du système restauré et le nombre de modifications d’origine qui ont été créées sur le contrôleur de domaine restauré avant qu’elle ne soit 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 journalise 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 éviter la création de mises à jour d’origine uniques Active Directory sur le contrôleur de domaine mal restauré, le service Accès réseau est interrompu. Lorsque le service Net Logon est suspendu, les comptes d’utilisateur et d’ordinateur ne peuvent pas modifier le mot de passe d’un contrôleur de domaine qui ne répliquera pas ces modifications en sortie. De même, les outils d’administration Active Directory privilégient un contrôleur de domaine sain lorsqu’ils effectuent des mises à jour d’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’invocation.

Ces événements peuvent être enregistrés dans le journal des événements du service de répertoire. Toutefois, ils peuvent être remplacés avant d’être examinés par un administrateur.

Vous pouvez soupçonner qu’une restauration USN s’est produite. Toutefois, vous ne voyez pas les événements correspondants dans le journal des événements du service d’annuaire. Dans ce scénario, recherchez l’entrée de Registre Dsa Not Writable. Cette entrée vous fournit la preuve qu’une restauration USN a été effectuée.

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

La suppression ou la modification manuelle de la valeur d’entrée de Registre Dsa Not Writable place le contrôleur de domaine de restauration dans un état définitivement non pris en charge. C’est pourquoi ces changements ne sont pas pris en charge. Plus précisément, la modification de la valeur supprime le comportement de quarantaine ajouté par le code de détection de la restauration USN. Les partitions Active Directory du contrôleur de domaine de restauration seront définitivement incohérentes avec les partenaires de réplication directs et transitives 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