MENU
  1. ホーム
  2. Python
  3. Errore “The trust relationship between this workstation and the primary domain failed” in Windows: cause, soluzioni, prevenzione

Errore “The trust relationship between this workstation and the primary domain failed” in Windows: cause, soluzioni, prevenzione

Python

Su PC Windows in dominio Active Directory può apparire l’errore “The trust relationship between this workstation and the primary domain failed”. In questa guida spieghiamo cause, diagnostica, soluzioni rapide e prevenzione, con procedure PowerShell e checklist operative per ambienti piccoli e grandi.

Indice

Scenario e sintomi

In un dominio con controller Windows Server 2019 e ~100 client Windows 10 (più qualche server 2012 R2), alcuni utenti non riescono ad accedere al log‑on di Windows. Sullo schermo compare:

The trust relationship between this workstation and the primary domain failed

Il problema talvolta ricompare dopo aver rimosso e riaggiunto il computer al dominio e, in alcuni casi, subito dopo un cambio password dell’utente.

Che cos’è la “relazione di trust” del computer

Ogni computer unito al dominio possiede un account macchina in Active Directory con una password del canale protetto (secure channel). Questa password è gestita automaticamente dal sistema operativo e, per impostazione predefinita, viene rinnovata circa ogni 30 giorni. La comunicazione autenticata fra il client e i Domain Controller avviene tramite questo canale, sfruttando Kerberos (o NTLM in casi particolari). I Domain Controller mantengono la password corrente e anche quella precedente per tollerare un singolo “salto” di sincronizzazione.

Se la password memorizzata sul client non coincide con quella dell’oggetto computer in AD (o se la sincronizzazione oraria supera la tolleranza Kerberos), la workstation non può stabilire il canale sicuro e il logon al dominio fallisce.

Cause tecniche frequenti

  • Skew dell’orario superiore a 5 minuti tra client e DC (Kerberos rifiuta i ticket fuori tolleranza).
  • Snapshot/rollback di VM o ripristini di backup che riportano indietro la password macchina del client o del DC.
  • Replica AD in ritardo o incongruenze tra i Domain Controller.
  • Client lontani o spesso offline (laptop) che non contattano i DC per lunghi periodi: il DC potrebbe aver ruotato più volte la password.
  • Connettività/DNS non corretti (client che usano DNS pubblici o misti invece dei DNS di dominio).
  • Unione al dominio clonata (immagini non generalizzate): più PC derivati da una VM già unita al dominio.
  • RODC in filiale con Password Replication Policy non adeguata: il computer non riesce ad autenticarsi offline.
  • Reset della password macchina su un DC specifico e logon contro un altro DC prima che la replica termini.

Diagnostica rapida (runbook per help desk)

  1. Verifica orario: w32tm /query /status w32tm /query /peers Correggi puntando alla gerarchia di dominio: w32tm /config /syncfromflags:domhier /update e poi w32tm /resync /rediscover.
  2. Verifica DNS (solo DNS AD, niente DNS pubblici): ipconfig /all nslookup -type=SRV ldap.tcp.dc.msdcs.<dominiofqdn>
  3. Connettività verso i DC: ping, porte 88/135/389/445/3268/464/5722 raggiungibili (firewall/VPN?).
  4. Stato replica AD (esegui da un DC): repadmin /replsummary repadmin /showrepl dcdiag /v
  5. Test del canale sicuro sul client: nltest /scquery:<DOMINIONETBIOS> nltest /scverify:<DOMINIONETBIOS> In PowerShell: Test-ComputerSecureChannel -Verbose
  6. Ticket Kerberos: klist klist purge
  7. Event Viewer (cliente):
    • System > Netlogon: 5719, 5722, 5805, 3210.
    • System > Kerberos: evento 4 (KRBAPERR_MODIFIED).
    • System > Time-Service: avvisi di mancata sincronizzazione.

Soluzioni rapide e sicure

Riparazione senza rimuovere il PC dal dominio (consigliata)

Dal client, con un account amministrativo locale o credenziali di dominio con diritti adeguati, rigenera la password macchina puntando a un DC specifico (meglio nel site del client o il PDC Emulator in presenza di latenza/replica lenti):

# PowerShell
Reset-ComputerMachinePassword -Server <DC_FQDN>

In alternativa:

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

Oppure via CMD:

