Errore di trust tra workstation e dominio in Windows: soluzione definitiva e prevenzione

Ecco come risolvere l’errore di trust tra workstation e dominio in Windows quando compaiono messaggi come “There is no logon server available” o “The security database… trust relationship”. Procedura dettagliata, cause, verifiche e prevenzione per ridurre i tempi di fermo.

Indice

Cos’è l’errore di trust tra workstation e dominio

In un dominio Active Directory, ogni computer ha un account macchina con una password segreta condivisa con i Domain Controller (DC). Questa password viene aggiornata automaticamente, per impostazione predefinita, ogni 30 giorni. L’accesso al dominio, l’applicazione delle Group Policy e l’emissione di ticket Kerberos dipendono dall’esistenza di un secure channel integro tra la workstation e il DC. Se la password del computer non coincide più con quella memorizzata in Active Directory, o se fattori di rete/tempo impediscono la validazione, il secure channel si rompe: nasce così l’errore di trust.

Sintomi e messaggi tipici

In fase di logon: There are currently no logon servers available to service the logon request.
Durante un tentativo di rejoin: The security database on the server does not have a computer account for this workstation trust relationship.
Applicazione GPO e accesso a risorse di rete che falliscono, con errori Kerberos o SMB.
Eventi in Visualizzatore eventi > Registri di Windows > Sistema correlati a Netlogon e Kerberos (es. ID 3210 sul client; 5722, 5805 sui DC).

Verifiche rapide prima di agire

Prima di passare alla procedura risolutiva, elimina i falsi positivi con controlli essenziali:

DNS corretto: imposta come DNS preferito un DC autorevole del dominio (non DNS pubblici). Verifica: ipconfig /all nslookup -type=SRV ldap.tcp.dc._msdcs.contoso.local ping dc01.contoso.local
Tempo allineato: Kerberos tollera uno skew di ~5 minuti. Verifica e risincronizza: w32tm /query /status w32tm /resync /force
Porte e firewall: assicurati che le porte AD siano raggiungibili dal client (vedi tabella più avanti). Un blocco su 88/389/445/135/53/464 può simulare una rottura del trust.

Procedura completa risolutiva

Questa è la sequenza più affidabile quando il PC era già nel dominio e non riesce più ad autenticarsi. Funziona nella vasta maggioranza dei casi.

Accedi con l’amministratore locale
Disconnetti temporaneamente la rete (stacca il cavo o disattiva il Wi‑Fi) e accedi con un account locale dotato di diritti amministrativi. La disconnessione evita che il computer tenti, invano, la convalida di dominio prima di permetterti l’accesso locale. Consiglio: se non ricordi la credenziale locale ma hai ancora accesso, abilita preventivamente (in ambienti gestiti) il Local Administrator Password Solution o conserva utenze break‑glass sicure.
Rimuovi il PC dal dominio
1. Questo PC → Proprietà → Impostazioni avanzate di sistema.
2. Scheda Nome computer → Cambia….
3. Seleziona Workgroup (es. WORKGROUP) e conferma.
4. Riavvia quando richiesto.
Alternativa PowerShell (se il client è ancora in grado di eseguire script amministrativi): Remove-Computer -UnjoinDomainCredential (Get-Credential) -PassThru -Verbose -Restart
Ri‑unisci il PC al dominio
1. Dopo il riavvio, accedi ancora come amministratore locale.
2. Ripeti il percorso precedente, seleziona Domain, inserisci il FQDN del dominio (es. contoso.local).
3. Fornisci credenziali con permesso di join (di norma un Domain Admin o un utente con delega Add workstations to domain).
4. Riavvia nuovamente quando richiesto.
Alternativa PowerShell: Add-Computer -DomainName contoso.local -Credential (Get-Credential) -Restart
Verifica connettività e ora
- Allineamento orario: w32tm /resync.
- DNS/risoluzione: vedi comandi in “Verifiche rapide”.
- Connettività porte: Test-NetConnection dc01.contoso.local -Port 88 Test-NetConnection dc01.contoso.local -Port 389 Test-NetConnection dc01.contoso.local -Port 445 Test-NetConnection dc01.contoso.local -Port 135

Conferme post‑join

whoami /fqdn
echo %LOGONSERVER%
klist
dir \\contoso.local\SYSVOL

Se tutti i comandi rispondono coerentemente (utente di dominio, logon server valorizzato, ticket Kerberos presenti, accesso a SYSVOL), il trust è stato ripristinato.

Alternative veloci se la procedura standard fallisce

