Gestion des conflits de réplication Active Directory après une restauration de contrôleur de domaine

Introduction

Restaurer un contrôleur de domaine (Domain Controller, DC) à une date antérieure sans préparation adéquate peut entraîner des conflits majeurs dans Active Directory (AD). Ces problèmes se manifestent par des interruptions de réplication, des erreurs de synchronisation, et des dysfonctionnements des services AD.

Scénario : Restauration d’une VM contenant un DC

Supposons qu’un DC, nommé DC4, ait été restauré depuis une sauvegarde de VM. Sa base de données AD est désormais obsolète, et ses Update Sequence Numbers (USN) sont en désaccord avec ceux des autres DC. Ce problème, connu sous le nom de USN rollback, provoque des erreurs de réplication.

+---------------+             +---------------+             +---------------+
|   DC1 (PDC)  | <=========> |   DC2 (RID)  | <=========> |   DC3         |
+---------------+             +---------------+             +---------------+
       ^                                                               ^
       |                                                               |
       |                      +---------------+                       |
       +----------------------|  DC4 (Restauré) |<-----------------------+
                              +---------------+

- DC4 restauré provoque des conflits avec DC1 (PDC) et DC2 (RID).
- La réplication AD est interrompue.

Dans cet article, nous allons expliquer les causes, les impacts et fournir des étapes détaillées pour résoudre ce problème.

Les causes des conflits

  1. USN rollback : Chaque DC utilise un numéro de séquence (USN) pour suivre les modifications AD. Lorsqu’un DC est restauré avec un USN inférieur, les autres DC rejettent ses modifications.
  2. Conflits de rôles FSMO : Si le DC restauré détient un rôle critique (comme le RID Master ou le PDC Emulator), cela peut perturber la gestion des modifications AD.
  3. Données incohérentes dans SYSVOL : SYSVOL contient les scripts de connexion et les objets de stratégie de groupe (GPO). Une désynchronisation peut empêcher la bonne application des GPO.

Impacts sur l’infrastructure

  • Arrêt de la réplication AD : Les modifications AD cessent d’être propagées.
  • Problèmes d’authentification : Les utilisateurs ne peuvent plus s’authentifier.
  • Corruption des données AD : Les objets obsolètes ou incohérents perturbent les autres DC.

Types de restauration Active Directory

Restauration non autoritative

Lors d’une restauration non autoritative, le DC restauré force une synchronisation avec les autres DC pour obtenir des données mises à jour. Ses données locales sont marquées comme obsolètes.

  • Recommandée : Utilisée dans les cas où d’autres DC sont intacts.
  • Appropriée ici : Permet d’éviter de propager des données obsolètes.

Restauration autoritative

Une restauration autoritative force le DC restauré à devenir la source principale, même si ses données sont obsolètes.

  • Rarement recommandée : Risque élevé de propagation de données incorrectes.
  • Usage spécifique : Utile uniquement pour restaurer des objets AD spécifiques supprimés par erreur.

Étapes de résolution

Identifier le problème

Connectez-vous à un DC sain (par exemple, DC1) et exécutez les commandes suivantes pour analyser l’état de l’AD :

netdom query fsmo
repadmin /showrepl
repadmin /replsummary
dcdiag /e /c /v /f:dcdiag_report.txt

Recherchez les erreurs associées, telles que :

  • USN rollback : Vérifiez les journaux d’événements AD (IDs 2042, 1084).
  • Objets persistants non synchronisés (lingering objects).

Isoler le DC restauré

Pour empêcher la propagation des conflits, déconnectez temporairement DC4 du réseau en désactivant son interface réseau.

Gestion des rôles FSMO

Si DC4 détient des rôles FSMO, transférez ou saisissez ces rôles sur un DC sain. Prenons un exemple concret où :

  • Nom_Rôle = PDC Emulator (rôle détenu par le DC restauré).
  • Nom_DC_Cible = DC1 (un contrôleur de domaine sain dans le même site).

Transférer un rôle FSMO (si DC4 est toujours accessible)

Si DC4 est toujours fonctionnel mais doit céder ses rôles.

Lister les rôles FSMO actuels (sur DC1) :

netdom query fsmo

