Restauration d'un contrôleur de domaine par point de contrôle Hyper-V

Ce que révèlent les événements. Un contrôleur de domaine ne se restaure pas comme un serveur de fichiers. La réplication AD s'appuie sur un numéro de séquence de mise à jour (USN) croissant, un invocationID et un vecteur de mise à jour. En restaurant DC02 à l'état du 7 mars, on remet ses USN en arrière : DC01 et les autres partenaires ont déjà vu des USN supérieurs et considèrent que DC02 n'a rien de neuf à proposer, tandis que DC02 se croit en avance. Windows détecte cette incohérence, place le contrôleur en quarantaine (événement 2095, réplication bloquée) et signale l'échec de réplication en 13508. Le partage SYSVOL n'est plus publié car l'état restauré de SYSVOL ne correspond plus à celui du domaine : les stratégies de groupe et les scripts d'ouverture ne sont plus servis, ce qui explique le blocage des ouvertures de session sur le site secondaire.

Pourquoi le point de contrôle Hyper-V est proscrit. La restauration d'une VM hébergeant AD DS n'est prise en charge que si l'hyperviseur et l'intégration invitée gèrent le changement d'invocationID (support des identifiants de génération) et si la restauration intervient dans la durée de vie des objets supprimés. Un point de contrôle classique restauré cinq jours plus tard sort de ce cadre. S'y ajoute un risque de sécurité : les mots de passe réinitialisés et les comptes désactivés entre le 7 et le 12 mars réapparaissent, et des objets supprimés peuvent être ressuscités par réplication.

Conclusion : DC02 n'est pas réparable par une commande ; il doit être démissionné de force puis reconstruit. Il faut aussi vérifier que DC01 n'a pas hérité d'objets obsolètes et que la corbeille AD n'a pas été sollicitée.

Séquence de remise en service :

1. Isoler DC02 en déconnectant sa carte réseau virtuelle. Tant qu'il est en ligne, il peut répondre aux requêtes des clients du site secondaire avec un annuaire obsolète et authentifier des comptes ou des mots de passe révoqués.
2. Constater et archiver : repadmin /showrepl, événements 2095, 13508 et 8614, dcdiag /v, export des journaux. Ces éléments serviront au diagnostic et à l'analyse post-incident.
3. Démission forcée : Uninstall-ADDSDomainController -ForceRemoval (ou dcpromo /forceremoval). Le serveur redevient membre du domaine sans propager sa base.
4. Nettoyage des métadonnées sur DC01 avec ntdsutil : supprimer l'objet serveur, son objet de configuration, les enregistrements DNS associés, et vérifier dans Sites et services qu'aucun lien de réplication orphelin ne subsiste. Contrôler avec repadmin /replsummary et dcdiag /test:dns que DC01 est seul et sain.
5. Promouvoir à nouveau DC02 en contrôleur supplémentaire du même domaine, laisser la réplication initiale s'achever, puis vérifier repadmin /showrepl, les partages SYSVOL et NETLOGON, dcdiag /v, et nltest /dsregdns pour l'enregistrement DNS dynamique.
6. Valider côté client : ouverture de session sur un poste du site secondaire, résolution de l'enregistrement SRV _ldap._tcp, puis gpupdate /force.

L'indisponibilité du site secondaire est de l'ordre de deux à quatre heures ; c'est le prix d'un annuaire sain. Si DC02 portait des rôles FSMO ou était l'unique serveur DNS du site, la séquence doit être adaptée avant l'étape 3 (transfert des rôles et de la zone).

Sauvegarde et restauration.

• Sauvegarder l'état du système des deux DC (et non la VM entière) avec Windows Server Backup ou un outil prenant en charge AD, vers un support situé hors du cluster Hyper-V. Une restauration d'état système reste cohérente du point de vue de l'AD, l'invocationID étant modifié par la restauration.
• Tester la restauration au moins deux fois par an, dans un réseau isolé, avec un test d'ouverture de session et d'application des GPO. Une sauvegarde non testée ne compte pas.
• Ne jamais conserver de point de contrôle d'un DC au-delà de quelques heures, et uniquement avec le support des identifiants de génération activé ; inscrire cette règle dans la procédure Hyper-V.

Surveillance.

• Alerter sur les événements 13508, 13568, 1988 et 2095, ainsi que sur les codes 8614 et 8456 de repadmin, avec un contrôle quotidien de repadmin /replsummary.
• Surveiller l'âge du plus ancien objet supprimé (tombstone lifetime) : une restauration au-delà est interdite, ce qui rend inutile de conserver des sauvegardes très anciennes.
• Contrôler w32tm /monitor : DC01 détient le rôle PDC emulator et doit pointer vers une source NTP fiable ; un décalage supérieur à cinq minutes casse Kerberos.

Architecture.

• Un seul DC détenant les cinq rôles est un point de fragilité : le second DC doit être placé sur un hôte Hyper-V distinct et, si possible, dans une autre salle. Répartir les rôles FSMO entre DC01 et DC02 et supprimer les dépendances qui font de DC02 le seul serveur DNS du site secondaire.