Active Directory: sincronizzazione password tra domini in trust (Kerberos, Azure AD Connect, MIM)

Hai un trust bidirezionale tra due domini Active Directory, ma dopo il cambio password l’accesso nel dominio “di destinazione” fallisce? Questa guida spiega perché il solo trust non sincronizza le password e come ripristinare l’accesso con una checklist operativa, comandi e soluzioni supportate.

Indice

Panoramica del problema

Dopo aver configurato un rapporto di trust bidirezionale tra due domini o foreste Active Directory, gli utenti riescono ad autenticarsi nel dominio “di destinazione” fino a quando non cambiano la password nel dominio “di origine”. Dal primo cambio password in poi, l’accesso cross‑domain fallisce e sembra che “la password non si sincronizzi”.

Questo comportamento è coerente con il design di Active Directory: un trust non replica le password. Il trust consente la federazione dell’autenticazione (Kerberos/NTLM) tra domini/foreste, ma la verifica delle credenziali avviene sempre nel dominio di origine dell’account. Se, per qualunque motivo, il controller di dominio del dominio di destinazione non riesce a completare il percorso Kerberos verso il dominio di origine, l’autenticazione fallisce, e il cambio password rende evidente il problema perché invalida eventuali ticket o cache precedenti.

Come funziona davvero l’autenticazione tra domini AD

Comprendere il flusso Kerberos aiuta a diagnosticare in modo mirato:

Ticket iniziale (TGT): l’utente ottiene un TGT dal KDC del proprio dominio (dominio di origine).
Referral cross‑domain: quando accede a una risorsa nel dominio di destinazione, il KDC del dominio di destinazione emette un Referral TGT verso il dominio di origine o verso il dominio intermedio, in base alla topologia del trust.
Validazione credenziali: la password non “viaggia” e non viene copiata; il dominio di origine verifica gli hash password e rilascia i ticket appropriati.
Autorizzazione: i SID contenuti nel ticket (inclusi i SIDHistory se permesso) determinano l’accesso alla risorsa nel dominio di destinazione.

Punto chiave: se DNS, routing, firewall, orologi o configurazioni di trust ostacolano questi passaggi, l’autenticazione cross‑domain si rompe. Dopo un cambio password, anche eventuali credenziali memorizzate lato client o ticket Kerberos non sono più validi, facendo emergere il guasto.

Cause tipiche del mancato accesso dopo il cambio password

Trust incompleto, errato o unidirezionale: il trust deve essere corretto per tipo (External vs. Forest), direzione (bidirezionale) e ambito (transitivo/non transitivo).
DNS non autoritativo o non risolvente: i DC di ogni dominio devono risolvere correttamente record SRV e A dell’altro dominio (kerberos.tcp, ldap.tcp, gc.tcp, zona _msdcs).
Firewall/IPS: porte Kerberos/TCP‑UDP 88, LDAP 389/636, SMB 445, RPC 135 + range dinamico 49152‑65535, Global Catalog 3268/3269, NTP 123 non aperte tra i DC (e tra tutti i DC coinvolti, non solo alcuni).
Skew orario: differenze di orario > 5 minuti invalidano i ticket (errore Kerberos KRBAPERR_SKEW).
Replica AD degradata: latenze e failure di replica tra i DC (soprattutto verso l’FSMO PDC Emulator) portano a “password mismatch” temporanei.
SID filtering o Selective Authentication mal configurati: blocchi dei SIDHistory o mancata assegnazione del diritto “Allowed to authenticate” interrompono l’accesso.
Tipi di cifratura Kerberos incompatibili: RC4 disabilitato su un lato, DES ancora forzato, o msDS-SupportedEncryptionTypes non coerenti dopo il cambio password.
RODC e Password Replication Policy non allineati: in siti remoti, se un RODC non può memorizzare o ottenere la password aggiornata, l’accesso fallisce.

Soluzioni proposte e passi consigliati

