Repadmin : diagnostiquer et réparer la réplication Active Directory

La réplication Active Directory est l'un des mécanismes les plus critiques de l'infrastructure Windows en entreprise. Elle garantit que les modifications apportées à l'annuaire — création de comptes, changements de mots de passe, mise à jour de stratégies de groupe — sont propagées de façon cohérente à tous les contrôleurs de domaine (DC) du réseau, qu'ils se trouvent dans un même site ou dans des agences géographiquement distantes. Lorsque la réplication est défaillante, les conséquences peuvent être graves et multiples : des utilisateurs ne peuvent plus s'authentifier sur certains sites, des changements de mots de passe ne se propagent pas, des groupes de sécurité sont incohérents entre DC, et des GPO ne s'appliquent pas correctement. Dans les scénarios les plus critiques, la divergence prolongée entre DC peut entraîner des conflits d'objets difficiles à résoudre et même compromettre la sécurité du domaine. Repadmin, l'outil en ligne de commande inclus dans Windows Server et les RSAT (Remote Server Administration Tools), est l'instrument de diagnostic principal pour analyser, surveiller et réparer la réplication Active Directory. Ce guide couvre les commandes essentielles de repadmin, l'interprétation de leurs sorties, les erreurs les plus fréquentes et leur résolution, ainsi qu'un scénario de remédiation complet pour vous guider lors d'incidents réels.

Fonctionnement de la réplication Active Directory (sites, site links, topologie KCC)

Avant de diagnostiquer les problèmes, il est essentiel de comprendre comment la réplication fonctionne.

Active Directory organise les DC en sites, qui représentent des portions du réseau à haute connectivité (typiquement un campus ou un datacenter). Au sein d'un même site, la réplication est quasi-immédiate (moins de 15 secondes par défaut) et se produit via une topologie en anneau optimisée. Entre sites, la réplication est planifiée selon des site links configurés dans les Paramètres de Sites et Services Active Directory (dssite.msc).

La topologie de réplication n'est pas définie manuellement mais calculée automatiquement par le KCC (Knowledge Consistency Checker), un processus qui s'exécute sur chaque DC toutes les 15 minutes. Le KCC construit et maintient la topologie de réplication optimale en créant des objets de connexion (Connection Objects) entre DC. Si un DC tombe en panne, le KCC reconfigure la topologie pour maintenir la réplication.

Chaque modification dans l'AD est associée à un Update Sequence Number (USN), un compteur incrémenté localement sur chaque DC. Les DC s'échangent leurs USN pour savoir quelles modifications chacun possède déjà. Un vecteur nommé up-to-dateness vector maintient cette information. La réplication multi-maître signifie que n'importe quel DC peut recevoir des modifications, qui sont ensuite propagées aux autres.

Les partitions répliquées incluent : la partition de domaine (objets du domaine : users, computers, GPO...), la partition de configuration (topologie de la forêt), la partition de schéma (définition des classes/attributs), et les partitions d'application (DNS intégré AD par exemple).

repadmin /showrepl — analyser l'état de réplication de tous les DC

La commande repadmin /showrepl est le point d'entrée principal du diagnostic. Elle affiche l'état des partenaires de réplication entrants de chaque DC.

# État de réplication du DC local
repadmin /showrepl

# État de réplication d'un DC spécifique
repadmin /showrepl dc01.ayinedjimi.fr

# État de tous les DC de la forêt
repadmin /showrepl *

La sortie typique ressemble à :

Replication Summary Start Time: 2026-06-14 09:15:42

Beginning data collection for replication summary, this may take a while:

Source DSA          Largest Delta    Fails/Total %%   Error
DC01                00:05:23              0 / 5      0
DC02                00:12:45              0 / 5      0
DC03                PENDING               1 / 5     20   (1722) The RPC server is unavailable.

Chaque bloc de la sortie représente un partenaire de réplication entrant et indique :

• Largest Delta : délai depuis la dernière réplication réussie. Un delta de plusieurs heures ou jours est anormal.
• Fails/Total : nombre d'échecs sur les N dernières tentatives. Un ratio élevé indique un problème persistant.
• Last Success Time : horodatage de la dernière réplication réussie.
• Last Failure Status : code d'erreur en cas d'échec.

