Restauration et récupération d'un contrôleur de domaine local corrompu

Lorsqu'un contrôleur de domaine est corrompu ou restauré incorrectement, la crainte est énorme : Les connexions échouent, les GPO cessent de s'appliquer et la réplication s'interrompt presque sans aucun indice.La bonne nouvelle est qu'il existe des procédures claires pour récupérer un contrôleur de domaine physique ou virtuel, à condition que les méthodes de sauvegarde et de restauration acceptées soient respectées.

Dans les environnements Windows Server modernes, la restauration d'un contrôleur de domaine nécessite une bonne compréhension de concepts tels que : État du système, restauration faisant autorité/non faisant autorité, annulations SYSVOL, DFSR/FRS et USNSi ces problèmes sont abordés à la hâte ou avec des outils d'imagerie incompatibles, il peut en résulter une multitude d'incohérences silencieuses très difficiles à diagnostiquer.

Pourquoi il est essentiel de protéger et de restaurer correctement un contrôleur de domaine

Active Directory est au cœur de l'authentification et de l'autorisation dans un domaine Windows.Il stocke les utilisateurs, les ordinateurs, les groupes, les relations d'approbation, les stratégies de groupe, les certificats et d'autres éléments critiques. Ces informations résident principalement dans la base de données. Ntds.dit, les fichiers journaux et le dossier associés VOLSYS, parmi d’autres composantes qui constituent ce qu’on appelle « l’état du système ».

L'état du système comprend, entre autres, Les fichiers journaux et les données d'Active Directory, le Registre Windows, le volume système SYSVOL, la base de données de certificats (si une autorité de certification existe), la métabase IIS, les fichiers de démarrage et les composants protégés du système d'exploitationPar conséquent, toute stratégie sérieuse de continuité d'activité doit inclure des sauvegardes régulières de l'état du système de chaque centre de données.

En cas de corruption effective de la base de données Active Directory, d'échec grave de réplication ou de problème avec autorisations sur VOLSYSLe contrôleur de domaine peut cesser de traiter les requêtes, ne pas parvenir à démarrer les services Active Directory ou déclencher des erreurs en cascade dans toute la forêt. Dans ces cas, Un rétablissement rapide et approprié fait toute la différence entre un incident grave et une catastrophe prolongée..

Avant de tenter une restauration, il est crucial de faire la distinction entre un véritable problème de base de données et des pannes plus courantes. Très souvent, La cause réside dans le DNS, les modifications du réseau, les pare-feu ou les routes modifiées avec des outils tels que commande netshIl est donc conseillé d'éliminer ces facteurs avant de toucher à la base de données AD.

Outils de diagnostic et de contrôle de réplication de base

En cas de symptômes de corruption ou d'échecs de réplication, la première étape logique consiste à vérifier l'état de l'environnement à l'aide des outils natifs. DCDiag, Repadmin, ReplMon (dans les versions plus anciennes) et l'Observateur d'événements Ce sont vos meilleurs alliés avant d'envisager des restaurations radicales.

Avec DCDiag Une vérification générale de tous les contrôleurs de domaine est effectuée, permettant d'identifier les problèmes liés à la réplication, au DNS, aux services AD DS, etc. Administrateur de compte Il vous permet de visualiser l'état de la réplication, les partenaires de réplication, les filigranes USN et de détecter les objets persistants. Dans les anciennes versions de Windows, ReplMon Il offrait une représentation graphique des erreurs de réplication au sein du domaine.

En plus de ces outils, il est essentiel de consulter l'Observateur d'événements pour les événements « Services d'annuaire » et « Réplication DFS ». Des événements comme 467 et 1018 indiquent une corruption réelle de la base de données., tandis que les événements 1113/1115/1114/1116 concernent l’activation ou la désactivation de la réplication d’entrée/sortie.

Si un centre de distribution suspecté doit être temporairement isolé pour l'empêcher de propager la corruption, nous pouvons Désactivez la réplication entrante et sortante avec Repadmin:

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

