Réplication Active Directory en échec : erreurs 0x80090322 et 1256 — guide de dépannage Kerberos, DNS et RPC

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.

Sommaire

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émentDonnées clés
Domain ControllersADSVR‑01 (KL‑DC), ADSVR‑DR
Depuis17 décembre 2024
SymptômesÉchecs réplication AD, erreurs 0x80090322 et 0x000004E8
ImpactsObjets AD non convergents, risques de logons/stratégies incohérents, dépendances applicatives potentiellement affectées

Causes probables identifiées

CatégorieDétails essentiels
Authentification KerberosSPN manquant ou incorrect pour ADSVR‑DR, mot de passe d’ordinateur obsolète, canal sécurisé rompu.
Réseau/RPCPorts LDAP/RPC/DNS bloqués ou filtrés entre sites ; pare‑feu local ou inter‑site mal configuré.
DNSRésolution directe / inversée incorrecte, enregistrements SRV manquants/obsolètes.
Synchronisation de tempsDéviation > 5 minutes entre DC, ce qui bloque Kerberos.

Plan d’action immédiat

  1. 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:*
  2. Vérifier les prérequis de base :
    • Exécuter l’invite de commandes en administrateur.
    • Utiliser un compte Administrateur du domaine.
    • Tester ping et nslookup dans les deux sens entre ADSVR‑01 et ADSVR‑DR.
  3. 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 :

  1. 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.
  2. 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).
  3. Enregistrements SRV Cruciaux dans _msdcs.<domaine> :
    • _kerberos._tcp.dc._msdcs.<domaine>
    • _ldap._tcp.dc._msdcs.<domaine>
    • Sites : _sites selon la topologie
    Si nécessaire, relancer le service DNS et 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.

  1. 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"
  2. Détecter les doublons : setspn -X
  3. 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 :

ServicePortProtocoleRôle
RPC Endpoint Mapper135TCPDécouverte RPC
LDAP389TCP/UDPAnnuaire
LDAPs636TCPAnnuaire chiffré
SMB445TCPRPC/Netlogon/FSRM
GC3268TCPGlobal Catalog
GCs3269TCPGlobal Catalog SSL
RPC dynamiques49152–65535TCPAppels DRSUAPI, etc.
DNS53TCP/UDPRé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 typiquesInterprétation
Directory Service1311, 1865, 1566, 2042, 2087, 2088Topologie/KCC, USN, DNS vers DC/KDC, latence excessive
System5719, 5722, NetlogonCanal sécurisé et authentification machine
DNS Server4013, 4000, 4007Dépendance AD, enregistrements SRV
SecurityKerberos (KRB_AP_ERR_MODIFIED)SPN incorrect/dupliqué, horloge

Solutions appliquées et sequence recommandée

  1. Réinitialisation mot de passe machine (netdom resetpwd) sur le DC non‑PDC puis redémarrage.
  2. Vérifications réseau/DNS : ping, nslookup bidirectionnels, SRV sous _msdcs.
  3. Diagnostics repadmin : /showrepl, /replsum, export CSV pour traçabilité.
  4. SPN Kerberos : contrôle setspn -X, correction -S/-D.
  5. Recréer le canal sécurisé : nltest /sc_reset, /sc_verify si besoin.
  6. 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

  1. Sur ADSVR‑DR (non‑PDC), exécuter : netdom resetpwd puis redémarrer.
  2. Comparer l’heure de ADSVR‑01 et ADSVR‑DR (w32tm) ; corriger si écart.
  3. Vérifier DNS (A/PTR/SRV) et régénérer netlogon si nécessaire.
  4. Contrôler SPN (setspn -X) ; corriger ou supprimer les doublons.
  5. Tester les ports clés (Test-NetConnection) et le chemin inter‑site.
  6. Relancer KCC et forcer repadmin /syncall /AePd.
  7. Analyser repadmin /replsum jusqu’à stabilisation sans erreur.

Recommandations complémentaires si le problème persiste

ActionPourquoi / Comment
Contrôler les SPNsetspn -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 DCDIAGdcdiag /c /v /e /f:C:\dcdiag.txt pour obtenir les tests complets.
Vérifier la synchronisation horairew32tm /query /status ; configurer le PDC‑Emulator comme source NTP fiable.
Valider les ports réseauConfirmer l’ouverture de TCP 135, 389, 445, 636, 3268, 3269, 49152‑65535 (RPC dynamiques).
Relancer la topologierepadmin /kcc <DC> puis repadmin /syncall /AePd après correction des erreurs.
Dernier recoursSi la réplication reste bloquée : metadata cleanup du DC fautif puis promotion / réintégration propre.

Matrices de diagnostic par symptôme

SymptômeVérifications cibléesCommandes utilesRésolution
0x80090322 “target principal name is incorrect”SPN du DC, canal sécurisé, horlogesetspn -X, nltest /sc_verify, w32tm /query /statusCorriger SPN, réinitialiser canal sécurisé, resync temps
0x000004E8 “remote system is not available”Ports, filtrage VPN/pare‑feu, routageTest-NetConnection -Port, tracerouteOuvrir ports, ajuster politiques réseau
Échecs réplication DRS intra/inter‑siteSRV sous _msdcs, KCC/ISTGrepadmin /kcc, dcdiagRégénérer SRV, relancer KCC, corriger DNS

Validation après remédiation

  1. Repadmin : obtenir 0 échec et un délai de réplication conforme. repadmin /replsum repadmin /showrepl *
  2. Événements : absence d’erreurs Kerberos/DNS/Netlogon répétitives durant 2–3 cycles de réplication.
  3. Objets de contrôle : créer un utilisateur de test sur ADSVR‑01, vérifier sa présence sur ADSVR‑DR et inversement.
  4. 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 :

  1. Effectuer un metadata cleanup du DC fautif (hors ligne ou irrécupérable) avec ntdsutil.
  2. Supprimer les enregistrements DNS restants (A/SRV) correspondants.
  3. Vérifier la santé globale (dcdiag, repadmin).
  4. 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

  1. Réinitialiser le mot de passe machine et le canal sécurisé via netdom resetpwd ou nltest /sc_reset.
  2. Corriger les SPN Kerberos manquants ou en double sur ADSVR‑DR.
  3. Assurer une DNS et une synchronisation horaire parfaites avant tout nouveau test.
  4. Vérifier les ports RPC et LDAP inter‑site ; ajuster pare‑feu / VPN si nécessaire.
  5. Relancer la réplication avec repadmin /syncall /AdeP et contrôler repadmin /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.

Sommaire