Pour une sortie plus lisible en CSV (exportable dans Excel) :

repadmin /showrepl * /csv > C:\logs\replication-report.csv

repadmin /replsummary — vue synthétique rapide

La commande repadmin /replsummary offre une vue condensée, parfaite pour une vérification rapide de la santé globale de la réplication :

repadmin /replsummary

# Résultat typique (environnement sain)
Replication Summary Start Time: 2026-06-14 09:20:00

Beginning data collection for replication summary, this may take awhile:
.....

Source DSA       Largest Delta  Fails/Total %%   Error
DC01              00:04:15        0 / 10     0
DC02              00:09:30        0 / 10     0

Destination DSA  Largest Delta  Fails/Total %%   Error
DC01              00:04:15        0 / 10     0
DC02              00:09:30        0 / 10     0

Cette commande distingue les "Source DSA" (DC dont vous recevez des données) et les "Destination DSA" (DC vers lesquels vous envoyez des données). Des erreurs uniquement en Source indiquent un problème de connectivité ou de configuration côté source. Des erreurs uniquement en Destination suggèrent un problème sur le DC de destination.

Utilisez repadmin /replsummary /bysrc pour regrouper par source ou /bydest pour regrouper par destination, ce qui facilite l'identification du DC problématique dans les grandes infrastructures.

repadmin /syncall — forcer la réplication immédiate

