Windows Administration: Disaster Recovery: Active Directory Users and Groups

Article
08/24/2016

Administration de Windows

Récupération après incident : utilisateurs et groupes Active Directory

Gil Kirkpatrick

Vue d'ensemble:

Mécanismes de réplication et liaison d'objets
Utilisation de NTDSUTIL pour sauvegarder et restaurer
Restaurations faisant autorité et ne faisant pas autorité

Active Directory est l'un des services les plus importants dans un réseau Windows. Pour éviter les pannes et la perte de productivité, il est essentiel d'avoir un plan de récupération après incident pour les problèmes apparentés à Active Directory. Cela peut paraître évident, mais

vous seriez surpris d'apprendre le nombre d'administrateurs qui n'ont pas de plan pour l'une des raisons les plus fréquentes qui provoquent la défaillance d'Active Directory® : la suppression accidentelle de données.

La suppression accidentelle d'objets est l'une des causes de défaillance de service les plus communes. Lorsque j'anime des séminaires et des conférences, je demande souvent qui a été victime d'une défaillance d'Active Directory provoquée par une suppression accidentelle de données. Et à chaque fois, presque tout le monde lève la main.

Pour comprendre pourquoi que la récupération de données est si complexe, vous devez d'abord comprendre : comment Active Directory enregistre et copie des objets, comment il supprime des objets, et les mécanismes de restaurations autorisés et non autorisés.

Enregistrement d'objets

Active Directory est une base de données d'objets spécialisée qui implémente le modèle de données X.500/LDAP. La banque de données (appelée arborescence d'information d'annuaire ou DIT) est basée sur le moteur de stockage extensible (Extensible Storage Engine, ESE), un moteur de base de données à méthode d'accès séquentielle indexée (ISAM). Active Directory enregistre la DIT dans deux tableaux : le tableau des données (qui contient les véritables objets et attributs d'Active Directory), et le tableau des liens (qui contient les relations entre les objets).

Chaque objet Active Directory est enregistré dans une ligne séparée au sein du tableau des données, avec une colonne par attribut. Le tableau des données contient toutes les entrées pour toutes les répliques enregistrées dans le contrôleur de domaine (Domain Controller, DC). Dans un DC normal, le tableau des données contient le contexte d'attribution (Naming Context, NC) du domaine, le NC de la configuration, et le NC du schéma. Sur un catalogue global, le tableau des données contient des entrées pour chaque objet de la forêt.

Active Directory utilise la balise DNT (Distinguished Name Tag), un nombre entier de 32 bits, pour identifier de façon unique chaque ligne du tableau des données. La DNT, utilisée pour se référer aux objets en interne, est beaucoup plus petite que d'autres identificateurs tels que le nom unique (DN) ou et le GUID d'objet (une structure binaire de 16 octets). Mais contrairement au GUID d'objet, la DNT est un identificateur local, et est différente sur chaque DC.

Comment Active Directory lie les objets

Active Directory gère deux genres de relations entre les objets dans la DIT : la relation parent-enfant (également appelée relation de conteneur) et la relation de référence (également appelée relation de lien). Pour implémenter la relation parent-enfant, Active Directory enregistre une colonne supplémentaire dans le tableau des données appelé PDNT (Parent Distinguished Name Tag). Cette colonne contient toujours la DNT du parent de l'objet.

Chaque attribut Active Directory est défini par un objet attributeSchema dans le conteneur Schéma Active Directory. Certains attributs Active Directory sont définis comme des attributs de lien, tels qu'ils sont déterminés par une valeur paire différente de zéro dans l'attribut linkID de l'objet attributeSchema. Les attributs de lien établissent une relation entre les objets dans l'annuaire et peuvent posséder une seule ou plusieurs valeurs. L'attribut du membre d'un objet groupe constitue un exemple d'attribut de lien à plusieurs valeurs : il établit un lien entre l'objet de groupe et ses objets membres.

Même s'il semble que l'attribut de membre d'un groupe contient le DN des membres (comme affiché par le composant logiciel enfichable d'Active Directory Users and Computers, par exemple), ce n'est pas ainsi qu'Active Directory les enregistre. Lorsque vous ajoutez le DN d'un objet membre à un attribut de membre du groupe, Active Directory enregistre la DNT de l'objet, et non pas son DN. Puisque la DNT n'est pas modifiée, même lorsqu'un objet est renommé, vous pouvez renommer un objet utilisateur sans qu'Active Directory n'ait à trier tous les groupes dans le système pour mettre à jour chacun des attributs membres. C'est comme cela qu'Active Directory maintient l'intégrité référentielle dans la DIT. La figure 1 illustre une représentation, très simplifiée, de la façon dont le tableau des données et le tableau des liens sont liés entre eux. Ces tableaux indiquent que les trois objets utilisateur, Molly Clark, Alexander Tumanov et Makoto Yamagishi, sont tous membres du groupe Senior Engineers.

Figure 1 Comment les tableaux des données et des liens sont liés

Tableau des données
DNT	PDNT	Classe d'objet	Cn
14529	14401	organizationalUnit	Ingénieurs
14530	14529	Groupe	Ingénieurs seniors
14531	14529	Utilisateur	Molly Clark
14532	14529	Utilisateur	Alexander Tumanov
14533	14529	Utilisateur	Makoto Yamagishi
Tableau des liens
Attribut	DNT	Lien suivant
Membre	14530	14531
Membre	14530	14532
Membre	14530	14533

