Sauvegarde Active Directory : valider la restauration

Ce que signifie valider une sauvegarde Active Directory pour restaurer la forêt

La validation d’une sauvegarde Active Directory pour la restauration d’une forêt pose deux questions : peut-on restaurer la sauvegarde, et l’organisation peut-elle justifier sa confiance dans la forêt qui en résulte ? Une restauration réussie répond à la première. La seconde exige un point de restauration examiné, une procédure répétée lors d’un exercice et des preuves que l’annuaire restauré satisfait aux critères de reprise.

Le guide de restauration de forêt Active Directory de Microsoft fournit un modèle à adapter à l’environnement. Ses recommandations d’évaluation de l’incident excluent explicitement les recommandations de sécurité complètes pour restaurer une forêt piratée ou compromise. Utilisez la procédure de restauration en complément du travail de réponse à incident nécessaire pour établir la confiance.

Ici, restauration validée désigne un exercice ou une restauration documentés, avec des contrôles d’acceptation consignés et des limites explicitement indiquées. C’est une définition éditoriale, pas une certification Microsoft. « Le DC a démarré » et « la réplication fonctionne » sont des observations utiles, mais aucune ne démontre que l’état d’annuaire choisi est sûr.

Question	Preuves à demander	Ce qui reste ouvert
La sauvegarde est-elle restaurable ?	Le résultat d’une restauration réelle de la sauvegarde et du parcours de reprise choisis	La fiabilité de l’état restauré
La restauration est-elle reproductible ?	Une procédure à jour et un compte rendu d’exercice daté	Le périmètre du prochain incident
Le point de restauration est-il défendable ?	Une chronologie de l’incident et les raisons d’accepter cette sauvegarde	Les modifications malveillantes non couvertes par l’enquête
La forêt restaurée est-elle prête ?	Des contrôles opérationnels consignés et les décisions de revue de sécurité	Les dépendances ou mécanismes de persistance hors de ces contrôles

Traitez le temps de restauration comme un autre résultat à consigner. Un exercice rapide avec des identifiants inconnus, des données non examinées ou des échecs de validation non résolus ne doit pas être présenté comme une restauration validée.

Choisir un état de confiance avant de restaurer

Les recommandations de sélection des sauvegardes de Microsoft avertissent qu’une sauvegarde plus récente peut réintroduire des données dangereuses. Si l’heure de la défaillance est inconnue, recherchez le dernier état sûr. La restauration fait perdre les objets, mises à jour et modifications de configuration ou de schéma ultérieurs.

La même page recommande de sauvegarder régulièrement au moins deux DC accessibles en écriture par domaine. Elle exige les identifiants Domain Admin de chaque domaine et le mot de passe DSRM. Une sauvegarde de RODC ne peut pas restaurer un DC accessible en écriture ; la restauration de l’état du système sur une nouvelle installation Windows n’est pas prise en charge. Prévoyez le parcours de récupération complète du serveur approprié. Dsamain et un navigateur LDAP tel que Ldp peuvent aider à inspecter les données d’annuaire sauvegardées.

Lorsque la corbeille est activée, la validité des sauvegardes est limitée par la plus petite des valeurs deletedObjectLifetime et tombstoneLifetime. Ces conditions rendent insuffisant l’argument « nous avons un fichier récent » pour justifier la reprise.

Consignez, pour la décision de restauration, la sauvegarde choisie, le domaine qu’elle représente, les raisons pour lesquelles son état est acceptable et les modifications qui seront perdues. Si l’enquête ne permet pas d’étayer un point de confiance, consignez cette incertitude au lieu de rebaptiser « propre » la sauvegarde la plus récente.

Les affirmations sur la persistance doivent rester conditionnelles

L’inférence concernant la restauration est conditionnelle : si une modification malveillante de l’annuaire est présente dans la sauvegarde choisie et appartient à l’état restauré, restaurer cet état peut réintroduire la modification. Il s’agit d’une déduction du comportement de retour à un état antérieur documenté, et non d’une affirmation de Microsoft selon laquelle toute porte dérobée revient nécessairement intacte.