netdom resetpwd /server:<DCFQDN> /userd:<DOMINIO\utenteadmin> /passwordd:*

Al termine, riavvia la macchina. In molte situazioni è sufficiente anche il riavvio del servizio Netlogon (net stop netlogon && net start netlogon), ma un reboot assicura il rinnovo completo dei ticket e delle sessioni.

Reimpostare l’account computer da ADUC

  1. Apri Active Directory Users and Computers.
  2. Click destro sull’oggetto computer → Reset Account.
  3. Riavvia il client e prova l’accesso.

Questo metodo rigenera la password sul lato AD. Se il client tenta il logon contro un DC diverso prima che la replica si propaghi, potresti dover forzare la replica o puntare il comando di reset direttamente al DC più vicino.

Rimuovere e riaggiungere il PC al dominio (ultima spiaggia)

  1. Accedi con account locale amministrativo (non di dominio).
  2. Impostazioni di sistema → Rinomina questo PC (avanzate) → imposta temporaneamente il Workgroup.
  3. Riavvia → reinserisci nel Dominio con credenziali adeguate.

Questa soluzione funziona ma è più lenta, comporta due riavvii e può impattare criteri, profili vagamente mappati e software con binding al SID macchina. Di norma non è necessaria se il reset del canale sicuro riesce.

Prevenzione e “fix” permanente

AreaAzione consigliataComandi di verifica
Sincronizzazione orariaAllinea l’intera foresta usando la gerarchia AD. Il PDC Emulator del dominio radice deve sincronizzare con una fonte NTP affidabile.w32tm /query /status, w32tm /resync /rediscover
DNS di dominioConfigura i client per usare solo i DNS AD (niente DNS pubblici o misti). Disabilita “Append DNS suffixes” incoerenti.ipconfig /all, nslookup -type=SRV kerberos.tcp.<dominio>
Replica ADMonitora e risolvi backlog tra i DC; assegna i client al site corretto (subnet in Sites and Services).repadmin /replsummary, repadmin /showrepl
Backup & snapshotEvita snapshot di VM già unite al dominio. Prima della clonazione esegui sysprep /generalize o disunisci dal dominio.Procedure interne & checklist di hypervisor
Criteri di gruppoPer laptop spesso offline, valuta l’estensione della rotazione: Domain member: Maximum machine account password age (fino a 999 giorni). Non disabilitare la rotazione.GPMC → Security Options
Monitoraggio proattivoEsegui periodicamente Test-ComputerSecureChannel su tutti i client e invia alert. Integra in SIEM.Script PowerShell programmati, Task Scheduler

Script PowerShell pronti all’uso

Ripara la macchina locale puntando al DC “migliore”

$dc = (Get-ADDomainController -Discover -NextClosestSite).HostName
try {
    Write-Host "Reset della password macchina contro $dc..."
    Reset-ComputerMachinePassword -Server $dc -ErrorAction Stop
    Write-Host "Operazione completata. Riavviare il computer."
} catch {
    Write-Warning "Reset fallito: $($_.Exception.Message)"
    Write-Host "Tentativo con Test-ComputerSecureChannel -Repair..."
    Test-ComputerSecureChannel -Repair -Server $dc -Credential (Get-Credential)
}

Ripara in remoto un gruppo di PC (WinRM abilitato)

$computers = Get-Content .\pc-da-riparare.txt  # un nome per riga
$cred = Get-Credential  # credenziali dominio con diritti admin locali
Invoke-Command -ComputerName $computers -ScriptBlock {
    param($dc)
    try {
        Reset-ComputerMachinePassword -Server $dc -ErrorAction Stop
        "OK;$env:COMPUTERNAME"
    } catch {
        "KO;$env:COMPUTERNAME;$($_.Exception.Message)"
    }
} -ArgumentList ((Get-ADDomainController -Discover -NextClosestSite).HostName) -Credential $cred |
    Out-File .\esito-reset.csv -Encoding UTF8

Health check massivo e report CSV

Import-Module ActiveDirectory
$targets = Get-ADComputer -Filter { Enabled -eq $true -and OperatingSystem -like "Windows*" } -SearchBase "OU=Workstations,DC=contoso,DC=local" |
           Select-Object -ExpandProperty Name
