Premier article consacré aux objets tombstone

Bonsoir tout le monde,

pour cette fin d’année, nous ouvrons un dossier sur les objets tombstone avec un premier article ainsi qu’une petite tip sur le sujet.

Article: Le processus de suppression d’objets au sein de Active Directory (Les objets tombstone)

Tip: Visualiser le conteneur « Deleted Objects » 

Bonne lecture !

Le processus de suppression d’objets au sein de Active Directory (Les objets tombstone)

Sommaire

 

 

Introduction

Intimement liés au processus de suppression des objets au sein de l’annuaire Active Directory, la notion d’objet tombstone est un sujet incontournable mais souvent abordé de façon trop superficiel. Nous vous proposons donc de le traiter de manière approfondie dans cet article.

 

 

Qu’est-ce qu’un objet tombstone ?

En quelques mots, les objets tombstone sont des objets transformés suite à une demande de suppression. Ils portent d’ailleurs bien leur nom (tombstone signifiant outre-tombe en anglais) car ils sont considérés comme des objets supprimés tout en n’étant pas purgés immédiatement de la base Active Directory. Mais avant d’aller plus loin, nous allons essayer de vous expliquer leur utilité et leur importance pour le système de réplication Active Directory.

 

 

Les objets tombstone et la réplication Active Directory

Active Directory étant une architecture multi-maître, l’ajout, la modification et la suppression d’objets peut se faire sur tout contrôleur de domaine disponible. Cette architecture nécessite donc la mise en place d’un système de réplication adapté à ce type de scénario. En surface, le fonctionnement est simple (nous insistons sur le fait que la suite est une vue simplifiée des réplications Active Directory).

Chaque contrôleur de domaine dispose d’un compteur local qui est incrémenté à chaque ajout ou modification d’un objet sur sa base locale (cette valeur est appelée Update Sequence Number). Dans le même temps, un objet créé ou modifié se voit attribuer cette valeur de compteur via son attribut usnChanged. Durant la réplication, chaque contrôleur de domaine échange et stocke leur valeur de compteur respectif. Les contrôleurs de domaine savent donc s’ils doivent envoyer ou recevoir des mises à jour  en fonction des différentes valeurs des compteurs et peuvent identifier les mises à jour grâce à la valeur de compteur apposé à chaque objet concerné.

Prenons un exemple concret pour nous aider à mieux comprendre :

  • Le contrôleur de domaine  « A » à son compteur défini à 1000. En ajoutant un compte utilisateur, le compteur passe à 1001 et l’objet utilisateur voit son attribut usnChanged défini à 1001. Dans la foulée, un autre compte utilisateur est modifié et se voit attribué la valeur 1002 sur son attribut usnChanged passant la valeur du compteur à 1002.
  • Le contrôleur de domaine « B » connait la valeur initiale du compteur du contrôleur de domaine « A » qui était initialement de 1000. Lors de la prochaine réplication entre ces deux contrôleurs de domaine, le contrôleur de domaine « B » découvre que le compteur du contrôleur de domaine « » est passé à 1002. Il en déduit donc qu’il doit recevoir les mises à jour 1001 et 1002 correspondant aux valeurs usnChanged de nos deux objets modifiés préalablement.

Maintenant, au regard de cette petite explication sur le fonctionnement de la réplication Active Directory, il saute au œil que la suppression d’un objet au sein de l’annuaire ne peut supporter ce type de fonctionnement. En effet, l’attribut usnChanged d’un objet ne peut être mis à jour si l’objet lui-même est supprimé. Si la suppression d’un objet entraine l’incrémentation du compteur, comment sera-t-il possible d’identifier cette mise jour sans un objet avec une valeur usnChanged correspondante ?!

De ce fait, pour supporter la suppression d’objet dans le cadre de la réplication Active Directory, Microsoft a donc introduit la notion d’objet tombstone. Lorsque vous supprimez un objet depuis l’annuaire, il n’est pas immédiatement purgé de la base Active Directory mais converti en objet tombstone. Il est marqué comme supprimé et est conservé temporairement dans la base Active Directory, le temps de signifier à chaque contrôleur de domaine que l’objet est en cours de suppression et surtout de pouvoir l’identifier grâce à la valeur de son attribut usnChanged.

 

 

Les caractéristiques d’un objet tombstone

La suppression d’un objet au sein de l’annuaire est donc essentiellement une requête spéciale de modification le transformant en objet tombstone. Elle se réalise généralement en suivant les opérations ci-dessous:

  • Passage de l’attribut isDeleted à TRUE sur l’objet concerné.