Priorità	Azione	Dettagli operativi	Perché può risolvere
1	Verifica del trust	– Controllare che il trust sia bidirezionale e di tipo Forest/External a seconda dello scenario. – Assicurarsi che nelle impostazioni del trust sia abilitato il SID filtering corretto e che non ci siano restrizioni RPC o firewall tra i controller di dominio. – Verificare selettive authentication e diritti “Allowed to authenticate” se abilitati.	Un trust configurato in modo incompleto o unidirezionale può impedire ai controller di dominio di completare i referral Kerberos e autorizzare gli accessi.
2	Controllo dei log e della replica AD	– Esaminare Event Viewer → Directory Service / KDC / DNS Server su entrambi i DC per errori di replica e Kerberos. – Usare `repadmin /showrepl` e `repadmin /replsummary` per individuare latenze o errori di connessione. – Verificare la salute del catalogo globale e la reachability dei ruoli FSMO.	I problemi di replica (schema, time‑skew, DNS, firewall) sono le cause più frequenti di desincronizzazione percepita.
3	Password Hash Synchronization (PHS)	– Se i domini sono integrati con Azure AD, abilitare PHS per allineare le credenziali lato cloud; abbinare Password writeback + SSPR per gestire il cambio password da Azure verso l’on‑prem. – In scenari solo on‑premises, valutare Microsoft Identity Manager (MIM) con l’agente Password Change Notification Service (PCNS) per replicare i cambi password tra directory.	Con PHS non è la password in chiaro a viaggiare, ma l’hash. Con MIM/PCNS è possibile sincronizzare i cambi password tra domini on‑prem, garantendo coerenza.
4	Reimpostazione manuale come workaround	Finché non si individua la causa, reimpostare nel dominio di destinazione la stessa password scelta dall’utente o allineare le password tramite helpdesk/SSPR.	Permette agli utenti di lavorare senza interruzioni mentre si diagnostica il problema.
5	Valutare la consolidazione dei domini	Se i domini hanno funzioni sovrapposte e i problemi persistono, considerare un merge (migrazione di oggetti con SIDHistory o decommissioning di un dominio).	Eliminare la necessità di sincronia riduce complessità amministrativa e punti di errore.

Procedura operativa passo‑passo (playbook)

Verifica immediata del trust

netdom trust DOMINIOA /domain:DOMINIOB /verify
netdom trust DOMINIOB /domain:DOMINIOA /verify
nltest /trusted_domains
nltest /domaintrusts /alltrusts
Get-ADTrust -Filter * | Format-Table Name,Direction,ForestTransitive,SelectiveAuthentication

Selezionare il tipo corretto di trust (Forest vs External) e verificare se è transitivo.
Se Selective Authentication è abilitata, confermare i permessi “Allowed to authenticate” sui computer/risorse target per i gruppi del dominio di origine.

Controllo DNS e raggiungibilità

nslookup -type=SRV kerberos.tcp.dc._msdcs.DOMINIOA
nslookup -type=SRV ldap.tcp.gc._msdcs.DOMINIOA
nltest /dsgetdc:DOMINIOA /force /gc
Test-NetConnection DC-DOMINIOA.fqdn -Port 88
Test-NetConnection DC-DOMINIOA.fqdn -Port 135
Test-NetConnection DC-DOMINIOA.fqdn -Port 445

Accertarsi che i DC di ogni dominio possano risolvere e raggiungere tutti i DC dell’altro dominio, non solo uno. Evitare dipendenze da forwarder esterni per la zona _msdcs: meglio una condizionale o la delega corretta.

Verifica oraria

w32tm /query /status
w32tm /query /source
w32tm /monitor /computers:DC-DOMINIOA,DC-DOMINIOB

Se la differenza supera 5 minuti, riallineare le gerarchie NTP: il PDC Emulator di ogni foresta dovrebbe sincronizzare da una fonte affidabile; gli altri DC da lui.

Replica Active Directory

