Procédure de modification du Tombstone Lifetime

 

Sommaire

 

 

Introduction

Nous avons vu dans notre article Impact du Tombstone Lifetime sur Active Directory que la durée de conservation des objets tombstone à un impact sur Active Directory et qu’il était possible de la modifier pour l’adapter aux besoins de votre organisation. Toutefois, peu le savent mais la modification du Tombstone Lifetime peut entraîner des problèmes qui peuvent être évités si vous suivez la procédure adéquate.

 

 


Modifier la valeur du Tombstone Lifetime

Le Tombstone Lifetime est défini simplement par un attribut et est donc facilement modifiable. Vous pouvez donc réaliser l’opération via la console ADSIEDIT par exemple.

Lancez la console à l’aide de la commande « adsiedit.msc » depuis « Démarrer » | « Exécuter ».

{gallery}40_Change_TSL/01{/gallery}

 

 

 

 

 

Une fois dans la console ADSIEDIT, réalisez un clic droit sur « Modification ADSI » et sélectionnez « Connexion… ». Depuis la fenêtre « Paramètres de connexion », nous allons choisir « Sélectionnez un contexte d’attribution de noms connu » en précisant « Configuration » à partir de la liste déroulante.

{gallery}40_Change_TSL/02{/gallery}

 

 

 

 

 

 

 

 

Il suffit de naviguer vers l’objet « CN=Directory Service » depuis « CN=Configuration,DC=<ForestRoot> » | « CN=Services » | « CN=Windows NT » | « CN=Directory Service » et accéder à ses propriétés à l’aide d’un clic droit.

{gallery}40_Change_TSL/03{/gallery}

 

 

 

 

 

 

 

L’objet « CN=Directory Service » est constitué d’attributs dont « tombstoneLifetime » que nous allons donc modifier en le sélectionnant et en cliquant sur le bouton « Modifier ».

{gallery}40_Change_TSL/04{/gallery}

 

 

 

 

 

 

 

 

 

Remarque: augmenter la valeur du tombstone lifetime signifie également que vous allez conserver plus longuement des objets en attente de suppression et donc augmenter la taille de votre base Active Directory.

ATTENTION !!! L’attribut TombstoneLifetime est unique au sein d’une forêt. La modification concernera donc l’ensemble des domaines de votre forêt.

 

 

 


Effets de bord

La principale problématique du changement de la valeur du Tombstone Lifetime est sa latence de réplication sur l’ensemble de votre forêt. La modification de cette valeur doit être prise en compte sur l’ensemble des contrôleurs de domaine de la forêt avant que le garbage collection process n’est pu s’exécuter localement sur chaque contrôleur de domaine.

Prenons un exemple concret. Pour cela nous allons nous appuyer sur le schéma ci-dessous.

{gallery}40_Change_TSL/05{/gallery}

 

 

 

Vous disposez de deux contrôleurs de domaine placés sur deux sites Active Directory différents que nous appellerons DC1 et DC2. Vous modifiez la valeur sur DC1 pour passer la valeur de 60 à 180 jours (Etape 1) cependant le DC2 n’a pas pris en compte la mise à jour et le garbage collection process s’est exécuté (Etape 2 et 3). De ce fait, le DC2 a appuyé son garbage collection process sur une valeur de Tombstone Lifetime à 60 jours et a donc supprimé tous les objets tombstone excédant cette durée.

Par la suite, Une réplication s’effectue entre les deux contrôleurs de domaine (Etape 4) cependant et comme en toute logique, aucun objet tombstone n’a été supprimé sur DC1, les objets purgés par le garbage collection process du DC2 seront réintroduits (Etape 5). La base Active Directory est donc dès lors inconsistante (introduction « d’objets en attente » appelés communément lingering objects).

