Les objets persistants peuvent rester après avoir ramené un serveur de catalogue global obsolète en ligne

Article
05/24/2024

Cet article décrit les procédures de nettoyage des objets qui sont réintroduis dans AD après avoir ramené un contrôleur de domaine hors connexion en ligne.

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

Symptômes

Vous apportez un contrôleur de domaine (DC) ou un serveur de catalogue global en ligne une fois qu’il a été hors connexion depuis longtemps. Une fois qu’il est en ligne, vous observez un ou plusieurs des problèmes suivants :

Les messages électroniques ne sont pas remis à un utilisateur dont l’objet utilisateur a été déplacé entre les domaines. Une fois que vous avez remis en ligne le contrôleur de domaine ou le serveur de catalogue global obsolète, les deux instances de l’objet utilisateur apparaissent dans le catalogue global. Les deux objets ont la même adresse de messagerie. Par conséquent, les messages électroniques ne peuvent pas être remis.
Un compte d’utilisateur qui n’existe plus apparaît toujours dans la liste d’adresses globale.
Un groupe universel qui n’existe plus apparaît toujours dans le jeton d’accès d’un utilisateur.
D’autres contrôleurs de domaine ou serveurs de catalogue globaux journalisent des événements tels que EventID 1084, il n’existe aucun objet de ce type sur le serveur. Une autre réplication est bloquée sur les contrôleurs de domaine ou les serveurs de catalogue globaux concernés.

Cause

Ces problèmes peuvent se produire si le serveur de catalogue global ou dc a été hors connexion depuis plus longtemps que la valeur de l’attribut Tombstone-Lifetime des objets utilisateur.

Pour plus d’informations sur l’attribut Tombstone-Lifetime , consultez l’attribut Tombstone-Lifetime.

L’attribut Tombstone-Lifetime définit le nombre de jours avant la suppression d’un objet supprimé des services d’annuaire. Cela permet de supprimer des objets de serveurs répliqués et d’empêcher les restaurations de réintroduire un objet supprimé. La valeur par défaut est 180 jours. Après ce temps, Active Directory n’a plus besoin de mémoriser la modification.

Si un contrôleur de domaine ou un serveur de catalogue global est hors connexion pendant plus longtemps que la valeur de l’attribut Tombstone-Lifetime , sa copie d’Active Directory (ou du catalogue global) peut contenir des objets qui ont été supprimés sur les autres contrôleurs de domaine. Toutefois, les autres contrôleurs de domaine ne se rappellent plus que les objets ont été supprimés. Lorsque vous mettez en ligne le contrôleur de domaine hors connexion, il synchronise sa copie d’Active Directory avec le reste du domaine. Étant donné que les informations relatives aux suppressions ont été ignorées, le contrôleur de domaine réplique les objets affectés (appelés objets persistants) vers le reste du domaine.

En général, AD DS utilise un modèle de réplication de cohérence libre, dans lequel certains contextes d’affectation de noms (également appelés partitions d’annuaire) sont en lecture/écriture et d’autres sont en lecture seule. Lorsqu’un contrôleur de domaine qui reçoit un objet répliqué qui appartient à un contexte de nommage en lecture/écriture et que cet objet n’existe pas déjà dans la copie locale de l’arborescence d’informations d’annuaire (DIT), le contrôleur de domaine crée l’objet. À mesure que le processus de réplication se poursuit, l’objet réapparaît sur tous les contrôleurs de domaine du domaine.

Les contrôleurs de domaine et les serveurs de catalogue globaux peuvent également utiliser un modèle de cohérence de réplication strict. Sous ce modèle, lorsque le contrôleur de domaine reçoit un objet répliqué qui n’existe pas déjà dans le dit local, le contrôleur de domaine cesse de recevoir ou d’envoyer des données répliquées et enregistre des événements tels que l’ID d’événement 1084, « Il n’existe aucun objet de ce type sur le serveur ». Pour plus d’informations sur la cohérence de réplication stricte, notamment les circonstances dans lesquelles les contrôleurs de domaine peuvent utiliser ce modèle par défaut, consultez la base de connaissances 910205, informations sur les objets persistants dans une forêt Windows Server Active Directory. Pour plus d’informations sur les problèmes de pierre tombstone, consultez KB216993 durée de conservation utile d’une sauvegarde à l’état du système d’Active Directory.