Pour lister l’ensemble des Tombstones du domaine, vous pouvez passer par une requête PowerShell et  le module Active Directory (disponible sur Windows 7 ou 2008 R2) :

Get-ADObject -IncludeDeletedObjects -Server server.corp.com -Credential « CORP\user » -Filter { isDeleted -eq $true }

La même commande mais cette fois-ci pour lister uniquement les tombstones issues de la classe User:

Get-ADObject –IncludeDeletedObjects -Server server.corp.com -Credential « CORP\user » -Filter { isDeleted -eq $true -and objectClass -eq « user » }

 

  • Déplacement du tombstone dans le conteneur caché « Deleted Objects » de chaque domaine.

Chaque objet supprimé est déplacé automatiquement dans le conteneur « Deleted Objects » présent sur chaque partition de domaine de la forêt. Notez cependant qu’il existe toutefois un cas particulier où l’objet tombstone n’est pas déplacé dans le conteneur « Deleted Objects ». Il s’agit des objets ayant une valeur à 0x02000000 pour l’attribut systemFlags (voir l’article MSDN System-Flags attribute pour la liste des valeurs possible).

Le conteneur « Deleted Objects » est un conteneur caché et il ne peut être ni être vu ou parcouru par les outils d’administration traditionnels. Il faudra passer par le biais de LDP (Visualiser le conteneur « Deleted Objects »).

 

  • Modification du RDN (Relative Distinguished Name) de l’objet à une valeur unique et impossible à reproduire.

Le conteneur « CN=Deleted Objects,DC=MONDOMAINE,DC=LOCAL » étant plat (ne contient pas de sous-conteneur), il est possible que plusieurs tombstones ayant le même RDN se retrouvent au sein de ce conteneur. Sachant que le RDN doit être unique au sein d’un conteneur, il est nécessaire de renommer chaque objet tombstone pour assurer l’unicité. Le passage d’un objet à un tombstone entraine donc la modification du RDN suivant la syntaxe suivante : CN=<OLD RDN>\0ADEL:<objectGUID>

« <OLD RDN> » : l’ancien RDN du compte supprimé.

« \0A » : Le caractère ASCII de saut de ligne.

« DEL: » : Une chaîne de caractères pour rappeler qu’il s’agit d’un objet supprimé.

« <objectGUID> » : l’attribut unique objectGUID de l’objet supprimé afin d’assurer l’unicité du nouveau RDN.

Par exemple, pour le compte  ayant pour RDN « utilisateur1 » et le GUID « 52dbfe62-dcc7-4629-9c5a-e0ae8f0b0950 », le tombstone aura pour RDN « CN=utilisateur1\0ADEL:52dbfe62-dcc7-4629-9c5a-e0ae8f0b0950 ».

 

  • Destruction d’attributs.

Le passage d’un objet à un état Tombstone entraine la destruction de certains attributs. Il est important de le souligner car il est possible de réanimer un objet tombstone si nécessaire (un article vous serez proposé en temps voulu sur le sujet).  

En effet, l’objectif  principal d’Active Directory est de conserver uniquement les informations permettant d’identifier l’objet marqué comme supprimé et donc se débarrasse des attributs considérés comme superflus. De plus, et cela pour des questions techniques, il n’est pas possible de conserver les attributs liés dit «  linked attributes » (attribut memberOf ,member…).

Il est toutefois possible d’exiger la conservation d’un attribut d’un objet lors de sa suppression grâce à  la propriété searchFlags défini à 0x00000008 hormis les attributs liés biensur (liste des valeurs de searchFlags possible consultable ici).

Grâce à l’outil AdFind (disponible ici), il est possible de lister les attributs maintenus sur les objets tombstone. Pour cela, il suffit de saisir la commande « adfind –sc tombstonel ».

{gallery}38_tombstones/01{/gallery}

 

 

 

 

 

 

 

 

 

La durée de conservation des objets tombstone

Comme nous l’avons vu précédemment, un objet  converti en tombstone est conservé temporairement au sein de la base afin de signifier à l’ensemble des contrôleurs de domaine qu’il a été supprimé. 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 » (durée de vie d’un tombstone).

Par défaut, la durée de conservation des objets tombstone varie en fonction de la version du premier contrôleur de domaine promu au sein de la forêt.

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

Même en se référant à notre tableau, il reste difficile de connaitre la version du premier contrôleur de domaine promu au sein d’une forêt et  il est donc préférable de la vérifier. Le Tombstone Lifetime est défini par l’attribut « tombstoneLifetime » sur l’objet « cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=<forestDN> ». 

