Errore di trust relationship tra workstation e dominio in Windows Server 2016: cause, diagnosi e soluzioni

Una VM Windows Server 2016 unita al dominio che “perde” il trust ogni pochi giorni è un campanello d’allarme. In questa guida trovi la causa tecnica dell’errore, come diagnosticarlo in modo sistematico e le azioni concrete per risolverlo definitivamente, senza ricadute.

Indice

Panoramica del problema

L’errore riportato a video è:

The security database on the server does not have a computer account for this workstation trust relationship.

Nel registro eventi compaiono ripetuti Audit Failure con Security ID = NULL SID e codice di errore 0xC000018B (account computer non trovato o non allineato nel database di sicurezza del dominio). Il fenomeno tipicamente interessa una sola VM mentre gli altri server continuano ad autenticarsi regolarmente.

Che cosa significa davvero

Fra ogni membro di dominio e un controller di dominio esiste un canale sicuro Netlogon. Questo canale usa una password dell’account computer (diversa dalle password utente) che, per impostazione predefinita, viene rinnovata automaticamente circa ogni trenta giorni. Se la password memorizzata localmente dalla VM non coincide con quella custodita in Active Directory, oppure se la VM si autentica verso un DC dove l’oggetto non è aggiornato o non esiste, il canale sicuro si rompe e l’autenticazione Kerberos/NTLM fallisce.

Le cause più comuni sono:

Password macchina non allineata a causa di snapshot/rollback della VM o ripristini da backup.
Replica AD in ritardo o incoerente, che espone la VM a DC con informazioni “vecchie”.
Skew orario oltre la tolleranza Kerberos, spesso per doppia sincronizzazione tempo host/guest vs. gerarchia di dominio.
DNS non coerente o configurato verso server pubblici invece che interni al dominio.
SPN duplicati o account computer disabilitato/tombstoned.
GPO o parametri Netlogon che impediscono il cambio password automatico.

Segnali e sintomi da riconoscere

Accesso con credenziali di dominio che fallisce, ma Administrator locale funziona.
Eventi 5722 e 5805 su DC o sulla VM, che indicano mismatch di password o account inesistente.
Errori periodici ogni pochi giorni o settimane, spesso dopo attività di manutenzione o backup.
Eventi 1097/1058 legati a impossibilità di applicare GPO, segno di trust non operativo.
Comando nltest /sc_verify:<DOMINIO> che restituisce status diverso da 0x0.

Strategia di diagnosi

Prima di “toccare” l’account computer, esegui una sequenza di verifiche che isola la causa primaria e previene ricadute:

Accedi con l’amministratore locale della VM e conferma che il nome computer sia quello atteso (sysdm.cpl o hostname).
Controlla DNS: la VM deve usare solo DNS interni del dominio, nell’ordine corretto. Niente DNS pubblici sulla scheda di rete della VM.
Verifica orario: confronta l’ora della VM con un DC e con il PDC Emulator. La differenza non deve superare pochi minuti; idealmente secondi.
Test del canale sicuro: nltest /sc_query:<DOMINIO> nltest /sc_verify:<DOMINIO>
Controlla replica AD da un DC: repadmin /replsummary repadmin /showrepl repadmin /syncall /AdeP
Cerca SPN duplicati: setspn -Q */<ComputerName>
GPO e Netlogon: genera un report GPO e verifica i parametri che influenzano la password macchina. gpupdate /force gpresult /h C:\Temp\gpresult.html

Procedura rapida consigliata

Su un DC, esegui Reset Account dell’oggetto computer problematico in Active Directory Users and Computers.

Sulla VM, accedi con l’Administrator locale ed esegui il reset del canale sicuro:netdom resetpwd /s:<FQDN_DC> /ud:<DOMINIO\Admin> /pd:Riavvia la VM.

Conferma lo stato:nltest /sc_verify:<DOMINIO>Deve restituire Status = 0x0.

Esegui e salva le verifiche finali:repadmin /syncall /AdeP w32tm /query /status

Soluzioni proposte e raccomandate

La tabella seguente riassume le attività chiave con scopo e dettagli operativi. Ogni voce è seguita da consigli pragmatici utili in ambienti virtualizzati.