Résolution 1 : déterminer si Active Directory a des objets persistants et éviter les objets persistants futurs

La base de connaissances 910205 explique plusieurs façons de déterminer si votre système Active Directory a accumulé des objets persistants. La base de connaissances 910205 décrit également les étapes à suivre pour empêcher l’accumulation d’objets persistants.

Résolution 2 : Supprimer les objets persistants

Si l’objet ne doit pas exister dans Active Directory du tout (par exemple, si l’objet a été réintroduisé par un contrôleur de domaine obsolète), vous pouvez supprimer les objets avec les outils standard (tels que ADSIEdit ou le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory).

Il est facile de supprimer des objets persistants pour les contextes d’affectation de noms en lecture/écriture. Dans Windows Server 2003 et versions ultérieures, vous pouvez supprimer des objets persistants à l’aide de la commande repadmin /removelingeringobjects. Pour plus d’informations sur l’utilisation de RepAdmin, consultez l’ID d’événement de réplication Active Directory 1388 ou 1988 : un objet persistant est détecté.

Cet article explique comment supprimer des objets persistants qui sont déjà apparus dans des contextes d’affectation de noms en lecture seule, tels que des partitions d’annuaire sur des serveurs de catalogue globaux ou des contrôleurs de domaine en lecture seule . Les fonctionnalités décrites dans la section Plus d’informations existent toujours dans les systèmes d’exploitation plus récents et peuvent toujours être utiles pour résoudre les problèmes inattendus de comportement RepAdmin.

Plus d’informations

Cette procédure nécessite l’objectGUID d’un contrôleur de domaine qui a une copie en lecture/écriture de l’objet et l’objectGUID de l’objet lui-même. Si vous devez supprimer plusieurs objets, déterminez si l’un des objets se trouve dans une relation parent/enfant (vous pouvez déterminer cela à partir des noms uniques des objets). Si c’est le cas, commandez les suppressions afin que tous les objets enfants soient supprimés avant leurs objets parents.

Cette procédure comporte trois étapes principales, que vous devez effectuer sur un ordinateur qui a accès à la forêt (et vous devez utiliser un compte d’utilisateur disposant d’autorisations d’administration sur la forêt) :

Obtenez le nom unique et ObjectGUID de l’objet persistant.
Identifiez un contrôleur de domaine dans le domaine d’objet.
Supprimez les objets persistants. Sélectionnez l’une des méthodes suivantes :
- Supprimez quelques objets persistants.
- Supprimez un grand nombre d’objets persistants.

Important

Chaque serveur de catalogue global sur lequel vous envisagez d’exécuter les opérations de suppression (étape 3) doit disposer d’une connectivité réseau au contrôleur de domaine que vous avez identifié (étape 2).

Pour plus d’informations sur la résolution des problèmes, consultez les sections suivantes :

Message d’erreur lors de l’exécution de Walkservers.cmd pour modifier de nombreux objets persistants dans l’environnement.
Message d’erreur 87 lors de la suppression d’objets persistants dans l’environnement.

Obtenir le nom unique et ObjectGUID de l’objet persistant

La meilleure façon d’identifier le domaine dans lequel se trouve un objet (et à partir de celui-ci pour déterminer le nom d’un contrôleur de domaine qui a une copie en lecture/écriture de l’objet) consiste à récupérer le nom unique de l’objet. Vous pouvez rechercher le nom (ou les parties du nom) de l’objet à l’aide de l’outil Ldp.exe. Pour ce faire, procédez comme suit :

Démarrez Ldp.exe.

