Depuis le 17 décembre 2024, la réplication Active Directory échoue entre les contrôleurs de domaine ADSVR‑01 (KL‑DC) et ADSVR‑DR. Ce guide explique les causes probables (Kerberos, DNS, RPC, temps) et fournit un plan d’action concret pour restaurer une réplication saine.
Vue d’ensemble du problème
Les commandes repadmin /syncall
et repadmin /showrepl
rapportent en boucle :
- 0x80090322 / 2148074274 — “The target principal name is incorrect” : échec d’authentification Kerberos (SPN erroné/dupliqué ou canal sécurisé rompu).
- 0x000004E8 / 1256 — “The remote system is not available” : indisponibilité réseau ou RPC entre contrôleurs.
Situation constatée : 330 échecs consécutifs au moment des relevés, impactant la cohérence AD entre KL‑DC et DR.
Élément | Données clés |
---|---|
Domain Controllers | ADSVR‑01 (KL‑DC), ADSVR‑DR |
Depuis | 17 décembre 2024 |
Symptômes | Échecs réplication AD, erreurs 0x80090322 et 0x000004E8 |
Impacts | Objets AD non convergents, risques de logons/stratégies incohérents, dépendances applicatives potentiellement affectées |
Causes probables identifiées
Catégorie | Détails essentiels |
---|---|
Authentification Kerberos | SPN manquant ou incorrect pour ADSVR‑DR, mot de passe d’ordinateur obsolète, canal sécurisé rompu. |
Réseau/RPC | Ports LDAP/RPC/DNS bloqués ou filtrés entre sites ; pare‑feu local ou inter‑site mal configuré. |
DNS | Résolution directe / inversée incorrecte, enregistrements SRV manquants/obsolètes. |
Synchronisation de temps | Déviation > 5 minutes entre DC, ce qui bloque Kerberos. |
Plan d’action immédiat
- Réinitialiser le mot de passe machine sur le DC non‑PDC (ADSVR‑DR si ADSVR‑01 détient le rôle PDC) puis redémarrer le DC concerné :
netdom resetpwd /s:<PDC> /ud:<domaine\admin> /pd:*
- Vérifier les prérequis de base :
- Exécuter l’invite de commandes en administrateur.
- Utiliser un compte Administrateur du domaine.
- Tester
ping
etnslookup
dans les deux sens entre ADSVR‑01 et ADSVR‑DR.
- Collecter des diagnostics Repadmin pour établir une base avant/après :
repadmin /showrepl >C:\rep1.txt repadmin /replsum >C:\rep2.txt repadmin /showrepl * /csv >C:\repsum.csv
Procédure détaillée de dépannage
Vérifier et assainir la résolution DNS
Une réplication fiable dépend d’une résolution DNS parfaite. Procédez dans cet ordre :
- Relevé des IP et suffixes sur chaque DC :
ipconfig /all
Assurez‑vous que les DC pointent d’abord vers des DNS AD intégrés (souvent eux‑mêmes), et non vers un résolveur externe. - Résolution A/PTR des noms des DC (aller/retour) :
nslookup ADSVR-01.domain.tld nslookup ADSVR-DR.domain.tld nslookup <IP-d-ADSVR-01> nslookup <IP-d-ADSVR-DR>
Corrigez toute divergence (FQDN incorrect, absence de PTR, IP obsolète). - Enregistrements SRV Cruciaux dans
_msdcs.<domaine>
:_kerberos._tcp.dc._msdcs.<domaine>
_ldap._tcp.dc._msdcs.<domaine>
- Sites :
_sites
selon la topologie
netlogon
pour régénérer les SRV :nltest /dsregdns sc stop netlogon && sc start netlogon ipconfig /registerdns
Contrôler la synchronisation horaire
Kerberos exige une dérive de temps < 5 minutes. Vérifiez le statut sur chaque DC :
w32tm /query /status
w32tm /query /configuration
Le PDC‑Emulator du domaine doit être la source NTP de référence (pointant vers des sources de confiance) :
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
w32tm /resync /nowait
Réinitialiser le canal sécurisé machine
Si le mot de passe d’ordinateur est désynchronisé ou que le canal sécurisé est rompu :
netdom resetpwd /s:<PDC> /ud:<domaine\admin> /pd:*
Alternative côté membre / contrôleur :
nltest /sc_reset:<domaine>
nltest /sc_verify:<domaine>
Redémarrez le DC concerné après la réinitialisation.
Vérifier et corriger les SPN Kerberos
Un SPN erroné ou dupliqué provoque typiquement l’erreur 0x80090322
(“target principal name is incorrect”) et des KRB_AP_ERR_MODIFIED dans l’Observateur d’événements.
- Lister les SPN attendus pour ADSVR‑DR (exemples) :
setspn -Q "host/ADSVR-DR" setspn -Q "host/ADSVR-DR.domain.tld" setspn -Q "ldap/ADSVR-DR.domain.tld" setspn -Q "ldap/domain.tld/ADSVR-DR" setspn -Q "gc/ADSVR-DR.domain.tld"
- Détecter les doublons :
setspn -X
- Corriger : ajouter l’entrée manquante ou supprimer le doublon (avec prudence) :
setspn -S ldap/ADSVR-DR.domain.tld <CompteMachineADSVR-DR> setspn -D ldap/ADSVR-DR.domain.tld <ObjetErroné>
Valider la connectivité réseau et RPC
Confirmez la communication bidirectionnelle sur les ports requis :
Service | Port | Protocole | Rôle |
---|---|---|---|
RPC Endpoint Mapper | 135 | TCP | Découverte RPC |
LDAP | 389 | TCP/UDP | Annuaire |
LDAPs | 636 | TCP | Annuaire chiffré |
SMB | 445 | TCP | RPC/Netlogon/FSRM |
GC | 3268 | TCP | Global Catalog |
GCs | 3269 | TCP | Global Catalog SSL |
RPC dynamiques | 49152–65535 | TCP | Appels DRSUAPI, etc. |
DNS | 53 | TCP/UDP | Résolution |
Tests rapides depuis chaque DC :
Test-NetConnection ADSVR-DR -Port 135
Test-NetConnection ADSVR-DR -Port 389
Test-NetConnection ADSVR-DR -Port 445
Test-NetConnection ADSVR-DR -Port 3268
Test-NetConnection ADSVR-DR -Port 53
Vérifiez l’absence de filtrage inter‑site (pare‑feu périmétriques/VPN) et de règles locales bloquantes.
Analyser DCDIAG et Repadmin
Collecte complète et interprétation :
dcdiag /c /v /e /f:C:\dcdiag.txt
repadmin /replsum
repadmin /showrepl *
/replsum
: taux d’échec par partenaire/site. Visez 0 échec et un queue length minimal./showrepl
: détail par partition (Schema, Configuration, Domain, ForestDNSZones, DomainDNSZones) et direction.
Relancer la topologie AD
Après corrections DNS/SPN/RPC, forcez KCC et resync :
repadmin /kcc <NomDuDC>
repadmin /syncall /AePd
Attendez la stabilisation puis revalidez :
repadmin /replsum
repadmin /showrepl
Observateur d’événements à examiner
Journal | Événements typiques | Interprétation |
---|---|---|
Directory Service | 1311, 1865, 1566, 2042, 2087, 2088 | Topologie/KCC, USN, DNS vers DC/KDC, latence excessive |
System | 5719, 5722, Netlogon | Canal sécurisé et authentification machine |
DNS Server | 4013, 4000, 4007 | Dépendance AD, enregistrements SRV |
Security | Kerberos (KRB_AP_ERR_MODIFIED) | SPN incorrect/dupliqué, horloge |
Solutions appliquées et sequence recommandée
- Réinitialisation mot de passe machine (
netdom resetpwd
) sur le DC non‑PDC puis redémarrage. - Vérifications réseau/DNS :
ping
,nslookup
bidirectionnels, SRV sous_msdcs
. - Diagnostics repadmin :
/showrepl
,/replsum
, export CSV pour traçabilité. - SPN Kerberos : contrôle
setspn -X
, correction-S
/-D
. - Recréer le canal sécurisé :
nltest /sc_reset
,/sc_verify
si besoin. - Relancer KCC et réplication :
repadmin /kcc
,/syncall /AePd
, contrôle jusqu’à 0 échec.
Guides opératoires pas à pas
Checklist express avant toute action
- Accès Administrateur du domaine validé.
- Instantané de l’état courant enregistré (
repadmin
,dcdiag
). - Sauvegarde récente des DC (état du système) confirmée.
- Fenêtre de maintenance et plan de retour arrière définis.
Exemple de séquence complète
- Sur ADSVR‑DR (non‑PDC), exécuter :
netdom resetpwd
puis redémarrer. - Comparer l’heure de ADSVR‑01 et ADSVR‑DR (
w32tm
) ; corriger si écart. - Vérifier DNS (A/PTR/SRV) et régénérer
netlogon
si nécessaire. - Contrôler SPN (
setspn -X
) ; corriger ou supprimer les doublons. - Tester les ports clés (
Test-NetConnection
) et le chemin inter‑site. - Relancer KCC et forcer
repadmin /syncall /AePd
. - Analyser
repadmin /replsum
jusqu’à stabilisation sans erreur.
Recommandations complémentaires si le problème persiste
Action | Pourquoi / Comment |
---|---|
Contrôler les SPN | setspn -Q "GC/<FQDN-ADSVR-DR>" et corriger avec setspn -S ... au besoin. |
Forcer la recréation du canal sécurisé | nltest /sc_reset:<domaine> puis nltest /sc_verify:<domaine> . |
Analyser DCDIAG | dcdiag /c /v /e /f:C:\dcdiag.txt pour obtenir les tests complets. |
Vérifier la synchronisation horaire | w32tm /query /status ; configurer le PDC‑Emulator comme source NTP fiable. |
Valider les ports réseau | Confirmer l’ouverture de TCP 135, 389, 445, 636, 3268, 3269, 49152‑65535 (RPC dynamiques). |
Relancer la topologie | repadmin /kcc <DC> puis repadmin /syncall /AePd après correction des erreurs. |
Dernier recours | Si la réplication reste bloquée : metadata cleanup du DC fautif puis promotion / réintégration propre. |
Matrices de diagnostic par symptôme
Symptôme | Vérifications ciblées | Commandes utiles | Résolution |
---|---|---|---|
0x80090322 “target principal name is incorrect” | SPN du DC, canal sécurisé, horloge | setspn -X , nltest /sc_verify , w32tm /query /status | Corriger SPN, réinitialiser canal sécurisé, resync temps |
0x000004E8 “remote system is not available” | Ports, filtrage VPN/pare‑feu, routage | Test-NetConnection -Port , traceroute | Ouvrir ports, ajuster politiques réseau |
Échecs réplication DRS intra/inter‑site | SRV sous _msdcs , KCC/ISTG | repadmin /kcc , dcdiag | Régénérer SRV, relancer KCC, corriger DNS |
Validation après remédiation
- Repadmin : obtenir 0 échec et un délai de réplication conforme.
repadmin /replsum repadmin /showrepl *
- Événements : absence d’erreurs Kerberos/DNS/Netlogon répétitives durant 2–3 cycles de réplication.
- Objets de contrôle : créer un utilisateur de test sur ADSVR‑01, vérifier sa présence sur ADSVR‑DR et inversement.
- Surveillance continue : planifier une vérification quotidienne automatisée.
repadmin /replsummary > C:\Logs\replsummary_$(Get-Date -Format yyyyMMdd).txt
Bonnes pratiques pour éviter la récurrence
- Source de temps unique : le PDC‑Emulator synchronise l’ensemble, lui‑même synchronisé sur une source NTP fiable.
- DNS AD‑intégré uniquement pour les DC ; bannir les résolveurs publics dans la configuration NIC des DC.
- Contrôles SPN réguliers après opérations majeures (renommage, réhébergement, réinstallation de rôles).
- Pare‑feu inter‑site documenté : règles explicites pour RPC dynamiques et journalisation des dénis.
- Supervision : alertes sur événements 1311/1865/2087, latence de réplication et dérive de temps.
- Procédure de retour arrière prête
Exemples de commandes et sorties attendues
Repadmin résumé
Repadmin: running command /replsum
Source DSA largest delta fails/total %% error
ADSVR-01 00:07:12 0 / 12 0
ADSVR-DR 00:06:58 0 / 12 0
Vérification du canal sécurisé
nltest /sc_verify:<domaine>
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\ADSVR-01.domain.tld
The secure channel from ADSVR-DR to ADSVR-01 is working
Détection de doublons SPN
setspn -X
Checking domain DC=domain,DC=tld
CN=ADSVR-DR,OU=Domain Controllers,...
CN=AutreObjet,OU=Servers,...
Duplicate SPN found: ldap/ADSVR-DR.domain.tld
Dernier recours : nettoyage de métadonnées et réintégration
Si, malgré la correction SPN/DNS/RPC/temps et la réinitialisation du canal sécurisé, la réplication reste bloquée ou que le DC présente des incohérences graves :
- Effectuer un metadata cleanup du DC fautif (hors ligne ou irrécupérable) avec
ntdsutil
. - Supprimer les enregistrements DNS restants (A/SRV) correspondants.
- Vérifier la santé globale (
dcdiag
,repadmin
). - Promouvoir un nouveau DC ou réintégrer le serveur après remise à plat.
Important : documenter les étapes et conserver les exports repadmin
avant/après pour l’audit.
Résumé opérationnel
- Réinitialiser le mot de passe machine et le canal sécurisé via
netdom resetpwd
ounltest /sc_reset
. - Corriger les SPN Kerberos manquants ou en double sur ADSVR‑DR.
- Assurer une DNS et une synchronisation horaire parfaites avant tout nouveau test.
- Vérifier les ports RPC et LDAP inter‑site ; ajuster pare‑feu / VPN si nécessaire.
- Relancer la réplication avec
repadmin /syncall /AdeP
et contrôlerrepadmin /replsum
jusqu’au retour à “0 échec”.
Annexes utiles
Script PowerShell de contrôle rapide
# Contrôle rapide santé réplication et temps
$partners = (repadmin /showrepl *) -join "`n"
$time = w32tm /query /status
$dns = ipconfig /all
$summary = repadmin /replsum
$report = @"
===== REPLICATION PARTNERS =====
$partners
===== W32TM STATUS =====
$time
===== IPCONFIG /ALL =====
$dns
===== REPLSUMMARY =====
$summary
"@
$path = "C:\Logs\AD_Health_$(Get-Date -Format yyyyMMdd_HHmm).txt"
$report | Out-File -FilePath $path -Encoding UTF8
Write-Host "Rapport généré: $path"
Points d’attention fréquents
- Renommage d’un DC sans nettoyage DNS/SPN complet.
- NIC d’un DC pointant vers un DNS externe (public) plutôt que vers un DNS AD.
- Changement de plage d’adresses ou de NAT sans mise à jour des PTR.
- Pare‑feu inter‑site introduit récemment sans règle pour RPC dynamiques.
- Déplacement de rôle PDC sans reconfiguration NTP.
FAQ rapide
Quelle différence entre netdom resetpwd
et nltest /sc_reset
?
Les deux restaurent le canal sécurisé. netdom resetpwd
réinitialise explicitement le mot de passe d’ordinateur avec le PDC. nltest /sc_reset
renégocie le canal sécurisé avec un DC de confiance ; il est moins intrusif mais ne corrige pas toujours un mot de passe machine corrompu.
Faut‑il activer un port RPC fixe ?
Dans des environnements très contraints, vous pouvez borner la plage RPC dynamique et n’autoriser que cette plage côté pare‑feu. Assurez‑vous de documenter ce choix et de l’appliquer de façon homogène sur tous les DC.
Comment détecter un KRB_AP_ERR_MODIFIED ?
Dans le journal Security, cherchez des événements Kerberos associés au service LDAP/host/gc
du DC. Ils pointent souvent vers un SPN en doublon ou une signature de ticket invalide due à un mot de passe machine obsolète.
Quand passer au nettoyage de métadonnées ?
Uniquement si le DC ne peut plus réintégrer le domaine proprement (base NTDS endommagée, restauration impossible, panne matérielle durable). Privilégiez toujours les corrections logiques (SPN, DNS, temps, RPC) avant.
En suivant ce guide, vous adressez méthodiquement les quatre piliers de la réplication AD — Kerberos, DNS, RPC et temps — et vous ramenez rapidement l’environnement à un état cohérent. Conservez la discipline de validation (repadmin, événements) afin de prévenir toute régression.