$cred = Get-Credential
$result = foreach($c in $targets){
    try{
        $ok = Invoke-Command -ComputerName $c -Credential $cred -ScriptBlock { Test-ComputerSecureChannel } -ErrorAction Stop
        [pscustomobject]@{Computer=$c; SecureChannel=$ok}
    } catch {
        [pscustomobject]@{Computer=$c; SecureChannel=$false}
    }
}
$result | Export-Csv .\securechannel-report.csv -NoTypeInformation -Encoding UTF8

Casi particolari e best practice

Laptop spesso offline

Se i portatili restano fuori sede per mesi, la password macchina può desincronizzarsi rispetto ai DC. Puoi:

  • Estendere il valore di Domain member: Maximum machine account password age (es. 90–180 giorni).
  • Assicurare connettività periodica via VPN always‑on o “device tunnel” per consentire il renewal.
  • Evitare di settare DisablePasswordChange=1 (registro HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters): è sconsigliato per la sicurezza.

RODC (Read‑Only Domain Controller)

In filiale con RODC e link WAN instabile:

  • Prepopola la Password Replication Policy includendo i computer della filiale.
  • Garantisci che il RODC possa replicare periodicamente; in caso di rottura ricorri a Reset-ComputerMachinePassword -Server <RODC_FQDN> localmente.

Snapshot e imaging

Mai clonare o eseguire snapshot/rollback di VM già unite al dominio. Per immagini di riferimento usa Sysprep con /generalize oppure disunisci dal dominio prima dello snapshot.

Replica e scelta del DC

Se il problema si presenta subito dopo un reset, punta i comandi al DC di sito del client o al PDC Emulator per ridurre il rischio di mismatch temporaneo. Puoi individuare il PDC con:

netdom query fsmo

In PowerShell:

(Get-ADDomain).PDCEmulator

Kerberos vs NTLM

La rottura del canale sicuro impatta sia Kerberos sia NTLM. Se l’utente riesce ad accedere grazie ai cached logons (criterio “Interactive logon: Number of previous logons to cache”), l’accesso alle risorse di rete fallirà comunque fino al ripristino del secure channel.

Messaggi simili da non confondere

  • “The security database on the server does not have a computer account for this workstation trust relationship”: l’account esiste? Verifica l’oggetto computer in AD (potrebbe essere stato eliminato o rinominato).
  • KRBAPERR_MODIFIED su file server: spesso è SPN duplicato o password macchina non allineata del server, non del client.

Tabella eventi utili (client e DC)

OrigineIDSignificatoAzione
Netlogon5719Nessun DC disponibileDNS, rete, firewall, VPN
Netlogon5722Autenticazione computer fallitaReset password macchina
Netlogon5805Il DC rifiuta l’autenticazione del computerControllo oggetto computer/replica
Netlogon3210Impossibile autenticarsi con DC specificoConnettività verso quel DC
Kerberos4KRBAPERR_MODIFIED (ticket non valido)SPN/password macchina, tempo
Time-Service36/47Time service non sincronizzatoCorreggi W32Time/NTP

Procedura guidata: flusso decisionale

  1. Guasto singolo o diffuso? Se molti PC: partire da tempo/DNS/replica. Se singolo: passa al punto 2.
  2. Test secure channel: Test-ComputerSecureChannel / nltest /sc_verify.
  3. Ripara con Reset-ComputerMachinePassword (target DC locale).
  4. Se fallisce, usa netdom resetpwd con credenziali di dominio.
  5. Se ancora KO: Reset Account da ADUC e riavvia il client.
  6. Ultima spiaggia: disunisci/reinserisci nel dominio (due riavvii).

Domande frequenti

Perché il problema si presenta dopo il cambio password dell’utente?

Il cambio della password utente è spesso coincidente con una fase di contatto con il DC: se il client o i DC hanno tempi sfasati o la replica è lenta, emergono subito problemi di trust già latenti.

Perdo i profili locali se rimuovo e riaggiungo il PC al dominio?

No, i profili utente sono legati ai SID degli utenti, non al SID della macchina. Tuttavia software o criteri legati alla membership potrebbero richiedere un refresh.

Posso evitare il riavvio?

A volte sì, riavviando Netlogon e rigenerando i ticket (klist purge). Ma per certezza operativa (servizi, driver, cache) è consigliato un reboot.

Ha senso disattivare la rotazione della password macchina?