Dans la plupart des versions de Windows, sélectionnez Démarrer>l’exécution et entrez ldp.exe. Dans les versions antérieures de Windows (comme Windows Server 2003 SP1), cet outil est disponible en tant qu’un des outils de support.
Sélectionnez Connexion>Connecter. Dans la zone Serveur , tapez le nom d’un serveur de catalogue global. Dans la zone Port , tapez 3268, puis sélectionnez OK.
Sélectionnez Liaison de connexion>. Tapez des informations d’identification valides si vos informations d’identification actuelles ne sont pas suffisantes pour interroger tout le contenu du catalogue global. Cliquez sur OK.
Sélectionnez Arborescence d’affichage>. Entrez le nom unique de la racine de la forêt, puis sélectionnez OK.
Dans la liste des arborescences, cliquez avec le bouton droit sur la racine de la forêt, puis sélectionnez Rechercher.
Dans la zone Filtre , tapez un filtre qui utilise le <format attribut> = <valeur> .

Dans le texte de filtre, <l’attribut représente l’attribut> objet à rechercher et< la valeur> représente les critères pour lesquels vous effectuez une recherche. Vous pouvez utiliser ***** en tant que caractère générique dans la valeur, et vous pouvez utiliser une expression.

Pour plus d’informations sur la syntaxe de filtre LDAP (Lightweight Directory Access Protocol), consultez La syntaxe du filtre de recherche.

Par exemple, pour rechercher des objets pour lesquels l’attribut sAMAccountName a une valeur de testuser, type (sAMAccountName = testuser) dans la zone Filtre. Pour rechercher un objet utilisateur, les attributs suivants sont les plus utiles :
- cn
- userPrincipalName
- sAMAccountName
- nom
- courrier
- sn
Pour rechercher un objet de groupe, les attributs suivants sont les plus utiles :
- cn
- sAMAccountName
- nom
Sous Étendue, sélectionnez Subtree.
Sélectionnez la zone Attributs , puis sélectionnez la fin de la chaîne d’attribut. Type ; objectGUID à la fin de la chaîne.

Dans certaines versions de Ldp, vous devez sélectionner Options pour afficher la zone Attributs.
Pour exécuter la requête, sélectionnez Exécuter.

Les résultats s’affichent dans la fenêtre principale du fournisseur de services.
Déterminez quels objets répertoriés dans les résultats doivent être supprimés du catalogue global. Une indication indiquant que vous avez trouvé un objet incorrect est que l’objet n’existe pas sur une copie en lecture/écriture du contexte d’affectation de noms.
Si les objets que vous recherchez ne sont pas inclus dans les résultats de la requête, réexécutez le filtre et réexécutez la recherche.
Si vous avez identifié un objet persistant, notez les valeurs de ses attributs DN et objectGUID . Vous aurez besoin de ces valeurs ultérieurement.

Identifier un contrôleur de domaine dans le domaine d’objet

La valeur de l’attribut DN de l’objet inclut le domaine de l’objet. Lorsque vous connaissez le domaine, vous pouvez identifier un serveur de catalogue dc ou global au sein du domaine. Pour ce faire, procédez comme suit.

Vérifiez les parties dc= de la valeur DN . Combinez les parties dc= pour obtenir le nom de domaine.

Par exemple, si un objet a la valeur DN de cn=FirstName LastName,cn=Users,dc=name1,dc=name2,dc=com, l’objet se trouve dans le name1.name2.com domaine.
Pour localiser un contrôleur de domaine (ou un serveur de catalogue global) dans ce domaine, ouvrez Utilisateurs et ordinateurs Active Directory, ouvrez le conteneur de domaine, puis ouvrez le conteneur contrôleurs de domaine.
Ouvrez une fenêtre d’invite de commandes avec élévation de privilèges et entrez repadmin /showreps dc-name.

Note

Dans cette commande, dc-name représente le nom de l’ordinateur du contrôleur de domaine que vous avez identifié à l’étape 2.

Dans les versions antérieures de Windows (comme Windows Server 2003 SP1), RepAdmin est disponible en tant qu’un des outils de support.

Repadmin produit des résultats qui ressemblent à ce qui suit :

Default-First-Site-Name\WS2016-DC-01 DSA Options : IS_GC Site Options : (none) GUID de l’objet DSA : <GUID> DSA invocationID : invocationID : <invocationID>
Notez la valeur du GUID de l’objet DSA. Il s’agit de la valeur objectGUID du contrôleur de domaine.

Supprimer des objets persistants

Utilisez les méthodes suivantes pour supprimer des objets persistants.

Supprimer quelques objets persistants de quelques serveurs de catalogue globaux

