Rédiger et répéter un plan de restauration de forêt AD

La restauration de forêt est la procédure que personne ne veut exécuter, et c'est pourquoi la plupart des organisations ne l'ont jamais fait. C'est le dernier recours lorsqu'Active Directory lui-même n'est plus digne de confiance : DC chiffrés par un rançongiciel, modification destructrice à l'échelle de la forêt, ou compromission si profonde qu'aucun DC ne peut être déclaré sain. Le guide de restauration de forêt Active Directory de Microsoft (Active Directory Forest Recovery Guide) décrit la procédure en détail. Le lire pendant un incident, avec l'activité à l'arrêt et la direction en cellule de crise, c'est le pire moment pour découvrir que vos mots de passe DSRM se trouvent dans un coffre qui s'authentifie auprès d'AD.

Ce guide transforme la procédure de Microsoft en un runbook qui vous appartient, adapté à votre forêt, et en un programme de répétition qui prouve qu'il fonctionne. Il suppose l'existence des sauvegardes décrites dans la protection des sauvegardes AD contre les rançongiciels, et va plus loin que la vue d'ensemble de l'article pilier sur l'évaluation, la sauvegarde et la restauration.

Mesurer : ce que le plan doit connaître

Un plan de restauration est essentiellement un inventaire. Rassemblez et conservez hors ligne, sur papier et sur un support chiffré en dehors d'AD :

• La topologie de la forêt : chaque domaine, ses DC, leurs sites, adresses IP et versions de système d'exploitation, ainsi que les DC qui détiennent les rôles FSMO et le catalogue global.
• La cartographie des sauvegardes : pour chaque domaine, quels DC sont sauvegardés, dans quel format, où se trouve la copie immuable et comment y accéder sans AD.
• Les identifiants : mots de passe DSRM des DC sauvegardés, comptes de secours pour les hyperviseurs, le stockage et les consoles de sauvegarde qui ne dépendent pas d'AD, et la procédure d'accès au coffre hors ligne.
• Les dépendances : DNS, DHCP, AD CS, Entra Connect, AD FS, PAM, et l'ordre dans lequel les applications doivent redémarrer.
• Les personnes : des responsables nommés pour chaque phase, avec des suppléants, et un moyen de communication hors bande qui ne repose pas sur Exchange ou Teams authentifiés via l'AD compromis.

# Instantané de la topologie à imprimer et à conserver avec le plan
Get-ADForest | Select-Object Name, ForestMode, SchemaMaster, DomainNamingMaster, Domains, GlobalCatalogs
Get-ADDomain | Select-Object DNSRoot, DomainMode, PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address, OperatingSystem, IsGlobalCatalog, OperationMasterRoles
(Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties tombstoneLifetime).tombstoneLifetime

Un tombstoneLifetime vide correspond à l'ancienne valeur par défaut de 60 jours des forêts créées avant Windows Server 2003 SP1. Les forêts créées ultérieurement ont une valeur par défaut de 180 jours.

Décider : s'agit-il d'une restauration de forêt ?

Inscrivez les critères de décision dans le plan pour que le responsable de l'incident n'ait pas à improviser :

Décidez également quelle sauvegarde est saine. Si l'attaquant est présent depuis longtemps, la sauvegarde la plus récente peut contenir sa persistance : administrateurs illégitimes, AdminSDHolder modifié, SID History, GPO malveillantes, clés permettant de forger des golden tickets. Le plan doit désigner qui prend cette décision et sur quels éléments, généralement les chronologies forensiques issues de votre chaîne de transfert d'événements.

La procédure de restauration

L'ordre ci-dessous suit le guide de Microsoft. Alignez votre runbook sur la version actuelle de ce guide, et non sur ce résumé.

1. Construire la salle blanche

Construisez un réseau isolé sans route vers la production, avec un hyperviseur ou du matériel sain, des supports d'installation sains vérifiés par hash et des postes d'administration construits à partir d'images de confiance. Tout ce qui suit se passe ici. La forêt restaurée ne rejoint la production que lorsque vous décidez qu'elle est saine.