repadmin /replsummary
repadmin /showrepl * /csv
Get-ADReplicationFailure -Scope Forest -Target DOMINIOA
Get-ADReplicationPartnerMetadata -Target * -Scope Forest | 
  Select Server,LastReplicationSuccess,ConsecutiveReplicationFailures | 
  Sort LastReplicationSuccess

Latent o failure di replica (RPC 1722, DNS 2087/2088, KCC 1311/1865) impattano la coerenza delle password e della topologia del trust.

Diagnostica Kerberos

klist purge
klist get krbtgt/DOMINIOA
klist get cifs/FILESERV.DOMINIOB

Controllare i log Security per 4768/4769/4771 e il log Kerberos Key Distribution Center su ciascun DC: errori di pre‑autenticazione, encryption‑type mismatch, skew temporali, TGT rifiutati dopo il cambio password.

Controllo dei tipi di cifratura

# Sul DC (PowerShell) per un account utente di test
Get-ADUser &lt;utente&gt; -Properties msDS-SupportedEncryptionTypes | 
  Select-Object Name,msDS-SupportedEncryptionTypes

Evita DES. Abilita AES128/256 dove possibile su client e DC.
Se RC4 è stato disabilitato di recente, assicurati che tutti i membri e i trust supportino AES e che le chiavi siano rigenerate dopo il cambio password.

Validazione del canale sicuro

Test-ComputerSecureChannel -Verbose
nltest /sc_query:DOMINIOA
nltest /sc_query:DOMINIOB

Problemi di secure channel possono far fallire l’autenticazione cross‑domain specialmente subito dopo il cambio password.

Rete e sicurezza: porte e prerequisiti

Servizio	Porte	Note
Kerberos	TCP/UDP 88	Autenticazione
LDAP / LDAPS	TCP 389 / 636	Bind, query directory
Global Catalog	TCP 3268 / 3269	Ricerca universale in foresta
SMB	TCP 445	Sysvol, condivisioni
RPC Endpoint Mapper	TCP 135	Indispensabile per i canali RPC
RPC dinamico	TCP 49152–65535	Obbligatorio tra i DC di domini diversi
NTP	UDP 123	Sincronizzazione oraria

In ambienti segmentati, applicare una matrix di any‑to‑any tra i DC per le porte AD. Limitazioni parziali o NAT sbagliati causano errori intermittenti, spesso visibili solo dopo un cambio password.

Quando e come sincronizzare davvero le password

Ribadiamo: il trust di Active Directory non sincronizza le password tra domini/foreste; abilita la federazione dell’autenticazione. Se il requisito è “stessa password in entrambi i domini”, ecco i modelli supportati:

Scenario ibrido con Azure AD

Password Hash Synchronization (PHS): i domini inviano ad Azure AD l’hash della password. Gli utenti hanno un’unica password in cloud.
Password writeback + SSPR: abilitando il writeback, i cambi password effettuati in Azure vengono scritti nel dominio di origine dell’utente (quello autoritativo per l’oggetto). Se coesistono identità duplicate in più domini on‑prem, serve un disegno di identità chiaro (ancoraggio univoco) o una riconciliazione.

Nota: PHS di per sé non “propaga” la password dal dominio A al dominio B on‑prem. Per avere la medesima password in più directory on‑prem, serve un motore di sincronizzazione che gestisca l’evento di cambio password.

Scenario solo on‑premises

Microsoft Identity Manager (MIM) + PCNS: intercetta gli eventi di cambio password nei DC del dominio di origine e li replica verso le directory di destinazione in modo sicuro. È la soluzione standard per la cross‑domain password synchronization on‑prem.
ADMT/PES (migrazione): se l’obiettivo è l’unificazione, migrare gli account con SIDHistory e dismettere il dominio secondario riduce la complessità eliminando la necessità di sincronizzare le password.

Workaround e mitigazioni rapide

