Évaluation AD, sauvegarde et restauration de forêt

Les contrôles de durcissement se dégradent en silence. Un paramètre de stratégie de groupe dérive, un compte de service est entré dans Domain Admins pendant un incident et personne ne l'a retiré, une nouvelle approbation est arrivée avec un projet de migration et n'a jamais été réexaminée. L'évaluation, la sauvegarde et la répétition de la restauration forment la couche de gouvernance qui détecte ces dérives et garantit que lorsque, et non si, quelque chose tourne mal, vous disposez à la fois des éléments pour savoir ce qui s'est passé et d'un chemin éprouvé vers une forêt saine.

Cet article couvre l'exécution et l'interprétation des évaluations de posture, la comparaison de la configuration avec le Security Compliance Toolkit de Microsoft et les CIS Benchmarks, le traitement de LAPS et du modèle de tiers comme des contrôles récurrents plutôt que comme des projets ponctuels, la protection des sauvegardes Tier 0 et la répétition d'une restauration complète de forêt.

Outils d'évaluation de la posture

Trois outils couvrent l'essentiel de vos besoins, et ils sont complémentaires plutôt que redondants :

Exécutez PingCastle (ou Purple Knight) en tâche planifiée plutôt qu'en exécution ponctuelle :

# PingCastle, mode healthcheck, planifié via le Planificateur de tâches
PingCastle.exe --healthcheck --server dc01.domain.com --level Full

Lire le score : ne courez pas après 100/100. Certains constats sont des faux positifs dans votre environnement ou des risques acceptés (documentés, par exemple une application héritée qui exige un protocole ancien). Ce qui compte :

1. Les constats critiques diminuent d'une version à l'autre, sans jamais augmenter.
2. Tout nouveau constat dans les catégories Trusts ou Privileged Accounts est trié sous quelques jours, pas au cycle trimestriel suivant : ces catégories évoluent le plus vite et sont les plus souvent pertinentes pour un attaquant.
3. Les constats sont rattachés à un ticket et à un responsable, au lieu d'être simplement réexaminés et réacceptés indéfiniment.

Comparaison aux référentiels : Microsoft SCT et CIS Benchmarks

Les scanners de posture vous renseignent sur les risques au niveau des objets AD (comptes obsolètes, approbations mal configurées, délégation). En général, ils ne remplacent pas complètement une comparaison des stratégies de groupe avec un référentiel, qui vous indique si vos GPO réelles correspondent à une base de sécurité validée.

• Microsoft Security Compliance Toolkit (SCT) : fournit des sauvegardes de GPO de référence pour chaque version de Windows Server prise en charge, ainsi que Policy Analyzer, un outil graphique/en ligne de commande qui compare vos GPO de production au référentiel et signale chaque paramètre divergent.
• CIS Benchmarks pour Windows Server / Active Directory : un référentiel maintenu de manière indépendante et plus prescriptif ; de nombreux environnements réglementés exigent spécifiquement la conformité CIS plutôt que (ou en plus de) celle du référentiel Microsoft.

Démarche :

# Exporter les GPO actuelles pour comparaison
Get-GPO -All | ForEach-Object { Backup-GPO -Guid $_.Id -Path "C:\GPOBackups" }

Chargez ensuite les sauvegardes exportées ainsi que les sauvegardes de GPO de référence SCT/CIS dans Policy Analyzer, et générez un rapport des écarts. Consignez les exceptions (les paramètres dont vous vous écartez délibérément) dans un document avec une justification et un responsable : les auditeurs, et vous-même plus tard, en aurez besoin.

Relancez cette comparaison chaque fois que Microsoft publie un nouveau référentiel SCT (généralement aligné sur chaque mise à jour de fonctionnalités de Windows Server) et, dans tous les cas, au moins deux fois par an.

LAPS et modèle de tiers : des contrôles récurrents, pas des projets ponctuels

LAPS (Local Administrator Password Solution / Windows LAPS) comme le modèle de tiers d'administration (Tier 0 et accès privilégiés) se dégradent s'ils sont traités comme un projet de déploiement plutôt que comme un contrôle continu :

# Vérifier que LAPS renouvelle réellement les mots de passe, et pas seulement qu'il est installé
# Windows LAPS (attributs msLAPS-*)
Get-ADComputer -Filter * -Properties msLAPS-PasswordExpirationTime |
  Where-Object { $_.'msLAPS-PasswordExpirationTime' -lt (Get-Date).AddDays(-35).ToFileTime() } |
  Select-Object Name
# Ancien Microsoft LAPS, uniquement si son extension de schéma (ms-Mcs-AdmPwd*) est installée
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwdExpirationTime |
  Where-Object { $_.'ms-Mcs-AdmPwdExpirationTime' -lt (Get-Date).AddDays(-35).ToFileTime() } |
  Select-Object Name

# Vérifier qu'aucun compte inattendu n'a atterri dans les groupes Tier 0
Get-ADGroupMember "Domain Admins" -Recursive | Select-Object Name, SamAccountName
Get-ADGroupMember "Enterprise Admins" -Recursive | Select-Object Name, SamAccountName