Après une correction (redémarrage de service, correction de DNS, rétablissement d'une connexion réseau), forcez une réplication immédiate pour accélérer la convergence :

# Forcer la réplication sur tous les partenaires du DC local
repadmin /syncall /AdeP

# Options importantes:
# /A  : Sync toutes les partitions (All)
# /d  : Identifier les DC par DN plutôt que GUID
# /e  : Propager à travers la forêt entière (Enterprise)
# /P  : Pousser les modifications (Push) au lieu de les récupérer
# /q  : Mode silencieux (Quiet) - moins de sortie
# /s  : Sync depuis une source spécifique seulement

# Forcer depuis un DC source spécifique
repadmin /sync dc=ayinedjimi,dc=fr dc01.ayinedjimi.fr dc02.ayinedjimi.fr

La combinaison /syncall /AdeP est la plus agressive et déclenche une réplication complète sur l'ensemble de la forêt. À utiliser avec précaution dans les grandes infrastructures car cela génère du trafic réseau significatif.

Pour vérifier l'état après synchronisation :

repadmin /showrepl /errorsonly

repadmin /showrepl /errorsonly — isoler les erreurs

La commande avec le flag /errorsonly filtre la sortie pour n'afficher que les liens de réplication en erreur, ce qui simplifie grandement l'analyse dans les environnements avec de nombreux DC :

repadmin /showrepl * /errorsonly

# Alternative : repadmin /showrepl avec filtre PowerShell
repadmin /showrepl * | Where-Object { $_ -match "FAIL|Error" }

Vous pouvez combiner avec /csv pour exporter uniquement les erreurs :

repadmin /showrepl * /errorsonly /csv > C:\logs\repl-errors.csv

Cette vue concentrée permet d'identifier rapidement quels DC sont en erreur, sur quelles partitions, et depuis combien de temps. Dans un environnement sain, cette commande ne devrait rien afficher ou afficher uniquement des erreurs transitoires récentes.

Les erreurs de réplication les plus fréquentes (1722 RPC, 1256, 8452, 8606)

La connaissance des codes d'erreur les plus courants permet un diagnostic rapide et ciblé.

Erreur 1722 — "The RPC server is unavailable"

C'est l'erreur la plus fréquente. Elle indique que le DC source ne répond pas aux appels RPC. Causes possibles et résolutions :

# Vérifier la connectivité réseau
Test-NetConnection dc01.ayinedjimi.fr -Port 135

# Vérifier la résolution DNS
Resolve-DnsName dc01.ayinedjimi.fr

# Vérifier les ports RPC dynamiques (49152-65535)
Test-NetConnection dc01.ayinedjimi.fr -Port 49152

# Vérifier que le service RPC est démarré
Get-Service RpcSs,RpcEptMapper | Select Status

Solution : vérifiez le pare-feu Windows et les règles réseau entre sites. Les ports nécessaires pour la réplication AD sont 135 (RPC endpoint mapper), 49152-65535 (RPC dynamique), 389/636 (LDAP/LDAPS), 3268/3269 (GC LDAP), 53 (DNS), 445 (SMB).

Erreur 1256 — "The remote system is not available"

Le DC cible n'est pas joignable du tout. Vérifiez que le serveur est en ligne, que les services Active Directory (NTDS, Netlogon, DNS) sont démarrés, et que les enregistrements DNS SRV sont corrects :

nslookup -type=SRV _ldap._tcp.ayinedjimi.fr
dcdiag /test:DNS /v

Erreur 8452 — "The naming context is in the process of being removed or is not replicated from the specified server"

Cette erreur survient généralement lors de la démission d'un DC ou lorsqu'une partition n'est plus hébergée sur un DC. Vérifiez avec :

repadmin /showrepl dc01.ayinedjimi.fr /showattr
repadmin /viewlist *

Erreur 8606 — "Insufficient attributes were given to create an object"

Souvent lié à des lingering objects (objets persistants obsolètes). Un objet a été supprimé sur un DC mais existe encore dans d'autres DC car la réplication n'a pas fonctionné pendant une durée supérieure à la durée de vie des tombstones (par défaut 180 jours). Voir la section sur les lingering objects ci-dessous.

dcdiag /test:replications — complément diagnostique

L'outil dcdiag complète repadmin avec des tests automatisés sur différents aspects du contrôleur de domaine :

# Test complet de réplication
dcdiag /test:replications

# Test sur tous les DC du domaine
dcdiag /test:replications /e

# Test avec sortie détaillée
dcdiag /test:replications /v

# Tests complémentaires utiles
dcdiag /test:netlogons      # Vérifier le service Netlogon
dcdiag /test:DNS            # Vérifier la configuration DNS
dcdiag /test:Connectivity   # Test de connectivité générale
dcdiag /test:RidManager     # Vérifier le RID pool
dcdiag /test:MachineAccount # Vérifier le compte machine du DC

La sortie de dcdiag indique clairement les tests passés (.) et les tests échoués (FAILED). Chaque test FAILED est accompagné d'un message d'erreur explicatif. Exécutez dcdiag en sortie vers un fichier pour analyse approfondie :

dcdiag /test:replications /e /v /f:C:\logs\dcdiag-report.txt

Métadonnées AD et lingering objects (repadmin /removelingeringobjects)

Les lingering objects sont des objets qui existent sur un DC mais qui ont été supprimés dans le reste de la forêt. Ils apparaissent quand un DC a été hors ligne plus longtemps que la Tombstone Lifetime (TSL), par défaut 180 jours depuis Windows Server 2003 SP1. À son retour, ce DC tente de répliquer des objets qui sont considérés comme "fantômes" par les autres DC.

Pour détecter les lingering objects :

# Scanner les lingering objects sur dc03 par rapport à dc01 (référence)
repadmin /removelingeringobjects dc03.ayinedjimi.fr dc01.ayinedjimi.fr `
  "DC=ayinedjimi,DC=fr" /advisory_mode

# La sortie listera les objets fantômes sans les supprimer (mode advisory)
# Une fois validé, supprimer réellement:
repadmin /removelingeringobjects dc03.ayinedjimi.fr dc01.ayinedjimi.fr `
  "DC=ayinedjimi,DC=fr"

Les métadonnées de réplication permettent d'analyser l'historique des modifications d'un objet spécifique et de détecter des conflits :

# Voir les métadonnées de réplication d'un objet
repadmin /showobjmeta dc01.ayinedjimi.fr "CN=John Doe,CN=Users,DC=ayinedjimi,DC=fr"

# Voir les métadonnées pour tous les DC
repadmin /showobjmeta * "CN=John Doe,CN=Users,DC=ayinedjimi,DC=fr"

Cette commande révèle sur quel DC chaque attribut a été modifié en dernier, et quand. Indispensable pour résoudre des conflits de réplication sur des objets spécifiques.

Netlogon.log et event viewer — traces complémentaires

Le journal Netlogon.log enregistre les activités d'authentification et les communications entre DC. Il est particulièrement utile pour diagnostiquer les problèmes de Kerberos et les refus d'authentification :

# Activer le journal Netlogon verbose (si pas déjà actif)
nltest /dbflag:0x2080ffff

# Localisation du journal
C:\Windows\debug\netlogon.log

# Filtrer les erreurs
Select-String -Path "C:\Windows\debug\netlogon.log" -Pattern "ERROR|FAILED|DENY"

Dans l'Observateur d'événements, les journaux les plus pertinents pour la réplication AD sont :

• Applications and Services Logs → Microsoft → Windows → ActiveDirectory_DomainService : Events 1083, 1085, 1925, 1926, 2087, 2088 concernent directement la réplication
• System : Events Netlogon, Time Service (W32TM — les problèmes de temps peuvent bloquer la réplication Kerberos)
• Security : Events 4771, 4768, 4769 pour les tickets Kerberos

Les Event IDs les plus critiques pour la réplication :

• 1925 : Tentative d'établissement d'un lien de réplication échoué
• 1311 : La topologie de réplication KCC ne peut pas créer d'objet de connexion
• 2087/2088 : Échec de résolution DNS d'un DC partenaire

# Filtrer les events de réplication via PowerShell
Get-EventLog -LogName "Directory Service" -Source "Microsoft-Windows-ActiveDirectory_DomainService" `
  -EntryType Error,Warning -Newest 50 | Select-Object EventID,TimeGenerated,Message | Format-List

Scénario de remédiation complet (exemple réel step-by-step)

Voici un scénario typique : le lundi matin, les utilisateurs du site de Lyon signalent qu'ils ne peuvent pas s'authentifier avec leurs mots de passe récemment changés. Votre outil de monitoring indique des erreurs de réplication sur DC03-LYON.

Étape 1 : Diagnostic initial

# Vue d'ensemble de la réplication
repadmin /replsummary

# Résultat: DC03-LYON affiche 48h de delta et 100% d'échecs avec erreur 1722

Étape 2 : Vérification de la connectivité réseau

# Depuis DC01-PARIS
Test-NetConnection dc03-lyon.ayinedjimi.fr -Port 135
# Résultat: TimeOut - connexion impossible sur le port 135

ping dc03-lyon.ayinedjimi.fr
# Résultat: Succès - ICMP répond

Interprétation : le DC répond au ping (couche réseau OK) mais le port RPC 135 est bloqué. Problème de pare-feu ou de service Windows.

Étape 3 : Vérification sur le DC Lyon

# Sur DC03-LYON en local
Get-Service RemoteRegistry,RpcSs,RpcEptMapper,NTDS,Netlogon | Select Name,Status

# Résultat: RpcEptMapper = Stopped

Étape 4 : Remédiation

# Redémarrer le service RPC Endpoint Mapper
Start-Service RpcEptMapper
Set-Service RpcEptMapper -StartupType Automatic

# Vérifier
Test-NetConnection dc03-lyon.ayinedjimi.fr -Port 135
# Résultat: TcpTestSucceeded: True

Étape 5 : Forcer la réplication et valider

# Forcer la réplication
repadmin /syncall dc03-lyon.ayinedjimi.fr /AdeP

# Vérifier le résultat
repadmin /showrepl dc03-lyon.ayinedjimi.fr /errorsonly
# Résultat: aucune erreur

# Vérifier que les changements de mots de passe sont bien répliqués
repadmin /showobjmeta dc03-lyon.ayinedjimi.fr "CN=User Qui Change Mot De Passe,CN=Users,DC=ayinedjimi,DC=fr"

Étape 6 : Documentation et prévention

Documentez l'incident : cause (RpcEptMapper arrêté suite à une mise à jour Windows dont le redémarrage automatique avait échoué), durée (48h), impact (authentification impossible pour 120 utilisateurs à Lyon), résolution. Mettez en place une alerte monitoring sur l'état du service RpcEptMapper et un seuil d'alerte sur le delta de réplication (> 60 minutes = warning, > 4 heures = critical).

Pour un audit approfondi de votre infrastructure AD, notamment des droits et permissions susceptibles d'affecter la réplication, consultez notre service de pentest Active Directory. Retrouvez également notre article sur les top 10 des attaques Active Directory pour comprendre comment les problèmes de réplication peuvent être exploités par des attaquants.

La documentation Microsoft de dépannage AD DS fournit des arbres de décision détaillés pour chaque code d'erreur repadmin, ainsi que des guides spécifiques pour les environnements multi-sites et multi-forêts. Complétez votre lecture avec le guide de référence Troubleshooting Active Directory Replication Problems pour les scénarios avancés.

Sur le plan préventif, plusieurs bonnes pratiques réduisent considérablement la fréquence des incidents de réplication. Assurez-vous que tous vos DC synchronisent l'heure via la même source NTP fiable — les problèmes de décalage horaire de plus de 5 minutes bloquent l'authentification Kerberos et cascadent en erreurs de réplication. Vérifiez régulièrement la santé DNS : chaque DC doit avoir des enregistrements SRV corrects dans toutes les zones DNS intégrées AD. Maintenez un monitoring de la connectivité réseau entre sites avec des alertes sur les latences et pertes de paquets. Planifiez des tests de réplication trimestriels dans le cadre de vos procédures de maintenance Active Directory, et documentez la topologie complète (sites, site links, DC par site) pour faciliter le diagnostic lors d'incidents.

FAQ — Réplication Active Directory avec repadmin

Quelle est la durée maximale acceptable pour le delta de réplication entre DC d'un même site ?

Au sein d'un même site, la réplication doit normalement converger en moins de 5 minutes. Un delta supérieur à 30 minutes sur un lien intra-site est anormal et mérite investigation. Entre sites, le délai dépend de la planification du site link (par défaut toutes les 180 minutes), mais un delta supérieur à deux fois l'intervalle planifié indique que la réplication a raté plusieurs cycles consécutifs — signe d'un problème persistant. En pratique, configurez vos alertes monitoring sur un seuil de 60 minutes pour les liens intra-site et de 8 heures pour les liens inter-sites, avec escalade progressive.

Peut-on utiliser repadmin sur un poste de travail sans être sur un DC ?

Oui, repadmin.exe est inclus dans les RSAT (Remote Server Administration Tools) disponibles pour Windows 10 et 11. Installez-les via : Paramètres → Applications → Fonctionnalités facultatives → RSAT : Services de domaine Active Directory et outils LDAP. Vous devez ensuite exécuter repadmin avec des credentials d'administrateur de domaine. Presque toutes les commandes repadmin fonctionnent à distance, ce qui évite de devoir se connecter directement sur chaque DC pour diagnostiquer.

Comment savoir si un DC a été hors ligne assez longtemps pour avoir des lingering objects ?

Comparez la durée d'absence du DC avec la Tombstone Lifetime (TSL) de votre forêt. Vérifiez la TSL avec : Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ayinedjimi,DC=fr" -Properties tombstoneLifetime. Si la valeur est 0 ou null, la TSL est celle par défaut (60 jours pour les forêts créées avant 2003 SP1, 180 jours pour les suivantes). Si le DC a été hors ligne plus longtemps que la TSL, exécutez un scan en mode advisory avant de le reconnecter au réseau.

La commande repadmin /syncall provoque-t-elle une charge importante sur le réseau ?

Cela dépend du volume de modifications en attente. Dans un environnement normal avec peu de modifications en attente, la charge est négligeable. Si un DC a été hors ligne plusieurs heures ou jours, la synchronisation forcée peut générer un trafic significatif correspondant à la quantité de modifications accumulées. Dans les grandes infrastructures (>50 DC, >100 000 objets), préférez synchroniser partition par partition et DC par DC plutôt que d'utiliser le flag /e (Enterprise) qui propage à toute la forêt simultanément. Planifiez les synchronisations massives en dehors des heures de pointe.

Repadmin peut-il être utilisé dans des scripts de monitoring automatisé ?

Absolument. L'option /csv de repadmin génère une sortie structurée facilement parsable par PowerShell ou Python. Un script de monitoring typique exécute repadmin /replsummary /bysrc /bydest /csv, parse le CSV, et déclenche des alertes si le nombre d'échecs dépasse un seuil ou si le delta dépasse une durée maximale. Ce script peut être intégré à des outils SIEM comme Wazuh, Elastic, ou Zabbix pour une surveillance continue de la santé de la réplication AD. Des solutions spécialisées comme SolarWinds IP Address Manager ou ManageEngine AD360 incluent des tableaux de bord AD avec surveillance de la réplication préconfigurée.