Partager via

Comment détecter et supprimer des objets persistants dans une forêt Windows Server Active Directory

  • Article

Cet article fournit des informations sur les objets persistants dans une forêt services de domaine Active Directory (AD DS). Plus précisément, l’article décrit les événements qui indiquent la présence d’objets persistants, les causes des objets persistants et les méthodes que vous pouvez utiliser pour supprimer les objets persistants.

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

Résumé

Les objets persistants sont des objets qui réapparaîtront dans la forêt AD DS après leur suppression. Ce comportement peut se produire si un contrôleur de domaine arrête la réplication des modifications apportées à d’autres contrôleurs de domaine dans la forêt pendant un certain temps, puis redémarre la réplication. Ce comportement se produit en raison de la façon dont la forêt réplique les suppressions d’objets entre plusieurs contrôleurs de domaine.

Comment les suppressions d’objets sont répliquées par le biais d’une forêt

Lorsque vous supprimez un objet dans une forêt AD DS, AD DS génère un objet tombstone pour représenter l’objet supprimé. L’objet tombstone contient un petit sous-ensemble des attributs de l’objet supprimé. D’autres contrôleurs de domaine du domaine et de la forêt utilisent la réplication entrante pour recevoir l’objet tombstone et mettre à jour leurs informations de forêt pour tenir compte de la suppression. L’objet tombstone reste dans la forêt pendant une période spécifiée connue sous le nom de durée de vie des pierres tombales (TSL). À la fin du TSL, AD DS supprime définitivement l’objet tombstone. Tous les partenaires de réplication directe et transitive du contrôleur de domaine d’origine doivent recevoir une copie de l’objet tombstone au sein du TSL.

La valeur par défaut du TSL dépend de la version du système d’exploitation qui s’exécute sur le premier contrôleur de domaine installé dans une forêt. Pour toutes les versions actuellement prises en charge de Windows Server, le TSL par défaut est de 180 jours.

Note

La valeur TSL existante ne change pas lorsque vous mettez à niveau un contrôleur de domaine vers une version plus récente de Windows Server. La valeur TSL existante persiste jusqu’à ce que vous le modifiez manuellement.

Comment se produisent les objets persistants

Des objets persistants peuvent se produire si un contrôleur de domaine arrête la réplication des modifications vers ou depuis la topologie de réplication restante pendant un certain temps, puis redémarre la réplication (par exemple, si le serveur doit être déconnecté physiquement et déplacé, puis reconnecté). Lorsqu’un contrôleur de domaine ne réplique pas pendant une période plus longue que la TSL, le contrôleur de domaine peut ne pas recevoir un ou plusieurs objets tombstone. Par conséquent, un ou plusieurs objets supprimés de la forêt sur tous les autres contrôleurs de domaine peuvent persister sur le contrôleur de domaine déconnecté. Ces objets sont appelés objets persistants.

Lorsque le contrôleur de domaine déconnecté commence à répliquer à nouveau, il agit en tant que partenaire de réplication source qui a un objet que son partenaire de destination n’a pas. Le contrôleur de domaine de destination répond en effectuant l’une des actions suivantes :

  • Si la Strict Replication Consistency clé de Registre est activée sur le contrôleur de domaine de destination, ce contrôleur de domaine reconnaît qu’il ne peut pas mettre à jour l’objet. Le contrôleur de domaine de destination arrête localement la réplication entrante de la partition d’annuaire à partir du contrôleur de domaine source.

  • Si la Strict Replication Consistency clé de Registre est désactivée sur le contrôleur de domaine de destination, ce contrôleur de domaine demande le réplica complet de l’objet. Cette opération réintroduisent l’objet dans la forêt. D’un point de vue administratif, un objet que vous avez supprimé réapparaît.

Les objets persistants ne provoquent pas toujours des symptômes notables. Dans les conditions suivantes, les objets persistants peuvent rester non détectés :

  • Un administrateur, une application ou un service ne met pas à jour l’objet persistant.
  • Un administrateur, une application ou un service n’essaie pas de créer un objet portant le même nom dans le domaine.
  • Un administrateur, une application ou un service n’essaie pas de créer un objet à l’aide du même nom d’utilisateur principal (UPN) dans la forêt.

Causes de déconnexions longues

La façon la plus simple d’éviter les objets persistants consiste à empêcher les contrôleurs de domaine de se déconnecter de la topologie de réplication pendant des périodes supérieures à la TSL. Si un contrôleur de domaine doit être déconnecté pendant une période prolongée, tenez compte du potentiel des objets persistants.