2. Restaurer le premier DC accessible en écriture du domaine racine de la forêt

Restaurez un DC accessible en écriture, de préférence un ancien catalogue global et serveur DNS, à partir de la sauvegarde retenue. Si le serveur ou la VM du DC d'origine peut être réutilisé, démarrez-le en DSRM et restaurez l'état du système comme ci-dessous. S'il a disparu, effectuez d'abord une restauration complète du système (bare-metal) à partir d'une sauvegarde complète du serveur sur du matériel isolé, puis poursuivez depuis le DSRM.

# Sur le DC à restaurer, redémarrer en DSRM
bcdedit /set safeboot dsrepair
shutdown /r /t 0

# Après ouverture de session avec le compte DSRM
wbadmin get versions -backupTarget:E:
wbadmin start systemstaterecovery -version:09/20/2026-02:00 -backupTarget:E: -authsysvol -quiet

Il s'agit d'une restauration ne faisant pas autorité d'AD DS avec une restauration faisant autorité de SYSVOL. Le commutateur -authsysvol marque le SYSVOL de ce DC comme copie principale. Si la méthode de restauration ne prend pas en charge ce commutateur, positionnez msDFSR-Options à 1 sur CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<DC>,OU=Domain Controllers,<domain DN> avant de redémarrer.

Avant de quitter le DSRM, empêchez le DC d'attendre des partenaires de réplication qui n'existent plus :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' `
  -Name 'Repl Perform Initial Synchronizations' -Value 0 -Type DWord
bcdedit /deletevalue safeboot

3. Reprendre le contrôle du domaine

Une fois le DC démarré en mode normal, avec un DNS pointant vers lui-même :

• Saisissez tous les rôles FSMO détenus par des DC qui ne seront pas restaurés :