Cette distinction compte pour les ACL et AdminSDHolder. Notre article sur AdminSDHolder et SDProp explique la persistance via un modèle d’ACL modifié et pourquoi corriger uniquement l’ACL d’un objet protégé peut laisser le problème du modèle non résolu. Pour la restauration, vérifiez si le modèle sauvegardé et les permissions pertinentes correspondent à une référence acceptée. Les pages Forest Recovery citées ici ne décrivent pas explicitement la restauration d’une porte dérobée AdminSDHolder.

La documentation Microsoft sur les modèles de certificats indique que les modèles des autorités de certification d’entreprise résident dans AD DS. Elle distingue la modification d’un modèle, l’activation de l’émission sur une autorité de certification et la publication d’un certificat émis. Un modèle modifié inclus dans l’état d’annuaire restauré pourrait donc réapparaître : c’est une inférence conditionnelle. Cela n’établit pas l’état restauré de chaque autorité de certification, certificat émis ou secret PKI. Définissez séparément la revue PKI complémentaire.

Notre article sur Golden Ticket décrit le risque de persistance associé à un secret krbtgt compromis. Les instructions de restauration et les délais de réinitialisation ci-dessous proviennent de Microsoft Learn. Le lien explique pourquoi ce secret compte ; il ne constitue pas la référence pour cette procédure de restauration.

Suivre la séquence de restauration avec des points de validation

Les prérequis Microsoft supposent que la cause et les remèdes possibles ont été évalués avec le support Microsoft et que la restauration de la forêt est la solution retenue, souvent en dernier recours. Ils demandent aussi un plan documenté, testé en laboratoire avec des sauvegardes de production.

Préparez cette décision avant d’entamer des étapes de restauration destructives. Consignez le périmètre de l’incident, les identifiants de reprise, les informations d’accès d’urgence et les sauvegardes choisies. La procédure doit rendre la décision suivante claire même quand les services d’annuaire habituels sont indisponibles.

Ce qui suit est une vue d’ensemble de la séquence de restauration initiale de Microsoft, pas un substitut exécutable à la procédure complète :

Restaurer en isolement. Commencez par un DC accessible en écriture du domaine racine de la forêt, puis restaurez les autres domaines, les parents avant les enfants.
Employer le bon mode de restauration pour le premier DC restauré de chaque domaine. Restaurez AD DS de manière non autoritaire et SYSVOL de manière autoritaire, selon la méthode documentée. Les DC suivants du domaine doivent resynchroniser SYSVOL depuis la copie autoritaire.
Vérifier les données restaurées avant la connexion à la production. Effectuez les étapes documentées pour FSMO, les métadonnées, DNS, RID, les mots de passe des comptes et l’heure. Une intrusion suspectée exige la réinitialisation des mots de passe administratifs et le remplacement de tous les mots de passe gMSA. Une compromission suspectée de comptes utilisateurs exige aussi de planifier la réinitialisation des mots de passe de tous les utilisateurs du domaine.
Valider ensemble les DC restaurés. Utilisez un réseau isolé commun avant la transition vers la production.
Sauvegarder les DC restaurés avant de redéployer les DC restants.

La page documente également les contrôles opérationnels suivants dans sa section sur la santé de la réplication de la forêt, après la transition vers le réseau de production :

repadmin /replsum
DCDiag /v

Ils évaluent la réplication et la santé des DC et de DNS. Un résultat réussi ne certifie pas l’absence de persistance. Gardez les preuves opérationnelles et les conclusions de la revue de sécurité distinctes dans le dossier de restauration.

Réinitialiser krbtgt deux fois avec l’intervalle documenté

La procédure Microsoft de réinitialisation de krbtgt s’applique aux DC accessibles en écriture, pas aux RODC. Dans Utilisateurs et ordinateurs Active Directory, activez les fonctionnalités avancées, ouvrez le conteneur Users du domaine et utilisez Réinitialiser le mot de passe sur krbtgt.

Effectuez l’opération deux fois. Le compte conserve les deux mots de passe les plus récents ; deux réinitialisations retirent l’ancien mot de passe de cet historique. Learn exige 10 heures entre les réinitialisations avec les durées de vie maximales par défaut des tickets utilisateur et de service. Si la durée maximale est modifiée, le délai d’attente doit être supérieur à la valeur configurée. Ne supposez pas que la première réinitialisation invalide systématiquement tous les tickets forgés.