Transférez le rôle FSMO PDC Emulator vers DC1 (si DC4 est toujours accessible) :

ntdsutil
roles
connections
connect to server DC1
quit
transfer PDC

Saisir un rôle FSMO (si DC4 est hors ligne ou inutilisable)

En cas de panne de DC4, saisissez les rôles FSMO (commandes à exécuter sur DC1) :

ntdsutil
roles
connections
connect to server DC1
quit
seize PDC

Validez le transfert des rôles (exécuté sur DC1) :

netdom query fsmo

Nettoyer les métadonnées de l’AD

Si DC4 ne peut pas être récupéré, supprimez ses métadonnées de l’annuaire Active Directory depuis un contrôleur de domaine sain (exemple : DC1) :

ntdsutil
metadata cleanup
remove selected server DC4

Restauration non autoritative de DC4

Si vous décidez de conserver DC4, effectuez une restauration non autoritative. Ces actions doivent être effectuées sur DC4.

  • Redémarrez DC4 en mode restauration des services d’annuaire (DSRM).
  • Lancez une restauration non autoritative : 
ntdsutil "activate instance ntds" "authoritative restore" quit
  • Redémarrez les services AD :
net start ntds

Synchroniser les réplicas et corriger les lingering objects

Après avoir réintégré DC4, forcez une synchronisation globale depuis un contrôleur de domaine sain (exemple : DC1).

Forcer une synchronisation globale

Sur un DC sain :

repadmin /syncall /AdeP

Si des lingering objects sont détectés, identifiez-les et supprimez-les depuis DC1.

Identifier et supprimer les lingering objects

repadmin /removelingeringobjects <GUID_DC4> <NomDuSite> /ADVISORY_MODE

Supprimez-les sans /ADVISORY_MODE : 

repadmin /removelingeringobjects <GUID_DC4> <NomDuSite>

Resynchroniser SYSVOL

Si le dossier SYSVOL est désynchronisé, procédez à une resynchronisation. Les actions suivantes doivent être exécutées sur DC4.

Non autoritative

Sur DC4 :

  • Modifiez la clé de registre suivante pour forcer une resynchronisation non autoritative :
Set-ItemProperty -Path "HKLM:\\System\\CurrentControlSet\\Services\\NtFrs\\Parameters\\Backup/Restore\\Process at Startup" -Name "BurFlags" -Value 2
  • Redémarrez le service DFSR ou NTFRS :
net stop ntfrs
net start ntfrs

Autoritative

Si nécessaire, forcez DC4 à être la source principale :

Set-ItemProperty -Path "HKLM:\\System\\CurrentControlSet\\Services\\NtFrs\\Parameters\\Backup/Restore\\Process at Startup" -Name "BurFlags" -Value 4

Redémarrez le service :

net stop ntfrs
net start ntfrs

Validation et suivi

Pour confirmer que tout est opérationnel, exécutez ces commandes sur un contrôleur de domaine sain (exemple : DC1) :

  • Vérifiez la réplication AD :
repadmin /replsummary
  • Exécutez un diagnostic complet :
dcdiag /e /c /v
  • Surveillez les journaux d’événements pour détecter toute erreur persistante.

Prévention future

  • Éteindre proprement les DC : Avant toute restauration, assurez-vous que le contrôleur de domaine est arrêté correctement pour éviter les incohérences. Utilisez les commandes ou interfaces prévues par Microsoft pour effectuer cet arrêt.
  • Sauvegardes compatibles AD : Utilisez des outils gérant les métadonnées AD correctement (Windows Server Backup, Veeam, etc.), afin de garantir une récupération sans conflits.
  • Surveillance proactive : Implémentez des outils comme Azure AD Connect Health pour suivre la santé de l’AD.
  • Environnements de test : Validez les modifications d’infrastructure sur un environnement de staging avant de les appliquer en production.

Conclusion

Restaurer un contrôleur de domaine nécessite une planification minutieuse pour éviter les conflits de réplication. En suivant ces étapes et en adoptant de bonnes pratiques, telles que l’utilisation de sauvegardes compatibles AD et des validations sur un environnement de test, vous pouvez garantir la stabilité de votre infrastructure.

Étiquettes

Publications similaires