Ces liens sont appelés liens « suivant ». De même, Active Directory fournit également des attributs de liens précédents. Ceux-ci fournissent une référence de l'objet vers lequel pointe un autre objet, celui qui possède le lien suivant. L'attribut memberOf pour les utilisateurs et les groupes est un exemple d'attribut de lien ascendant. L'objet attributeSchema qui décrit un attribut de lien ascendant possède une valeur linkID qui est supérieure à la valeur linkID à nombre paire de l'attribut du lien suivant qui lui correspond. Par exemple, l'attribut de membre dans le schéma de Windows Server® 2003 R2 possède une valeur linkID égale à 2 ; l'attribut memberOf qui sert de lien ascendant possède une valeur linkID égale à 3. La figure 2 fournit une liste des attributs liés définis par défaut dans le schéma de Windows Server 2003 R2.

Figure 2 Schéma des attributs de lien dans Windows Server 2003 R2

Forward Link Attribute	linkID	Back Link Attribute	Linked
member	2	memberOf	3
manager	42	directReports	43
owner	44	ownerBL	45
siteObject	46	siteObjectBL	47
nonSecurityMember	50	nonSecurityMemberBL	51
queryPolicyObject	68	queryPolicyBL	69
privilegeHolder	70	isPrivilegeHolder	71
managedBy	72	managedObjects	73
hasPartialReplicaNCs	74
hasMasterNCs	76	masteredBy	77
syncMembership	78
serverReference	94	serverReferenceBL	95
bridgeheadTransportList	98	bridgeheadServerListBL	99
netbootServer	100	netbootSCPBL	101
frsComputerReference	102	frsComputerReferenceBL	103
fRSMemberReference	104	fRSMemberReferenceBL	105
fRSPrimaryMember	106
siteLinkList	142
siteList	144
msCOM-PartitionLink	1040	msCOM-PartitionSetLink	1041
msDS-NC-Replica-Locations	1044
msFRS-Hub-Member	1046
msCOM-UserPartitionSetLink	1048	msCOM-UserLink	1049
msDS-SDReferenceDomain	2000
msDS-HasInstantiatedNCs	2002
msDS-NonMembers	2014	msDS-NonMembersBL	2015
msDS-MembersForAzRole	2016	msDS-MembersForAzRoleBL	2017
msDS-OperationsForAzTask	2018	msDS-OperationsForAzTaskBL	2019
msDS-TasksForAzTask	2020	msDS-TasksForAzTaskBL	2021
msDS-OperationsForAzRole	2022	msDS-OperationsForAzRoleBL	2023
msDS-TasksForAzRole	2024	msDS-TasksForAzRoleBL	2025
msDS-HasDomainNCs	2026
msSFU30PosixMember	2030	msSFU30PosixMemberOf	2031
msDS-hasMasterNCs	2036	msDs-masteredBy	2037
msDS-ObjectReference	2038	msDS-ObjectReferenceBL	2039
msDFSR-ComputerReference	2050	msDFSR-ComputerReferenceBL	2051
msDFSR-MemberReference	2052	msDFSR-MemberReferenceBL	2053

Les attributs lien ascendants possèdent toujours plusieurs valeurs, et ils sont gérés automatiquement par Active Directory. En fait, il est impossible de modifier directement un attribut de lien ascendant. Même s'il semble possible de modifier l'attribut memberOf d'un utilisateur ou d'un groupe grâce au composant logiciel enfichable MMC Active Directory Users and Computers, ce dernier modifie en fait l'attribut de membre du groupe correspondant, et Active Directory met à jour l'attribut de memberOf de façon transparente. C'est pourquoi vous n'avez pas besoin d'autorisations sur l'objet utilisateur pour ajouter l'utilisateur à un groupe, car la seule chose que vous modifiez vraiment, c'est l'attribut de membre de l'objet de groupe. Puisque chaque DC gère ses attributs de lien ascendant de façon locale, les modifications des liens ascendants ne sont jamais répliquées. Seule la modification de l'attribut du lien suivant, comme l'attribut de membre d'un groupe, est répliquée.

Dans un DC normal, le tableau des données contient des entrées pour les objets domaine, ainsi que des objets provenant des conteneurs Configuration et Schéma. Mais certains types de groupe peuvent contenir des références aux objets qui résident dans un autre domaine. Comment Active Directory enregistre-t-il une DNT pour un objet qui n'est pas dans son tableau de données ? La réponse réside dans le propriétaire du rôle des opérations à maître unique flottant (FSMO) du maître d'infrastructure et d'un objet appelé objet fantôme.

Les objets fantômes

Lorsque vous ajoutez un membre d'un domaine à un groupe appartenant à un autre domaine, Active Directory crée automatiquement un objet spécial dans le tableau des données appelé un fantôme, qui contient l'objectGUID, l'objectSid et le DN du nouveau membre. Cela fournit une DNT que peut être enregistrée dans l'attribut de membre du groupe. Si un contrôleur de domaine est un catalogue global, il n'aura pas besoin de créer un fantôme, parce qu'il a déjà une entrée dans son tableau des données pour chaque objet de la forêt.

Le DC qui contient le rôle FSMO de l'infrastructure vérifie périodiquement les entrées dans son tableau des données et les compare à celles du catalogue global. Lorsqu'il découvre qu'un objet a été déplacé, renommé ou supprimé, il met à jour les fantômes dans le tableau des données et réplique la modification aux autres DC du domaine. Et grâce à un compte de référence, le maître d'infrastructure peut également supprimer des fantômes auxquels aucun attribut de lien suivant du domaine ne fait plus référence.