No, è una pratica da evitare: riduce la sicurezza e non risolve le cause (tempo, replica, snapshot). Usala solo in scenari eccezionali e isolati, documentando il rischio.

Funziona anche su Windows 11 o server più recenti?

Sì. I comandi e le logiche descritte sono valide per client Windows 10/11 e server moderni (2016+). Le GUI possono differire leggermente.

Checklist operativa (copia-incolla per ticket)

  • Verifica tempo: w32tm /query /status (tolleranza ≤ 5 minuti).
  • DNS: solo DNS AD configurati nelle schede di rete.
  • Connettività verso DC del site locale.
  • Test-ComputerSecureChannel → se False → reset.
  • Reset-ComputerMachinePassword -Server <DC_FQDN> → riavvio.
  • Se persistente: Reset Account da ADUC o netdom resetpwd.
  • Controlla Event Viewer: Netlogon 5719/5722/5805; Kerberos 4.
  • Se casi multipli: verifica repadmin /replsummary e NTP.

Approfondimento tecnico: cosa succede sotto il cofano

La password macchina è un segreto condiviso tra computer e AD (attributo unicodePwd nell’oggetto computer). Durante il logon al dominio, la workstation stabilisce un canale sicuro con il DC negoziando le chiavi; Kerberos usa i ticket TGT/TGS legati al tempo del sistema. Se l’orologio è fuori tolleranza, i ticket vengono scartati; se la password macchina è diversa, il DC non firma correttamente i messaggi Netlogon e l’autenticazione fallisce. La presenza della password precedente nel DC consente di recuperare situazioni in cui il client ha aggiornato o meno la password a ridosso della replica. Quando la discrepanza supera un “passo”, hai l’errore di trust.

Riepilogo rapido

  • Causa principale: password del canale sicuro non allineata fra client e AD (o tempo fuori tolleranza).
  • Fix immediato: Reset-ComputerMachinePassword o netdom resetpwd; in alternativa Reset Account da ADUC, ultima spiaggia rejoin.
  • Prevenzione: tempo e replica corretti, solo DNS di dominio, niente snapshot di PC uniti al dominio, monitoraggio proattivo e, se serve, aumento dell’intervallo di rinnovo.

Esempi pratici pronti da incollare

Forzare la risincronizzazione oraria client

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /resync /rediscover

Pulizia ticket e riavvio Netlogon

klist purge
net stop netlogon && net start netlogon

Verifica SRV Kerberos/LDAP nel DNS

nslookup -type=SRV kerberos.tcp.<dominio_fqdn>
nslookup -type=SRV ldap.tcp.dc.msdcs.<dominiofqdn>

Matrici di troubleshooting (rapido “causa ↔ azione”)

IndicatorePossibile causaAzione
5719 su molti clientDC non raggiungibili / DNS erratoCorreggi DNS, firewall, routing, VPN
5722/5805 su client specificoPassword macchina desincronizzataReset secure channel (PowerShell/CMD)
KRBAPERR_MODIFIED su file serverSPN/password macchina del serverReset password server, verifica SPN duplicati
Problemi dopo restore VMSnapshot/rollbackSysprep/Disjoin prima di snapshot; reset password macchina
Solo filiale con RODCPRP non adeguataPrepopola cache password macchine/utenti
Ripetuto dopo rejoinReplica lenta, reset su DC “sbagliato”Punta al DC locale o PDC; verifica repadmin

Note di sicurezza e governance

  • Mantenere attiva la rotazione della password macchina rafforza la postura di sicurezza del dominio.
  • Loggare e monitorare i reset di password macchina come evento di manutenzione: utile in audit per correlare incidenti.
  • Documentare le eccezioni (kiosk, DMZ, macchine isolate) e isolarle in OU dedicate con GPO specifiche.

Contenuti essenziali (one‑pager per stampa):

  • Comando chiave: Reset-ComputerMachinePassword -Server <DC_FQDN>
  • Verifica: Test-ComputerSecureChannel -Verbose
  • Alternative: netdom resetpwd | ADUC → Reset Account | Rejoin (ultima opzione)
  • Prevenzione: NTP, DNS AD only, replica OK, no snapshot di PC uniti, monitoraggio periodico.
Python
Active Directory Kerberos PowerShell Troubleshooting Windows Windows Server Windows10
Indice