Si vous n’avez que quelques objets et catalogues globaux, procédez comme suit pour supprimer les objets à l’aide de Ldp.exe :

Utilisez les informations d’identification de l’administrateur d’entreprise pour vous connecter à chaque serveur de catalogue global qui contient une copie de l’objet persistant.
Démarrez Ldp.exe et connectez-vous au port 389 sur le contrôleur de domaine local (laissez la zone Serveur vide).
Sélectionnez Liaison de connexion>. Laissez toutes les zones vides (vous êtes déjà connecté en tant qu’administrateur d’entreprise).
Sélectionnez Parcourir>la modification.
Configurez les entrées suivantes dans la boîte de dialogue Modifier :
1. Laissez la zone Dn vide.
2. Dans la zone Attribut , tapez RemoveLingeringObject.
3. Dans la zone Valeurs , tapez une valeur qui utilise le format suivant :
  
  <GUID=dcGUID> : <GUID=objectGUID>
  
  Dans cette valeur, dcGUID représente le GUID du contrôleur de domaine que vous avez identifié à l’étape 2 de cette section, et objectGUID représente le GUID de l’objet persistant que vous avez identifié à l’étape 1 de cette section.
  
  La valeur doit ressembler à ce qui suit :
  
  <GUID=<GUID>> : <GUID=<GUID>>
  
  Important
  
  Dans la valeur, n’omettez pas les espaces avant et après le signe deux-points.
4. Sélectionnez Opération>Remplacer, puis entrez.
  
  La zone Liste d’entrées affiche la commande complète.
5. Sélectionnez Exécuter.
  
  Les résultats s’affichent dans la fenêtre principale du fournisseur de services et doivent ressembler à ce qui suit.
  
  Appeler Modifier... ldap_modify_s(ld, '(null)',[1] attrs) ; Modification de « ».

Supprimer un grand nombre d’objets persistants de plusieurs serveurs de catalogue globaux

Si vous devez supprimer un grand nombre d’objets persistants, vous pouvez supprimer plus efficacement en utilisant des scripts qu’en les supprimant manuellement. Pour générer de tels scripts, procédez comme suit :

Créez un dossier et, dans ce dossier, créez des fichiers qui ont les noms suivants :
- Walkservers.cmd
- Walkobjects.cmd
- Modifyrootdse.vbs
- Server-list.txt
- fichier Object-list.txt

Collez le texte suivant dans Walkservers.cmd :

for /f %%j in (server-list.txt) do walkobjects %%j

Collez le texte suivant dans Walkobjects.cmd :

for /f "delims=@" %%i in (object-list.txt) do cscript //NoLogo MODIFYROOTDSE.VBS %1 "%%i" >>update-%1.log

Collez le texte suivant dans Modifyrootdse.vbs :

'********************************************************************
'*
'* File: MODIFYROOTDSE.VBS
'* Created: January 2002
'* Version: 1.0
'*
'* Main Function: Writes Active Directory information to clean up
'* objects as per: Q314282.
'* Usage: Modifyrootdse.vbs <TargetServer> <GUID PAIR>
'* Parameter are fed into the script using a pair of batch files.
'*
'* Copyright (C) 2002 Microsoft Corporation '*
'********************************************************************
OPTION EXPLICIT
ON ERROR RESUME NEXT

Dim objDomain
Dim ObjValue, strServerName, adsLdapPath
Dim i

'Get the command-line arguments

if Wscript.arguments.count <> 2 Then
    Print "Invalid Number of Parameters. Use with WalkServers.CMD and WalkObjects.CMD"
    WScript.quit
End If

strServerName = Wscript.arguments.item(0)
ObjValue = Wscript.arguments.item(1)

adsLdapPath = "LDAP://" & strServerName & "/RootDSE"

Set objDomain = GetObject(adsLdapPath)
    If Err.Number <> 0 Then
    WScript.Echo "Error opening ROOTDSE. Error number is: " & Err.Number & ". Error description is: " & Err.Description & "."
    Set objDomain = Nothing
    WScript.quit
End If

objDomain.Put "RemoveLingeringObject", ObjValue
objDomain.Setinfo

If Err.Number = 0 Then
    WScript.Echo "Object " & ObjValue & " was removed."