Les fantômes autorisent les DC à gérer des références aux objets d'autres domaines de la forêt, mais les attributs lien suivant peuvent aussi faire référence aux objets qui sont hors de la forêt : par exemple, dans un domaine de confiance. Dans ce cas, Active Directory crée un objet appelé Sécurité extérieure principale (Foreign Security Principal, FSP) dans le conteneur CN=ForeignSecurityPrincipals du NC du domaine. La FSP contient l'Identificateur de sécurité de l'objet étranger (le SID) et les autres attributs qui identifient l'objet dans le domaine étranger, mais il n'y a pas de processus pour s'assurer que le FSP est maintenu à jour. Dans l'objectif de récupération de données, nous traitons les FSP comme n'importe quel autre objet d'Active Directory.

Suppression d'objets

Ici, je m'intéresse en priorité à la restauration d'utilisateurs et de leurs appartenances aux groupes. Cependant, les mêmes principes s'appliquent à la récupération d'autres attributs liés.

Lorsqu’Active Directory supprime un objet, il ne supprime pas physiquement l'objet de la DIT. Il se contente en fait de paramétrer son attribut Deleted sur vrai, ce qui le rend invisible aux opérations d'annuaire normales. Active Directory supprime tous les attributs qui ne sont pas destinés à être enregistrés, tels qu'ils sont définis par le schéma, et modifie le nom distingué relatif (Relative Distinguished Name, RDN) de l'objet en <ancien RDN>\0aDEL:<objectGUID>. Il transfère ensuite l'objet vers le conteneur CN=Deleted Objects pour le NC. (Il existe certaines classes d'objets dans le NC de Configuration qu'Active Directory ne transfère pas au conteneur d'Objets Supprimés). Active Directory supprime tous les liens « suivant » vers d'autres objets que détient l'objet supprimé, ce qui réduit leur compte de référence dans le tableau de lien. S'il existe d'autres objets qui contiennent des liens suivant vers l'objet désormais supprimé, Active Directory supprime également ces liens.

L'objet résultant est appelé une pierre tombale (« tombstone »). Active Directory copie cette pierre tombale sur les autres DC, où les mêmes modifications sont effectuées. Notez qu'Active Directory ne réplique pas les modifications effectuées vers les liens suivant qui font référence à l'objet supprimé. Chaque DC effectue la modification équivalente localement : il n'y a donc pas de besoin de la répliquer. Cela a des conséquences sur la récupération d'appartenances aux groupes, comme nous verrons plus tard dans cet article.

Active Directory maintient les objets supprimés dans la DIT, ainsi qu'il est défini par l'attribut tombstoneLifetime de l'objet CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<domaine racine>. Le processus de nettoyage de la mémoire sur chaque DC supprime les pierres tombales qui sont plus vieilles que la durée de vie configurée de la pierre tombale. Par défaut, la vie de la pierre tombale est de 60 jours pour Windows® 2000, Windows Server 2003 et Windows Server 2003 R2. Elle est de 180 jours sous Windows Server 2003 SP1.

La durée de vie de la pierre tombale a beaucoup d'importance pour le processus de restauration. Il est impossible de restaurer à partir d'une sauvegarde qui est plus vieille que la durée de vie de la pierre tombale. Puisque les objets qui ont été supprimés et nettoyés de la mémoire du domaine n'ont plus de pierre tombale, l'opération de suppression ne répliquera jamais de nouveau vers le DC restauré. Les objets supprimés resteront ensuite sur le DC restauré comme des objets sans but, et le DC restauré ne convergera jamais convenablement avec les autres DC à l'intérieur du domaine.

Réplication d'objets

Quand un contrôleur de domaine exécute une opération de mise à jour de n'importe quel genre, comme par exemple l'ajout d'un objet ou la modification d'un attribut, il attribue un nombre de 64 bits à l'opération de mise à jour appelée Numéro de séquence de mise à jour (USN). Active Directory étiquette les objets et les attributs qui sont mis à jour avec leur USN, pour aider à déterminer s'ils doivent être répliqués.

Active Directory réplique les objets attribut par attribut. C'est-à-dire que si vous modifiez l'un des attributs d'un objet, Active Directory copiera uniquement cet attribut, et non pas l'objet entier. Pour ce faire, Active Directory conserve une trace des modifications qu'il effectue à chaque attribut grâce à des métadonnées de réplication. Les métadonnées de réplication d'un attribut incluent :

L'USN local, qui identifie l'opération de modification sur le DC local.
L'invocationID du DC qui a provoqué la modification (en particulier, l'attribut invocationID de l'objet nTDSSettings du DC correspond), qui identifie une génération particulière de la DIT sur un contrôleur de domaine.
L'USN de l'opération originale, telle qu'il existe sur le DC qui a provoqué la modification.
Un horodatage qui contient l'heure système du DC à laquelle le changement a été effectué.
Un numéro de version séquentiel de 32 bits qui est incrémenté chaque fois que la valeur est modifiée.

Lorsqu'un DC de destination demande des modifications par l'intermédiaire de son partenaire DC de source, il envoie l'USN de la dernière modification de réplication réussie au DC source, avec un vecteur de mise à jour qui inclut le plus grand USN d'origine que le DC de destination ait vu de chaque DC qui possède une réplique du NC en cours de réplication. Le DC source utilise ces informations pour envoyer uniquement les mises à jour que le DC de destination n'a pas encore vues.

