Deux forêts Active Directory liées par un trust : après un changement de mot de passe, l’utilisateur n’accède plus aux ressources de l’autre domaine. Voici une méthode complète, concrète et reproductible pour diagnostiquer et corriger la situation.
Problème : la synchronisation des mots de passe entre deux domaines en relation d’approbation échoue
Vous administrez deux forêts ou deux domaines Active Directory unis par une relation d’approbation (trust). Tant que l’utilisateur conserve son mot de passe, tout fonctionne. Dès qu’il change ce mot de passe dans le domaine source, les accès au domaine cible échouent (Kerberos/NTLM), comme si la synchronisation des mots de passe n’avait pas eu lieu, ou comme si la mise à jour n’était pas « connue » côté cible.
Avant d’entrer dans le détail, une idée clé : un trust n’exige pas, en soi, une synchronisation de mot de passe. Par défaut, l’authentification se fait dans le domaine source, puis un Kerberos referral permet d’accéder à la ressource dans le domaine cible. Toutefois, beaucoup d’organisations maintiennent deux comptes (un par domaine) et souhaitent garder le même secret sur les deux comptes : c’est là que la « synchro de mots de passe » intervient (via PCNS/MIM, un Password Filter DLL, un produit tiers, etc.). Dans les deux scénarios, un changement de mot de passe qui ne se propage pas correctement casse l’accès inter‑forêts.
Pourquoi cela se produit
- Réplication Active Directory : un changement de mot de passe déclenche une réplication dite « urgente ». Si un DC distant n’a pas encore reçu la mise à jour, il peut refuser l’authentification immédiatement après le changement.
- Dérive d’horloge : Kerberos tolère un faible décalage (par défaut 5 minutes). Au‑delà, les tickets échouent avec des erreurs typiques.
- DNS et routage : un trust opérationnel repose sur des conditional forwarders et l’accessibilité des services SRV (KDC/GC). Des SRV introuvables ou bloqués par un pare‑feu empêchent la mise à jour ou la vérification.
- Options du trust : Selective Authentication et SID filtering mal réglés peuvent empêcher l’accès même si l’authentification réussit. L’utilisateur peut alors sembler « désynchronisé » alors que le blocage est autorisationnel.
- Mécanisme de synchronisation parallèle : si vous conservez deux comptes et vous appuyez sur un Password Filter DLL, PCNS/MIM ou un outil tiers, un service arrêté, des ACL inutiles ou une configuration incomplète de la clé LSA « Notification Packages » suffisent à interrompre la copie de secret.
- Types de chiffrement Kerberos : un changement de mot de passe peut exposer une incompatibilité d’encryption types (AES vs RC4). Certains services ou comptes de service figés sur d’anciens algorithmes cessent alors d’accepter le ticket.
- RODC et cache d’identifiants : la présence d’un Read‑Only Domain Controller qui « cache » des secrets peut retarder l’effet d’un changement si la réplication amont est dégradée.
Diagnostic rapide
Commencez par reproduire sur un poste de test (compte affecté, même site AD si possible), puis enchaînez les vérifications ci‑dessous :
- Horloge et source NTP côté clients et DC : la tolérance Kerberos est serrée. Mesurez et corrigez immédiatement tout écart d’horloge.
- Réplication AD entre les DC des deux forêts : recherchez des arriérés, des partenaires injoignables ou des erreurs DFSR/NTDS.
- DNS inter‑forêts : résolvez les enregistrements SRV Kerberos/GC et les noms des DC distants depuis chaque forêt.
- Trust : validez la relation, le sens (bi‑directionnel recommandé) et les options Selective Authentication / SID Filtering.
- Journaux : corrélez les événements Kerberos/LSA/NETLOGON au moment exact du changement et de la tentative d’accès.
- Mécanisme de synchronisation : si vous dupliquez les comptes, vérifiez que le pipeline de synchro capture bien les notifications de changement et peut écrire dans le domaine cible.
Étapes de résolution détaillées
| Étape | Action | Pourquoi / points clés |
|---|---|---|
| 1 | Vérifier la configuration de la relation d’approbation | Le plus simple et le plus robuste est une approbation bi‑directionnelle (Forest trust si forêts, External trust sinon). Confirmez si Selective Authentication est activée. Si oui, le groupe ou l’utilisateur doit disposer de « Allowed to authenticate » sur les serveurs du domaine cible. Si vous utilisez SIDHistory (coexistence/migrations), évaluez l’impact d’un SID filtering activé. Get-ADTrust -Filter * | Select-Object Name,Direction,TrustType,SelectiveAuthentication,SIDFilteringQuarantined |
| 2 | Contrôler la réplication AD et l’horloge | Des écarts > 5 min provoquent des échecs Kerberos (erreur de pré‑authentification, ticket expiré). Vérifiez la réplication urgente des mots de passe et l’état global. repadmin /replsummary repadmin /showrepl * /csv > repl.csv w32tm /query /status w32tm /query /source netdom query fsmo |
| 3 | Examiner les journaux d’événements | Sur les DC source et cible, inspectez Directory Service, Security, System. LSA/Kerberos : 40960/40961 (LSASRV), 5/14/18/19 (Kerberos), 4771/4768/4769 (audits échec/réussite). NETLOGON : 5719/5722/3210 indiquent des soucis de canal sécurisé ou de découverte de DC. Remarque : 1202 (SceCli) peut pointer un problème de stratégie et révéler un souci collatéral plutôt qu’un échec d’authentification pur. |
| 4 | Valider le mécanisme de synchronisation utilisé | Sans duplication de comptes : pas de vraie « synchro de mot de passe ». Le trust et la réplication AD suffisent ; concentrez‑vous sur Kerberos, DNS, heure. Avec duplication de comptes : Password Filter DLL personnalisé : vérifiez son load par LSA, les droits NTFS et l’entrée de registre. PCNS/MIM ou outil tiers : contrôlez le service de capture sur chaque DC source, la connectivité vers le moteur de synchro, et les droits d’écriture dans le domaine cible. reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v "Notification Packages" sc query type= service state= all | findstr /I "pcns mim fim sync" |
| 5 | Forcer une resynchronisation manuelle (temporaire) | Réinitialisez le mot de passe du compte homonyme dans le domaine cible avec exactement le même secret que dans le domaine source pour lever le blocage immédiat. Attention aux stratégies de mot de passe : si l’historique empêche la réutilisation, un administrateur peut définir le secret et cocher « L’utilisateur doit changer le mot de passe à la prochaine ouverture de session ». |
| 6 | Envisager des alternatives structurelles | Consolidation des deux domaines dans une même forêt avec relations de confiance internes et/ou migration contrôlée. Active Directory Federation Services (AD FS) pour du SSO fédéré, supprimant la dépendance à une synchronisation permanente de secrets entre comptes dupliqués. |
Vérifications réseau et DNS indispensables
Sans résolution correcte des SRV et sans ports ouverts, le trust paraît « cassé » alors que l’AD est simplement injoignable.
Commandes utiles
:: Tester les SRV Kerberos et Global Catalog du domaine cible
nslookup -type=SRV _kerberos._tcp.dc._msdcs.cible.local
nslookup -type=SRV _gc._tcp.cible.local
:: Localiser un DC du domaine partenaire
nltest /dsgetdc:cible.local /force /dns
:: Purger le cache Kerberos côté client lors des tests
klist purge
:: Vérifier le canal sécurisé machine <-> domaine
nltest /sc_verify:source.local
nltest /sc_verify:cible.local
:: Valider les ports ouverts
Test-NetConnection dc1.cible.local -Port 88
Test-NetConnection dc1.cible.local -Port 389
Test-NetConnection dc1.cible.local -Port 445Ports et services à autoriser entre forêts
| Port | Protocole | Service | Rôle |
|---|---|---|---|
| 53 | TCP/UDP | DNS | Résolution noms/SRV |
| 88 | TCP/UDP | Kerberos | Auth et tickets inter‑forêts |
| 123 | UDP | NTP | Synchronisation de l’horloge |
| 135 | TCP | RPC EPM | Découverte des services AD |
| 389 | TCP/UDP | LDAP | Annuaire |
| 445 | TCP | SMB | Accès SYSVOL/Netlogon |
| 464 | TCP/UDP | kpasswd | Changement de mot de passe |
| 3268/3269 | TCP | GC/GC SSL | Global Catalog |
| 49152‑65535 | TCP | RPC dynamiques | Répl./DCSvc divers |
Comprendre la propagation d’un changement de mot de passe
Quand un utilisateur change son mot de passe sur un DC, ce contrôleur :
- Applique la modification localement.
- Déclenche une réplication urgente vers son partenaire et vers le PDC Emulator du domaine.
- Les autres DC apprennent la mise à jour au fil de la réplication (immédiate intrasite, planifiée intersites).
Dans l’intervalle, une authentification peut :
- Échouer si elle aboutit sur un DC encore stale.
- Réussir si la vérification retombe sur le PDC Emulator, qui connaît « le dernier mot ».
Conséquence pratique : accélérez la convergence — corrigez l’horloge, surveillez la topologie de sites et la latence intersites, éliminez les liens RPC bloqués.
Cas fréquents et correctifs ciblés
Décalage d’horloge
Si le client et le DC du domaine source ou cible ne partagent pas la même référence NTP, les tickets Kerberos échouent après le changement.
w32tm /config /syncfromflags:domhier /update
w32tm /resync /nowaitSRV/DNS incomplets ou erronés
Assurez‑vous que chaque forêt détient des conditional forwarders vers l’autre et que les SRV _kerberos et _ldap sont exposés par les DC. Sans cela, la découverte inter‑forêts ne fonctionne pas.
Selective Authentication et autorisations
Avec Selective Authentication, l’authentification peut techniquement réussir mais l’accès être refusé faute d’ACL « Allowed to authenticate » sur les serveurs du domaine cible. Ajoutez l’utilisateur ou, mieux, un groupe du domaine source à cette ACL sur les ordinateurs cibles.
SID filtering
Si vous exploitez SIDHistory pendant une migration, désactivez le filtrage ou adaptez‑le sur le trust concerné. Sinon, des SIDs nécessaires au contrôle d’accès ne seront pas honorés.
Types de chiffrement Kerberos incompatibles
Les comptes et services modernes utilisent AES. Des hôtes anciens forcés en RC4/DES généreront des échecs après changement de secret.
# Examiner les types de chiffrement d'un compte utilisateur
Get-ADUser jdupont -Properties msDS-SupportedEncryptionTypes |
Select-Object Name,msDS-SupportedEncryptionTypesRODC et mots de passe mis en cache
Un RODC peut répondre avec des informations périmées si la réplication amont est en défaut. Forcer une réplication ou vider un cache ciblé peut lever le doute.
repadmin /rodcpwdrepl <NomRODC> <Utilisateur>Mécanismes de synchronisation entre comptes dupliqués
Si vous maintenez un compte « jumeau » dans le domaine cible et vous synchronisez les secrets :
- Password Filter DLL : il doit être dans
%SystemRoot%\System32, listé dansHKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages, et l’identifiant de service doit pouvoir ouvrir un canal sécurisé vers le moteur de synchro. - PCNS/MIM ou équivalent : le password change notification doit s’abonner à tous les DC pertinents du domaine source, et le connecteur vers le domaine cible doit disposer des droits reset password et write lockoutTime au besoin.
- Contrôle opérationnel : exécutez une modification de test et suivez‑la de bout en bout dans les journaux de l’agent, puis du moteur de synchro.
Procédure de test reproductible
- Créez un compte « lab » dans le domaine source et, s’il y a duplication, son homonyme dans le domaine cible.
- Connectez‑vous à une ressource du domaine cible (SMB ou HTTP) pour valider l’état avant changement.
- Changez le mot de passe sur un DC proche du PDC Emulator.
- Immédiatement après, purgez le cache Kerberos sur le poste de test (
klist purge) et rejouez l’accès. - Notez l’heure précise et relevez simultanément :
- Événements 4768/4769/4771 sur le DC source.
- Événements 40960/40961 sur les serveurs cible.
- Événements NETLOGON 5719/5722/3210 si canal sécurisé en défaut.
- Si duplication de comptes : observez les journaux de l’agent de capture, puis du moteur de synchronisation, et enfin l’écriture dans le domaine cible.
Trucs et pièges de terrain
- UPN suffix incohérent : un UPN non routable (
@local) complique la découverte inter‑forêts. Normalisez vos suffixes UPN. - Politiques de mot de passe dissemblables : si le domaine cible impose une longueur/complexité supérieure, votre pipeline de synchro échoue silencieusement. Harmonisez les GPO (Password Policy/Fine‑Grained PSO).
- Token bloat sur des comptes sur‑membrets : l’accès peut échouer sur UDP Kerberos. Le client bascule sur TCP mais certains équipements intermédiaires peuvent perturber ce trafic.
- SPN dupliqués dans le domaine cible : un SPN en double provoque des erreurs Kerberos (KRB_AP_ERR_MODIFIED). Corrigez les doublons avant d’incriminer la « synchro ».
- DFS et SYSVOL dégradés : un SYSVOL inaccessible (DFSR cassé) empêche l’application de GPO influant sur l’auth. Résolvez vos arriérés DFSR.
Playbook condensé
| Action | Commande / Où | Attendu |
|---|---|---|
| Comparer l’heure source/cible | w32tm /query /status (clients & DC) | Écart <= 5 min, même source NTP |
| Réplication AD | repadmin /replsummary (DC) | Aucun partenaire en échec |
| DNS SRV inter‑forêts | nslookup -type=SRV _kerberos._tcp.dc._msdcs.<domaine> | Liste de KDC valide |
| Canal sécurisé | nltest /sc_verify:<domaine> (serveur membre) | Succès |
| Purge tickets | klist purge (client) | Nouveau TGT post‑changement |
| Validation du trust | MMC « Domains and Trusts » / PowerShell | Bi‑directionnel, options conformes |
| Pipeline de synchro | Journaux agent/serveur (PCNS/MIM/tiers) | Événements de capture et d’écriture OK |
Quand forcer une remise à plat
Si, malgré toutes les corrections, l’échec persiste immédiatement après chaque changement de mot de passe, posez‑vous deux questions :
- Le trust vous suffit‑il ? Si oui, supprimez la duplication de comptes et laissez AD faire son travail : plus de synchro de secrets, moins de complexité.
- Besoin de comptes dupliqués ? Stabilisez un pipeline supporté et observable (PCNS/MIM ou un outil industriel), documentez les prérequis (droits, pare‑feu, GPO), et implémentez une supervision forte (alertes à l’échec de capture/écriture).
FAQ express
Faut‑il Azure AD Connect pour synchroniser deux domaines on‑prem ?
Non pour le trust en lui‑même. Azure AD Connect traite principalement AD → Azure AD (avec éventuel password writeback vers on‑prem). Pour de l’on‑prem ↔ on‑prem, utilisez PCNS/MIM ou un produit spécialisé, ou — mieux — évitez la duplication de comptes.
Combien de temps dure la propagation d’un changement de mot de passe ?
Elle est urgente intrasite (presque immédiate) et dépend de vos liaisons intersites. Une mauvaise topologie, des liens RPC filtrés ou des DC surchargés allongent ce délai.
Pourquoi l’utilisateur se connecte parfois avec l’ancien mot de passe ?
Parce que le DC contacté n’a pas encore reçu la mise à jour. Le PDC Emulator « sait » plus vite. D’où l’intérêt de vérifier sur quel DC le client tombe et d’accélérer la convergence.
Selective Authentication est‑elle compatible avec ce scénario ?
Oui, mais requiert des ACL « Allowed to authenticate » explicites sur les hôtes cibles. Sans ces droits, l’accès est refusé même si l’authentification primaire a réussi.
Checklist finale
- Trust bi‑directionnel, type adéquat, options revues (Selective Authentication, SID filtering).
- Heure alignée (source NTP commune), tolérance ≤ 5 min.
- Réplication AD saine (
repadminsans erreurs, PDC Emulator joignable). - DNS inter‑forêts opérationnel (SRV KDC/GC résolus, conditional forwarders en place).
- Pare‑feu ouverts : 53, 88, 123, 135, 389, 445, 464, 3268/3269 et RPC dynamiques.
- Journaux analysés : corrélation temporelle des événements LSA/Kerberos/NETLOGON/DS.
- Si duplication de comptes : pipeline de synchro monitoré, Password Filter DLL chargé, droits d’écriture confirmés.
- Plan de secours : resynchronisation manuelle ponctuelle (même secret) + réflexion structurelle (éliminer la duplication, ou basculer vers AD FS selon besoin).
Références utiles pour approfondir (sans lien)
- KB 325850 : dépannage des relations d’approbation Active Directory.
- KB 304403 : Password Change Notification Service.
- Événements Kerberos : 4768/4769/4771 côté sécurité, 40960/40961 côté LSA.
- NETLOGON : 5719/5722/3210.
Conclusion
Dans un environnement multi‑forêts, un échec d’accès après changement de mot de passe n’est pas une fatalité : réplication, horloge, DNS et options de trust expliquent la majorité des cas. Si vous maintenez des comptes dupliqués, traitez la synchronisation comme une chaîne de production : instrumentation, logs lisibles, alertes. À défaut, simplifiez l’architecture et appuyez‑vous sur le modèle natif du trust ou sur une fédération AD FS. En appliquant ce guide, vous identifierez rapidement si le problème vient d’un stale DC, d’une dérive d’horloge, d’un DNS borgne, d’un canal sécurisé fragilisé ou d’une chaîne de synchro rompue — et vous saurez comment y remédier durablement.