Else
    WScript.Echo "Object " & ObjValue & " could not be removed. Error number is: " & Err.Number & ". Error description is: " & Err.Description & "."
End If

WScript.Quit

Note

Si vous démarrez Modifyrootdse.vbs manuellement, veillez à placer entre guillemets tous les paramètres qui contiennent des espaces.

Créez une liste de tous les noms de domaine complets des serveurs de catalogue globaux et des contrôleurs de domaine qui contiennent les objets persistants, puis collez la liste dans Server-list.txt. Utilisez les noms de domaine complets pour éviter les recherches de suffixes DNS.
Pour chaque objet persistant, identifiez un contrôleur de domaine dans le domaine d’objet qui n’a pas de copie de l’objet persistant. En règle générale, il s’agit d’un contrôleur de domaine qui a un contexte de nommage en lecture/écriture dans lequel vous avez supprimé manuellement l’objet persistant. Comme décrit ailleurs dans cet article, utilisez RepAdmin pour obtenir la valeur objectGUID de chaque contrôleur de domaine.
Dans Object-list.txt, créez une liste de paires GUID, au format suivant :

<GUID=dcGUID> : <GUID=objectGUID>

Note

Dans cette valeur, dcGUID représente le GUID du contrôleur de domaine qui n’a pas de copie de l’objet persistant, et objectGUID représente le GUID de l’objet persistant.

Chaque paire doit ressembler à ce qui suit :

<GUID=<GUID>> : <GUID=<GUID>>

Important

Dans la valeur, n’omettez pas les espaces avant et après le signe deux-points.
Exécutez le fichier Walk-servers.cmd.

Pour chaque serveur de catalogue dc ou global répertorié dans Server-list.txt, les scripts génèrent un fichier journal nommé Update-server-name.log. Chaque fichier journal contient une ligne pour chaque objet à supprimer.

Étant donné que les objets persistants peuvent ne pas exister sur chaque serveur répertorié, les erreurs dans les fichiers journaux n’indiquent pas nécessairement un problème. Toutefois, les messages d’erreur de l’opération de formulaire refusés ou d’erreur d’opération indiquent qu’il existe un problème avec les GUID ou avec la syntaxe de la valeur. Si ces erreurs se produisent, vérifiez les éléments suivants :

Vérifiez que les GUID DC sont les GUID appropriés pour les contrôleurs de domaine qui contiennent un contexte de nommage en lecture/écriture du domaine qui contient l’objet.
Assurez-vous que les GUID d’objet identifient les objets persistants dans les contextes d’affectation de noms en lecture seule (serveurs de catalogue globaux ou contrôleurs de domaine réseau).

Erreur lors de l’exécution de Walkservers.cmd pour modifier de nombreux objets persistants dans l’environnement

GUID de l’objet <:<>>< GUID=<GUID>> n’a pas pu être supprimé. Numéro d’erreur : -2147016672. La description de l’erreur est la suivante : .

Cause de cette erreur

Cette erreur se produit lorsque le script s’exécute sur le GUID d’un contrôleur de domaine qui ne contient pas de contexte d’affectation de noms en lecture/écriture qui correspond au contexte d’affectation de noms qui contient l’objet persistant. Vérifiez l’emplacement de l’objet persistant par l’outil Ldp.exe.

Exemple

Dans l’exemple suivant, l’objet persistant à supprimer se trouve dans le domaine corp.company.local. Toutefois, l’entrée <GUID=<GUID>> dans le fichier Objects-list.txt est associée à un contrôleur de domaine qui réside dans le domaine company.local. Ce contrôleur de domaine n’a pas de contexte de nommage en lecture/écriture pour le domaine corp.company.local.

La recherche suivante produit plusieurs objets qui représentent le même utilisateur (Joe) et répertorie leurs valeurs objectGUID .