Pour rétablir la réplication normale, il suffit de supprimer ces options :

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

Sauvegardes de l'état du système prises en charge sur les contrôleurs de domaine

Pour pouvoir récupérer un contrôleur de domaine avec des garanties, il est essentiel de disposer de Sauvegardes de l'état du système effectuées à l'aide d'outils compatibles avec Active DirectoryCes outils utilisent les API de sauvegarde et de restauration de Microsoft et le service de cliché instantané des volumes (VSS) de manière prise en charge.

Parmi les solutions les plus courantes, on trouve Sauvegarde Windows Server, solutions tierces intégrées à VSS (telles que NAKIVO, Backup Exec et autres)ou des services publics plus anciens tels que Ntbackup sous Windows 2000/2003. Dans tous les cas, ils doivent respecter les API AD afin de garantir la cohérence de la base de données et de ses répliques après restauration.

Windows Server 2012 et les versions ultérieures intègrent une nouveauté importante : ID de génération Hyper-V (GenID)Cet identifiant permet à un contrôleur de domaine virtuel de détecter que son disque a été restauré à un point antérieur dans le temps. Lorsque cela se produit, AD DS génère un nouvel ID d'invocation et traite la situation comme si elle avait été restaurée à partir d'une sauvegarde réussie.notifiant ses partenaires de réplication, permettant ainsi une réécriture sécurisée sans provoquer de restauration USN.

Il est essentiel de respecter le pierre tombale à vieCela indique la durée de conservation d'une sauvegarde de l'état du système sans risque de réintroduction d'objets supprimés depuis longtemps. Cette durée est généralement de 180 jours dans les versions récentes, et il est recommandé d'effectuer des sauvegardes au moins tous les 90 jours afin de maintenir une marge de sécurité suffisante.

Méthodes non autorisées provoquant des inversions USN

L'une des causes les plus dangereuses d'incohérences silencieuses dans Active Directory est… USN restreintCette situation se produit lorsque le contenu de la base de données AD est restauré à l'aide d'une technique non prise en charge, sans que l'ID d'invocation soit restauré ni que les partenaires de réplication soient avertis.

Le scénario typique consiste à démarrer un contrôleur de domaine à partir d'un image disque ou un instantané de machine virtuelle pris dans le passésans utiliser une restauration système compatible. Vous pouvez aussi copier directement le fichier Ntds.dit, utiliser des logiciels d'imagerie comme Ghost, démarrer à partir d'un miroir de disque défectueux ou réappliquer un instantané de stockage au niveau de la baie.

Dans ces cas, le contrôleur de domaine continue d'utiliser le même ID d'invocation qu'auparavant, mais son Le compteur local de l'USN reculeLes autres centres de données se souviennent avoir reçu des modifications jusqu'à un numéro USN élevé, donc lorsque le centre de données rétabli tente de renvoyer des numéros USN déjà reconnus, Leurs partenaires estiment qu'ils sont au courant des dernières évolutions et cessent d'accepter des changements concrets..