Les conditions suivantes peuvent entraîner des déconnexions longues :

  • Un administrateur supprime un contrôleur de domaine du réseau, puis le place dans le stockage.

  • Un administrateur pré-étape un contrôleur de domaine, puis l’envoie à un emplacement distant. Toutefois, le TSL expire avant que le contrôleur de domaine atteigne l’emplacement distant.

  • Le contrôleur de domaine ne peut pas se connecter à un réseau étendu (WAN) pendant de longues périodes. Par exemple, un contrôleur de domaine à bord d’un navire de croisière peut ne pas être en mesure de répliquer plus longtemps que le TSL si le navire est en mer.

Dans les conditions suivantes, les objets persistants peuvent apparaître même si le contrôleur de domaine était hors connexion pour moins que le TSL par défaut :

  • Un administrateur raccourcit le TSL pour forcer le garbage collection d’objets supprimés.

  • L’horloge système sur le contrôleur de domaine source ou de destination est incorrectement avancée ou restaurée. Les asymétries d’horloge sont les plus courantes après le redémarrage d’un contrôleur de domaine et peuvent se produire pour les raisons suivantes :

    • La batterie de l’horloge système ou la carte mère a un problème.

    • La source de temps d’un ordinateur est configurée de manière incorrecte. Une telle source peut inclure un serveur source de temps configuré à l’aide du service de temps Windows (W32Time), à l’aide d’un serveur de temps tiers ou à l’aide de routeurs réseau.

    • Un administrateur avance ou restaure l’horloge système pour prolonger la durée de vie utile d’une sauvegarde d’état système ou accélérer le garbage collection d’objets supprimés. Assurez-vous que l’horloge système reflète l’heure réelle. Vérifiez également que les journaux d’événements ne contiennent pas d’événements non valides à partir de l’avenir ou du passé.

Indications indiquant qu’une forêt a des objets persistants

Même s’il n’existe aucun effet notable, la présence d’objets persistants peut entraîner des problèmes. Ces problèmes sont susceptibles de se produire si un objet persistant est un principal de sécurité.

Événements qui indiquent que la forêt peut avoir des objets persistants

ID événement Description générale
1862 ou 1863 Le contrôleur de domaine local n’a pas reçu récemment d’informations de réplication de plusieurs contrôleurs de domaine (intersechage).
1864 Le contrôleur de domaine local n’a pas reçu récemment d’informations de réplication de plusieurs contrôleurs de domaine (résumé).
1,311 Le vérificateur de cohérence des connaissances (KCC) n’a pas pu créer une topologie d’arborescence couvrante.
20:42 Il a été trop long depuis que ce serveur a été répliqué pour la dernière fois avec le serveur source nommé.

Événements qui indiquent que la forêt a des objets persistants

ID événement Description générale
1084 Cet objet ne se trouve pas sur le serveur.
1388 Ce système de destination a reçu une mise à jour pour un objet qui aurait dû être présent localement, mais pas.
1,311 Un autre contrôleur de domaine a répliqué un objet non présent sur ce contrôleur de domaine.

Note

  • Les objets persistants n’existent pas sur les contrôleurs de domaine qui journaliser l’ID d’événement 1988. Le contrôleur de domaine source contient l’objet persistant.
  • Lorsque les mises à jour d’un objet persistant sont répliquées d’un contrôleur de domaine à un autre, le comportement de journalisation des événements du contrôleur de domaine dépend de la valeur de la partition de répertoire qui contient l’objet persistant pouvant être écrit. Si l’objet persistant sur le contrôleur de domaine de destination réside dans une partition accessible en écriture, le contrôleur de domaine enregistre un événement. Si l’objet persistant réside dans une partition en lecture seule, l’objet ne peut pas être mis à jour et le contrôleur de domaine ne journalise pas d’événement.

Erreurs repadmin qui indiquent que la forêt a des objets persistants

ID événement Description générale
8240 Cet objet ne se trouve pas sur le serveur.
8,606 Des attributs insuffisants ont été attribués pour créer un objet.