Planifiez ces deux contrôles au minimum chaque semaine. La dérive des appartenances aux groupes (un compte de service ajouté à Domain Admins pendant un incident et jamais retiré, un prestataire doté d'un accès temporaire qui a survécu à la mission) est l'une des façons les plus courantes dont le modèle de tiers échoue en silence, et elle reste invisible tant que vous ne la cherchez pas activement. Corrélez avec les événements 4728/4732/4756 pour savoir quand et par qui la dérive s'est produite, et pas seulement qu'elle existe.

Protéger les sauvegardes Tier 0

La sauvegarde de l'état du système d'un contrôleur de domaine est, dans les faits, une copie de chaque identifiant du domaine : la base NTDS avec tous les hashs de mots de passe, et la clé krbtgt qui signe chaque ticket Kerberos. Protégez-la en conséquence :

• Réalisez des sauvegardes de l'état du système, et pas seulement des sauvegardes au niveau fichier ou des instantanés de VM, afin que les restaurations faisant autorité et ne faisant pas autorité fonctionnent correctement :

wbadmin start systemstatebackup -backupTarget:E: -quiet

• Stockez les sauvegardes hors ligne, de manière immuable ou isolée de la production. Si un identifiant équivalent Domain Admin (ou un rançongiciel qui en a obtenu un) peut atteindre et supprimer votre stockage de sauvegarde, ce n'est pas une sauvegarde : c'est une seconde copie du même actif que l'attaquant possède déjà. Un stockage objet immuable (écriture unique, rétention verrouillée) ou un support réellement hors ligne/isolé sont tous deux acceptables ; un partage de sauvegarde joint au même domaine, accessible par les mêmes comptes privilégiés, ne l'est pas.
• Restreignez les droits d'opérateur de sauvegarde : Backup Operators peut lire toute la base NTDS via une sauvegarde de l'état du système, ce qui rend ce groupe équivalent à Domain Admin du point de vue de la confidentialité. Auditez ses membres aussi strictement que ceux de Domain Admins.
• Testez la capacité de restauration, et pas seulement la bonne fin des sauvegardes. Un travail de sauvegarde signalé comme réussi vous dit qu'il a écrit des données ; il ne vous dit pas que ces données se restaurent.

Répéter la restauration de forêt

Microsoft publie un guide de restauration de forêt AD (AD Forest Recovery Guide) détaillé, qui décrit l'ordre exact des opérations pour se remettre d'un scénario où la forêt n'est plus digne de confiance (rançongiciel, modification malveillante du schéma, ou perte d'un nombre de DC suffisant pour casser la réplication ou le quorum). Ne le lisez pas pour la première fois pendant un incident réel.

Ordre général des opérations (voir le guide de Microsoft pour la procédure complète) :

1. Identifiez la dernière sauvegarde de l'état du système réputée saine et exempte de logiciel malveillant pour un DC par domaine, en privilégiant un serveur de catalogue global du domaine racine de la forêt.
2. Isolez l'environnement (déconnexion du réseau, suspension de la réplication) avant de restaurer, afin qu'un adversaire encore actif ou un partenaire de réplication corrompu ne puisse pas réinfecter le DC restauré.
3. Restaurez le premier DC de chaque domaine (en commençant par la racine de forêt) en mode de restauration des services d'annuaire (DSRM), sous la forme d'une restauration ne faisant pas autorité d'AD DS avec une restauration faisant autorité de SYSVOL (wbadmin start systemstaterecovery ... -authsysvol, ou msDFSR-Options à 1 sur l'abonnement SYSVOL du DC pour DFSR). Tous les autres DC seront reconstruits : aucun partenaire de réplication n'a donc de modifications à écraser.
4. Réinitialisez deux fois le mot de passe krbtgt dans chaque domaine dans le cadre de la restauration, en respectant la convergence de la réplication entre les deux réinitialisations : cela invalide tous les tickets Kerberos émis avant la restauration, y compris ceux forgés par un attaquant.
5. Nettoyez les métadonnées de tous les DC qui ne seront pas restaurés, avec ntdsutil, afin que des objets DC obsolètes ne provoquent pas de problèmes de réplication ou de DNS :

ntdsutil
metadata cleanup
connections
connect to server <survivingDC>
quit
select operation target
list domains
select domain <n>
list sites
select site <n>
list servers in site
select server <n>
quit
remove selected server
quit
quit

6. Reconstruisez et repromouvez les DC restants à partir de supports sains une fois le premier DC et le nettoyage des métadonnées validés.
7. Rétablissez progressivement la connectivité réseau et la réplication, en surveillant les signes de réinfection avant de reconnecter entièrement l'environnement.

Répétez cette procédure dans un laboratoire isolé au moins une fois par an. Un guide de restauration ne se lit pas comme il s'exécute : problèmes de mot de passe DSRM, placement inattendu des rôles FSMO ou méconnaissance de la syntaxe de ntdsutil sous pression sont précisément les frictions que vous voulez découvrir pendant un exercice, et non pendant un incident de rançongiciel à 2 heures du matin.

Ce que cela casse

Rien directement : il s'agit de gouvernance et de reprise après sinistre, pas d'un contrôle exposé à la production. Le coût se mesure en temps et en rigueur de processus : exécutions d'évaluation planifiées, budget de stockage pour une rétention immuable/hors ligne, et exercices de restauration périodiques qui consomment de l'infrastructure de laboratoire et du temps humain. Rien de cela ne modifie au quotidien l'authentification ni les accès des utilisateurs.

Associez cette démarche au durcissement de Kerberos pour la cadence de rotation de krbtgt hors scénarios de restauration, et à l'audit, la journalisation et la détection afin que, lorsqu'une évaluation de posture signale un constat, vous disposiez aussi des journaux pour déterminer s'il a déjà été exploité.