Il en résulte que certaines modifications (par exemple, Création d'utilisateurs, modification de mots de passe, enregistrement d'appareils, modification d'appartenance à des groupes, nouveaux enregistrements DNSCes erreurs ne sont jamais répliquées du centre de données restauré au reste du réseau, mais les outils de surveillance peuvent ne pas les détecter clairement. Il s'agit d'une panne silencieuse extrêmement dangereuse.

Pour détecter ces situations, les pilotes Windows Server 2003 SP1 et versions ultérieures consignent les informations. Événement 2095 des services d'annuaire Lorsqu'un contrôleur de domaine distant est détecté en train d'envoyer des USN déjà acquittés sans modification de l'ID d'invocation, le système Il met en quarantaine le contrôleur de domaine concerné, suspend Netlogon et empêche toute modification ultérieure. qui n'a pas pu être reproduit correctement.

En tant que preuve médico-légale supplémentaire, cela peut à consulter dans le Registre la clé HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Paramètres et la valeur Dsa non modifiableSi cette valeur est définie (par exemple, 0x4), cela indique que le DC a été mis dans un état d'écriture par détection d'inversion USN. La modification manuelle de cette valeur pour la « corriger » n'est absolument pas prise en charge. et laisse la base de données dans un état incohérent permanent.

Stratégies générales en cas de corruption ou de restauration d'un contrôleur de domaine

La procédure à suivre en cas de contrôleur de domaine corrompu ou mal restauré dépend de plusieurs facteurs : Nombre de contrôleurs de domaine dans le domaine/la forêt, disponibilité de copies valides de l'état du système, présence d'autres rôles (FSMO, CA, catalogue global) et étendue temporelle du problème.

S'il existe d'autres DC sains dans le domaine et Il n'existe aucune donnée critique unique sur le contrôleur de domaine endommagé.L'option la plus rapide et la plus simple consiste généralement à supprimer le contrôleur de domaine et à le recréer. Toutefois, s'il s'agit du seul contrôleur de domaine, ou s'il héberge des rôles et des données sensibles, une restauration plus minutieuse (autoritaire ou non) sera nécessaire.

De manière générale, les options sont les suivantes :

• Rétrogradez de force le contrôleur de domaine corrompu et supprimez-le du domaine., suivi du nettoyage des métadonnées et, le cas échéant, d'une nouvelle promotion.
• Restauration à partir d'une sauvegarde système valide, que ce soit en mode autoritaire ou non autoritaire.
• Reconstruisez le contrôleur de domaine à partir d'un autre en utilisant IFM (Installation à partir d'un support)., lorsqu'il n'y a pas de copie récente mais qu'il existe d'autres contrôleurs de domaine corrects.
• Utilisation d'un instantané VHD d'un DC virtuel, en appliquant les étapes supplémentaires pour marquer la base de données comme restaurée à partir d'une sauvegarde (Base de données restaurée à partir d'une sauvegarde = 1) et en s'assurant qu'un nouvel InvocationID est généré.

Si une restauration USN est clairement suspectée (par exemple, après la restauration d'une machine virtuelle à partir d'un instantané sans suivre les bonnes pratiques) et que l'événement 2095 apparaît, la solution la plus judicieuse consiste généralement à Retirez ce contrôleur de domaine du service et n'essayez pas de le « réparer » sur place., à moins qu'il ne soit possible de revenir à une sauvegarde de l'état du système pris en charge effectuée avant la restauration.

Rétrogradation forcée et nettoyage des métadonnées

Lorsqu'un contrôleur de domaine est tellement endommagé qu'il ne peut pas être rétrogradé normalement, ou qu'il a été restauré incorrectement et que vous souhaitez éviter qu'il ne propage des problèmes, vous pouvez recourir à une rétrogradation forcée.

Dans les versions précédentes, cette opération était effectuée avec dcpromo /forceremoval, Qui Supprimez le rôle AD DS sans tenter de répliquer les modifications au reste de la forêt.Dans les environnements modernes, l'assistant a changé, mais le concept reste le même : supprimer le contrôleur de domaine problématique de la topologie AD sans qu'il participe à la réplication ultérieure.

Après une rétrogradation forcée, il est impératif d'exécuter une commande depuis un contrôleur de domaine sain. nettoyage des métadonnées en utilisant l'outil NtdsutilCe processus supprime toutes les références au contrôleur de domaine supprimé (objets Paramètres NTDS, références DNS, etc.) de la base de données Active Directory, de sorte que Il ne reste aucun vestige « fantôme » susceptible de perturber la réplication.

Si le contrôleur dégradé possédait des rôles FSMO (émulateur PDC, maître RID, maître de schéma, etc.), il sera nécessaire de transférer ou s'emparer de ces rôles Il est possible de déplacer le serveur vers un autre contrôleur de domaine avant ou après la rétrogradation, selon la situation. Le système d'exploitation pourra ensuite être réinstallé sur ce serveur, qui pourra alors être promu à nouveau en tant que contrôleur de domaine opérationnel.