Attività	Scopo	Dettagli operativi
1. Verificare lo stato dell’account computer in AD	Escludere oggetto disabilitato o eliminato	In Active Directory Users and Computers controlla che l’oggetto non sia “disabled”, non abbia rename pendenti e sia replicato su tutti i DC. Comandi utili: `repadmin /replsummary` per lo stato globale, `repadmin /showobjmeta` per verificare la cronologia attributi sull’oggetto computer. Se l’oggetto risulta in un altro sito AD, controlla la latenza di replica inter-sito.
2. Resettare la password del canale sicuro	Rigenerare la coppia di credenziali workstation‑DC	Dalla VM, con utenza locale Admin: `netdom resetpwd /s:<FQDNDCscrivibile> /ud:<DOMINIO\Admin> /pd:` Oppure con PowerShell: `Reset-ComputerMachinePassword -Server <FQDNDCscrivibile> -Credential (Get-Credential)` In alternativa, da ADUC: tasto destro sull’oggetto → Reset Account, quindi rieseguire il join se necessario. Evita di puntare a un RODC: usa sempre un DC scrivibile.
3. Controllare sincronizzazione oraria	Evitare fallback di Kerberos (> cinque minuti)	Imposta la VM per sincronizzare dall’albero di dominio: `w32tm /config /syncfromflags:DOMHIER /update w32tm /resync` Verifica: `w32tm /query /status w32tm /query /configuration` In ambienti VMware/Hyper‑V, evita doppie sorgenti tempo: o lasci l’integrazione host‑guest, o la disattivi in favore di W32Time. L’host deve comunque avere un’ora corretta.
4. Eliminare SPN duplicati	Prevenire conflitti di autenticazione	Cerca SPN in collisione: `setspn -Q */<ComputerName>` Rimuovi i record doppi con: `setspn -D <SPN> <Account>` Dupliche tipiche: `HOST/`, `RestrictedKrbHost/`, `WSMAN/`, `WSMAN/<FQDN>`.
5. Garantire DNS pulito	Risoluzione coerente di DC e VM	Configura la VM per usare soltanto i DNS interni del dominio. Ripulisci cache e registra il record: `ipconfig /flushdns ipconfig /registerdns` Sui DC verifica l’esistenza del record A e PTR della VM in zona forward e reverse; ricreali se mancanti.
6. Forzare e diagnosticare GPO	Scongiurare politiche corrotte o non replicate	Aggiorna e genera un report: `gpupdate /force gpresult /h C:\Temp\gpresult.html` Controlla gli eventi 1097 e 1058. Una GPO corrotta o non raggiungibile spesso è spia di DNS o trust non sani.
7. Esaminare le repliche AD	Evitare oggetti o password “stale”	Esegui: `repadmin /showrepl repadmin /syncall /AdeP` Se vedi errori persistenti di replica, risolvi prima di tentare ulteriori reset password della macchina.
8. Verificare snapshot o rollback della VM	Impedire il ripristino di una password ormai scaduta	Se la VM viene periodicamente riportata a uno snapshot, la password locale torna “vecchia” e il trust si rompe di nuovo. Disabilita job di snapshot automatici o rigenera gli snapshot subito dopo un cambio password riuscito. Quando crei template di VM, generalizza con Sysprep (`sysprep /generalize`) prima di unirle al dominio.
9. Controllare parametri Netlogon	Evitare blocco o estendere vita password	La chiave: `HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange` deve essere `0`. Se necessario, modifica in GPO: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Domain member: Disable machine account password changes (impostare su Disabled). Per allungare l’intervallo di rinnovo, usa Domain member: Maximum machine account password age.
10. Analizzare Event ID 5722 e 5805	Identificare causa primaria	Questi eventi indicano mismatch di password o account “tombstoned”. Se dopo i reset il problema persiste, valuta la ricreazione della VM con nuovo nome computer per eliminare SID corrotti o una storia di replica compromessa.

Approccio diagnostico avanzato

Log di debug Netlogon

Attiva il debug per ottenere dettagli del handshake del canale sicuro:

nltest /dbflag:0x2080ffff
REM Log in %SystemRoot%\debug\netlogon.log
nltest /dbflag:0x0

Nel file netlogon.log cerca messaggi di trust failure, DC contattati e codici di errore.

Tracce di rete mirate

Con Wireshark, usa il filtro:

kerberos || netlogon

Controlla sequenze AS‑REQ/AS‑REP e TGS‑REQ/TGS‑REP per errori legati allo skew temporale o a SPN non risolti. Verifica anche bind e RPC su Netlogon Secure Channel.

Strumenti PowerShell utili

# Verifica canale sicuro
Test-ComputerSecureChannel -Verbose

Ripara con credenziali di dominio

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Reset password macchina verso un DC specifico

Reset-ComputerMachinePassword -Server  -Credential (Get-Credential)

Convalida Kerberos tickets

klist
klist purge