Le problème vient essentiellement du manque de maîtrise du garbage collection process qui peut être amené à s’exécuter avant que la mise à jour du Tombstone Lifetime ait été déployée sur la totalité des contrôleurs de domaine de la forêt. Le garbage collection process s’exécute toutes les 12 heures ce qui dans un premier temps ne laisse qu’une faible marge d’erreur pour la réplication de la nouvelle valeur du Tombstone Lifetime. Rajoutons à cela que le garbage collection process s’exécute de façon asynchrone sur chaque contrôleur de domaine. La fenêtre de 12 heures s’appuie exclusivement sur l’heure de démarrage du service Netlogon de chaque contrôleur de domaine et il est impossible de passer outre (même en forçant manuellement l’exécution du garbage collection process qui ne permet pas de réinitialiser le compte à rebours).

 

 

 

Procédure de modification

L’objectif principal est de gagner en maîtrise sur le garbage collection process. Il faut que nous assurions, autant que faire se peut, que la nouvelle valeur du Tombstone Lifetime soit répliquée avant que le garbage collection process est eu le temps de s’exécuter sur l’ensemble de la forêt.

Les étapes à suivre sont :

Modification de l’intervalle d’exécution du garbage collection process et attendre sur un délai raisonnable sa réplication:

Tout d’abord, il est important de noter que la période d’exécution du garbage collection process ne peut excéder le tiers de la durée du Tombstone Lifetime. Donc, pour une valeur de Tombstone Lifetime égale à 60 jours, la valeur du garbage collection process ne peut dépasser 20 jours, soit 480 heures. Vous pouvez toutefois lui attribuer une valeur supérieure mais elle ne pourra pas dépasser cette limitation.

Modifier la valeur du garbage collection process est une opération similaire à celle vue plus haut pour le Tombstone Lifetime. Il s’agit de l’attribut garbageCollPeriod rattaché au même objet que l’attribut tombstoneLifetime. Passez la valeur au tiers de celle du Tombstone Lifetime, soit le maximum possible (Par exemple 480). {gallery}40_Change_TSL/06{/gallery}

 

 

 

 

 

 

 

 

 

Modification de la durée de vie de conservation des objets tombstone et attendre le délai nécessaire pour sa réplication:

Désormais, nous pouvons modifier la valeur du Tombstone Lifetime plus sereinement et patienter le temps nécessaire à sa réplication. Le seul problème étant que la base Active Directory ne sera plus purgée de ses objets tombstone.

Remarque: il peut être intéressant de vérifier à l’aide d’un script PowerShell (par exemple) que la nouvelle valeur du garbageCollPeriod et ensuite celle du tombstoneLifetime aient bien été répliquées sur l’ensemble des contrôleurs de domaine.

Rétablissement de l’intervalle initial d’exécution du garbage collection process:

Une fois que l’opération de modification du Tombstone Lifetime a été réalisée avec succès, plus rien ne s’oppose à rétablir l’intervalle d’exécution par défaut du garbage collection process.

Remarque: Notez que si l’attribut garbageCollPeriod n’a pas de valeur définie alors elle est par défaut à 12 heures.

 

 

 

Conclusion

 

Nous avons donc pu voir ensemble que modifier le Tombstone Lifetime n’est pas une opération anodine et qu’elle peut également avoir des effets négatifs sur votre architecture. Bien entendu, cela dépendra essentiellement du nombre de contrôleurs de domaine et de domaines concernés par cette opération.

Impact du Tombstone Lifetime sur Active Directory

Sommaire

 

 

Introduction

Une des principales caractéristiques des objets tombstone est d’avoir une durée de vie limitée définie précisément par le Tombstone Lifetime. De ce point de vue simplifiée, nous pourrions nous en arrêter là, pourtant, la valeur du Tombstone Lifetime a de nombreux impacts sur le fonctionnement de l’annuaire Active Directory que nous allons donc voir au sein de cet article.

 

 

Qu’est-ce que le Tombstone Lifetime ?

Nous avons déjà présenté brièvement dans notre article sur les objets tombstone (Le processus de suppression d’objets au sein de Active Directory (Les objets tombstone)) ce qu’est le Tombstone Lifetime. Nous allons toutefois nous permettre d’en faire le rappel.