Restauration non autorisée vs restauration autorisée dans Active Directory

Lorsqu'une copie valide de l'état du système est disponible, la récupération d'AD peut être effectuée de deux manières : non autoritaire et autoritaireComprendre cette différence est essentiel pour ne pas passer à côté de changements récents ou pour ne pas reproduire des données obsolètes.

Dans une restauration non autoriséeLe contrôleur de domaine est ramené à un point antérieur, mais une fois qu'il démarre, Les autres contrôleurs de domaine sont considérés comme la référence.Autrement dit, après le démarrage, le contrôleur de domaine restauré demande une réplication entrante et met à jour sa base de données avec les modifications manquantes provenant des autres contrôleurs de domaine. Cette option est idéale lorsque Il existe d'autres contrôleurs fonctionnels, et nous voulons que celui qui a été restauré les rattrape..

Dans une restauration autoritaireToutefois, il est explicitement indiqué que Ce sont les données restaurées qui doivent prévaloir. par rapport aux autres contrôleurs de domaine. Cela signifie qu'après la restauration, les objets récupérés auront un numéro de version plus élevé afin de forcer leur réplication depuis ce contrôleur de domaine vers le reste du domaine. C'est le choix approprié lorsque Nous avons supprimé accidentellement des objets ou des unités d'organisation, ou nous souhaitons rétablir le contenu de SYSVOL et de GPO à un état antérieur et le répliquer..

Un détail important est que la restauration faisant autorité ne concerne pas nécessairement l'intégralité de la base de données. Avec l'utilitaire Ntdsutil Des objets individuels, des sous-arbres (par exemple, une unité organisationnelle) ou le domaine entier peuvent être désignés comme faisant autorité. Cela offre une flexibilité considérable pour, par exemple, Récupérer uniquement un utilisateur, un groupe, une unité d'organisation ou le sous-arbre dc=mycompany,dc=local.

Procédure générale de restauration de l'état du système dans un DC

Le schéma de base pour restaurer l'état système d'un centre de données (physique ou virtuel) avec des outils compatibles est toujours similaire : Démarrez en mode de restauration des services d'annuaire (DSRM), restaurez à l'aide de l'outil de sauvegarde, puis redémarrez..

En résumé, les étapes typiques pour un contrôleur de domaine virtuel seraient les suivantes :

1. Démarrez la machine virtuelle dans le Gestionnaire de démarrage Windows (Généralement en appuyant sur F5/F8 au démarrage). Si la machine virtuelle est gérée par un hyperviseur, il peut être nécessaire de la mettre en pause pour enregistrer la frappe.
2. Dans les options de démarrage avancées, sélectionnez Mode de restauration des services d'annuaire (Mode de restauration des services d'annuaire). Ce mode démarre le serveur sans monter la base de données Active Directory de manière fonctionnelle.
3. Connectez-vous avec le compte administrateur DSRM défini lors de la promotion initiale du contrôleur de domaine (et non avec un compte d'administrateur de domaine standard).
4. Exécutez l'outil de sauvegarde utilisé (Sauvegarde Windows Server, NAKIVO ou autre compatible) et choisissez de restaurer l'état du système au point de sauvegarde souhaité.
5. Terminez l'assistant de restauration et Redémarrez le DC en mode normalLors d'une restauration non autoritaire, le serveur lancera une réplication pour rattraper les autres contrôleurs de domaine.

Lorsque nous parlons de produits de sauvegarde tiers, tels que Sauvegarde et réplication NAKIVOSon mode « compatible avec les applications » est capable de reconnaître que la machine en cours de récupération est un contrôleur de domaine et Ajustement automatique du processus pour préserver la cohérence ADDans la plupart des scénarios comportant plusieurs contrôleurs, une récupération complète en mode non autoritaire est suffisante.

Restauration faisant autorité avec Ntdsutil

Si vous souhaitez que les modifications apportées au contrôleur de domaine restauré prévalent sur les autres, vous devez ajouter une étape supplémentaire après la restauration non autoritaire : Utilisez Ntdsutil pour marquer les objets comme faisant autorité..

Le flux simplifié serait le suivant :

1. Restaurez l'état du système de manière standard et laissez le serveur en état de marche. Mode DSRM (Ne redémarrez pas encore en mode normal).
2. l'ouverture d'une invite de commandes avec privilèges élevés et courir ntdsutil.
3. Activez l'instance AD ​​avec activer l'instance ntds.
4. Entrer dans le contexte de la restauration faisant autorité avec restauration autorisée.
5. Utilisez des commandes comme restore object <DN_objeto> o restore subtree <DN_subarbol>, où DN est le nom distinctif de l'objet ou du sous-arbre à restaurer de manière faisant autorité.
6. Confirmez la transaction et, une fois terminée, Redémarrez le DC en mode normal afin que les objets marqués soient répliqués en priorité par rapport au reste du domaine.

Ce type de restauration exige une grande prudence. Si l'intégralité du domaine est restaurée de manière faisant autorité et que la sauvegarde est ancienneIl existe un risque de perte des modifications légitimes effectuées après la sauvegarde (par exemple, la création d'utilisateurs, la modification de mots de passe ou de groupes). C'est pourquoi il est courant de limiter les restaurations faisant autorité aux seuls objets ou arborescences strictement nécessaires.