Prevenzione e buone pratiche

Gestione del tempo

Assicurati che il PDC Emulator del dominio sia l’origine autorevole del tempo.
Evita doppi meccanismi di sincronizzazione: o time sync host‑guest, o W32Time tramite gerarchia AD. Non entrambi.
Monitora periodicamente w32tm /query /status su VM e DC.

Backup e snapshot

Non riportare periodicamente la VM a uno snapshot “datato”. Se devi usarli, crea uno snapshot nuovo subito dopo un cambio password macchina riuscito.
Per ripristini da backup, valuta procedure application‑aware e post‑restore che forzino il reset del canale sicuro.

DNS e rete

La scheda di rete della VM deve indicare solo DNS interni. Se serve risoluzione pubblica, delegala ai DNS aziendali, non a resolver internet diretti.
Mantieni coerenti i record A e PTR e verifica la scavenging policy della zona per evitare rimozioni premature.

Controllo di replica

Monitora repadmin /replsummary e gli eventi di Directory Services su ogni DC.
In presenza di siti multipli, verifica i tempi di replicazione e la disponibilità dei bridgehead.

Antivirus ed EDR

Alcuni agent interferiscono con SMB o RPC dinamici. Prevedi eccezioni per i processi e le porte usate da Netlogon e Kerberos. Se noti trust che cade in concomitanza con aggiornamenti agent, testa una policy di esclusione mirata.

Controllo porte e firewall

Apri fra VM e DC: TCP/UDP 88, 135, 389, 445, 3268/3269 (se presente GC), e l’intervallo RPC dinamico TCP 49152‑65535. Su ambienti restrittivi, valuta un static port mapping per RPC Endpoint Mapper o una riduzione controllata dell’intervallo dinamico.

Procedura estesa passo passo

Isola la VM dalla causa più probabile:
- Disabilita eventuali job di snapshot automatico.
- Se la VM è un clone di un template unito a dominio, pianifica la ricreazione corretta con Sysprep.
Allinea l’orologio: w32tm /config /syncfromflags:DOMHIER /update w32tm /resync w32tm /query /status
Pulisci DNS: ipconfig /flushdns ipconfig /registerdns
Reset del canale sicuro: netdom resetpwd /s:<FQDNDCscrivibile> /ud:<DOMINIO\Admin> /pd: Riavvia e verifica con nltest /sc_verify:<DOMINIO>.
Forza replica: repadmin /syncall /AdeP Attendi che tutti i DC riportino esito positivo.
Controlla GPO e Netlogon: gpupdate /force gpresult /h C:\Temp\gpresult.html Assicurati che Disable machine account password changes sia disabilitata.
Riesamina eventi:
- Eventi 5722 e 5805 dopo il riavvio indicano che il mismatch persiste. Ripeti il reset verso un altro DC scrivibile.
- Eventi 1058/1097 indicano problemi di percorso SYSVOL o DFS‑R, tipicamente DNS o replica.

Quando ricreare la VM

Se il problema si ripresenta ciclicamente nonostante il reset e le correzioni a tempo, DNS e replica, è probabile che la VM venga regolarmente riportata a uno stato in cui la password macchina è obsoleta. In questi casi:

Valuta la ricreazione del server con nuovo nome computer e join ex novo al dominio.
Ritira l’oggetto computer obsoleto e pulisci eventuali SPN residui.
Rivedi la pipeline di backup e snapshot per impedire futuri rollback inconsapevoli.

Domande frequenti operative

È meglio il reset da client o da DC

Il comando da client (netdom resetpwd o Reset-ComputerMachinePassword) è più affidabile perché riallinea la password in entrambe le estremità del canale, puntando esplicitamente a un DC conosciuto e scrivibile. Il reset da ADUC richiede spesso un rejoin per aggiornare la password locale.

Posso allungare la durata della password macchina

Sì, tramite GPO Domain member: Maximum machine account password age. Aumentare troppo il valore riduce la sicurezza e non risolve cause come snapshot o replica difettosa. Usalo solo come misura temporanea.

È necessario rimuovere e riunire al dominio

Solo quando il reset del canale sicuro non funziona o quando l’oggetto è corrotto/tombstoned. Prima prova sempre il reset e un controllo puntuale di DNS/tempo/replica.

Esempi pronti da incollare

Script PowerShell per test e riparazione

