Windows Server

Réanimation des objets tombstone d'Active Directory

Gil Kirkpatrick

 

Vue d'ensemble:

• Mode de stockage des objets supprimés dans Active Directory
• Utilisation de LDP et ADRESTORE pour rechercher et restaurer des objets tombstone
• Attributs des objets et systemFlags

Bien qu'il ne s'agisse probablement pas de votre thème de réflexion privilégié, la perte accidentelle de données est une réalité et, en tant que professionnel de l'informatique, vous devez être préparé à toutes sortes de scénarios de récupération. Dans le numéro d'avril 2007 de TechNet Magazine, j'ai évoqué l'importance de mettre en place un plan

de récupération des utilisateurs et des groupes Active Directory®. Dans cet article, disponible à l'adresse technetmagazine.com/issues/2007/04/ADRecovery, j'ai expliqué le mécanisme de liaison, de réplication et de suppression d'objets, ainsi que de restaurations faisant autorité. Malheureusement, la fonction de restauration faisant autorité exige que vous démarriez un contrôleur de domaine en mode Restauration du service d'annuaire (DSRM). Ce mode rend le contrôleur de domaine indisponible pendant la durée de l'opération de restauration.

Mais il existe une autre méthode que vous devez connaître. La réanimation des objets tombstone (aucun rapport avec les zombies !) fournit le seul moyen de récupérer des objets supprimés sans déconnecter un contrôleur de domaine, et de récupérer les informations d'identité d'un objet supprimé, telles que ses attributs objectGUID et objectSid. Elle résout habilement le problème de la recréation d'un utilisateur ou d'un groupe supprimé et de la réorganisation de toutes les références des anciennes listes de contrôle d'accès (ACL) qui contiennent l'objectSid de l'objet supprimé. Gardez seulement à l'esprit que la réanimation des objets tombstone comporte ses propres restrictions, que j'aborderai ultérieurement. Je vous recommande donc de conserver les restaurations faisant autorité dans votre escarcelle.

La réanimation des objets tombstone a été introduite dans Windows Server® 2003 Active Directory pour simplifier certains scénarios de récupération des données. Cette fonctionnalité tire parti du fait qu'Active Directory conserve les objets supprimés dans la base de données pendant un certain temps avant de les supprimer physiquement. Dans cet article, je décrirai en détail la façon dont Active Directory supprime et réanime les objets, et vous expliquerai comment vous pouvez récupérer les objets supprimés à l'aide d'outils Microsoft standard.

Qu'est-ce qu'un objet tombstone ?

Lorsque Active Directory supprime un objet de l'annuaire, il ne supprime pas physiquement l'objet de la base de données. Active Directory marque l'objet comme supprimé en définissant l'attribut isDeleted de l'objet sur TRUE, en supprimant la plupart des attributs de l'objet, en renommant l'objet, puis en le déplaçant vers un conteneur spécial du contexte de nommage de l'objet appelé CN=Deleted Objects. L'objet, maintenant appelé objet tombstone ou objet tombstone, est invisible aux opérations d'annuaire normales. Il n'est pas visible dans les composants logiciels enfichables Microsoft® Management Console (MMC) et la plupart des utilitaires LDAP (Lightweight Directory Access Protocol) ignorent totalement l'existence de l'objet tombstone. L'objet tombstone a, dans les faits, totalement disparu. Les données sont cependant toujours là, mais invisibles. Pourquoi Active Directory conserve-t-il des objets tombstone, c'est-à-dire des objets supprimés, dans la base de données ?

Bien qu'invisible pour les autres processus, un objet tombstone est visible pour le processus de réplication d'Active Directory. Afin de s'assurer que la suppression est exécutée sur tous les contrôleurs de domaine hébergés par l'objet supprimé, Active Directory copie l'objet tombstone sur les autres contrôleurs de domaine. Ainsi, l'objet tombstone est utilisé pour répliquer la suppression sur l'ensemble de l'environnement Active Directory.

Durée de vie d'un objet tombstone

Active Directory supprime généralement un objet de l'annuaire en réponse à une opération du protocole de suppression LDAP ou une opération de suppression du Gestionnaire de comptes de sécurité (SAM). Cette opération, appelée suppression d'origine, est distincte des opérations de suppression exécutées par le processus de réplication d'Active Directory. Notez que cette discussion ne concerne pas les objets dynamiques, dont le mécanisme de suppression est différent et qui sont directement supprimés par Active Directory lorsque leur durée de vie (TTL) expire.

Lorsque Active Directory reçoit l'opération de suppression, il lance d'abord une liste de vérification pour vérifier que l'objet est autorisé à être supprimé. Ce processus est étonnamment compliqué car il vérifie que les critères suivants sont tous satisfaits :