Restauration et récupération du SYSVOL (FRS vs DFSR)

SYSVOL est un composant clé du contrôleur de domaine : Il stocke les scripts de démarrage, les stratégies de groupe, les modèles de sécurité et d'autres ressources partagées essentielles.Un problème d'autorisation, une corruption de fichiers ou des problèmes de réplication peuvent rendre les GPO inutilisables ou provoquer un comportement erratique chez les clients.

Selon la version de Windows Server et l'état de la migration, SYSVOL peut être répliqué par FRS (Service de réplication de fichiers) pourquoi DFSR (Réplication du système de fichiers distribué)La procédure de restauration complète de SYSVOL varie selon celui des deux systèmes utilisés.

Pour le déterminer, vous pouvez consulter la clé dans le Registre. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalStateSi cette sous-clé existe et que sa valeur est 3 (SUPPRIMÉ), DFSR est utilisé. Si elle n'existe pas ou si sa valeur est différente, l'environnement utilise encore FRS.

Dans les environnements avec FRS, la récupération faisant autorité de SYSVOL implique généralement l'ajustement de la valeur Drapeaux de Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process à une valeur spécifique (par exemple, 212 décimal / 0xD4 hexadécimal) pour indiquer que ce DC est la source faisant autorité.

Si SYSVOL est répliqué par DFSR, le processus est un peu plus complexe : il implique l’utilisation de ADSIEdit modifier les objets d'abonnement SYSVOL (attributs) msDFSR activé y Options msDFSR) sur le contrôleur de domaine faisant autorité et sur les autres, forcer la réplication Active Directory, exécuter dfsrdiag pollad et confirmer dans le journal des événements l'apparition de événements 4114, 4602, 4614 et 4604 qui certifient que SYSVOL a été initialisé et répliqué correctement.

Récupération des contrôleurs de domaine virtuels à partir d'un disque dur virtuel

Dans les environnements virtualisés, il est très courant d'avoir Fichiers VHD/VHDX des contrôleurs de domaineSi vous ne disposez pas d'une sauvegarde de l'état du système mais que vous avez un VHD « ancien » fonctionnel, vous pouvez monter un nouveau contrôleur de domaine à partir de ce disque, en procédant toutefois avec la plus grande prudence afin d'éviter une restauration USN.

La recommandation est Ne démarrez pas directement cette machine virtuelle en mode normal.Vous devriez plutôt démarrer à partir du VHD précédent dans DSRMOuvrez l'Éditeur du Registre et accédez à HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersLà, il est conseillé de vérifier la valeur Nombre de restaurations DSA précédentes (si elle existe) et, surtout, créez une nouvelle valeur DWORD (32 bits) appelée Base de données restaurée à partir d'une sauvegarde avec la valeur 1.