In alcuni scenari (controller di dominio temporaneamente irraggiungibili, VM riportate da snapshot, necessità di preservare SID e ACL) puoi usare approcci mirati.

Opzione	Comando/Tool	Quando usarla
Reset del computer account da AD	Active Directory Users and Computers → tasto destro sul computer → Reset Account	Utile se l’oggetto è “bloccato” ma vuoi conservare lo stesso SID e le relative ACL su file share
Rigenerare la password macchina da client	`Reset-ComputerMachinePassword -Credential (Get-Credential)`	Alternativa rapida senza uscire/rientrare dal dominio; tenta la riparazione del secure channel
Netdom (vecchi sistemi)	`netdom resetpwd /server:DC_FQDN /userd:DOM\Admin /passwordd:*`	Disponibile in RSAT o su server; equivalente storico a PowerShell
Ricreare il computer account	Elimina l’oggetto in AD, quindi esegui un nuovo join (genera nuovo SID)	Da usare se l’account è corrotto o mancante; attenzione a profili e ACL lato file server

Diagnostica avanzata

Test di secure channel e dominio

nltest /sc_verify:CONTOSO
nltest /dsgetdc:contoso.local
Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Eventi da controllare

Client: Netlogon ID 3210 (autenticazione computer fallita), Kerberos errori KDCERRSKEW (orologio).
Domain Controller: Netlogon ID 5722/5805 (autenticazione computer fallita o account inesistente/disabilitato).

Replica e salute del dominio

Se il problema si ripresenta o coinvolge più client, verifica DC e replica:

dcdiag /v
repadmin /replsummary
repadmin /showrepl
Get-ADReplicationFailure -Scope Site -Target Default-First-Site-Name

Ambienti ibridi e RODC

RODC (Read‑Only Domain Controller): alcune password macchina potrebbero non essere memorizzate localmente. Assicurati che il client contatti un DC scrivibile per il reset.
Join ibrido AAD: il reset del secure channel riguarda la parte AD on‑prem. Valuta anche dsregcmd /status per lo stato del dispositivo in Azure AD se usi scenari ibridi.

Porte e servizi indispensabili

Servizio	Porta/Proto	Uso	Verifica rapida
Kerberos	88 TCP/UDP	Ticket di autenticazione	`Test-NetConnection DC -Port 88`
LDAP	389 TCP/UDP	Bind, query AD	`Test-NetConnection DC -Port 389`
LDAPS	636 TCP	LDAP su TLS (se abilitato)	`Test-NetConnection DC -Port 636`
Global Catalog	3268/3269 TCP	Query GC / LDAPS GC	`Test-NetConnection DC -Port 3268`
SMB	445 TCP	SYSVOL/NETLOGON, GPO	`dir \\dominio\SYSVOL`
RPC Endpoint	135 TCP	RPC endpoint mapper	`Test-NetConnection DC -Port 135`
RPC dinamiche	49152–65535 TCP	RPC DCOM (varie funzioni AD)	Verifica con firewall policy
DNS	53 TCP/UDP	Risoluzione FQDN e record SRV	`nslookup ldap.tcp.dc._msdcs.contoso.local`
Kerberos change pwd	464 TCP/UDP	Cambio password macchina/utente	`Test-NetConnection DC -Port 464`

Motivi comuni della rottura del trust

Rotazione della password macchina non replicata correttamente tra i DC.
Snapshot o restore di VM riportate a uno stato con password macchina obsoleta.
Skew orario oltre i 5 minuti, che invalida i ticket Kerberos.
Oggetto computer disabilitato, eliminato o spostato in OU con policy restrittive.
DNS errato sul client (DNS pubblico o non autorevole) che impedisce di trovare i DC.
Replica AD degradata o DC fuori sync.
Firewall/IPS che blocca porte essenziali (soprattutto 88, 389, 445, 135, 53, 464).
Clonazione immagini senza sysprep o generalize corretti, con SID e account confliggenti.

Prevenzione e buone pratiche