ldap_search_s(ld, « DC=company,DC=local », 2, « (cn=User*) », attrList, 0, &msg) Result <0> : (null)
Noms de domaine correspondants :
Obtention de 4 entrées :
>> Dn : CN=User, Joe,OU=Exec,OU=Corporate Users,DC=corp,DC=company,DC=local
1> canonicalName : corp.company.local/Corporate Users/Exec/User, Joe ;
1> cn : Utilisateur, Joe ; 1> description : CEO ;
1> displayName : User, Joe ; 1> distinguishedName : CN=User, Joe,OU=Exec,OU=Corporate Users,DC=corp,DC=company,DC=local ; 4> objectClass : top ; person ; organizationalPerson ; user ; user ;
1> objectGUID :< GUID> ; 1> nom : Utilisateur, Joe ;
>> Dn : CN=User, Joe,OU=Migration,DC=corp,DC=company,DC=local 1> canonicalName : corp.company.local/Migration/User, Joe ;
1> cn : Utilisateur, Joe ;
1> description : Compte désactivé ; 1> displayName : User, Joe ; 1> distinguishedName : CN=User, Joe,OU=Migration,DC=corp,DC=company,DC=local ;
4> objectClass : top ; person ; organizationalPerson ; user ;
1> objectGUID : <GUID> ;
1> nom : Utilisateur, Joe ;

Dans cet exemple, supposons qu’il existe un contrôleur de domaine dans le domaine corp.company.local nommé CORP-DC-01. L’exécution de la commande repadmin /showreps CORP-DC-01 produit le GUID> de valeur <objectGUID. Ce GUID remplace le GUID précédent dans le fichier Objects-list.txt. L’entrée de cet objet persistant apparaît désormais comme suit :

<GUID=<GUID>> : <GUID=<GUID>>

Le premier GUID est le GUID du contrôleur de domaine dans le domaine corp.company.local. Le deuxième GUID est le GUID de l’objet persistant. Après cette modification, le script Walk-servers.cmd s’exécute correctement.

Message d’erreur 87 lors de la suppression d’objets persistants dans l’environnement

Cette erreur peut se produire lorsque vous trouvez des objets qui n’apparaissent pas sur tous les contrôleurs de domaine qui hébergent le contexte d’affectation de noms, mais repadmin /removelingeringobjects ne les suppriment pas. Il peut s’agir d’une situation où un contrôleur de domaine hub réplique de nouveaux objets qu’il a créés avec des serveurs de catalogue globaux, mais pas avec des contrôleurs de domaine réplica en lecture/écriture dans son propre domaine.

Cette erreur n’est retournée que dans deux cas :

L’objet existe sur le contrôleur de domaine de référence.
L’objet est trop jeune (par rapport à la valeur TSL actuelle) pour être persistant.

Pour obtenir un exemple de deuxième cas, considérez un serveur de catalogue global qui a les métadonnées suivantes :

Attribut Loc.USN Originating DC Org.USN Org.Time/Date Ver
======= =============== ========= ============= === =========
143543261 d20f71f3-6147-4f80-a0c2-470541ef09e6 104742409 <DateTime> objectClass
Vecteur de mise à jour d’un réplica RW : d20f71f3-6147-4f80-a0c2-470541ef09e6 @ USN 104583382 @ Time <DateTime>
Vecteur de mise à jour d’un GC : d20f71f3-6147-4f80-a0c2-470541ef09e6 @ USN 104762881 @ Time <DateTime>

Dans ce cas, le contrôleur de domaine a créé l’objet après la réplication avec les contrôleurs de domaine dans son propre domaine a échoué, mais il a toujours été répliqué avec des serveurs de catalogue globaux dans d’autres domaines.

Pour résoudre ce problème, laissez ces objets devenir des objets persistants réels (anciens au-delà de TSL), puis supprimez-les à l’aide du script dans cet article. Pour vous assurer que les données continuent de se répliquer, définissez Autoriser la réplication avec un partenaire divergent et endommagé sur tous les contrôleurs de domaine de la forêt.

Si vous ne pouvez pas résoudre les erreurs dans les fichiers journaux à l’aide de ces méthodes, vous rencontrerez peut-être un problème différent. Pour obtenir de l’aide supplémentaire, contactez les services de support technique Microsoft.

Collecte de données

Si vous avez besoin d’aide du support Microsoft, nous vous recommandons de collecter les informations en suivant les étapes mentionnées dans Collecter des informations à l’aide de TSS pour les problèmes de réplication Active Directory.

Partager via