En sélectionnant cette valeur, Active Directory est informé que la base de données a été restaurée à partir d'une sauvegarde, ce qui force génération d'un nouvel InvocationID lors du démarrage en mode normalDe cette manière, les autres contrôleurs de domaine l'interprètent comme une nouvelle instance et ajustent correctement leurs marques de réplication, empêchant ainsi la restauration de l'USN.

Après avoir redémarré le contrôleur de domaine en mode normal, il est conseillé de consulter l'Observateur d'événements, et plus particulièrement le journal des événements. services d'annuaire, à la recherche du événement 1109Cet événement confirme que l'attribut InvocationID du serveur a été modifié et affiche les anciennes et nouvelles valeurs, ainsi que le numéro USN le plus élevé au moment de la sauvegarde. De plus, la valeur de Nombre de restaurations DSA précédentes Il aurait fallu l'augmenter de un.

Si ces événements n'apparaissent pas ou si le nombre n'augmente pas, vous devez vérifier les versions du système d'exploitation et les Service Packs, car Certains comportements de restauration dépendent de patchs spécifiques.Dans tous les cas, il est toujours conseillé de travailler sur une copie du disque dur virtuel original, en conservant une version intacte au cas où le processus devrait être répété.

Scénarios pratiques et recommandations supplémentaires

En pratique, les problèmes de corruption ou de restaurations inadéquates apparaissent souvent dans des situations quotidiennes : Modifications manuelles des autorisations dans SYSVOL, tentatives de mise à jour des modèles ADMX/ADML, modifications de GPO non répliquéesetc. Il est relativement facile de provoquer des incohérences si des dossiers partagés sont modifiés manuellement, par exemple : SYSVOL\Policies sans respecter la réplication.

En cas de contrôleur de domaine principal présentant une réplication défaillante (données AD et SYSVOL) et de messages de surveillance du type «La base de données a été restaurée à l'aide d'une procédure non prise en charge. Cause possible : restauration USN”, la chose prudente à faire est :

• Vérifiez avec dcdiag y repadmin l’étendue des erreurs et la présence éventuelle d’« objets persistants ».
• Vérifiez l'événement 2095 et sa valeur. Dsa non modifiable dans le Registre.
• Évaluer si cela est possible Supprimez ce contrôleur de domaine et reconstruisez-le. (S'il y a trois autres DC sains ou plus, c'est généralement la meilleure option).
• S'il s'agit du seul DC ou critique, soulevez un restauration de l'état du système à partir d'une sauvegarde compatible, idéalement récente et datant de la période de suppression.

Dans les domaines comportant plusieurs contrôleurs, il est fortement recommandé que les contrôleurs de domaine soient aussi « purs » que possible : sans rôles supplémentaires ni données d'utilisateur localDe cette manière, si l'un d'eux tombe en panne ou est corrompu, un nouveau peut être formaté et promu à partir d'un autre contrôleur de domaine ou via IFM, ce qui réduit considérablement la complexité de la récupération.

De plus, il convient de rappeler certaines limitations, telles que : Les copies de l'état du système ne sont valides que pendant la période de suppression. (60, 90 ou 180 jours selon la configuration) afin d'éviter la restauration d'objets supprimés, et sachant que les clés machine NTLM changent tous les 7 jours. Dans le cas de restaurations très anciennes, il peut être nécessaire de réinitialiser les comptes d'équipe problèmes liés à « Utilisateurs et ordinateurs Active Directory » ou même à leur suppression et à leur réintégration au domaine.

Mettre en place des procédures de sauvegarde régulière de l'état du système, Documentez clairement les rôles FSMO, le catalogue global et la topologie de réplication.Tester les étapes de restauration en laboratoire est un investissement en temps qui épargne bien des soucis le jour où un contrôleur de domaine est corrompu ou lorsqu'une personne applique un instantané sans réfléchir.