Pendant que le DC de destination traite les mises à jour d'attribut entrantes, il vérifie le numéro de version de chaque attribut. Si le numéro de version d'un attribut entrant est plus grand que la version que le DC possède déjà pour cet attribut, le DC enregistre la valeur entrante. Si le numéro entrant de version est égal à la version que le DC possède déjà, le DC compare les horodateurs et utilise l'attribut possédant l'horodateur le plus récent. Si les horodateurs sont identiques, le DC de destination choisit la valeur avec le plus grand invocationID. Ce système garantit que chaque DC choisira finalement la même valeur pour chaque attribut répliqué.

Réplication de valeurs liées

Sous Windows 2000, Active Directory répliquait les attributs à valeurs multiples de la même manière que les attributs à valeur unique. Cela provoquait des problèmes pour les grands objets de groupe dynamique, dont l'attribut de membre à valeur multiple pouvait changer fréquemment sur différents DC. Si un administrateur ajoutait un utilisateur à un groupe sur un DC, et qu'un autre administrateur ajoutait un utilisateur différent au groupe sur un autre DC dans la fenêtre de latence de réplication, Active Directory choisissait le dernier ajout et perdait le premier. Microsoft a traité ce problème dans Windows Server 2003 avec un processus appelé réplication de valeurs liées (LVR).

Sous Windows Server 2003, au niveau fonctionnel de la forêt ou au niveau fonctionnel de la forêt provisoire, Active Directory copie séparément les valeurs individuelles des attributs de lien suivant, et chaque valeur possède ses propres métadonnées de réplication. Cela résout efficacement le problème rencontré sous Windows 2000, où des mises à jour presque simultanées d'appartenance au groupe sur différents DC pouvaient provoquer des pertes de données.

Il existe cependant un point dont il faut être conscient. Le fait d'augmenter le niveau fonctionnel de la forêt ne corrige pas automatiquement les attributs de lien à valeurs multiples avec les nouvelles métadonnées de réplication. Seules les valeurs qui sont ajoutées après l'augmentation du niveau fonctionnel de la forêt recevront les nouvelles métadonnées. Cela aura un effet significatif sur la récupération d'appartenances aux groupes, comme vous verrez dans un moment.

Sauvegarde

Windows fournit l'utilitaire très basique NT-BACK-UP qui peut être utilisé pour effectuer une sauvegarde de l'état du système d'un DC. L'état du système d'un contrôleur de domaine inclut son registre, SYSVOL, les fichiers de la DIT d'Active Directory ainsi que les fichiers système critiques. La plupart des utilitaires de sauvegarde tiers ont également la capacité de sauvegarder et de restaurer l'état du système d'un DC.

Pour exécuter une sauvegarde d'état du système sur un fichier de disque, utilisez la commande suivante :

NTBACKUP backup systemstate /F “<filename>”

Ici, <filename> est le nom du fichier de sauvegarde devant être créé, et devrait utiliser l'extension .bkf.

Exécution d'une restauration ne faisant pas autorité

La restauration d'objets Active Directory supprimés à partir d'une sauvegarde est un processus de deux étapes. Premièrement, vous redémarrez le DC en mode restauration du service d'annuaire (DSRM), puis vous restaurez l'intégralité de la DIT d'Active Directory à partir de la sauvegarde d'état du système, en utilisant l'utilitaire NTBACKUP de Windows ou un produit tiers équivalent. Ce processus remplacera toute la DIT.

Il y existe deux façons de démarrer un DC en DSRM. Si vous avez accès à la console de système du DC, arrêtez et redémarrez le DC puis appuyez sur F8 à l'invite pour appeler le menu de démarrage de Windows. Sélectionnez Restauration du service d'annuaire dans le menu et entrez le mot de passe du DSRM.