Par nature, un objet  tombstone n’est conservé que temporairement au sein de la base Active Directory afin de signifier à l’ensemble des contrôleurs de domaine que l’objet supprimé doit être purgé. Une fois que l’information est prise en compte durant la réplication, il n’y a donc plus d’intérêt de le conserver dans la base Active Directory. Il est même nécessaire de ne pas les conserver indéfiniment sous peine de voir la base grossir inutilement. De ce fait, un objet tombstone est purgé au bout d’une durée déterminée que l’on appelle le Tombstone Lifetime (en français on le traduirait par durée de vie d’un tombstone).

Active Directory conserve la valeur du Tombstone Lifetime sous la forme d’un attribut sur l’objet « cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=<forestDN> ». Vous pouvez donc consulter sa valeur depuis ADSIEDIT ou par ligne de commande (dsquery ou powershell). La valeur est conservée au niveau de la forêt (contexte d’attribution « configuration ») et est donc unique pour l’ensemble de la forêt.

La valeur du Tombstone Lifetime est exprimée en nombre de jours. Sa valeur par défaut peut être de 60 ou 180 en fonction de la version du premier contrôleur de domaine promu au sein de votre forêt. Ci-dessous, vous trouverez la valeur par défaut associée à chaque version de Windows Server.

Version du premier DC promu

Durée de vie d’un objet tombstone (jours)

Windows Server 2000

60

Windows Server 2003

60

Windows Server 2003 (SP1)

180

Windows Server 2003 R2 (SP1)

60

Windows Server 2003 R2 (SP2)

180

Windows Server 2008 / 2008 R2

180

Remarque: Par erreur, la version Windows Server 2003 R2 avec service pack 1 intégré est repassée à 60 jours. Le problème ayant été corrigé ultérieurement avec le service pack 2 (voir KB Microsoft correspondante ici).

La valeur du Tombstone Lifetime n’est pas modifiée lorsque vous réalisez une montée de version de Active Directory. Vous pouvez cependant la modifier manuellement et lui définir la valeur désirée.

 

 

L’impact du tombstone lifetime sur les réplications Active Directory

Pour supporter la réplication d’un objet supprimé, Active Directory utilise la transformation d’un objet en objet tombstone. Sachant que cette transformation n’a que cet objectif et qu’il est inconcevable de conserver indéfiniment des objets supprimés, ils sont donc automatiquement purgés après une période définie par le Tombstone Lifetime.

Imaginons maintenant que, passée la durée définie par le Tombstone Lifetime, un contrôleur de domaine n’a pu initier de réplication. Plusieurs objets auront été supprimés et une purge des objets tombstone aura été réalisée. A partir de ce moment, il sera impossible pour ce contrôleur de domaine de savoir si un objet a été supprimé (les objets tombstone ayant été purgé et étant le seul moyen d’en prendre connaissance). Dans ce cas de figure, si la réplication est rétablie, l’objet supprimé précédemment sur la base Active Directory mais toujours présent localement sur ce contrôleur de domaine peut être réintroduit.

Afin d’éviter ces effets de bord, Active Directory est doté d’un mécanisme de protection qui va bloquer automatiquement et de manière indéfinie ce lien de réplication.

Prenons l’exemple suivant:

  • Etape 1: au jour 1, le DC1 ne peut plus communiquer avec ses pairs (panne matériel, rupture des liens de communication…).
  • Etape 2: au jour 2, des suppressions sont réalisées sur l’annuaire. Les objets sont transformés en objets tombstone et ne surviront que pendant la durée définie par le Tombstone Lifetime (60 jours). Le DC1 n’en prend pas connaissance.
  • Etape 3: au jour 62.5, les objets tombstones de plus de 60 jours sont purgés de la base Active Directory par le garbage collection process.
  • Etape 4: au jour 63, les liens de réplications sont rétablis. DC1 tente de se répliquer avec ses partenaires mais Active Directory bloque désormais les demandes. Le DC1 pourrait réintroduire des objets déjà supprimés mais non identifiés comme tel.

