Sauvegarder et restaurer Active Directory : System State et restauration autoritaire

Une infrastructure Active Directory sans sauvegarde testée est une bombe à retardement. La redondance entre deux DC ne protège pas contre la corruption logique : une suppression accidentelle de 500 comptes, un ransomware qui chiffre la base NTDS, une mauvaise extension de schéma propagent leur dégât instantanément aux deux DC. La seule parade : une sauvegarde régulière du System State, restaurable rapidement, testée trimestriellement. Ce tutoriel met en place la sauvegarde Windows Server Backup, explique les concepts critiques (System State, restauration autoritaire vs non autoritaire, USN, AD Recycle Bin), et teste une restauration complète sur un environnement de lab.

Prérequis : un DC fonctionnel (cf. Promouvoir le premier contrôleur de domaine). Panorama : Windows Server 2025 et Active Directory pour PME.

Prérequis

• Un DC Windows Server 2025 avec System State accessible.
• Un volume dédié à la sauvegarde, séparé du système (D:\, lecteur réseau, disque USB) avec au minimum 50 Go libres.
• Le rôle Windows Server Backup installé : Install-WindowsFeature -Name Windows-Server-Backup.
• Idéalement un environnement de lab isolé pour tester la restauration sans impact sur la production.
• Niveau attendu : intermédiaire à avancé.
• Temps estimé : 1 heure pour le setup initial, 2 heures pour un test de restauration complet.

Étape 1 — Comprendre ce que contient le System State d’un DC

Sur un contrôleur de domaine, le System State regroupe tout ce qui constitue l’identité de la machine et la base AD :

• Le fichier NTDS.dit — base Active Directory complète.
• Le partage SYSVOL — GPO, scripts logon, données DFSR.
• Le registre Windows.
• Les fichiers de démarrage et la base COM+.
• Les fichiers du système d’exploitation protégés (Windows File Protection).
• Les certificats de l’autorité de certification si AD CS est installé.

Un backup du System State d’un DC pèse typiquement 8 à 25 Go selon la taille de l’annuaire. C’est suffisant pour restaurer entièrement le DC sur du matériel neuf si le serveur d’origine est définitivement perdu.

Étape 2 — Activer l’AD Recycle Bin (corbeille AD)

Avant de configurer le backup, activer la AD Recycle Bin. Cette fonctionnalité, disponible depuis Server 2008 R2 mais désactivée par défaut sur les forêts plus anciennes, permet de restaurer un objet supprimé pendant 180 jours sans recourir à une restauration de backup. Une simple suppression accidentelle d’utilisateur ne nécessite plus de toucher au System State.

Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' `
  -Scope ForestOrConfigurationSet `
  -Target 'ad.entreprise.com' -Confirm:$false

L’activation est irréversible. Vérifier :

Get-ADOptionalFeature -Filter * | Select-Object Name, EnabledScopes

Recycle Bin Feature doit afficher EnabledScopes non vide. Tester en supprimant puis restaurant un compte test :

New-ADUser -Name 'test-recycle' -Path "CN=Users,DC=ad,DC=entreprise,DC=com"
Remove-ADUser -Identity 'test-recycle' -Confirm:$false
Get-ADObject -Filter 'Name -like "*test-recycle*"' -IncludeDeletedObjects |
  Restore-ADObject

Le compte réapparaît dans son OU d’origine.

Étape 3 — Configurer la sauvegarde quotidienne

Le module WindowsServerBackup permet de planifier une sauvegarde régulière du System State. On vise une fréquence quotidienne, conservée 14 jours pour pouvoir remonter à n’importe quel jour de la semaine précédente.

$policy = New-WBPolicy

# Ajouter le System State
$systemState = Get-WBSystemState
Add-WBSystemState -Policy $policy

# Cible de sauvegarde : volume D:\Backup
$target = New-WBBackupTarget -VolumePath 'D:\'
Add-WBBackupTarget -Policy $policy -Target $target

# Planification : tous les jours à 2h du matin
$schedule = [datetime]"02:00"
Set-WBSchedule -Policy $policy -Schedule $schedule

# Activer la politique
Set-WBPolicy -Policy $policy -AllowDeleteOldBackups -Force

La première sauvegarde se lance lors de la prochaine planification, ou immédiatement via :

Start-WBBackup -Policy (Get-WBPolicy)

Surveiller les premiers cycles dans l’Event Viewer (Windows Logs → Application → source Backup).

Étape 4 — Sauvegarde déportée hors-site

Une sauvegarde sur le même hyperviseur ou le même bâtiment qu’un DC ne protège pas contre l’incendie ou le ransomware qui chiffre les partages locaux. La sauvegarde doit être déportée. Trois patterns courants en PME :

• Disque USB rotatif — deux disques externes, un branché en semaine N, l’autre en semaine N+1, l’opérateur emporte chaque semaine le disque déconnecté à son domicile ou dans un coffre. Simple, abordable, efficace.
• Stockage objet immuable — bucket S3-compatible (Wasabi, Backblaze B2, OVHcloud Object Storage) avec versioning et Object Lock activé. Le ransomware ne peut pas modifier les fichiers même avec les clés d’accès volées.
• Veeam Backup & Replication — Community Edition gratuite jusqu’à 10 instances, avec déport vers un repository distant (NAS ou cloud).

Pour automatiser la copie vers un bucket S3-compatible :

# Installer AWS CLI ou rclone
choco install rclone -y

# Config rclone vers Wasabi (une fois)
rclone config

# Script quotidien après backup
rclone copy 'D:\WindowsImageBackup' wasabi:bucket-ad-backup-ent/ `
  --transfers 4 --progress