Il est possible de consulter sa valeur à l’aide de l’outil dsquery. Il suffit simplement d’exécuter la commande «  dsquery * « cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=<forestDN> » –scope base –attr tombstonelifetime ».

{gallery}38_tombstones/02{/gallery}

 

 

 

 

Vous pouvez également passer par la commande PowerShell suivante (nécessite le module Active Directory) :

Get-ADObject « CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=MONDOMAINE,DC=LOCAL » -Properties tombstonelifetime

Remarque : si aucune valeur n’est retournée cela induit que la valeur est par défaut à 60.

Comme vous avez pu le constater, la valeur du Tombstone Lifetime a évolué avec l’arrivée des nouvelles versions de Windows Server et elle est passée de 60 à 180 jours. Il est toutefois important de souligner que cela n’est en rien lié avec les montées de versions du système d’exploitation. Cette évolution est en rapport avec le retour d’expérience de Microsoft sur la gestion des objets tombstone et les problèmes engendrés par divers clients avec une durée de vie trop courte. De ce fait, il vous est tout à fait possible de modifier cette valeur si nécessaire (un article vous serez proposé en temps voulu sur le sujet).

Si vous désirez approfondir votre compréhension du Tombstone Lifetime et de son impact sur l’annuaire, nous vous invitons à consulter notre article Impact du Tombstone Lifetime sur Active Directory.

 

 

La suppression des objets tombstone

Une fois que la durée de vie d’un objet tombstone est dépassée, il faut qu’il soit purgé de l’annuaire afin de libérer de l’espace inutilement occupé. Pour cela, Active Directory s’appuie sur le « garbage collection process ». Le garbage collection process est une routine s’exécutant localement sur chaque contrôleur de domaine. Il s’acquitte de l’opération de purge des objets tombstone ayant atteint leur durée de vie précisée par la valeur de l’attribut tombstonelifetime. C’est la dernière pierre de l’édifice dans le processus de suppression des objets au sein de Active Directory.

Remarque : le garbage collection process prend en charge également la défragmentation en ligne de la base Active Directory.

Le garbage collection process se lance une première fois 15 minutes après le démarrage d’un contrôleur de domaine. Il s’exécute ensuite toutes les 12 heures. Cette intervalle d’exécution s’appuie sur l’attribut « garbageCollPeriod » de l’objet « cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=<forestDN> ». 

Il peut se vérifier aisément à l’aide de l’outil dsquery en exécutant la commande « dsquery * « cn=directory service,cn=windows nt,cn=services,cn=configuration,dc=<forestDN> » –scope base –attr garbagecollperiod ».

{gallery}38_tombstones/03{/gallery}

 

 

 

 

Vous pouvez également passer par la commande PowerShell suivante (nécessite le module Active Directory) :

Get-ADObject « CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=MONDOMAINE,DC=LOCAL » -Properties garbagecollperiod

Remarque : Comme pour l’attribut tombstonelifetime, si la valeur de l’attribut garbagecollperiod est nulle alors cela signifie qu’elle est définie à sa valeur par défaut, soit 12 heures. Dans ces conditions la requête dsquery ou PowerShell ne renverrons aucune valeur.

Il est possible de modifier cette valeur par défaut (à l’aide de ADSIEDIT par exemple). Notez toutefois que vous ne pourrez pas descendre en dessous de 1 heure.

Si nécessaire, il est également possible de lancer le garbage collection process manuellement en créant le fichier ldf ci-dessous et en éxecutant la commeande « ldifde -i -f gbgCollection.ldf » où gbgCollection.ldf est le nom attribué à notre fichier.

{codecitation style= »brush: diff »}

dn:

changetype: modify

add: doGarbageCollection

doGarbageCollection: 1

{/codecitation}

 

 

Le processus de suppression des objets en bref

 En guise de conclusion, nous allons donc reprendre ensemble les étapes du processus de suppression au sein de l’annuaire Active Directory.

Etape 1: un objet est supprimé sur la demande d’un administrateur. L’objet est modifié en objet tombstone. Son état sera propagé sur l’ensemble des contrôleurs de domaine.

Etape 2: l’objet tombstone reste présent dans la base durant la période précisée par la valeur du tombstone lifetime.

Etape 3: le garbage collection process qui s’éxecute localement sur chaque contrôleur de domaine et cela toutes les 12 heures détecte que l’objet vient d’atteindre son espérance de vie. Il le supprime définitivement le cas échéant.

{gallery}38_tombstones/04{/gallery}