Autres indications indiquant que la forêt comporte des objets persistants

  • La liste d’adresses globale microsoft Exchange Server contient un compte d’utilisateur ou de groupe supprimé. Dans ce cas, le nom du compte s’affiche dans la liste d’adresses réseau, mais des erreurs se produisent lorsque les utilisateurs essaient d’envoyer des messages électroniques.

  • Un objet doit être unique dans la forêt, mais vous voyez plusieurs copies de l’objet dans le sélecteur d’objets ou la gal. Ces cas peuvent inclure des objets en double qui ont changé de noms. Ces objets en double confondent les recherches d’annuaire. Par exemple, si une recherche ne peut pas résoudre les noms uniques relatifs de deux objets, la fonction de résolution de conflit ajoute *CNF:<GUID> à l’un des noms. Dans cet exemple, * représente un caractère réservé, CNF est une constante qui indique une résolution de conflit et <GUID> représente la valeur d’attribut objectGUID .

  • Un utilisateur a un compte actuel, mais le compte a été renommé. L’utilisateur ne reçoit pas de messages électroniques. Les deux instances de l’objet utilisateur (la version actuelle et une version antérieure) s’affichent dans la liste d’adresses de groupe. Étant donné que les deux objets ont la même adresse e-mail, les messages électroniques ne peuvent pas être remis.

  • Un groupe universel qui n’existe plus continue d’apparaître dans le jeton d’accès d’un utilisateur. Par conséquent, l’utilisateur peut avoir accès à une ressource que vous souhaitiez être indisponible pour cet utilisateur.

  • Vous ne pouvez pas créer un objet ou une boîte aux lettres Exchange. Toutefois, vous ne voyez pas l’objet dans la forêt. Un message d’erreur signale que l’objet existe déjà.

  • Les recherches qui utilisent des attributs d’un objet existant peuvent trouver incorrectement plusieurs copies d’un objet qui utilisent le même nom. Un objet a été supprimé du domaine, mais cet objet reste dans un serveur de catalogue global isolé.

Supprimer les objets persistants de la forêt

Sélectionnez l’une des méthodes suivantes pour supprimer les objets persistants.

Méthode 1 : Utiliser LOLv2

La méthode préférée pour détecter et supprimer des objets persistants consiste à utiliser Lingering Object Liquidator v2 (LoLv2). Pour télécharger l’outil, consultez Lingering Object Liquidator (LoL)

Pour plus d’informations sur l’utilisation de LoLv2, consultez les articles suivants :

Méthode 2 : Utiliser l’outil Repadmin

Si vous ne pouvez pas utiliser LoLv2, vous pouvez utiliser l’outil Repadmin (Repadmin.exe). Pour plus d’informations, consultez Étapes d’utilisation de Repadmin pour supprimer des objets persistants.

Empêcher les objets persistants

Pour empêcher les objets persistants dans votre forêt, utilisez l’une des méthodes suivantes.

Méthode 1 : Activer l’entrée de Registre De cohérence de réplication stricte

Important

Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, vérifiez que vous suivez ces étapes attentivement. Pour pallier à toute éventualité, sauvegardez le Registre avant de le modifier afin de pouvoir le restaurer en cas de problème. Pour plus d’informations sur la sauvegarde et la restauration du registre, voir : Procédure de sauvegarde, de modification et de restauration du Registre dans Windows.

Vous pouvez activer l’entrée de Strict Replication Consistency Registre sur chaque contrôleur de domaine afin que les objets suspects soient mis en quarantaine sur le contrôleur de domaine source. Ensuite, les administrateurs peuvent supprimer ces objets avant que les objets ne se répartissent dans la forêt.

Si un objet persistant accessible en écriture se trouve dans votre environnement et qu’une tentative est effectuée pour mettre à jour l’objet, la valeur de l’entrée de Registre détermine si la Strict Replication Consistency réplication continue ou s’arrête. L’entrée Strict Replication Consistency de Registre se trouve dans la sous-clé de Registre suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

  • Nom : Strict Replication Consistency
  • Type de données : REG_DWORD
  • Valeurs :
    • 0 (désactivé). Le contrôleur de domaine de destination demande l’objet complet du contrôleur de domaine source. L’objet persistant réapparaît dans la forêt en tant qu’objet nouveau.
    • 1 (activé). Le contrôleur de domaine de destination arrête la réplication entrante de la partition d’annuaire appropriée à partir du contrôleur de domaine source.

La valeur par défaut pour Strict Replication Consistency dépend de la version Windows du premier contrôleur de domaine dans la forêt. Cet ordinateur crée le domaine racine de forêt d’une nouvelle forêt.

  • Si la forêt a été créée en favorisant un serveur exécutant Windows Server 2003 ou une version ultérieure, la valeur par défaut est Strict Replication Consistency 1 (activée) sur tout contrôleur de domaine que vous ajoutez à la forêt.

  • Si la forêt a été créée en favorisant un serveur exécutant Windows 2000 Server, la valeur Strict Replication Consistency par défaut est 0 (désactivée) sur n’importe quel contrôleur de domaine que vous ajoutez à la forêt. Dans ce cas, suivez les étapes décrites dans Vérifier que la cohérence de réplication stricte est activée sur les contrôleurs de domaine nouvellement promus.