Pour une restauration impliquant des RODC, Learn indique de ne pas supprimer leurs comptes krbtgt_number. Ne leur appliquez pas la procédure des DC accessibles en écriture.

Détection : mesurer l’âge des sauvegardes et les preuves manquantes

La réussite d’une tâche de sauvegarde, un horodatage d’annuaire et un exercice de restauration correspondent à des preuves différentes. Examinez chacune pour ce qu’elle démontre.

Les recommandations Microsoft sur la latence des sauvegardes documentent :

Repadmin.exe /showbackup

Collectez les dates de sauvegarde indiquées pour les DC et contextes de nommage ciblés, et consignez le périmètre réel de la commande. Repadmin exige des identifiants administratifs sur chaque DC ciblé. Microsoft explique que l’horodatage de sauvegarde est écrit par les sauvegardes utilisant les API standard de sauvegarde ; une copie de la base AD au niveau fichier n’apporte pas cette protection.

Enquêtez lorsque les sauvegardes sont plus anciennes que la moitié de la durée de vie des objets tombstone de la forêt. Learn indique que les sauvegardes dépassant cette durée de vie sont invalides et recommande au moins des sauvegardes quotidiennes dans presque tous les scénarios. Lisez les paramètres de durée de vie réels de la forêt. Ne leur substituez ni une valeur universelle de 180 jours ni le seuil indépendant de 60 jours du collecteur.

Un horodatage récent ne démontre toujours ni l’intégrité du support ni la réussite d’une restauration.

Signal à examiner	Preuves à collecter	Décision suivante
Informations de sauvegarde manquantes ou anciennes	Résultats de `/showbackup` avec leur périmètre, historique des tâches et inventaire des sauvegardes disponibles	Corriger la couverture manquante ou les tâches en échec
Aucun exercice de restauration consigné	Date du dernier exercice, identifiants des sauvegardes et résultats des contrôles	Planifier un exercice avec les sauvegardes de production
Point de restauration incertain	Chronologie de l’incident et examen de l’état sauvegardé candidat	Établir le dernier point de confiance ou conserver l’incertitude
Corbeille indisponible ou état inconnu	État réel de la fonctionnalité et revue des prérequis	Prévoir l’activation avant de futures suppressions
Échec des contrôles de restauration	Résultats de diagnostic sauvegardés et écarts à la procédure	Résoudre l’échec avant d’accepter la restauration

Ce sont des pistes d’investigation, pas des observations d’un environnement client. Demandez les artefacts derrière « testé » ou « restaurable » : quelle sauvegarde, quel domaine, quelle révision de procédure et quels contrôles réussis ?

Remédiation : documenter, répéter et préparer la restauration d’objets (Remediation)

1. Adapter la procédure à la forêt

Les recommandations de planification Microsoft demandent une carte de topologie couvrant les DC, les rôles, l’état des sauvegardes et les relations d’approbation. Elles recommandent de pratiquer la restauration de forêt au moins chaque année et proposent aussi des exercices lorsque la composition des groupes Domain Admins ou Enterprise Admins change.

Transformez cette carte en dossier de décision utilisable : identifiez le DC de reprise de chaque domaine, les critères de sélection des sauvegardes, les accès requis et les points de validation. Désignez les responsables de la mise à jour de ces informations. Une lacune inexpliquée doit rester visible au lieu d’être masquée par une liste de contrôle complétée.

2. Répéter la restauration et conserver les résultats

Les prérequis demandent des sauvegardes et restaurations régulières d’AD DS et de SYSVOL en laboratoire, une revue régulière de la procédure et des mises à jour après les changements de système d’exploitation ou d’architecture. Répétez le parcours de reprise réel avec des sauvegardes de production.