Move-ADDirectoryServerOperationMasterRole -Identity 'DC01' `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force

• Nettoyez les métadonnées de tous les autres DC du domaine. Sur les versions actuelles de Windows Server, supprimer l'objet ordinateur du DC dans Utilisateurs et ordinateurs Active Directory, ou son objet serveur dans Sites et services Active Directory, effectue ce nettoyage, avec le nettoyage des métadonnées de ntdsutil en solution de repli. Supprimez aussi leurs enregistrements DNS ainsi que tous les enregistrements NS et délégations qui pointent vers eux.
• Augmentez le pool RID de 100 000 sur l'objet RID Manager (rIDAvailablePool sur CN=RID Manager$,CN=System), et invalidez le pool RID actuel sur le DC restauré. Ces deux étapes évitent des SID en double pour les objets créés après la prise de la sauvegarde.
• Réinitialisez le mot de passe du compte ordinateur du DC restauré, et réinitialisez chaque côté de chaque approbation (netdom trust ... /resetOneSide) une fois le domaine partenaire restauré.

4. Réinitialiser les identifiants

• Réinitialisez deux fois le mot de passe krbtgt. Avec un seul DC, il n'y a pas de réplication à attendre, mais laissez la première réinitialisation se terminer avant la seconde. Cela invalide tous les tickets signés avec les anciennes clés. Le mécanisme est détaillé dans la rotation du mot de passe krbtgt.
• Réinitialisez le mot de passe de l'Administrator intégré et de tous les comptes Tier 0, en désactivant tout compte dont vous ne pouvez pas répondre.
• Planifiez la réinitialisation de tous les mots de passe utilisateurs, des mots de passe des comptes de service et des clés gMSA si la sauvegarde a pu être volée. La sauvegarde contient chaque hash tel qu'il était au moment de la sauvegarde.

5. Restaurer les autres domaines, puis reconstruire

Répétez les étapes 2 à 4 pour un DC accessible en écriture dans chaque domaine, en descendant depuis la racine de la forêt. Les domaines peuvent être restaurés en parallèle une fois la racine opérationnelle. Suivez les étapes du guide relatives au catalogue global adaptées à votre topologie, car les utilisateurs ne peuvent pas ouvrir de session tant qu'aucun GC n'est disponible. Ensuite, promouvez de nouveaux DC à partir de supports sains. Ne restaurez pas d'autres sauvegardes. Reconnectez progressivement les sites et la réplication, en surveillant toute réinfection.

6. Nettoyer avant de reconnecter

Supprimez la persistance identifiée par l'équipe forensique, relancez une évaluation PingCastle et une revue des ACL, et vérifiez l'appartenance aux groupes privilégiés avant que le moindre trafic de production n'atteigne la forêt restaurée.

Vérifier

Chaque jalon de la restauration nécessite un test objectif :

dcdiag /v /c /e /f:C:\Recovery\dcdiag.txt
repadmin /replsummary
repadmin /showrepl * /csv > C:\Recovery\showrepl.csv
Get-ADDomainController -Filter * | Select-Object HostName, OperationMasterRoles, IsGlobalCatalog

# SYSVOL : 4602 = SYSVOL faisant autorité initialisé sur le premier DC ; 4604 = synchronisation ne faisant pas autorité terminée sur les nouveaux DC
Get-WinEvent -FilterHashtable @{ LogName = 'DFS Replication'; Id = 4602, 4604, 4614 } -MaxEvents 10
Get-SmbShare | Where-Object Name -in 'SYSVOL','NETLOGON'

Un DC qui présente un 4614 mais pas de 4604 attend toujours la réplication initiale de SYSVOL et ne partagera pas SYSVOL. Cela signifie généralement que le SYSVOL du premier DC n'a jamais été marqué comme faisant autorité.

Répéter

• Revue sur table, deux fois par an. Parcourez le runbook avec chaque responsable nommé. Vérifiez que chaque identifiant et chaque numéro de téléphone se trouvent bien là où le plan l'indique, et qu'aucune étape ne dépend discrètement d'AD, de la messagerie ou du SSO.
• Exercice technique, chaque année. Restaurez de vraies sauvegardes à partir de la copie immuable dans un laboratoire isolé et exécutez le runbook jusqu'à obtenir une forêt fonctionnelle avec de nouveaux DC. Chronométrez chaque phase.
• Mise à jour après chaque exercice. Chaque exercice produit des correctifs : pilotes manquants, mots de passe DSRM erronés, placement FSMO non documenté, scripts qui supposaient une build précise du système d'exploitation. Les outils commerciaux de restauration de forêt (Semperis ADFR, Quest Recovery Manager for AD) peuvent automatiser une grande partie de ce travail, mais ils exigent la même répétition.

Ce que cela casse

• Perte des données postérieures au point de sauvegarde. Toute modification postérieure à la sauvegarde retenue est perdue : nouveaux utilisateurs, changements de mot de passe, modifications de groupes, jonctions d'ordinateurs. Les machines jointes ou dont le secret a été renouvelé depuis peuvent perdre leur canal sécurisé et nécessiter Test-ComputerSecureChannel -Repair ou une nouvelle jonction.
• Kerberos et sessions. Réinitialiser deux fois krbtgt invalide tous les tickets. Chaque utilisateur et chaque service se réauthentifie, et les services de longue durée peuvent nécessiter un redémarrage.
• Identité hybride. Entra Connect voit l'annuaire restauré comme un vaste ensemble de modifications. Placez le serveur de synchronisation en mode intermédiaire (staging), examinez les exportations en attente et surveillez le seuil de suppression accidentelle.
• Risque lié aux exercices. Un DC restauré connecté par erreur à la production réintroduit d'anciens mots de passe et des objets persistants (lingering objects). Isolez physiquement ou logiquement le laboratoire, et vérifiez-le avant chaque exercice.
• Le temps. Une restauration réaliste d'une forêt multi-domaines prend des jours, pas des heures. Ce sont les durées mesurées lors des exercices, et non des RTO rêvés, qui doivent figurer dans votre plan de continuité d'activité.

Pour aller plus loin : protéger les sauvegardes AD contre les rançongiciels garantit qu'une sauvegarde saine existe, définir le Tier 0 liste tout ce qui doit revenir avec la forêt, et la thématique évaluation, sauvegarde et restauration rassemble toute la série.