Replica sana dei DC e servizio Kerberos Key Distribution Center attivo su tutti i controller.
Monitoraggio password macchina > 30 giorni: Get-ADComputer -Filter * -Properties PasswordLastSet | Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-30) } | Select-Object Name, PasswordLastSet | Sort-Object PasswordLastSet
NTP affidabile: PDC Emulator sincronizzato con un’origine esterna affidabile; i membri di dominio sincronizzano dai DC.
DNS corretto by design: nei template DHCP, imposta come DNS gli IP dei DC; evita DNS pubblici sui client di dominio.
Snapshot consapevoli: dopo un restore pianificato di VM, esegui Reset-ComputerMachinePassword o “Reset Account” in AD prima dell’avvio delle VM ripristinate.
Non disabilitare la rotazione delle password macchina (DisablePasswordChange): aumenta il rischio di rottura del trust ed espone a rischi di sicurezza.
Deleghe mirate: assegna il diritto “Add workstations to domain” a team di supporto per ridurre i tempi di ripristino senza fornire privilegi eccessivi.
Baseline e hardening: applica GPO che non interferiscano con Netlogon/Kerberos; valida i cambiamenti con ambienti di test.

Domande frequenti

Perdo i profili utente se esco e rientro nel dominio?

Il rejoin conserva i profili locali, ma se ricrei l’account computer (nuovo SID) potrebbe essere generato un profilo utente “nuovo” al prossimo logon. Per mantenere il profilo originale, verifica il mapping in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList o usa procedure di migrazione profilo con attenzione.

Posso risolvere senza uscire dal dominio?

Sì, prova prima con Test-ComputerSecureChannel -Repair o Reset-ComputerMachinePassword. Se falliscono, passa alla procedura completa di uscita → workgroup → nuovo join.

Serve un riavvio?

Sì, un riavvio è richiesto quando cambi l’appartenenza a dominio/workgroup e spesso è consigliato anche dopo il reset del secure channel.

Posso operare da remoto?

Se PSRemoting/WinRM è abilitato e il trust non impedisce il canale remoto, puoi tentare Invoke-Command o Enter-PSSession. In caso di blocco, pianifica l’accesso console o KVM.

Checklist operativa rapida

Controlla DNS, raggiungibilità DC e skew orario.
Prova Test-ComputerSecureChannel -Repair.
Se persiste: accedi con admin locale offline, esci dal dominio → entra in workgroup → ri‑entra nel dominio.
Verifica whoami /fqdn, %LOGONSERVER%, klist e accesso a \\dominio\SYSVOL.
Analizza eventi Netlogon/Kerberos e stato replica DC (dcdiag/repadmin) per prevenire recidive.

Procedura standard riassunta

Seguendo la sequenza uscita dal dominio → join a workgroup → nuovo join al dominio, la relazione di trust viene rigenerata e l’errore scompare nella quasi totalità dei casi. In alternativa, quando opportuno, puoi limitarti al reset della password macchina o dell’account computer in AD per una correzione puntuale.

Esempi pratici di comando end‑to‑end

Riparazione rapida del secure channel

# Esegui come amministratore sul client
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
In alternativa:
Reset-ComputerMachinePassword -Server dc01.contoso.local -Credential (Get-Credential)

Uscita e rejoin completamente automatizzati

# Uscita (richiede credenziali di dominio se il secure channel è ancora parzialmente funzionante)
Remove-Computer -UnjoinDomainCredential (Get-Credential) -PassThru -Verbose -Restart

Dopo il riavvio, eseguire:

Add-Computer -DomainName contoso.local -Credential (Get-Credential) -OUPath "OU=Workstations,OU=IT,DC=contoso,DC=local" -Restart

Validazione post‑intervento

whoami /fqdn
gpresult /r
klist get krbtgt
nltest /sc_verify:CONTOSO
dir \\contoso.local\SYSVOL

Note operative importanti

OU di destinazione: durante il rejoin, specifica un’OU adeguata per applicare le GPO corrette fin da subito.
Antivirus/EDR: talvolta componenti di protezione bloccano RPC/SMB: valuta una modalità di manutenzione per la finestra di riparazione.
Policy di rete: in reti segmentate, coordina con i team di rete per aprire temporaneamente le porte necessarie al ripristino.
Audit: registra il motivo, l’orario e le azioni eseguite; utili per capire pattern ricorrenti (es. problemi di replica legati a un sito remoto).

Riepilogo

Il messaggio “There is no logon server available…” o “The security database on the server does not have a computer account for this workstation trust relationship” indica la perdita del secure channel tra PC e dominio. Nella pratica, il ripristino più efficace è: accesso locale, uscita dal dominio con passaggio a workgroup, nuovo join al dominio e verifica di rete/tempo/DNS. Quando necessario, strumenti come Reset-ComputerMachinePassword, netdom resetpwd e il Reset Account in AD consentono di accorciare i tempi. Con replica sana, NTP affidabile e DNS corretti, l’errore di trust diventa raro e facilmente gestibile.