Le coût annuel pour ~200 Go déporté est inférieur à 30 € sur la plupart des providers.

Étape 5 — Comprendre restauration autoritaire vs non autoritaire

Deux modes de restauration coexistent :

• Non autoritaire (non-authoritative) — le DC restauré se réplique avec les autres DC et adopte les changements survenus depuis la sauvegarde. Utilisé quand le DC restauré est isolé ou pour remettre en service un DC tombé sur du matériel neuf.
• Autoritaire (authoritative) — le DC restauré impose ses données aux autres DC. Utilisé après une suppression massive : la sauvegarde devient la source de vérité, et la suppression accidentelle est annulée sur tous les DC. Beaucoup plus délicat, à utiliser uniquement avec préparation.

Sans AD Recycle Bin, la restauration autoritaire était la seule façon de récupérer un objet supprimé. Avec la Recycle Bin activée, l’autoritaire est devenu rare — réservé aux situations où la Recycle Bin elle-même est corrompue.

Étape 6 — Tester une restauration non autoritaire sur lab

Une sauvegarde non testée n’est pas une sauvegarde. Procéder en lab : cloner un DC sur un hyperviseur isolé, simuler une corruption, restaurer.

1. Cloner DC01 dans une VM Hyper-V DC01-LAB, isolée sur un vSwitch privé sans accès au LAN production.
2. Démarrer DC01-LAB et le placer en mode Directory Services Restore Mode (DSRM) : redémarrer en pressant F8 au boot, ou via PowerShell : bcdedit /set safeboot dsrepair puis Restart-Computer.
3. Ouvrir une session en mode DSRM avec le mot de passe DSRM (pas le mot de passe Domain Administrator).
4. Lancer la restauration :