Note

La Strict Replication Consistency valeur d’un contrôleur de domaine ne change pas si vous augmentez le niveau fonctionnel du domaine ou de la forêt.

La méthode préférée à activer Strict Replication Consistency consiste à utiliser Repadmin. Pour plus d’informations sur la procédure à suivre, consultez les articles suivants :

Méthode 2 : Vérifier la réplication à l’aide d’une commande de ligne de commande

Pour vérifier la réplication à l’aide de la repadmin /showrepl commande, procédez comme suit :

  1. Ouvrez une fenêtre d’invite de commandes (sélectionnez Démarrer>l’exécution, tapez cmd, puis sélectionnez OK).

  2. Depuis l’invite de commandes, exécutez la commande suivante :

    repadmin /showrepl * /csv >showrepl.csv

  3. Dans Microsoft Excel, ouvrez le fichier Showrepl.csv .

  4. Sélectionnez la colonne A + RPC et la colonne SMTP, puis sélectionnez Modifier>la suppression.

  5. Sélectionnez la ligne qui se trouve immédiatement sous les en-têtes de colonne, puis sélectionnez Volet Figer Windows>.

  6. Sélectionnez l’intégralité de la feuille de calcul, puis sélectionnez Filtre>automatique de filtre de données.>

  7. Dans l’en-tête de la colonne Dernière réussite , sélectionnez la flèche vers le bas, puis sélectionnez Trier croissant.

  8. Dans le titre de la colonne src DC , sélectionnez la flèche vers le bas, puis sélectionnez Personnalisé.

  9. Dans la boîte de dialogue Filtre automatique personnalisé, sélectionnez ne contient pas.

  10. Dans la zone à droite de ne contient pas, tapez del.

    Note

    Cette étape empêche les contrôleurs de domaine supprimés d’apparaître dans les résultats.

  11. Dans l’en-tête de la colonne Dernier échec , sélectionnez la flèche vers le bas, puis sélectionnez Personnalisé.

  12. Dans la boîte de dialogue Filtre automatique personnalisé, la sélection n’est pas égale.

  13. Dans la zone à droite de n’est pas égale, tapez 0.

  14. Vérifiez les échecs de réplication dans la feuille de calcul filtrée. Il s’agit des problèmes que vous devez résoudre.

Méthode 3 : Supprimer des contrôleurs de domaine

Si vous devez supprimer et remplacer un contrôleur de domaine, ou si vous pensez qu’un contrôleur de domaine échoue, assurez-vous que la période pendant laquelle le contrôleur de domaine est hors connexion est inférieur au TSL.

Méthode 4 : Augmenter le TSL

Vous pouvez utiliser Windows PowerShell ou ADSI Edit pour augmenter le TSL à 180 jours.

Pour utiliser PowerShell pour augmenter la TSL, ouvrez une fenêtre PowerShell d’administration, puis exécutez les commandes suivantes dans la séquence :

$ADForestconfigurationNamingContext = (Get-ADRootDSE).configurationNamingContext

Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,$ADForestconfigurationNamingContext” -Partition $ADForestconfigurationNamingContext -Replace @{tombstonelifetime=’180′}

ADSI Edit est disponible dans le menu Outils de Gestionnaire de serveur. Pour modifier la TSL, procédez comme suit :

  1. Dans ADSI Edit, connectez-vous à la partition configuration de la forêt. Pour cela, procédez comme suit :
    1. Dans le volet gauche, cliquez avec le bouton droit sur ADSI Modifier, puis sélectionnez Se connecter.
    2. Dans Paramètres de connexion, sélectionnez Sélectionner un contexte de nommage connu, puis sélectionnez Configuration.
    3. Cliquez sur OK.
  2. Dans l’arborescence de navigation, accédez à CN=Configuration>CN=Services>CN=Windows NT>CN=Directory Service.
  3. Cliquez avec le bouton droit sur CN=Directory Service, puis sélectionnez Propriétés.
  4. Sélectionnez l’onglet Attribut .
  5. Dans la liste Sélectionner les propriétés à afficher , sélectionnez Facultatif.
  6. Dans la liste Sélectionner une propriété à afficher , sélectionnez TombstoneLifetime.
  7. Dans la zone Modifier l’attribut, tapez 180, sélectionnez Définir, puis OK.

Collecte de données pour Support Microsoft

Si vous avez besoin d’aide de 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.