• L'attribut isDeleted de l'objet n'est pas déjà défini sur TRUE. (Vous ne pouvez pas supprimer un objet déjà supprimé !)
• L'indicateur de contrôle du descripteur de sécurité propre à la ressource « objet privé » n'est pas défini dans le descripteur de sécurité de l'objet. (Ceci semble être une « fonctionnalité » non documentée. L'indicateur d'objet privé est le bit 1 de l'octet Sbz1 de la structure du descripteur de sécurité).
• Le bit « Interdire la suppression » (0x80000000) n'est pas défini dans l'attribut systemFlags de l'objet.
• L'attribut isCriticalSystemObject de l'objet n'est pas défini sur TRUE.
• Le descripteur de sécurité de l'objet accorde les droits d'accès appropriés à l'utilisateur pour supprimer l'objet. (Plus particulièrement, l'utilisateur est autorisé à supprimer l'objet lui-même et à supprimer un enfant de l'objet parent).
• L'objet n'est pas un objet de référence croisée (objectClass = crossRef) pour un contexte de nommage existant.
• L'objet n'a pas d'objets subordonnés. (Si l'opération de suppression LDAP inclut l'id d'objet de contrôle LDAP « tree delete », Active Directory supprime également automatiquement les objets subordonnés, à moins que leur attribut isCriticalSystemObject ne soit défini sur TRUE. Ceci empêche la suppression par inadvertance d'objets système critiques au cours de l'opération de suppression de l'arborescence. Vous pouvez, bien sûr, supprimer ces objets individuellement).
• L'objet n'est pas un objet interne critique (par exemple, il ne s'agit pas de l'objet nTDSDSA du contrôleur de domaine ou des objets d'espace réservé pour les ancêtres des têtes de contexte de nommage).

Outre le fait que ces critères doivent être satisfaits, Active Directory doit également être dans un état approprié pour traiter l'opération de suppression. Par exemple, si Active Directory est en train de modifier un nom de domaine, il ne peut pas supprimer un compte de confiance du domaine ou un objet crossRef.

S'il est déterminé que l'objet peut réellement être supprimé, Active Directory le transforme en objet tombstone. Active Directory supprime d'abord les attributs inutiles de l'objet, ne conservant dans l'objet tombstone que les attributs spécifiés à la figure 1 et ceux définis dans le schéma. (Pour plus d'informations, consultez la section « Récupération des attributs d'objet »). Il modifie ensuite le nom unique relatif (RDN) de l'objet en CN=<old RDN>\0ADEL:<objectGUID>, où \0A indique le caractère de saut à la ligne ASCII et <objectGUID> est l'objectGUID exprimé sous forme de chaîne. L'attribut lastKnownParent est ensuite défini sur le nom unique (DN) du conteneur parent de l'objet et l'attribut isDeleted est défini sur TRUE. Active Directory supprime ensuite tous les attributs des liens précédents ou suivants de l'objet. Enfin, si le bit « Interdire le déplacement à la suppression » de l'attribut systemFlags de l'objet n'est pas défini, Active Directory déplace l'objet vers le conteneur CN=Deleted Objects pour le contexte de nommage. (Pour plus d'informations sur ce sujet, reportez-vous à l'encadré « Attribut systemFlags et comportement des objets »).

Figure 1 Attributs enregistrés dans un objet tombstone

Codés en dur pour être enregistrés

attributeID

attributeSyntax

dnReferenceUpdate

dNSHostName

flatName

governsID

groupType

instanceType

lDAPDisplayName

legacyExchangeDN

mS-DS-CreatorSID

mSMQOwnerID

nCName

objectClass

objectGUID

objectSid

oMSyntax

proxiedObejctName

replPropertyMetaData

sAMAccountName

securityIdentifier

sIDHistory

subClassOf

systemFlags

trustPartner

trustDirection

trustType

trustAttributes

userAccountControl

uSNChanged

uSNCreated

whenCreated

Enregistrés en raison du paramétrage de searchFlags

msDS-AdditionalSam­AccountName

msDS-Auxiliary-Classes

msDS-Entry-Time-To-Die

msds-Intid

msSFU30NisDomain

nTSecurityDescriptor

uid

Il est à noter que le dossier CN=Deleted Objects est plat et ne possède pas de hiérarchie d'objets. Vous pensez peut-être que cela risque de provoquer des conflits de nom si vous avez supprimé deux objets différents avec le même CN. En fait, ce n'est pas le cas. Comme l'objectGUID est incorporé dans le RDN de chaque objet tombstone, chacun d'eux est unique dans le conteneur CN=Deleted Objects.

Évidemment, les objets ne restent pas éternellement dans le conteneur CN=Deleted Objects. La durée de vie par défaut de l'objet tombstone est de 60 jours pour les forêts initialement créées avec Windows® 2000 et Windows Server 2003, et de 180 jours pour les forêts initialement créées avec Windows Server 2003 SP1. Vous pouvez modifier la durée de vie de l'objet tombstone en définissant l'attribut tombstoneLifetime de l'objet CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration, DC=<domaine racine>.

Toutes les 12 heures, chaque contrôleur de domaine démarre un processus de nettoyage de la mémoire. (Pour modifier ceci, vous pouvez définir une nouvelle valeur pour l'attribut garbageCollPeriod de l'objet CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration,DC=<domaine racine>.) Ce nettoyage de la mémoire numérise tous les objets tombstone sur le contrôleur de domaine et supprime physiquement tous ceux ayant dépassé leur durée de vie.

Utilisation de LDP pour rechercher les objets tombstone

LDP est un utilitaire de même type que l'Explorateur Windows permettant de travailler avec Active Directory. Á l'origine, LDP a été conçu par l'équipe de développement d'Active Directory pour tester son code LDAP alors qu'Active Directory était encore en phase de développement. Aujourd'hui intégré dans les outils de support de Windows Server 2003, LDP a évolué en un outil robuste qui facilite le travail avec Active Directory.

Bien que les objets tombstone soient invisibles pour les opérations d'annuaire normales, vous pouvez les rechercher dans Active Directory à l'aide des opérations de recherche LDAP et d'extensions LDAP spéciales baptisées contrôles. Définis dans la norme LDAP, les contrôles constituent un mécanisme utilisé pour étendre le protocole LDAP afin de fournir des fonctionnalités supplémentaires complétant celles définies dans la norme LDAP, tout en restant compatibles avec les autres logiciels conformes à la norme LDAP. Active Directory prend en charge 22 contrôles, y compris le contrôle Return Deleted Objects. Lorsqu'il est utilisé pour étendre une opération de recherche LDAP, ce contrôle récupère les objets supprimés qui seraient autrement invisibles.

Pour vous expliquer comment cela fonctionne, je me connecte au domaine foo.local avec mes informations d'identification d'administrateur d'entreprise, puis utilise le composant logiciel enfichable MMC Active Directory Users and Computers (ADUC) pour créer un objet utilisateur (CN=John Smith,CN=Users,DC=foo,DC=local), tel que décrit à la figure 2. Je supprime ensuite l'objet utilisateur, en utilisant à nouveau ADUC.

Figure 2** Utilisation d'ADUC pour créer un utilisateur **(Cliquer sur l'image pour l'agrandir)

Je peux maintenant exécuter le programme LDP et l'utiliser pour afficher l'objet tombstone correspondant à l'utilisateur supprimé. La première étape consiste à connecter LDP à un contrôleur de domaine spécifique et à s'authentifier en utilisant les informations d'identification appropriées. Pour me connecter au contrôleur de domaine, il me suffit de sélectionner l'option Connect (Connecter) du menu Connection (Connexion). Dans la mesure où j'exécute LDP sur le contrôleur de domaine, il me suffit d'appuyer sur OK pour me connecter au contrôleur de domaine local. Si vous exécutez LDP à distance, vous devez spécifier le nom du contrôleur de domaine auquel vous voulez vous connecter. Une fois la connexion établie, LDP affiche les attributs de rootDSE, lequel contient des attributs décrivant l'état et la configuration du contrôleur de domaine lui-même (voir la figure 3).

Figure 3** LDP connecté à un contrôleur de domaine **(Cliquer sur l'image pour l'agrandir)

Maintenant, pour m'authentifier auprès du contrôleur de domaine en utilisant des informations d'identification d'administrateur d'entreprise ou de domaine, je sélectionne Bind (Lier) dans le menu Connection (Connexion). Dans la mesure où je suis déjà connecté en tant qu'administrateur d'entreprise pour la forêt (les administrateurs d'entreprise et de domaine possèdent par défaut les droits nécessaires pour répertorier et réanimer les objets du conteneur CN=Deleted Objects), je laisse tout simplement le nom d'utilisateur et le mot de passe vides dans la boîte de dialogue Bind (Lier) et j'appuie sur OK. Je pourrais également entrer les informations d'identification appropriées dans cette même boîte de dialogue.

Je répertorie ensuite le contenu du conteneur CN=Deleted Objects,DC=foo,DC,local. Normalement, vous ne verrez jamais le conteneur CN=Deleted Objects car il est lui-même marqué comme supprimé. Le seul moyen de rechercher le conteneur CN=Deleted Objects est d'utiliser le contrôle LDAP Return Deleted Objects.

Pour utiliser ce contrôle avec LDP, accédez au menu Browse (Parcourir) et sélectionnez Search (Rechercher). La boîte de dialogue de recherche illustrée à la figure 4 apparaît. Le champ Base Dn vous permet de spécifier l'emplacement de l'arborescence où démarrer la recherche. J'entre le DN du conteneur Deleted Objects pour le domaine (dans cet exemple, le DN est CN=Deleted Objects,DC=foo,DC=local).

Figure 4** Boîte de dialogue de recherche de LDP **

Dans le champ Filter (Filtre), je spécifie les critères de recherche utilisés par LDP. La valeur par défaut est (objectClass=*) qui indique à la recherche de renvoyer tous les objets dont l'attribut objectClass comporte une valeur. Dans la mesure où même les objets supprimés dans Active Directory ont une valeur pour objectClass, le filtre par défaut renvoie chaque objet contenu dans la zone de recherche. Dans cet exemple, je modifie le filtre en (objectClass=user) pour limiter la recherche aux objets utilisateur. Il sera ainsi plus facile de rechercher l'utilisateur John Smith supprimé parmi les quelques milliers d'objets tombstone du conteneur CN=Deleted Objects.

Vous pouvez découvrir qu'il y a plus d'objets dans le conteneur CN=Deleted Objects que n'en renvoie Active Directory en une seule opération de recherche. Pour résoudre ce problème, vous pouvez utiliser une recherche LDAP paginée, qui renvoie les résultats d'un groupe à la fois. LDP ne vous permet cependant pas de spécifier à la fois une recherche paginée et une recherche étendue. Vous devez donc affiner votre filtre LDAP pour localiser l'objet que vous recherchez.

Les cases d'option Scope (Zone) vous permettent de spécifier la partie de l'arborescence dans laquelle effectuer la recherche. Une recherche de base ne renvoie que l'objet spécifié par le champ Base Dn. Une recherche à un niveau renvoie les objets qui sont immédiatement subordonnés à l'objet Base Dn. Et une recherche dans la sous-arborescence renvoie tous les objets subordonnés à l'objet Base Dn. Comme le dossier CN=Deleted Objects ne possède pas de hiérarchie, j'utilise une recherche à un niveau pour récupérer tous les objets tombstone.

Jusqu'ici, je ne vous ai présenté que les grands traits d'une recherche LDAP classique. Si je devais la lancer maintenant, LDP afficherait une erreur indiquant que CN=Deleted Objects,DC=foo,DC=com n'existe pas puisqu'il est marqué comme supprimé. Je dois encore inclure le contrôle LDAP Return Deleted Objects dans l'opération de recherche. Pour ce faire, je clique sur le bouton Options de la boîte de dialogue de recherche et je sélectionne Extended (Etendu) pour le type d'appel de recherche, comme illustré à la figure 5. Cette option me permet de spécifier des contrôles pour l'opération de recherche. Ici, je modifie également la liste des attributs en *. LDP affiche ainsi tous les attributs normaux de chaque objet qu'il récupère; au lieu du jeu d'attributs par défaut de LDP.

Figure 5** Boîte de dialogue des options de recherche de LDP **

J'appuie maintenant sur le bouton Controls (Contrôles) pour afficher la boîte de dialogue Controls (Contrôles). La boîte de dialogue Controls (Contrôles) de LDP est assez peu conviviale ; lorsque vous effectuez cette opération, veillez à bien respecter ces étapes pour ajouter le contrôle Return Deleted Objects.

Ouvrez la liste déroulante Load Predefined (Charger les éléments prédéfinis), sélectionnez Return deleted objects (Renvoyer les objets supprimés) et appuyez sur le bouton Check in (Archiver). Cette opération ajoute l'identificateur d'objet (OID) du contrôle Return Deleted Objects (1.2.840.113556.1.4.417) à la liste des contrôles actifs, comme illustré à la figure 6. LDP ajoute ensuite le contrôle à toutes opérations de recherche étendue ultérieures. Appuyez sur OK pour enregistrer les paramètres de contrôle et à nouveau sur OK pour fermer la boîte de dialogue Search Options (Options de Recherche).

Figure 6** Ajout d'un contrôle Return Deleted Objects **

La boîte de dialogue Controls (Contrôles) a un comportement particulier. Bien qu'un OID apparaisse dans la liste des contrôles actifs, ceci ne signifie pas nécessairement que le contrôle est réellement appliqué. Vous devrez parfois extraire un contrôle, puis l'archiver à nouveau pour vous assurer qu'il sera utilisé dans la prochaine opération LDAP.

Je maintenant suis prêt à lancer ma recherche. J'appuie sur le bouton OK de la boîte de dialogue de recherche de LDP et LDP récupère tous les objets utilisateur du conteneur CN=Deleted Objects pour le domaine. La figure 7 illustre mes résultats.

Figure 7** Résultats du conteneur CN=Deleted Objects **(Cliquer sur l'image pour l'agrandir)

Examen des résultats renvoyés par LDP

Ma recherche a renvoyé deux objets tombstone. Premièrement, vous pouvez voir le DN du premier objet tombstone : CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local. L'objectGUID de l'objet supprimé est représenté sous forme de chaîne (41800281-6bc4-42c3-a99b-b283022b3af8). En dessous du DN figure une liste d'attributs indiquant les valeurs pour objectClass, cn, distinguishedName, etc. Vous pouvez voir que la valeur de l'attribut isDeleted est TRUE, ce qui signifie que l'objet a réellement été supprimé. Vous voyez également que l'objectSid a été conservé dans l'objet tombstone, ce qui est important pour récupérer les objets tombstone de l'utilisateur et du groupe, comme nous le verrons ultérieurement. L'attribut lastKnownParent, qui représente le DN de l'objet qui contenait l'objet supprimé avant qu'il soit transformé en objet tombstone, est également extrêmement important pour la récupération des objets tombstone.

Dans mon exemple, LDP a affiché deux objets tombstone, qui étaient tous deux des objets utilisateur appelés CN=John Smith provenant initialement du conteneur CN=Users,dc=foo,dc=local. Comment deux objets séparés avec le même RDN peuvent-ils provenir du même conteneur ? L'explication est assez simple. Avant d'exécuter LDP pour rechercher les objets tombstone, j'ai créé l'objet utilisateur CN=John Smith dans le conteneur CN=Users,DC=foo,DC=local et je l'ai supprimé. J'ai ensuite créé un autre objet utilisateur avec les mêmes attributs et je l'ai également supprimé. Dans la mesure où j'avais déjà supprimé le premier objet utilisateur CN=John Smith, il était tout à fait raisonnable de créer le deuxième, même s'il avait le même nom. Mais ce sont des objets individuels uniques qui se distinguent par leur objectGUID. Du fait qu'Active Directory incorpore l'objectGUID dans le DN de l'objet tombstone, ils apparaissent comme des objets séparés dans le conteneur CN=Deleted Objects.

Réanimation d'un objet tombstone

Active Directory fournit un mécanisme permettant de restaurer un objet tombstone en objet normal. Il s'agit en fait d'une fonction d'annulation de suppression pour les objets supprimés. Cette fonction est une opération de modification propre à LDAP qui doit inclure deux modifications d'attribut spécifiques : elle doit supprimer l'attribut isDeleted (et non se contenter de le définir sur FALSE) et déplacer l'objet vers un autre conteneur en modifiant le distinguishedName de l'objet. En principe (mais pas nécessairement), le nouveau distinguishedName utilise l'attribut lastKnownParent comme conteneur et conserve le même RDN moins le composant \0ADEL:<objectGUID> qu'Active Directory a ajouté lorsque il a créé l'objet tombstone.

Avant de réanimer l'objet tombstone, Active Directory vérifie que certaines conditions nécessaires sont toutes remplies. L'utilisateur doit disposer du droit d'accès étendu de réanimation des objets tombstone, défini sur la tête de contexte de nommage du contexte de nommage contenant l'objet tombstone. L'utilisateur ne peut pas réanimer son propre objet. L'attribut isDeleted de l'objet tombstone doit être défini sur TRUE. L'Identificateur de sécurité (SID) du propriétaire de l'objet, tel que défini dans le descripteur de sécurité doit posséder un SID de l'un des domaines de la forêt ou d'un domaine de confiance.

Si l'objet en question se trouve dans les contextes de nommage de configuration ou de schéma, les bits FLAG_CONFIG_ALLOW_RENAME et FLAG_ CONFIG_ALLOW_MOVE doivent être définis dans l'attribut systemFlags de l'objet tombstone. Si l'objet se trouve dans les contextes de nommage de configuration ou de schéma et que l'indicateur FLAG_CONFIG_ALLOW_LIMITED_MOVE est défini, l'objet peut seulement être déplacé vers un conteneur ayant le même grand-parent, en d'autres termes, l'objet doit conserver son arrière grand-parent après le déplacement. Si l'objet se trouve dans le contexte de nommage d'un domaine ou dans une partition d'application, les bits FLAG_DOMAIN_DISALLOW_RENAME et FLAG_DOMAIN_DISALLOW_MOVE ne doivent pas être définis dans l'attribut systemFlags de l'objet tombstone.

L'utilisateur doit disposer des droits, comme défini dans le descripteur de sécurité, permettant de modifier le RDN (en principe contexte de nommage, mais pas toujours) et d'ajouter l'objet au nouveau conteneur parent. Le nouveau conteneur parent doit être un supérieur possible pour l'attribut objectClass de l'objet tombstone, tel que défini par le schéma. Bien qu'en général le déplacement à l'intérieur ou à l'extérieur du conteneur System ne soit pas autorisé (à moins que la valeur de Registre de la sous-arborescence système Unlock soit différente de zéro), la réanimation d'un objet tombstone dans le conteneur System est autorisée.

La réanimation d'un objet de schéma n'est jamais autorisée. Ce n'est cependant pas vraiment un problème puisque vous ne pouvez pas supprimer légitimement un objet du contexte de nommage de schéma.

Si toutes les vérifications sont satisfaisantes et que les exigences nécessaires sont respectées, Active Directory exécute les étapes suivantes sur l'objet tombstone pour réanimer l'objet :

• L'attribut isDeleted est supprimé.
• Si rien d'autre n'est précisé dans l'opération de modification, l'objectCategory est défini sur l'objectClass le plus spécifique indiqué dans l'objet tombstone.
• Le RDN est modifié et l'objet est écrit dans le nouveau conteneur parent.

Après réanimation, l'objet possède des attributs objectGUID et objectSid identiques à ceux qu'il possédait initialement. Cela signifie que les références externes à l'objet, par exemple dans les ACL, ne doivent pas être redéfinies comme c'est le cas si vous recréez un objet supprimé. L'objet réanimé a le même aspect et agit exactement de la même manière qu'avant sa suppression. Il existe cependant une différence importante : l'objet restauré ne possède pas les attributs qui n'ont pas été enregistrés dans l'objet tombstone.

Utilisation de LDP pour réanimer les objets tombstone

Attribut systemFlags et comportement des objets

L'attribut systemFlags est un attribut facultatif défini pour la classe Top, ce qui fait de systemFlags un attribut facultatif pour chaque classe d'Active Directory. Il s'agit d'un masque binaire d'entier de 32 bits qui contrôle le comportement des déplacements et des suppressions d'objet. Voici un récapitulatif des indicateurs importants.

FLAG_DISALLOW_DELETE (0x80000000)

Si cet indicateur est défini, le système n'autorise pas la suppression ou le déplacement de l'objet dans un autre domaine.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

Les objets des contextes de nommage de configuration et de schéma ne peuvent pas être renommés sauf si cet indicateur est défini dans l'attribut systemFlags.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

Les objets des contextes de nommage de configuration et de schéma ne peuvent pas être déplacés sauf si cet indicateur est défini dans l'attribut systemFlags.

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

Les objets des contextes de nommage de configuration et de schéma ne peuvent pas être déplacés sauf si cet indicateur est défini dans l'attribut systemFlags. Cet indicateur impose une restriction supplémentaire sur le conteneur cible de l'opération de déplacement : le conteneur cible doit avoir le même grand-parent que le conteneur actuel.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

Par défaut, les objets d'un contexte de nommage de domaine ou d'application peuvent être renommés. Cependant, si cet indicateur est défini dans l'attribut systemFlags de l'objet, le système n'autorise pas le changement de nom de l'objet.

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

Par défaut, les objets d'un contexte de nommage de domaine ou d'application peuvent être déplacés vers un autre conteneur. Cependant, si cet indicateur est défini dans l'attribut systemFlags de l'objet, le système n'autorise pas le déplacement de l'objet.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

Si cet indicateur est défini, le système ne déplace pas l'objet vers le conteneur CN=Deleted Objects de son contexte de nommage. Il se contente de déterminer l'attribut isDeleted, de renommer l'objet et de supprimer les attributs non désignés dans le schéma comme devant être enregistrés. Tous les objets supprimés n'apparaissent par conséquent pas dans le conteneur CN=Deleted Objects pour le contexte de nommage ; certains restent dans le conteneur parent original.

Maintenant que je vous ai expliqué les rouages de la réanimation des objets tombstone, je veux vous montrer comment je peux utiliser LDP pour restaurer l'utilisateur CN=John Smith que j'ai supprimé. Je me connecte d'abord à un contrôleur de domaine et je m'authentifie. Je peux maintenant exécuter une opération de modification à l'aide de LDP. Dans les paramètres de l'opération de modification, je peux supprimer l'attribut isDeleted et spécifier un nouveau DN en même temps.

Dans la mesure où j'agis sur un objet tombstone, je dois spécifier le contrôle LDAP Return Deleted Objects. Pour définir ce contrôle pour l'opération de modification dans LDP, sélectionnez Controls (Contrôles) dans le menu d'options, puis sélectionnez Return deleted objects (Renvoyer les objets supprimés) dans la liste déroulante Load Predefined (Charger les éléments prédéfinis), et appuyez ensuite sur le bouton Check in (Archiver), puis sur OK pour enregistrer les paramètres du contrôle.

Je sélectionne maintenant Modify (Modifier) dans le menu Browse (Parcourir) pour ouvrir la boîte de dialogue Modify (Modifier) et entrer le DN de l'objet tombstone que je veux restaurer. Le plus simple est de copier et coller le DN à partir des résultats de l'opération de recherche que j'ai exécutée précédemment.

Ensuite, je dois entrer une liste d'opérations d'attribut à exécuter. La réanimation d'un objet tombstone nécessite deux opérations d'attribut : la suppression de l'attribut isDeleted et le remplacement de l'attribut distinguishedName par le DN souhaité de l'objet tombstone réanimé. Je tape donc isDeleted dans le champ Attribute (Attribut) et je sélectionne la case d'option Delete (Supprimer). Lorsque j'appuie sur le bouton Enter (Entrée), l'opération d'attribut est ajoutée à la liste des entrées, comme illustré à la figure 8.

Figure 8** Spécification des opérations d'attribut à exécuter **

J'entre ensuite le distinguishedName dans le champ Attribute (Attribut), sélectionne la case d'option Replace (Remplacer) et entre le nouveau DN de l'objet dans le champ Values (Valeurs). Dans le cas présent, j'utilise le distuiguishedName original de l'utilisateur, CN=John Smith,CN=Users,DC=foo,DC=local. Lorsque j'appuie sur le bouton Enter (Entrée), l'opération de modification est ajoutée à la liste des entrées.

Puisque je dois inclure le contrôle LDAP Return Deleted Objects dans l'opération de modification, je dois utiliser une modification LDAP étendue. Pour ce faire, je coche la case Extended (Étendue). Une fois paramétrage terminé, comme illustré à la figure 9, j'appuie sur le bouton Run (Exécuter) pour effectuer les modifications. LDP affiche les résultats dans une grande fenêtre de texte.

Figure 9** Modification du distinguishedName **

Lorsque je reviens au composant logiciel enfichable MMC Active Directory Users and Computers et que je regarde dans le conteneur CN=Users, je retrouve à la même place l'objet utilisateur que j'avais supprimé. Mais l'objet comporte certaines différences importantes par rapport à son état original. Nous y reviendrons dans un instant.

Utilisation de ADRESTORE pour réanimer les objets tombstone

Une fois vous avez compris comment utiliser LDP, la réanimation d'un objet tombstone n'est pas extrêmement difficile. Mais elle n'est pas très commode non plus. Heureusement, nos amis de Sysinternals (une entreprise qui appartient maintenant à Microsoft) ont développé un outil de ligne de commande pour simplifier le processus de réanimation. Cet outil, baptisé ADRESTORE, est disponible sur le site Web de Microsoft à l'adresse microsoft.com/technet/ sysinternals/utilities/AdRestore.mspx. Son installation est simple. Il vous suffit de copier l'exécutable dans un répertoire approprié sur votre ordinateur (par exemple le répertoire C:\WINDOWS\SYSTEM32).

ADRESTORE s'exécute dans deux modes. Si vous l'exécutez sans aucun paramètre, il répertorie tous les objets tombstone du conteneur CN=Deleted Objects du domaine par défaut. Vous pouvez ajouter une chaîne de recherche à la ligne de commande pour sélectionner les objets à afficher, par exemple :

C:\> adrestore John

Vous affichez ainsi tous les objets tombstone du conteneur CN=Deleted Objects qui contiennent la chaîne « John » dans leur attribut CN ou UO (l'utilitaire utilise les filtres de recherche cn=*John* et ou=*John*). Ce n'est pas exactement la façon la plus souple de rechercher les objets tombstone, mais c'est réalisable dans la plupart des situations. La figure 10 illustre le résultat de ma recherche renvoyé dans ADRESTORE.

Figure 10** Attributs enregistrés dans un objet tombstone **(Cliquer sur l'image pour l'agrandir)

Si vous souhaiter réanimer un objet tombstone, et pas seulement le rechercher, vous devez spécifier le commutateur -r, ainsi qu'une chaîne facultative, comme suit :

C:\> adrestore –r John

Cette commande vous invite à réanimer chaque objet tombstone correspondant. ADRESTORE réanime toujours l'objet dans le conteneur fourni par l'attribut lastKnownParent de l'objet tombstone. Il n'existe aucune façon de spécifier un conteneur différent.

ADRESTORE propose une interface de ligne de commande commode pour utiliser la fonctionnalité de réanimation d'Active Directory. Bien que manquant encore de souplesse, son utilisation est un peu plus simple que LDP. Il n'en reste pas moins qu'ADRESTORE n'évite pas deux problèmes importants liés à la réanimation des objets tombstone : la récupération des attributs supprimés de l'objet lors de sa première suppression et la récupération des objets supprimés du contexte de nommage de configuration.

Récupération des attributs d'objet

En termes de récupération des données, la réanimation des objets tombstone présente un grand avantage par rapport à l'exécution d'une restauration faisant autorité : la réanimation d'un objet tombstone ne nécessite pas la déconnexion du contrôleur de domaine. La réanimation des objets tombstone est largement préférable à la simple création d'une nouvelle version d'un objet supprimé. Si vous recréez un objet, il possédera toujours les nouveaux attributs objectGUID et objectSid (s'il s'agit d'une entité de sécurité telle qu'un utilisateur). Par conséquent, toutes les références externes à l'objet, telles que les ACL, doivent être mises à jour pour refléter la nouvelle identité de l'objet. Cela peut être extrêmement laborieux.

Certains attributs sont supprimés lorsqu'un objet est supprimé, et ces attributs ne sont pas récupérés lors de la réanimation des objets tombstone. Mais Active Directory enregistre certains attributs essentiels dans l'objet tombstone, dont les plus importants sont ceux liés à l'identité tels que objectGUID et objectSid. Il enregistre également un grand nombre d'autres attributs par défaut (voir la figure 1). La plupart des attributs qui sont codés en dur pour être enregistrés ne sont pas très intéressants, surtout dans le cadre d'une discussion sur la récupération des objets utilisateur supprimés. Mais vous pouvez spécifier des attributs supplémentaires à enregistrer dans l'objet tombstone en définissant le bit 3 (0x00000008) de l'attribut searchFlags de l'objet attributeSchema correspondant dans le schéma Active Directory. Dans le schéma de Windows Server 2003 R2, ce bit est déjà défini pour certains attributs (également illustrés à la figure 1).

L'installation de certaines applications peut modifier le bit 3 du searchFlags des attributs existants, voire ajouter de nouveaux attributs dont le bit 3 est défini. Exchange Server, par exemple, configure plusieurs attributs supplémentaires à enregistrer dans l'objet tombstone.

Active Directory n'enregistre pas les attributs avec des liens précédents ou des liens suivants dans l'objet tombstone, même si vous spécifiez cet enregistrement dans l'attribut searchFlags de l'objet de schéma. En particulier, Active Directory n'enregistre pas les éléments tels que l'attribut de membre d'un groupe ou l'attribut memberOf d'un utilisateur. Ainsi la réanimation des objets tombstone n'offre pas de solution de récupération des d'appartenances aux groupes dans Active Directory. Sur ce thème, reportez-vous à mon article « Récupération après incident : utilisateurs et groupes Active Directory » à l'adresse technetmagazine.com/issues/2007/04/ADRecovery . Vous devrez donc toujours fournir un mécanisme alternatif pour récupérer ces informations lors de la réanimation des objets tombstone.

Si vous voulez utiliser la réanimation des objets tombstone dans le cadre de votre stratégie de récupération de données, vous devez vous assurer que les attributs importants sont enregistrés dans l'objet tombstone ou vous devez proposer une autre façon d'enregistrer et de récupérer les attributs importants, telle que l'utilisation de LDIFDE ou d'un autre modèle de sauvegarde et de restauration. Certains produits de récupération de données Active Directory tiers proposent un mécanisme automatisé de sauvegarde et de restauration des attributs qui ne sont pas enregistrés dans l'objet tombstone, ni récupérés à partir de cet objet.

Réanimation des objets à partir du contexte de nommage de configuration

La réanimation des objets tombstone souffre d'une autre restriction importante : en général vous ne pouvez pas réanimer des objets qui ont été supprimés du contexte de nommage de configuration. Ces objets sont soumis à des règles spéciales concernant le déplacement et la modification du nom, définies par l'attribut systemFlags de l'objet. Sauf indication contraire de l'attribut systemFlags, les objets du contexte de nommage de configuration ne peuvent pas être déplacés ou renommés, ce qui signifie que leurs objets tombstone ne peuvent pas être réanimés. Active Directory applique certaines valeurs pour l'attribut systemFlags lorsqu'il crée des objets de classes spécifiques, tel que définies à la figure 11. Notez qu'Active Directory applique l'opération logique au niveau du bit OR à ces valeurs en combinaison avec n'importe quelle valeur de systemFlags spécifiée dans l'opération d'ajout. De cette façon, même si l'application spécifie une valeur différente pour l'attribut systemFlags, les bits nécessaires sont correctement définis.

Figure 11 Paramètres par défaut de systemFlags

Classe	Paramètre par défaut
serveur	FLAG_DISALLOW_MOVE_ON_DELETE FLAG_CONFIG_ALLOW_RENAME FLAG_CONFIG_ALLOW_LIMITED_MOVE
site	FLAG_DISALLOW_MOVE_ON_DELETE
serversContainer	FLAG_DISALLOW_MOVE_ON_DELETE
nTDSDSA	FLAG_DISALLOW_MOVE_ON_DELETE
siteLink	FLAG_CONFIG_ALLOW_RENAME
siteLinkBridge	FLAG_CONFIG_ALLOW_RENAME
nTDSConnection	FLAG_CONFIG_ALLOW_RENAME

Les seuls objets du contexte de nommage de configuration que vous pouvez réanimer en temps normal sont les objets serveur. Il est intéressant de constater que, lorsque Active Directory supprime un objet serveur, son objet tombstone n'est pas déplacé vers le conteneur CN=Deleted Objects pour le contexte de nommage de configuration ; l'objet tombstone reste simplement à l'endroit où se trouve l'objet. Ceci permet au vérificateur de cohérence des données, un processus chargé du calcul de la topologie de réplication d'Active Directory, de récupérer automatiquement après certains scénarios dans lesquels les objets serveur supprimés risquent d'entraver une réplication correcte. Donc si vous essayez de réanimer un objet serveur, souvenez-vous que vous ne le trouverez pas dans le conteneur CN=Deleted Objects.

Réanimation dans votre plan de récupération

La réanimation des objets tombstone doit constituer un élément essentiel de votre boîte à outils de récupération de données. Ce mécanisme est le seul moyen de récupérer des objets supprimés sans déconnecter un contrôleur de domaine et, tout aussi important, le seul moyen de récupérer les informations d'identité d'un objet supprimé. Il résout habilement le problème de la recréation d'un utilisateur ou d'un groupe supprimé et de la réorganisation de toutes les anciennes références ACL.

Mais la réanimation des objets tombstone est une solution incomplète. Vous devez fournir votre propre mécanisme de récupération des attributs qu'Active Directory ne conserve pas dans les objets tombstone et votre capacité de récupération des objets supprimés du contexte de nommage de configuration est limitée. N'oubliez pas que si vous ne choisissez pas de réanimer un utilisateur ou un groupe supprimé, vous devrez toujours récupérer les appartenances aux groupes, ainsi que les autres attributs liés dont vous pouvez avoir besoin.

Gil Kirkpatrickest directeur technique chez NetPro et développe des logiciels pour Active Directory depuis 1996. Avec Guido Grillenmeier, qui travaille chez HP, il anime des ateliers consacrés à la récupération après incident Active Directory, qui connaissent un grand succès. Gil est également le fondateur de Directory Experts Conference (www.dec2007.com).

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.