Active Directory – Objets persistants

Ces objets sont plus une conséquence d’un sinistre, mais peuvent aussi donner du fil à retordre aux informaticiens. J’ai vu un certain nombre d’environnements dans lesquels il existe ou il a existé pendant un certain temps des objets persistants qui n’ont jamais été nettoyés.

C’est probablement dû au fait que Active Directory continue de fonctionner, hormis quelques anomalies telles que la présence d’objets dans un domaine, alors qu’ils sont absents d’un autre. Il est difficile de les nettoyer et cela s’applique à de multiples forêts de domaines. Pour faire court, les objets persistants résultent d’un DC qui est devenu inaccessible à d’autres DC plus longtemps que la durée de vie des objets fantômes (TSL) avant d’être replacé en ligne.

Les valeurs par défaut de TSL varient en fonction de la version de Windows que vous employez et elles sont personnalisables. Si le DC est placé en ligne après la purge des objets supprimés par le système de récupération de mémoire (GC), après l’expiration du TSL, il peut répliquer ces objets sur des DC sains et les réactiver. En général, cela pose problème sur les GC lorsque des objets en lecture seule sont répliqués.

Les événements 1864, 2042 et 1988 dans le journal d’événements Directory Services constituent de bons indicateurs en matière d’objets persistants. Vous pouvez voir des messages dans les journaux d’événements et la sortie Repadmin/showrepl.

Lors de tentatives de réplications des objets persistants, cela peut provoquer un arrêt de la réplication entre deux DC. Si la très importante de clé de Registre « StrictReplicationConsistency » a la valeur (1), ce qui signifie un comportement Strict et si un partenaire de réplication souhaite modifier un objet qui n’existe pas sur le DC, toute réplication sera interrompue. Un message très utile à cet effet s’affichera lors de l’exécution de la commande Repadmin/Showrepl, du journal d’événements DirSvcs, de Repadmin/Replsum et d’autres rapports et journaux :

The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.

Il existe d’autres messages particulièrement évidents. C’est une bonne chose ! Cela permet d’isoler la machine problématique et vous n’avez pas besoin de faire le ménage sur tous les DC. J’ai vu de nombreux environnements où cette clé de Registre est définie sur « loose » (0). Autrement dit, tous les DC vont répliquer les objets persistants et ce n’est pas souhaitable.

Si vous avez un environnement qui a démarré avec Windows 2000 et si vous avez effectué une mise à niveau (à la différence d’une installation toute neuve de la forêt complète) vers Windows 2003, 2008, etc., ce paramètre est probablement défini sur « loose », puisque c’était la valeur par défaut dans Windows 2000. La clé est située à l’emplacement suivant :

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\
   Parameters
   ValueName = Strict Replication Consistency

Grâce à des efforts diligents de la part de Microsoft, les objets persistants sont passés d’un cauchemar épouvantable dans Windows 2000 à une situation relativement facile à éliminer dans 2003 et les versions suivantes. L’outil clé est ce bon vieux Repadmin et le commutateur RemoveLingeringObjects. Vous ne trouvez pas cette option dans l’aide en ligne de Repadmin ? Essayez Repadmin/ExpertHelp.

SOLUTION : Si vous avez des serveurs Windows 2000 dans votre environnement et s’ils contiennent des objets persistants, la solution consiste à les remplacer par (et non à les mettre à niveau vers) des DC Windows 2008 (en supposant que Windows 2003 ne soit pas disponible).

Pour Windows 2003 et les versions suivantes, la réponse rapide est la suivante :

1.   Paramétrez tous les DC sur StrictReplicationConsistency = 1. Dans le cas contraire, la réplication des objets persistants continuera. Utilisez la commande Repadmin pour effectuer rapidement ce paramétrage sur tous les DC (ajoutez tous les DC dans DC_LIST ; consultez l’aide en ligne pour des détails sur Repadmin) :

repadmin /regkey DC_LIST +strict

2. Utilisez la commande Repadmin/removeLingeringObject :

Repadmin /removelingeringobjects <Dest_DC_LIST> <Source DC GUID> <NC> [/ADVISORY_MODE]
a. Dest_DC_List – liste des DC à utiliser
b.   Source DC GUID – le GUID DSA d’un DC fiable (de préférence le PDC)
c.   NC – contexte de nommage du domaine sur lequel les objets persistants existent
d.   /ADVISORY_MODE – détermine ce qu’il se passe lorsque vous exécutez réellement la commande

Voici un exemple de commande :

C:\>Repadmin /removeLingeringObjects wtec-dc1 f5cc63b8-cdc1-4d43-8709-22b0e07b48d1 dc=wtec,dc=adapps,dc=hp,dc=com

Cela doit être effectué sur tous les DC de la forêt et il est facile d’écrire un script à cet effet.

Active Directory, Gestion des sinistres, pour aller plus loin sur la gestion des sinistres avec les experts Actualités IT, Dossiers Experts pour Décideurs et Professionnels IT (itpro.fr)

Active Directory, Armageddon, exemple de sinistre

Active Directory, Armageddon, exemple de sinistre

Active Directory – Sinistre de réplication

Active Directory – Sinistre de réplication

Active Director – Sinistre virtuel

Active Director – Sinistre virtuel