Allineamento manuale della password nel dominio di destinazione (temporaneo), implementando policy e processi di helpdesk per ridurre l’impatto utenti.
Durata adeguata dei ticket Kerberos: in ambienti critici, rivedere le policy di durata dei ticket (TGT/TGS) per ridurre finestre di inconsistenza percepita, senza sacrificare la sicurezza.
SSPR centralizzato: introdurre il self‑service password reset con writeback per ridurre i tempi tra un cambio password e l’effettiva disponibilità cross‑dominio.

Checklist tecnica rapida

☑ Trust bidirezionale, tipo corretto (External vs Forest), selettive auth coerenti, SID filtering secondo requisito.
☑ DNS: record SRV kerberos, ldap, _gc risolvibili tra domini; forwarder/conditional delegation corretti.
☑ Rete: porte 88/389/445/135/49152‑65535/3268/3269/123 aperte tra tutti i DC.
☑ Orario: drift <= 5 min, gerarchia NTP sana (w32tm).
☑ Replica: repadmin pulito; nessun 1311/1722/2087 ecc. persistente.
☑ KDC: nessun 4771/kerberos pre‑auth fail legato a encryption type; AES abilitato.
☑ Se RODC: PRP consente la memorizzazione delle password necessarie; collegamenti verso RWDC stabili.
☑ Se serve stessa password in più directory: MIM/PCNS (on‑prem) o PHS + writeback/SSPR (ibrido) con ancoraggio identità chiaro.

Strumenti e comandi utili

Strumento/Comando	Uso	Output atteso/Interpretazione
`dcdiag /test:trusts`	Valuta lo stato dei trust definiti	Nessun errore critico; mismatch di direzione o di sicurezza evidenziati
`repadmin /replsummary`	Quadro di sintesi replica	Failure < 1%; latenze nella norma; errori RPC/DNS assenti
`repadmin /showrepl`	Dettaglio partner e naming context	Nessun errore “Last error” o “Last attempt” con codici 1722/8606 ecc.
`nltest`	Secure channel, discovery DC, trusts	`/sc_query` = success; `/dsgetdc` restituisce DC e GC corretti
`klist`	Ticket Kerberos client	Ticket aggiornati dopo `klist purge`; nessun referral errato
AD Replication Status Tool	Vista grafica degli errori di replica	Bacheca “green”; attenzione a siti remoti o DC obsoleti
AD Explorer	Ispezione attributi (es. `pwdLastSet`)	Verificare la data/ora di aggiornamento password sugli oggetti

Suggerimenti aggiuntivi

Sincronizzazione oraria: entrambi i domini devono usare una fonte NTP affidabile; uno scarto > 5 minuti può invalidare i ticket Kerberos.
DNS e risoluzione nomi: i DC di ciascun dominio devono poter risolvere SRV e record A dell’altro dominio, compresi i record _msdcs.
Firewall/IPS: aprire le porte RPC (TCP 135, 49152–65535) e Kerberos (TCP/UDP 88), oltre a SMB (TCP 445) e GC (3268/3269) fra tutti i DC coinvolti.
Tool utili: dcdiag /test:trusts, Active Directory Replication Status Tool, AD Explorer per controllare attributi relativi a password (unicodePwd, pwdLastSet).

Pattern architetturali consigliati

Foresta unica con più domini

Preferibile quando serve amministrazione separata ma identità coerenti. Il trust intra‑forest è transitivo e più semplice da gestire (GC, schema condiviso). La sincronizzazione password tra domini continua a non essere nativa: l’autenticazione rimane federata.

Foreste separate con trust

Necessario in scenari di fusione/acquisizione, compliance o confini di sicurezza. Richiede attenzione a DNS, firewall, routing e policy di cifratura. Se occorre “stessa password in tutte le foreste”, introdurre MIM/PCNS o orchestrare i cambi via Azure AD (PHS + writeback/SSPR) con governance chiara.

Domande frequenti

Il trust sincronizza le password? No. Il trust consente l’autenticazione cross‑domain, ma la password rimane nel dominio di origine.

Perché l’utente riusciva ad accedere prima del cambio password? Probabilmente grazie a ticket/cached credentials ancora validi. Dopo il cambio, i ticket scadono e il problema di connettività/configurazione emerge.