{gallery}39_TSL/06{/gallery}

 

 

 

 

Suite au blocage des réplications, nous aurons le message d’erreur ci-dessous lorsque nous tenterons de lancer manuellement la réplication depuis la console Sites et services Active Directory.

{gallery}39_TSL/01{/gallery}

 

 

 

 

 

 

Des évenements portant l’id 2042 dans le journal « Service d’annuaire » seront également enregistrées à chaque tentative de réplication.

{gallery}39_TSL/05{/gallery}

 

 

 

 

 

 

 

Toutefois, il est possible de passer outre ce mécanisme de protection et permettre la réintroduction d’objets purgés sur la base Active Directory qui sont appelés  des « lingering objects » ou objets en attente. La présence de ce type d’objet traduit une inconsistance de la base Active Directory.

 

 

L’impact du Tombstone Lifetime sur les restaurations Active Directory

L’impact de la durée de vie des objets tombstone ne se cantonne pas uniquement aux réplications. En effet, le principe est exactement du même ordre concernant la restauration d’une sauvegarde dépassant cette période. En tentant de restaurer une sauvegarde plus agée que la durée du Tombstone Lifetime, vous pourriez réinjecter potentiellement des objets déjà supprimés. Active Directory dispose donc également d’un mécanisme dans ce cas là en bloquant automatiquement la restauration. Plus clairement, cela signifie qu’avec une valeur de Tombstone Lifetime égale à 60 jours, vous ne pourrez pas établir un plan de sauvegarde de votre annuaire excédant cette période.

Lors d’une tentative de restauration Active Directory avec l’outil de sauvegarde Windows Server 2008 (Windows Server Backup) tombant sous le coup de cette contrainte, vous obtiendrez le message d’erreur suivant « L’attribut de durée de vie de temporisation Active Directory de la sauvegarde à expiré. Cette sauvegarde ne peut être utilisée pour effectuer une récupération d’Active Directory. Choisissez une sauvegarde plus récente ».

{gallery}39_TSL/02{/gallery}

 

 

 

 

 

 

 

Notez que depuis Windows Server 2003 SP1, Microsoft a introduit la possibilité de vérifier la dernière date de sauvegarde de l’annuaire Active Directory et un système de notification via le journal des évènements. Ce dernier vous avertit que la dernière sauvegarde réalisée de l’annuaire a excédé la moitié de la durée du tombstone lifetime (par défaut). Il s’agit de l’évènement 2089 consultable depuis le journal « Service d’annuaire ». Cet évènement est consigné pour chaque partition de l’annuaire.

{gallery}39_TSL/03{/gallery}

 

 

 

 

 

 

 

Remarque: l’intervalle de notification peut être défini manuellement en fonction de vos convenances via une clé de registre « HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Backup Latency Threshold (days) », valeur DWORD, en indiquant le nombre de jours voulu.

Pour évaluer la dernière date de sauvegarde, Active Directory contrôle simplement l’attribut dSASignature de chaque partition de l’annuaire et la compare avec la durée du Tombstone Lifetime. Cet attribut subit un horodatage à chaque sauvegarde réalisée. Par exemple, la commande « repadmin /showbackup <SERVER> » permet de contrôler la date de la dernière sauvegarde réalisée pour chaque partition de l’annuaire en s’appuyant sur l’attribut dSASignature.

{gallery}39_TSL/04{/gallery}

 

 

 

 

 

 

 

Conclusion

La durée de conservation des objets tombstone influant sur les réplications et les restaurations Active Directory, il est nécessaire de l’adapter en fonction des besoins de chacuns. La modification doit être  d’autant plus envisagée pour ceux disposant encore d’une valeur à 60 jours. Elle représente une réelle contrainte pour les plans de sauvegardes.

Nous verrons prochainement comment en modifier la valeur en limitant les effets de bord sur votre annuaire car modifier le Tombstone Lifetime nécessite quelques précautions.