Si vous gérez le serveur à distance, vous ne pourrez pas accéder au menu de démarrage de Windows. À la place, vous pouvez modifier les options de démarrage du système en sélectionnant Propriétés à partir du Poste de Travail, puis en cliquant sur l'onglet Avancé, avant d'appuyer sur le bouton Paramètres situé sous Démarrage et Récupération. Cliquez sur Modifier dans la section Démarrage du système pour modifier le fichier boot.ini, et ajoutez le commutateur /SAFEBOOT:DSREPAIR à la fin de la ligne, comme illustré à la figure 3. (Pour plus d'informations sur les commutateurs de boot.ini, voir microsoft.com/technet/sysinternals/information/bootini.mspx.)

Figure 3 Configuration des options de démarrage pour DSRM

Figure 3** Configuration des options de démarrage pour DSRM **(Cliquer sur l'image pour l'agrandir)

Lorsque vous redémarrez le serveur, il s'allumera en DSRM. N'oubliez pas de supprimer le commutateur /SAFEBOOT de boot.ini lorsque vous voulez redémarrer le DC en mode normal.

Une fois connecté à l'aide du mot de passe du DSRM, restaurez la sauvegarde d'état du système en utilisant une nouvelle fois la commande NTBACKUP, mais sans spécifier de paramètre. (Vous ne pouvez pas exécuter une restauration en utilisant NTBACKUP à partir de la ligne de commande). Lorsque l'assistant s'ouvre, sélectionnez Restaurer les fichiers et paramètres, puis cliquez sur Suivant. Sélectionnez ensuite le fichier de sauvegarde et cochez la boîte de dialogue État du système comme indiqué à la figure 4.

Figure 4 Utilisation de l'Assistant de sauvegarde ou de restauration pour restaurer l'état du système

Figure 4** Utilisation de l'Assistant de sauvegarde ou de restauration pour restaurer l'état du système **(Cliquer sur l'image pour l'agrandir)

Si vous redémarriez le DC en mode normal à ce stade, le processus de réplication d'Active Directory synchroniserait le contrôleur de domaine avec les autres DC du domaine, et toutes les données restaurées seraient remplacées par les données actuelles. Ce n'est pas votre objectif, bien sûr. Vous avez besoin, par contre, d'un moyen de forcer les objets en cours de restauration à se répliquer indépendamment des autres contrôleurs de domaine du domaine.

Exécution d'une restauration faisant autorité

NTDSUTIL augmente également le numéro de version de chaque attribut de 100 000 pour chaque jour entre la date de la sauvegarde et la date de la restauration. À moins qu'il existe des attributs qui sont mis à jour plus de 100 000 fois un jour (scénario assez peu probable), le numéro de version des attributs restaurés sera beaucoup plus grand que celui de la version détenue par d'autres DC, et l'objet restauré d'une manière faisant autorité se répliquera vers les autres DC. Les autres objets qui ont été restaurés d'une façon ne faisant pas autorité à partir de la sauvegarde seront remplacés pour finir par les données existantes sur les autres contrôleurs de domaine.

Après avoir terminé la restauration ne faisant pas autorité, mais avant de redémarrer en mode normal, vous devez utiliser le programme NTDSUTIL pour exécuter une restauration faisant autorité des objets que vous voulez récupérer. Malgré son nom, la restauration faisant autorité d'un objet ne « restaure » pas ce dernier ; elle s'assure simplement qu'Active Directory répliquera l'objet sur les autres DC. Pour ce faire, NTDSUTIL attribue l'USN suivant disponible à l'USN local des attributs de l'objet. L'objet sera ainsi envoyé aux partenaires de réplication la prochaine fois qu'ils se synchroniseront. Pour restaurer un objet, assurez-vous que le DC est lancé en DSRM, et procédez comme suit :

Ouvrez une invite de commande et tapez :

ntdsutil

Dans l'invite ntdsutil, tapez :

authoritative restore

À l'invite de restauration faisant autorité, saisissez :

restore object “<DN of object to be restored>”

Par exemple, si vous voulez restaurer le compte de Molly Clark à partir de l'OU Eng du domaine DRNET, tapez :

restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”

Si vous voulez effectuer une restauration faisant autorité d'un sous-arbre d'annuaire entier, par exemple une UO, saisissez plutôt ceci :

restore subtree “OU=Eng,DC=DRNET,DC=com”

(NTDSUTIL fournit également une commande de base de données de restauration qui effectue une restauration faisant autorité du domaine entier, ainsi que des NC de configuration et de schéma. La restauration du domaine entier est une opération périlleuse, et c'est une option que je ne recommande pas. Si vous avez besoin de restaurer un domaine entier, vous devez restaurer un contrôleur de domaine et promouvoir de nouveau les autres DC du domaine comme décrit dans « Planification d'une récupération de forêt d'Active Directory »,
À l'invite, confirmez que la restauration faisant autorité doit augmenter les numéros de version des objets et de leurs attributs respectifs.
Quittez ntdsutil (vous devrez taper « quit » deux fois).
Redémarrer le DC en mode normal d'Active Directory normal.

La prochaine fois le DC se réplique avec ses partenaires, l'utilisateur que vous avez restauré se répliquera vers l'extérieur. Mais la restauration de l'objet utilisateur ne constitue que la moitié du problème. Lorsque vous introduisez des liens d'objet comme ceux-là entre un groupe et ses membres, la situation devient plus compliquée. Il y a quelques problèmes fondamentaux auxquels vous risquez d'être confronté pendant et après la restauration, et que je vais essayer de décrire.

Tout d'abord, revoyons ce qui se produit lorsque vous supprimez un objet comportant des liens ascendants. Disons que vous supprimez un objet utilisateur qui est membre d'un ou de plusieurs groupes. Chaque contrôleur de domaine disposant d'une copie de l'objet utilisateur le convertit en pierre tombale et supprime toutes les références du tableau des liens, supprimant ainsi l'objet utilisateur des appartenances aux groupes dans le domaine de l'utilisateur. (Rappelez-vous que la suppression d'un utilisateur des appartenances aux groupes n'est pas une modification répliquée, puisque chaque DC met à jour l'appartenance au groupe de façon locale. Le numéro de version et l'USN local de l'attribut du membre du groupe restent inchangés). Un peu plus tard, les objets fantômes seront supprimés des tableaux des liens dans les autres domaines, mais toujours sans mettre à jour les métadonnées de réplication de l'attribut de membre du groupe.

Lorsque vous effectuez une restauration ne faisant pas autorité sur la DIT sur un contrôleur de domaine dans le domaine de l'utilisateur, vous récupérez l'objet utilisateur avec toutes les appartenances aux groupes dans le domaine, de sorte que le DC restauré soit cohérent. Et après avoir utilisé l'utilitaire NTDSUTIL pour exécuter une restauration faisant autorité de l'utilisateur, l'objet utilisateur se réplique vers tous les autres DC dans le domaine.

Mais puisque les métadonnées de réplication des groupes actuels dans le domaine sont inchangées, les attributs de membre des groupes sur le DC restauré sont en contradiction avec ceux qui sont présents sur les autres DC. Et il n'y a rien à faire pour les faire converger vers un état commun. Ainsi, les appartenances de l'utilisateur ne seront pas restaurées sur les autres DC dans le domaine.

Problème : les appartenances aux groupes dans le domaine ne sont pas restaurées

La restauration faisant autorité de l'objet utilisateur ne récupère pas les appartenances aux groupes de l'utilisateur. Pourquoi ? Parce que la relation d'appartenance est enregistrée et répliquée en utilisant l'attribut de membre des objets de groupe (les liens suivant), et non l'attribut memberOf de l'utilisateur (le lien ascendant). Le problème consiste à retrouver les anciennes appartenances aux groupes de l'utilisateur et, une fois que c'est fait, de les récupérer convenablement.

Microsoft a apporté beaucoup d'améliorations au processus de récupération des appartenances aux groupes de l'utilisateur, donc la technique que vous utilisez dépend de la version d'Active Directory que vous vous possédez. La section suivante s'applique principalement à Active Directory de Windows 2000.

Déterminer les anciennes appartenances aux groupes de l'utilisateur est assez simple : Inspectez simplement l'attribut de lien ascendant sur le DC restauré. Dans notre cas, il s'agit de l'attribut memberOf de l'objet utilisateur. L'attribut memberOf contiendra toutes les appartenances aux groupes locaux et globaux dans le domaine de l'utilisateur. Vous pouvez utiliser le composant logiciel enfichable MMC Active Directory Users and Computers (ADUC), ou l'utilitaire LDIFDE, qui est livré avec Windows Server, pour lister les appartenances aux groupes de l'utilisateur restaurés.

La ligne de commande LDIFDE suivante listera les groupes dans le domaine DRNET dont Molly Clark est membre et enregistrera les résultats dans le fichier output.ldf :

C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf

Noter que vous devez démarrer le DC en mode normal pour utiliser un outil LDAP et vous devez à nouveau désactiver la réplication entrante ; autrement les données que vous avez restaurées seraient remplacées. Pour désactiver la réplication entrante, le plus simple est d'utiliser la commande REPADMIN :

REPADMIN /options <dcname>+DISABLE_INBOUND_REPL

Ici, <dcname> est le nom du DC vers lequel vous restaurez. N'oubliez pas de réactiver la réplication en utilisant –DISABLE_INBOUND_REPL lorsque vous avez terminé.

Si vous récupérez seulement quelques utilisateurs, il est assez facile de réintégrer manuellement quelques utilisateurs aux groupes à l'aide de l'ADUC. Si vous récupérez plus d'utilisateurs que cela, il existe des outils qui peuvent automatiser une partie du processus. L'utilitaire GROUPADD de Microsoft (disponible auprès des services de support technique Microsoft) peut accepter le fichier LDIF que vous avez créé pour lister les anciennes appartenances aux groupes de l'utilisateur, et il génère à son tour un fichier LDIF qui recrée ces appartenances. Par exemple, vous utiliseriez cette commande GROUPADD pour traiter le fichier LDIF nous avons créé dans l'exemple précédent pour Molly Clark :

C:\> groupadd /after_restore output.ldf

Cette commande créera un nouveau fichier LDIF pour chaque domaine dans lequel Molly Clark appartenait à un groupe, avec le nom groupadd_<domain>.ldf (où <domain> est le nom de domaine pleinement qualifié du domaine dont les groupes seront mis à jour). Pour importer le fichier LDIF créé ci-dessus, il suffit de saisir la commande suivante :

C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf

Avec Windows Server 2003, Microsoft a amélioré NTDSUTIL pour profiter des métadonnées supplémentaires qui sont présentes dans l'attribut de membre pour prendre en charge la réplication de valeurs liées (LVR). Si l'objet utilisateur restauré avait été membre de n'importe quel groupe du domaine et si l'appartenance au groupe de l'utilisateur a été enregistrée avec les métadonnées de LVR, NTDSUTIL augmente alors le numéro de version de la valeur qui correspond à l'attribut de membre, ce qui provoque ensuite la réplication vers l'extérieur de l'appartenance aux groupes.

La version Windows Server 2003 SP1 de NTDSUTIL incorpore les fonctions GROUPADD et créera automatiquement les fichiers LDIF quand il exécutera la restauration faisant autorité de l'objet utilisateur. La figure 5 illustre la nouvelle version de NTDSUTIL, et la figure 6 indique le contenu du fichier LDIF créé automatiquement.

Figure 6 Contenu du fichier LDIF créé par NTDSUTIL

dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-

Figure 5 Nouveau NTDSUTIL avec capacités GROUPADD intégrées

Figure 5** Nouveau NTDSUTIL avec capacités GROUPADD intégrées **(Cliquer sur l'image pour l'agrandir)

Si vous restaurez une UO entière qui contient plusieurs utilisateurs et groupes, il est relativement fatigant de les réintégrer manuellement dans leurs groupes. Une autre façon de récupérer les appartenances aux groupes restaurées est d'effectuer une restauration faisant autorité sur les groupes eux-mêmes.

L'exécution d'une restauration faisant autorité de groupes pose cependant deux problèmes. Le premier problème est assez évident : si vous restaurez un groupe, l'appartenance dans ce groupe reviendra à son état au moment de la sauvegarde. Cela signifie que les modifications effectuées au groupe depuis la dernière sauvegarde devront être appliquées une nouvelle fois au groupe. Le deuxième problème est un peu plus subtil et concerne la façon dont fonctionne la réplication d'Active Directory. Après l'exécution d'une restauration faisant autorité d'utilisateurs et de groupes, il n'y existe pas de garantie sur l'ordre dans lequel ils se répliqueront vers l'extérieur. Si un objet de groupe se réplique vers un DC avant l'objet utilisateur restauré, le contrôleur de domaine en cours de réplication supprimera automatiquement la référence de l'utilisateur du groupe, car l'objet utilisateur n'existe pas encore sur le DC. Lorsque l'objet utilisateur est répliqué plus tard, il ne sera pas ajouté au groupe.

La solution la plus facile est d'exécuter la restauration faisant autorité des groupes une deuxième fois. Après la restauration faisant autorité, redémarrez en mode normal et assurez-vous que cette réplication a lieu convenablement. Ensuite, redémarrez à nouveau en DSRM et exécutez NTDSUTIL pour effectuer une restauration faisant autorité des groupes dont l'utilisateur était membre. Cela garantit que lorsque vous démarrez une nouvelle fois en mode normal, l'objet utilisateur se sera répliqué vers l'extérieur avant que les objets de groupe s'y référant ne se répliquent.

Problème : les appartenances aux groupes dans les autres domaines ne sont pas restaurées

Le problème « de quel groupe était membre cet utilisateur » est en fait plus complexe que ce que j'ai décrit. L'utilisateur que vous restaurez pourrait avoir été membre de groupes locaux et universels de domaine dans les autres domaines, et ces appartenances aux groupes ne seront pas restaurées lorsque vous effectuez une restauration ne faisant pas autorité. Donc comment savoir à quels groupes l'utilisateur appartenait dans les autres domaines ? La réponse se situe dans le catalogue global. Avec ses propres données de domaine, le catalogue global contient une copie en lecture seule des données des autres domaines dans la forêt.

Pour profiter des données du catalogue s'étalant sur toute la forêt, vous devez exécuter la restauration ne faisant pas autorité sur un catalogue global, ce qui signifie que vous devez au préalable avoir sauvegardé un catalogue global. Lorsque vous exécutez LDIFDE pour identifier les appartenances aux groupes de l'utilisateur, vous pouvez découvrir les appartenances aux groupes universels de l'utilisateur sur les autres domaines.

Lorsque vous listez les appartenances aux groupes de l'utilisateur que vous récupérez, connectez-vous au port 3268 du catalogue global, au lieu du port 389 par défaut, et spécifiez le domaine racine de la forêt comme base de la recherche. LDIFDE affichera les appartenances aux groupes récupérés de l'utilisateur, y compris l'appartenance aux groupes universels dans tous les domaines de la forêt. Voici comment procéder :

C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf

Si vous exécutez GROUPADD ou le nouveau NTDSUTIL sur un catalogue global, vous produirez un fichier LDIF pour le domaine de l'utilisateur, ainsi qu'un fichier LDIF pour chaque domaine dans lequel l'utilisateur restauré était membre d'un groupe universel. Lorsque vous importez ces fichiers LDIF, vous restaurez toutes les appartenances aux groupes de l'utilisateur. Enfin, presque toute, ce qui nous amène au problème suivant.

Problème : récupérer les appartenances aux groupes locaux de domaine dans les autres domaines

Il existe trois genres de groupes dans un environnement Active Directory de Windows. Les groupes globaux peuvent seulement contenir des membres dans le même domaine, mais ils peuvent être utilisés comme un membre à l'intérieur de groupes locaux de domaine dans son propre domaine et dans d'autres domaines dans la forêt. L'attribut de membre des groupes globaux n'apparaît pas dans le catalogue global, mais ce n'est pas un problème parce que les groupes globaux contiennent seulement des membres de leur propre domaine. Les groupes universels peuvent contenir des membres de n'importe quel domaine et peuvent être utilisés comme des membres dans les autres groupes universels de la forêt et dans des groupes locaux de domaine dans leur propre domaine comme dans d'autres domaines de la forêt. L'attribut de membre de groupes universels est répliqué vers les catalogues globaux. Les groupes locaux de domaine peuvent contenir des membres de n'importe quel domaine de la forêt, mais ils ne peuvent pas être utilisés comme membres dans les groupes d'autres domaines. Et plus important, l'attribut de membre des groupes locaux de domaine, comme celui des groupes globaux, n'apparaît pas dans le catalogue global. Par conséquent, il n'existe pas de moyen facile pour récupérer l'appartenance de l'utilisateur dans les groupes locaux de domaine dans les autres domaines.

Avant Windows Server 2003 SP1, le seul moyen de récupérer les appartenances aux groupes locaux de domaine dans les domaines étrangers était de restaurer un DC dans chaque domaine, puis de rechercher manuellement les données de domaine pour tous les groupes locaux de domaine qui contenaient l'utilisateur restauré, avant de réintégrer l'utilisateur aux groupes que vous aviez identifiés. Dans un grand environnement contenant beaucoup de domaines, cette approche était exclue, étant donné le temps qu'elle demandait.

La version Windows Server 2003 SP1 de NTDSUTIL peut aider. Lorsque vous exécutez NTDSUTIL sur un contrôleur de domaine, l'utilitaire crée un fichier texte qui contient le DN et le GUID des objets utilisateur restaurés. Ensuite, pour chaque domaine étranger, vous pouvez effectuer une restauration faisant autorité d'un DC unique, copier le fichier texte sur le DC et exécuter NTDSUTIL pour produire un nouveau fichier LDIF spécifique au domaine qui réintègre l'utilisateur récupéré aux groupes locaux de domaine dont il était membre.

Pour ce faire, suivez les étapes suivantes sur un DC dans chaque domaine étranger :

Démarrez le DC dans le domaine étranger en DSRM.
Utilisez NTBACKUP pour restaurer une copie de la DIT qui contient les appartenances aux groupes de l'utilisateur restauré.
Copiez le fichier .txt créé par NTDSUTIL au DC actuel.
Ouvrez une fenêtre de commande et tapez ntdsutil.
Tapez la restauration faisant autorité.
Tapez créer le(s) fichier(s) LDIF à partir de <file name> (où <file name> est le nom du fichier texte).
Tapez Le type « quit » deux fois pour quitter ntdsutil.
Redémarrez le DC en mode normal d'Active Directory.
Tapez ldifde –i –f <ldif filename> (où <filename> est le nom du fichier LDIF que vous venez de créer).

Vous avez maintenant restauré l'ensemble des appartenances aux groupes de l'utilisateur supprimé.

Étape par étape

La récupération des utilisateurs d'Active Directory et de leurs appartenances aux groupes n'est pas aisée, surtout dans un environnement à domaines multiples. Les étapes spécifiques nécessaires à la récupération appropriée des appartenances aux groupes dépendent de votre version de Windows.

S'il s'agit de Windows 2003 SP1, procédez comme suit :

Démarrez un GC en DSRM et exécutez une restauration d'état du système en utilisant une sauvegarde qui contient l'utilisateur supprimé.
Utilisez NTDSUTIL pour effectuer une restauration faisant autorité de l'utilisateur supprimé. NTDSUTIL créera un fichier texte contenant les DN et GUID de l'objet restauré, ainsi qu'un ou plusieurs fichier(s) LDIF pour restaurer les appartenances aux groupes de l'utilisateur.
Utilisez LDIFDE –i –f <LDIF filename> (où <LDIF filename> est le nom des fichiers LDIF créés à l'étape 2) pour importer les appartenances aux groupes dans le domaine actuel et dans les autres domaines.
Redémarrez le catalogue global en mode normal.
Sur un DC dans chaque domaine étranger, redémarrez en DSRM et exécutez une restauration d'état du système en utilisant une sauvegarde qui contient les appartenances aux groupes de l'utilisateur restauré.
Exécutez NTDSUTIL en utilisant la commande de création des fichiers ldif.
Redémarrez le DC en mode normal.
Utilisez LDIFDE –i –f <filename> (où <filename> est le nom du fichier LDIF que vous avez créé à l'étape 6) pour restaurer les appartenances aux groupes dans le domaine étranger.
À ce stade, vous pouvez forcer la réplication à l'aide de REPADMIN/syncall.

Si vous exécutez une version de Windows Server 2003 sans SP1 ou si vous exécutez Windows 2000, vous devez prendre quelques mesures supplémentaires. Puisque l'ancienne version de NTDSUTIL ne crée pas de fichiers LDIF, utilisez l'utilitaire GROUPADD pour les créer. Le processus est le suivant :

Démarrez un catalogue global dans DSRM et exécutez une restauration d'état du système en utilisant une sauvegarde qui contient l'utilisateur supprimé.
Désactivez le NIC ou débranchez le câble pour empêcher la réplication entrante.
Redémarrez le catalogue global en mode normal.
Utilisez LDIFDE –r « (distinguishedName=<dn>) » -t 3268 -l memberOf –p Base -f membership.ldf pour décharger l'appartenance de l'utilisateur avec le nom distingué <dn>.
Utilisez GROUPADD/after_restore membership.ldf pour créer les fichiers LDIF.
Utilisez LDIFDE –i –f <filename> (où <filename> est le nom du fichier LDIF créé par GROUPADD à l'Etape 5) pour importer les appartenances aux groupes dans le domaine actuel et dans les autres domaines.
Réactivez la réplication entrante en utilisant REPADMIN/options <dcname> -DISABLE_INBOUND_REPL.
Sur un DC dans chaque domaine étranger, redémarrez en DSRM et exécutez une restauration d'état du système en utilisant une sauvegarde qui contient les appartenances aux groupes de l'utilisateur restauré.
Redémarrez le DC en mode normal.
Utilisez LDIFDE –i –f <filename> (où <filename> est le nom du fichier LDIF créé par GROUPADD à l'étape 5) pour restaurer les appartenances aux groupes dans le domaine étranger.
À ce stade, vous pouvez forcer la réplication à l'aide de REPADMIN/syncall.

Tout ce qu'il reste à faire maintenant pour les environnements précédant Windows Server 2003 SP1, c'est de récupérer les appartenances aux groupes locaux du domaine étranger de l'utilisateur restauré. Vos seuls choix sont de restaurer manuellement les appartenances aux groupes locaux du domaine ou de restaurer un DC à partir d'une sauvegarde, puis d'effectuer une restauration faisant autorité sur les groupes locaux de domaine.

Résumé

S'il est très facile de supprimer accidentellement des utilisateurs ou même des UO sur Active Directory, récupérer convenablement les utilisateurs supprimés et leurs appartenances aux groupes peut s'avérer une tâche complexe, laborieuse et sujette aux erreurs. Pour être sûr de pouvoir récupérer de ce genre d'incident aussi rapidement que possible, vous devez comprendre les mécanismes des liens, de la réplication, de la suppression et de la récupération faisant autorité des objets.

Pensez-vous pouvoir réussir toutes ces étapes la première fois vous les essayez dans votre environnement de production ? Pour être prêt la prochaine fois que vous devez récupérer l'objet utilisateur de votre PDG, préparez un plan de récupération des objets supprimés. Et testez votre plan au moins une fois ou deux avant de l'essayer sur des données réelles. Votre responsable l'appréciera (tout comme votre PDG).

Ressources supplémentaires

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