Un compte rendu d’exercice utile identifie la révision de la procédure, les sauvegardes choisies, les opérateurs, les contrôles réalisés, leurs résultats et les écarts. Incluez la durée, mais précisez aussi ce que l’exercice a validé et ce qu’il n’a pas validé. Si une sauvegarde démarre correctement mais que la revue des données échoue, conservez les deux résultats. Si un accès requis était indisponible, consignez-le comme une dépendance de reprise à corriger.

Distinguez « la procédure a été exécutée » de « les critères d’acceptation sont satisfaits ». Répéter une procédure sans examiner ses résultats ne résout pas la question de la confiance.

3. Activer la corbeille avant d’en avoir besoin

Les recommandations Microsoft sur la corbeille indiquent que la fonctionnalité est désactivée par défaut et que son activation est irréversible. Elle conserve les attributs et liens des objets supprimés, y compris les appartenances aux groupes. Elle ne peut récupérer que les objets supprimés après son activation.

Vérifiez les prérequis documentés : niveaux fonctionnels de forêt et de domaine Windows Server 2008 R2 ou supérieurs, permissions administratives indiquées, et ADAC ou le module PowerShell Active Directory.

Pour le parcours ADAC documenté, sélectionnez le domaine cible approprié, choisissez Activer la corbeille dans le volet Tâches, confirmez les messages et actualisez ADAC. Après une suppression de test contrôlée, utilisez le conteneur Objets supprimés pour restaurer l’objet sélectionné et vérifier son emplacement.

Consignez la décision d’activation et un test contrôlé de restauration d’objet. La corbeille traite la récupération d’objets ; elle ne valide pas une forêt compromise. Gardez ce test distinct de l’exercice de restauration de la forêt.

4. Combler les lacunes de preuve avant de déclarer la restauration validée

Utilisez un court dossier d’acceptation reliant chaque conclusion à une preuve. « Sauvegarde disponible » doit nommer la sauvegarde. « Restauration répétée » doit identifier l’exercice. « État de confiance » doit identifier l’enquête et la revue de référence. « Contrôles opérationnels réussis » doit identifier les résultats consignés.

Lorsque l’incident exige un travail supplémentaire de sécurité ou de PKI, nommez la tâche non résolue et son responsable. Ne laissez pas un contrôle de réplication réussi devenir implicitement l’approbation de tout ce qui dépasse son périmètre.

Comment EtcSec détecte ces signaux

Le collecteur fournit trois contrôles actifs pertinents pour ce sujet. Ils identifient des signaux de configuration ou de revue ; ils ne prouvent pas que la forêt est restaurable.

Contrôle actif	Prédicat réel	Limite
`HDS_5_8_DR_PLAN_MISSING`	Moins de 2 DC inventoriés produit Count 1	Heuristique fondée sur le nombre de DC. Elle ne lit aucune procédure, sauvegarde ni compte rendu d’exercice. Deux DC colocalisés sans plan peuvent passer ; un déploiement à un seul DC bien planifié peut échouer.
`DC_BACKUP_OLD`	L’absence de `DomainInfo` ou de `LastADBackupDate` produit Count 1 ; sinon, plus de 60 jours entiers produit Count 1	Le fournisseur remplit le champ avec le maximum de `whenChanged` parmi les objets `nTDSDSA`. C’est un indicateur indirect de métadonnées NTDS au niveau de la collecte, pas l’âge des sauvegardes par DC. Des changements de topologie peuvent le faire paraître récent. Exactement 60 jours entiers ne déclenchent pas le contrôle.
`RECYCLE_BIN_DISABLED`	`RecycleBinEnabled=false` produit Count 1 ; true produit Count 0	Sans `DomainInfo`, le résultat est inconnu avec Count 0. Cela ne prouve pas que la fonctionnalité est activée.

L’identifiant HDS n’établit pas une exigence HDS numérotée précise et ne prouve pas qu’un plan de reprise manque. Utilisez-le pour déclencher une revue humaine de la topologie et de la planification de reprise.

BACKUP_AD_NOT_VERIFIED n’est pas mesuré par le collecteur. Son détecteur retiré ne renvoie aucun résultat et n’est pas enregistré. Il est exclu des tags de vulnérabilité de cet article. La vérification de restauration exige des preuves opérationnelles extérieures à ces contrôles d’annuaire.