Posso evitare MIM e ottenere comunque password uguali? In ibrido, sì: centralizzando i cambi su Azure AD con PHS + writeback/SSPR. Per replicare tra directory on‑prem diverse, serve un motore tipo MIM/PCNS.

Quali log devo guardare? Directory Service (replica/KCC), DNS Server (risoluzione), Kerberos Key Distribution Center e Security (4768/4769/4771). Eventi come 1311, 1722, 2087 indicano problemi di topologia, RPC o DNS.

Il SID filtering può bloccare l’accesso? Sì. Se i SIDHistory sono necessari, disabilitare il filtering o configurarlo secondo best practice. Con Selective Authentication concedere “Allowed to authenticate”.

Esempio di runbook di troubleshooting

Conferma trust: netdom ... /verify su entrambi i lati. Selezione corretta di External/Forest, bidirezionale, stato “validated”.
DNS: nslookup -type=SRV per kerberos, ldap, _gc verso l’altro dominio. Correggere zone/conditional forwarder/deleghe.
Rete: aprire le porte tra i DC (lista sopra). Usare Test-NetConnection per validare le porte da ogni DC verso ogni DC remoto.
Tempo: w32tm per allineare la gerarchia. Correggere drift > 5’.
Replica: repadmin /replsummary. Nessun errore? Proseguire. Errori? Risolverli prima di tutto.
Kerberos: su un client di test, klist purge e nuova autenticazione. Se fallisce, verificare 4771 (pre‑auth) e encryption types.
Policy/Filtri: rivedere Selective Authentication, “Allowed to authenticate” e SID filtering. Se serve, riabilitare temporaneamente per validare l’ipotesi.
Decisione: se serve coerenza password multi‑directory, pianificare MIM/PCNS (on‑prem) o modello PHS + writeback/SSPR (ibrido).

Conclusioni

Il trust AD consente l’autenticazione federata, non la sincronizzazione delle password. Se dopo il cambio password l’accesso cross‑dominio fallisce, la causa è quasi sempre in DNS/rete/orario/replica o in policy di fiducia (Selective Authentication, SID filtering, cifrature Kerberos). La checklist di questo articolo ti guida dal livello rete fino ai dettagli Kerberos. Quando la richiesta di business è avere la stessa password in più domini, affidati a MIM/PCNS on‑prem o a PHS + writeback/SSPR in scenari ibridi; in alternativa, considera la consolidazione dei domini per eliminare la necessità di sincronizzare.

Appendice: comandi rapidi copiabili

:: Trust
netdom trust DOMINIOA /domain:DOMINIOB /verify
netdom trust DOMINIOB /domain:DOMINIOA /verify
nltest /domaintrusts /alltrusts

:: DNS
nslookup -type=SRV kerberos.tcp.dc._msdcs.DOMINIOA
nslookup -type=SRV ldap.tcp.gc._msdcs.DOMINIOB
nltest /dsgetdc:DOMINIOA /force /gc

:: Porte
Test-NetConnection DC-REMOTO.fqdn -Port 88
Test-NetConnection DC-REMOTO.fqdn -Port 135
Test-NetConnection DC-REMOTO.fqdn -Port 445
Test-NetConnection DC-REMOTO.fqdn -Port 3268

:: Tempo
w32tm /query /status
w32tm /monitor /computers:DC1,DC2

:: Replica
repadmin /replsummary
repadmin /showrepl * /csv > repl.csv

:: Kerberos
klist purge
klist get krbtgt/DOMINIOA
klist get cifs/SERVER.DOMINIOB

Seguendo la checklist nell’ordine indicato, di solito si individua rapidamente se il problema è di replica (più comune) o di configurazione del trust, permettendo così di ripristinare l’autenticazione trasparente tra domini. Se la necessità è la sincronizzazione effettiva delle password, introdurre gli strumenti adeguati (MIM/PCNS o PHS + writeback/SSPR) o valutare la consolidazione dell’infrastruttura.