wbadmin start systemstaterecovery `
  -version:01/01/2026-02:00 `
  -backupTarget:D: `
  -quiet

La restauration prend 20 à 40 minutes. Au redémarrage, sortir du DSRM (bcdedit /deletevalue safeboot), tester l’ouverture de session AD locale, vérifier la base avec dcdiag. Si tout passe, la chaîne de sauvegarde est validée.

Étape 7 — Tester une restauration autoritaire d’OU complète

Scénario réel : un administrateur supprime par erreur l’OU Commerce avec ses 30 comptes utilisateurs. La réplication propage immédiatement la suppression aux deux DC. Avec Recycle Bin : on restaure individuellement. Sans Recycle Bin ou si la suppression date d’il y a 200 jours : restauration autoritaire requise.

1. Restaurer le System State en mode DSRM (cf. étape précédente).
2. Avant de sortir du DSRM, lancer ntdsutil :

ntdsutil
activate instance ntds
authoritative restore
restore subtree "OU=Commerce,OU=Utilisateurs,DC=ad,DC=entreprise,DC=com"
quit
quit

La commande incrémente le numéro de version des objets de cette OU pour qu’ils l’emportent sur les pairs lors de la prochaine réplication. Redémarrer hors DSRM. Les autres DC reçoivent la mise à jour et l’OU réapparaît partout.

Étape 8 — Stratégie de rétention adaptée à la PME

Conserver 14 jours quotidiens est un minimum, mais une vraie stratégie de rétention combine plusieurs cadences. Le modèle GFS (Grandfather-Father-Son), classique en sauvegarde, s’adapte parfaitement aux contrôleurs de domaine :

• Quotidiennes — 14 dernières sauvegardes, accessibles en quelques minutes pour les incidents courants (suppression accidentelle au-delà de la Recycle Bin, corruption récente).
• Hebdomadaires — 8 dernières sauvegardes du dimanche, sur un volume distinct ou un bucket cloud, pour remonter à deux mois en arrière en cas de drift insidieux.
• Mensuelles — dernière sauvegarde de chaque mois, conservée 12 mois, pour les audits réglementaires et les enquêtes sur des modifications historiques.

Ce schéma coûte peu en espace (la déduplication des System State successifs est forte) et offre une fenêtre de récupération de plus d’un an. Le cumul reste sous 500 Go pour la majorité des infrastructures PME.

Étape 9 — Documenter la procédure de bare-metal recovery

Si le serveur physique est détruit (incendie, vol, panne irréparable) et qu’on doit restaurer sur un matériel neuf, la procédure dite bare-metal recovery consiste à :

1. Préparer le serveur neuf avec un OS Windows Server 2025 minimum installé (même édition que le DC d’origine).
2. Connecter le volume de sauvegarde (USB, NAS).
3. Démarrer sur le DVD d’installation Windows Server 2025, choisir Réparer l’ordinateur → Dépannage → Récupération d’image système.
4. Sélectionner le backup le plus récent, lancer la restauration complète.
5. Au reboot, le serveur revit avec son identité d’origine. Vérifier dcdiag, sortir du mode DSRM si activé.

Compter 1 à 2 heures selon la taille de la base. La procédure complète, écrite étape par étape avec captures d’écran, doit être imprimée et accessible offline. Plusieurs binders papier rangés dans le coffre de l’entreprise, plus un export PDF sur deux clés USB chiffrées que les administrateurs gardent à leur domicile : c’est la résilience documentaire qui sauve réellement une PME quand le SI est paralysé et que les wikis internes sont inaccessibles. Vérifier annuellement que la procédure correspond toujours à l’infrastructure réelle : un serveur ajouté, un changement d’hyperviseur, une migration de DNS modifient les étapes et un document obsolète induit en erreur au pire moment. Faire relire la procédure par un technicien junior une fois par an : s’il comprend et peut exécuter, le document est utile ; sinon il faut le réécrire avant la prochaine vraie urgence.

Aparté — Sauvegarde des GPO indépendamment du System State

Les GPO sont incluses dans le System State puisqu’elles vivent dans SYSVOL et dans la base AD. Mais une sauvegarde dédiée des GPO offre une granularité supérieure : on peut restaurer une seule GPO sans toucher au reste, et on peut transporter une GPO d’un domaine de test vers la production.

$d = Get-Date -Format yyyyMMdd
$path = "D:\Backup\GPO\$d"
mkdir $path -Force | Out-Null
Backup-GPO -All -Path $path -Comment "Backup hebdo $d"

Chaque GPO produit un sous-dossier nommé par GUID, contenant son rapport HTML et tous ses paramètres. La restauration ciblée se fait par Restore-GPO -Name 'SEC-Baseline-Postes-Windows11' -Path $path. Cette pratique complète bien la sauvegarde System State : pour un changement de GPO planté, la restauration est instantanée et non destructrice. Programmer ce backup en plus de la sauvegarde quotidienne, idéalement avant chaque modification importante des GPO. Stocker les exports avec le reste de la documentation IT, dans un dépôt Git interne si possible, pour bénéficier de l’historique versionné.

Étape 10 — Vérifier régulièrement l’intégrité des backups

Un backup peut exister sur le disque mais être illisible. Tester :

Get-WBBackupSet | Select-Object BackupTime, BackupTarget, VersionId, Application
wbadmin get versions -backupTarget:D:

Chaque version doit lister System State dans Application. Pour valider plus en profondeur, on lance trimestriellement une restauration test en lab — c’est la seule garantie réelle.

Étape 11 — Surveiller la santé des backups au quotidien

Un script PowerShell quotidien qui surveille le dernier backup et alerte si rien ne s’est passé depuis 36 heures :

# C:\Admin\check-backup.ps1
$lastBackup = (Get-WBBackupSet | Sort-Object BackupTime -Descending |
  Select-Object -First 1).BackupTime
$delta = (Get-Date) - $lastBackup
if ($delta.TotalHours -gt 36) {
  Send-MailMessage -To 'admin@entreprise.com' -From 'noreply@entreprise.com' `
    -Subject "AD Backup overdue (last: $lastBackup)" `
    -Body "No backup since $lastBackup ($('{0:N1}' -f $delta.TotalHours) hours)" `
    -SmtpServer 'smtp.office365.com' -Port 587 -UseSsl `
    -Credential (Import-CliXml C:\Admin\smtp.cred)
}

Tâche planifiée chaque jour à 9h. Si un backup échoue silencieusement, l’admin est prévenu avant le second cycle.

Erreurs fréquentes

Vérification finale

Une sauvegarde System State quotidienne tourne sur le DC, déportée hors-site, conservée 14 jours. La Recycle Bin AD est activée. Un test de restauration en lab confirme la lisibilité du backup. Un script de monitoring alerte en cas de cycle manqué. La procédure de bare-metal recovery est documentée et imprimée. L’infrastructure peut désormais survivre à une corruption logique, un ransomware, ou une perte matérielle totale.

La suite logique : déployer WSUS pour centraliser les mises à jour Windows, dernière brique de l’administration courante. Panorama : Windows Server 2025 et Active Directory pour PME.

Ressources officielles

• Active Directory Forest Recovery Guide — Microsoft Learn
• Windows Server Backup overview — Microsoft Learn
• AD Administrative Center et AD Recycle Bin — Microsoft Learn
• WindowsServerBackup PowerShell module — Microsoft Learn