$domain = (Get-WmiObject Win32_ComputerSystem).Domain
Write-Host "Verifico canale sicuro con $domain..."
if (-not (Test-ComputerSecureChannel -Quiet)) {
  Write-Host "Riparo canale sicuro..." -ForegroundColor Yellow
  $cred = Get-Credential -Message "Credenziali di dominio per il reset"
  Test-ComputerSecureChannel -Repair -Credential $cred -Verbose
}
w32tm /query /status
nltest /sc_verify:$domain

Comandi chiave da ricordare

nltest /sc_query:<DOMINIO> – stato del canale sicuro
netdom resetpwd /s:<DC> /ud:<DOM\Admin> /pd: – reset password macchina
Reset-ComputerMachinePassword -Server <DC> – equivalente PowerShell
setspn -Q */<ComputerName> – ricerca di SPN
w32tm /config /syncfromflags:DOMHIER /update – allineamento orario
repadmin /syncall /AdeP – sincronizzazione replica AD
gpresult /h report.html – riepilogo GPO applicate

Lista di controllo finale

Account computer visibile, abilitato e replicato su tutti i DC.
SPN puliti, nessun duplicato.
DNS interno configurato come unico resolver sulla VM.
Sincronizzazione oraria corretta, nessun doppio meccanismo host‑guest.
GPO coerenti e parametri Netlogon non bloccanti.
Replica AD sana.
Nessun snapshot/rollback ricorrente post‑fix.
nltest /sc_verify:<DOMINIO> => Status 0x0.

Esempio di flusso decisionale

Il problema è appena comparso → Accedi come Administrator locale → Verifica tempo e DNS → Reset canale sicuro da client.
Il problema si ripete → Analizza snapshot/backup → Correggi pipeline → Conferma replica AD.
Persistenza nonostante i fix → Esamina SPN e tombstoning → Considera ricreazione della VM con nuovo nome.

Nota per ambienti misti e versioni successive

Le procedure descritte per Windows Server 2016 sono applicabili, con minime variazioni, anche a Windows Server 2012 R2, 2019 e 2022. In domini con più foreste o trust esterni, estendi le verifiche al percorso di autenticazione oltre la foresta e ai DNS condizionali coinvolti.

Conclusioni operative

L’errore di trust relationship non è un difetto casuale: è un sintomo di disallineamento fra lo stato locale della VM e quello custodito in Active Directory. Intervenire soltanto con un rejoin può spegnere l’incendio, ma per eliminare le ricadute serve rimuovere la causa primaria. Seguendo la checklist di verifica (tempo, DNS, replica), ripristinando il canale sicuro con gli strumenti corretti e impedendo rollback involontari dovuti a snapshot o backup, nella maggior parte dei casi il problema scompare stabilmente. Qualora il fenomeno persista, un nuovo server con SID e account freschi è spesso la soluzione più rapida e pulita, soprattutto se lo storico dell’oggetto in AD è compromesso o la VM proviene da cloni non generalizzati.

Appendice tecnica

Parametri di registro rilevanti

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange = 0
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags e Type per la configurazione tempo

Eventi da monitorare

System: Netlogon, W32Time, GroupPolicy
Security: Audit Failure con NULL SID e codice 0xC000018B
Directory Service su DC: 2042, 2092, errori DFS‑R su SYSVOL per problemi di replica

Port mapping RPC dinamico

Se devi restringere l’intervallo RPC dinamico per firewall inter‑sito, documenta la modifica e aggiorna le regole. Ricorda di mantenere aperta la porta TCP 135 per l’endpoint mapper.

Consigli per piattaforme di virtualizzazione

VMware: valuta di disattivare la sincronizzazione tempo delle VMware Tools sulle VM membro di dominio se l’host non è sincronizzato con la stessa fonte autorevole.
Hyper‑V: l’integrazione tempo può restare attiva solo se l’host segue la stessa gerarchia; in alternativa, disattivala a favore di W32Time.

Templating e clonazione

Per evitare SID e identità duplicate, generalizza sempre i template con Sysprep prima dell’unione al dominio. Non clonare una VM già unita al dominio e rimetterla online nello stesso dominio senza una nuova identità computer.

Procedura consigliata “rapida”

Su un DC, Reset Account dell’oggetto.
Sulla VM, accedi con Administrator locale → netdom resetpwd … → riavvio.
Conferma nltest /sc_verify:<DOMINIO> = Status = 0x0.
Esegui e salva repadmin /syncall e w32tm /query /status come verifica finale.

Applicando le misure sopra, l’errore di trust relationship non si ripresenta nella quasi totalità dei casi. Se il guasto ricompare ciclicamente, concentra la diagnosi su snapshot/backup che riportano indietro la VM o valuta la creazione di un nuovo server con identità pulita.