Trust relationship failed dopo ripristino DC da backup datato: guida completa per Active Directory

DC ripristinato da backup di 159 giorni e trust rotto? Questa guida pratica spiega perché tutti i PC mostrano “The trust relationship… failed”, come rimettere in piedi tempo, DNS e canali sicuri, e quando ricorrere a reset massivi o a un nuovo Domain Controller, riducendo al minimo i fermi.

Indice

Panoramica del problema

In seguito a un guasto importante, l’unico Domain Controller (DC) del dominio è stato ripristinato da un backup vecchio di circa 159 giorni. Tutti i client Windows, al logon, visualizzano l’errore: “The trust relationship between this workstation and the primary domain failed”. Il contesto è critico perché:

Il DC è l’unico del dominio, quindi non c’è ridondanza né una controparte con cui replicare e validare i dati.
I client hanno cambiato la propria password del computer più volte (per default ogni 30 giorni), mentre il controller è “tornato indietro nel tempo”.
La finestra temporale di backup è vicina ai limiti di tombstone lifetime; inoltre, se il DC fosse più “anziano” del suo USN atteso, il rischio di USN rollback è reale.

Tentativi già eseguiti ed esito

Tentativo	Esito
`Test‑ComputerSecureChannel -Repair`	Errore
`netdom resetpwd`	Segnala successo ma non risolve
Reset dell’account computer in AD	Nessun effetto

Perché accade davvero

Ogni computer membro di dominio mantiene una password del proprio account (oggetto Computer in AD) che ruota periodicamente. Se si riporta indietro il DC, il valore salvato nell’oggetto AD non corrisponde più a quello che i client hanno in locale. Il risultato è la rottura del secure channel (canale sicuro) tra il PC e il DC: Kerberos non si fida, NTLM fallisce, e il logon di dominio non procede.

In parallelo, un DC ripristinato da un backup “vecchio” può mostrare altri sintomi: replica SYSVOL/DFSR in blocco, record DNS obsoleti, tempi di sistema non allineati. Con Kerberos basta uno skew maggiore di ±5 minuti per mandare tutto in errore.

Soluzioni consigliate a colpo d’occhio

Area	Azioni consigliate
Verifica backup	Controllare i log di sistema e applicazione per segni di corruzione o servizi AD/DFSR in stato anomalo; accertarsi che il System State sia integro.
Sincronizzazione oraria	Allineare ora su DC e client; Kerberos tollera ±5 minuti. Verificare `w32tm` e il ruolo PDC Emulator.
Ripetere `netdom resetpwd`	Eseguire come Domain Admin, specificando `/Server:<DC> /UserD:<DomainAdmin> /PasswordD:<Pwd>` sul client interessato.
DNS	Assicurarsi che i client puntino al DC come DNS primario e che il DC risolva correttamente i record AD (SRV, LDAP, GC).
`Test‑ComputerSecureChannel`	Rieseguire (anche con `-Repair`) dopo aver sistemato DNS e ora; usare credenziali di dominio se richieste.
Account computer in AD	Verificare che l’oggetto non sia disabilitato o stantio; reimpostare la password se necessario.
Script/GPO	Automazione per resettare la password su più PC, con log e fallback.
Rimuovere e riaggiungere al dominio	Ultima ratio se i reset non funzionano o il canale sicuro non si ripristina.
Modalità di ripristino AD	Valutare restore non‑authoritative o authoritative per oggetti critici; operazioni da eseguire con cautela.
Supporto professionale	Coinvolgere supporto specializzato se l’ambiente è complesso o se si sospetta USN rollback.

Playbook operativo

Allineare subito l’ora

Il DC con ruolo PDC Emulator deve essere l’origine oraria autorevole del dominio. Se è l’unico DC, configurarlo verso un NTP esterno affidabile e verificare che i client ereditino dal dominio.

REM Sul DC (PDC Emulator)
w32tm /query /status
w32tm /query /configuration
w32tm /config /manualpeerlist:"0.pool.ntp.org,0x9 1.pool.ntp.org,0x9" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /rediscover

REM Sul client
w32tm /query /status
w32tm /config /syncfromflags:DOMHIER /update
w32tm /resync

Rimettere in sesto il DNS

I client devono usare solo il DC come DNS primario (evitare DNS pubblici). Il DC deve pubblicare SRV per LDAP, GC e Kerberos.

REM Sul DC
dcdiag /test:dns /dnsall /e /v

REM Dal client
ipconfig /all
ipconfig /flushdns
nslookup -type=SRV ldap.tcp.dc._msdcs.

Correggere eventuali IP errati, zone mancanti, forwarders o record SRV non pubblicati.

Ripristinare il secure channel del singolo PC

Agire prima da riga di comando (più veloce), poi da PowerShell se serve più verbosità.

REM Eseguire sul PC con problemi (come amministratore locale)
netdom resetpwd /server:<DC> /ud:<DOMINIO\Administrator> /pd:*

REM Verifica con NLTEST
nltest /sc_verify:
nltest /sc_reset:<DC>

# PowerShell sul PC interessato
Test-ComputerSecureChannel -Verbose
Se fallisce:
Test-ComputerSecureChannel -Repair -Verbose
Oppure, specificando DC e credenziali:
Reset-ComputerMachinePassword -Server &lt;DC&gt; -Credential (Get-Credential &lt;DOMINIO\Administrator&gt;)

Se questi passaggi non ripristinano il trust, procedere con la rimozione e la nuova associazione al dominio.

Rimozione e nuova associazione al dominio

È l’ultima ratio, ma spesso è la soluzione più rapida quando il DC è stato riportato troppo indietro rispetto ai client.

# Eseguire come amministratore locale sul PC
Remove-Computer -UnjoinDomainCredential <DOMINIO\Administrator> -PassThru -Verbose -Restart

Dopo il riavvio, rientrare nel dominio

Add-Computer -DomainName  -Credential  `
-OUPath "OU=Workstations,DC=contoso,DC=local" -Restart

Controllare lo stato dell’account computer in AD

Verificare che l’oggetto non sia disabilitato o fuori uso e controllare gli attributi chiave.

# Dal DC, modulo ActiveDirectory
Get-ADComputer -Identity &lt;PCNAME&gt; -Properties Enabled,PasswordLastSet,LastLogonDate
Per reimpostare la password dall'AD:
Set-ADAccountPassword -Identity &lt;PCNAME$&gt; -Reset
Enable-ADAccount -Identity &lt;PCNAME$&gt;

Automazione per più PC

Quando molti client lamentano la stessa anomalia, conviene usare un piccolo script per tentare il ripristino del secure channel in batch, con log e fallback. Esempio di script PowerShell da eseguire da una postazione amministrativa con reachability di rete e credenziali di dominio:

# repair-secure-channel.ps1
param(
  [Parameter(Mandatory)] [string]$ComputerListPath
)
$cred = Get-Credential -Message "Credenziali di dominio con diritti locali sui client"
$computers = Get-Content $ComputerListPath
$log = Join-Path $PSScriptRoot ("repair" + (Get-Date -Format 'yyyyMMddHHmm') + ".log")

foreach($c in $computers){
try {
"$c - Verifica canale sicuro..." | Tee-Object -FilePath $log -Append
$ok = Test-ComputerSecureChannel -Server (Get-ADDomainController -Discover).HostName `          -ComputerName $c -Credential $cred -ErrorAction Stop
    if($ok){
      "$c - OK" | Tee-Object -FilePath $log -Append
    } else {
      "$c - Tentativo di riparazione..." | Tee-Object -FilePath $log -Append
      Test-ComputerSecureChannel -Repair -ComputerName $c -Credential $cred -Verbose`
2>&1 | Tee-Object -FilePath $log -Append
}
} catch {
"$c - Errore: $_" | Tee-Object -FilePath $log -Append
}
}

Nota: usare la disjoin/join automatica via script solo se si dispone di un piano di rollback e di credenziali sicure (ad esempio con Just Enough Administration o account temporanei).

Approfondimenti critici

Tombstone lifetime e oggetti “lingering”

Con backup di ~159 giorni, la tombstone lifetime (tipicamente 180 giorni nei domini moderni, 60 nei domini più vecchi) è quasi raggiunta. Se tale periodo viene superato, gli oggetti eliminati logicamente non sono più replicabili e si rischiano oggetti lingering quando si reintroducono DC con viste divergenti.

Consiglio: se si prevede di aggiungere un secondo DC dopo il ripristino, accertarsi che la replica AD sia coerente e monitorare eventuali eventi di lingering; all’occorrenza pianificare una ripulitura mirata con gli strumenti appropriati, eseguendo sempre prima un backup.

USN rollback

Se il DC è stato riportato a uno stato con numeri di sequenza aggiornamenti (USN) più vecchi di quelli conosciuti dai partner (o è stato ripreso da snapshot), si entra in USN rollback. In questo stato il DC non è più affidabile come replica: l’unica correzione supportata è demotare il controller e promuoverne uno nuovo, ricostruendo la replica da zero.

Strategie pratiche quando esiste un solo DC

Nuovo DC pulito come obiettivo

Stabilizzare l’attuale DC quel tanto che basta per permettere la join di un nuovo server come membro di dominio (tempo e DNS a posto).
Installare un nuovo Windows Server aggiornato, unirlo al dominio e promuoverlo a Domain Controller con DNS.
Trasferire i ruoli FSMO sul nuovo DC e verificare: Schema, Domain Naming, RID, PDC Emulator, Infrastructure.
Convalidare replica AD e SYSVOL, poi pianificare la rimozione del vecchio DC (decommission) in modo pulito.

# Sul nuovo DC (modulo AD)
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSDomainController -DomainName &lt;dominio.local&gt; -InstallDNS

Trasferimento FSMO

Move-ADDirectoryServerOperationMasterRole -Identity <NUOVO-DC> `
-OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster </code></pre>

<h3>Riutilizzare il DC vecchio con restore autorevole selettivo</h3>
<p>Se non è possibile allestire subito un nuovo server, valutare in isolamento un <em>authoritative restore</em> solo degli oggetti indispensabili (ad esempio <em>KRBTGT</em>, gruppi amministrativi, OU Domain Controllers), quindi rientrare in produzione con grande cautela e, appena possibile, introdurre un secondo DC nuovo per avere ridondanza.</p>
<pre><code>REM Avvio in Directory Services Restore Mode (DSRM)
REM Ripristino System State, poi:
ntdsutil
activate instance ntds
authoritative restore
restore object "CN=krbtgt,CN=Users,DC=contoso,DC=local"
quit
</code></pre>
<p><strong>Attenzione:</strong> queste operazioni richiedono pratica ed elevato rischio operativo. Pianificare sempre snapshot del server <em>nuovo</em> (non del DC), backup e finestra di manutenzione.</p>

<h3>Reset sicuro dell’account KRBTGT</h3>
<p>Dopo il ripristino, è buona norma ruotare l’account <code>KRBTGT</code> (due volte, con replica completata tra un cambio e l’altro) per invalidare ticket Kerberos potenzialmente emessi prima del guasto.</p>
<pre><code># Dal DC con modulo ActiveDirectory
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (Read-Host -AsSecureString "Nuova password")
Attendere replica, poi eseguire un secondo reset con password diversa
</code></pre>

<h2>Client ancora fuori dominio dopo la stabilizzazione</h2>
<p>Anche con tempo e DNS corretti, alcuni PC possono restare “bloccati” con trust rotto. Nella pratica, spesso è più rapido:</p>
<ol>
  <li>Logon con amministratore locale;</li>
  <li>Rimozione dal dominio e riavvio;</li>
  <li>Join di nuovo al dominio (specificando eventualmente l’OU di destinazione);</li>
  <li><code>gpupdate /force</code> e verifica policy.</li>
</ol>
<p>Richiamare l’utente solo quando il canale sicuro è ripristinato e il profilo non viene rigenerato in modo indesiderato.</p>

<h2>Checklist di pronto intervento</h2>
<ul>
  <li>Verificare che il DC risponda a LDAP/Kerberos/DNS e che SYSVOL sia condiviso.</li>
  <li>Impostare correttamente l’origine oraria (PDC Emulator) e confermare <code>w32tm</code>.</li>
  <li>Correggere i DNS dei client: primario = DC; rimuovere DNS pubblici dalle NIC.</li>
  <li>Eseguire <code>Test‑ComputerSecureChannel</code> e <code>netdom resetpwd</code> sui client.</li>
  <li>Se fallisce, disjoin ➜ riavvia ➜ rejoin al dominio.</li>
  <li>Pianificare subito un secondo DC e trasferimento FSMO.</li>
  <li>Eseguire backup affidabili e test di ripristino a caldo.</li>
</ul>

<h2>Diagnostica approfondita</h2>
<h3>Event Viewer</h3>
<ul>
  <li><strong>Directory Service</strong>: errori di replica, segnali di USN rollback, oggetti lingering.</li>
  <li><strong>DFS Replication</strong>: stato di SYSVOL; eventuali blocchi da autorecupero in seguito a interruzioni prolungate.</li>
  <li><strong>System</strong>: W32Time, Netlogon, DNS Server, KDC.</li>
</ul>

<h3>Strumenti e comandi utili</h3>
<pre><code>repadmin /replsummary
repadmin /showrepl *
dcdiag /v
dcdiag /test:sysvolcheck /test:advertising
nltest /dclist:&lt;DOMINIO&gt;
whoami /upn
klist purge
</code></pre>

<h2>Errori comuni da evitare</h2>
<ul>
  <li><strong>Usare DNS pubblici sui client</strong>: impedisce la localizzazione del DC e dei servizi AD.</li>
  <li><strong>Ignorare l’orario</strong>: skew &gt; 5 minuti = Kerberos KO.</li>
  <li><strong>Ripristinare DC da snapshot</strong>: porta facilmente a USN rollback.</li>
  <li><strong>Forzare reset massivi senza log</strong>: difficile tracciare cosa è stato corregto e cosa no.</li>
  <li><strong>Operare senza backup attuale</strong>: ogni intervento su AD va sempre preceduto da un System State recente.</li>
</ul>

<h2>Prevenzione per il futuro</h2>
<ul>
  <li>Almeno due DC per dominio in <em>site</em> diversi, con replica verificata.</li>
  <li>Backup del System State frequente e archiviazione off‑site; eseguire restore testati periodicamente.</li>
  <li>Monitoraggio costante di repliche AD e DFSR, con alert su errori critici.</li>
  <li>Controllo del ruolo PDC Emulator come <em>time source</em> e GPO coerenti per l’orario.</li>
  <li>Politiche di <em>break-glass</em> per accessi di emergenza e runbook documentati.</li>
</ul>

<h2>Passi minimi raccomandati</h2>
<ol>
  <li>Impostare l’ora corretta su DC e client; verificare <code>w32tm /query /status</code>.</li>
  <li>Controllare DNS su DC (<code>dcdiag /test:dns</code>) e che i client puntino a quel DNS.</li>
  <li>Su ogni client:
    <pre><code>Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Verbose  # se il primo fallisce

Se fallisce ancora, dal client come Admin locale: disjoin dal dominio ➜ riavvia ➜ join di nuovo.
Nel frattempo, programmare la creazione di un secondo DC e un piano di backup affidabile.

Domande frequenti

Perché netdom resetpwd dice “successo” ma non cambia nulla?
Se l’orario o il DNS non sono corretti, il reset può fallire in modo silente. Allineare tempo, verificare SRV e ritentare. In alcuni casi, l’account computer locale è troppo divergente e serve la disjoin/join.

Quanto incide il backup di 159 giorni?
Moltissimo: si sfiora la finestra tipica di tombstone e si perde la storia delle password macchina. Se compaiono sintomi di replica/USN rollback, demotare e promuovere un DC nuovo è spesso la cura più sicura.

Conviene forzare la politica che impedisce il cambio password dei computer?
No. È un palliativo che indebolisce la sicurezza e non risolve l’incongruenza del DC ripristinato. Meglio rimettere in coerenza dominio e client.

Posso usare GPO per riparare il trust?
Sì, ma con prudenza. Un startup script che esegue Test‑ComputerSecureChannel -Repair può aiutare in ambienti ampi, purché sia ben loggato e usi credenziali protette.

Conclusione

La perdita di trust dopo il ripristino di un unico DC da un backup datato è un incidente insidioso ma affrontabile con un approccio disciplinato: tempo e DNS prima di tutto, reset mirati dei canali sicuri, rimozione e ri‑join dove serve. In parallelo, va tracciata una via d’uscita strutturale: introdurre un secondo Domain Controller, trasferire FSMO e mettere in sicurezza backup e monitoraggio. Così si ristabilisce la fiducia tra client e dominio oggi e si evita di rivivere lo stesso problema domani.

Seguendo questi passaggi si ristabilisce la fiducia client‑dominio e si riduce drasticamente il rischio di ripetere l’incidente.

Riepilogo operativo in una tabella

Fase	Obiettivo	Comandi chiave	Esito atteso
Orario	Allineare Kerberos	`w32tm /query /status`, `w32tm /resync`	Skew < 5 minuti
DNS	Risoluzione AD	`dcdiag /test:dns`, `nslookup SRV`	SRV OK, client puntano al DC
Secure channel	Riparare trust	`netdom resetpwd`, `Test‑ComputerSecureChannel -Repair`	Logon dominio ripristinato
Fallback	Forzare coerenza	`Remove-Computer`, `Add-Computer`	PC rientra nel dominio
Resilienza	Evitare recidive	`Install-ADDSDomainController`, `Move-ADDirectoryServerOperationMasterRole`	Secondo DC attivo

Informazioni supplementari utili

Tombstone Lifetime e USN‑rollback
- Con backup ~159 giorni, la tombstoneLifetime tipica (180 giorni nei domini recenti, 60 nei più vecchi) è quasi oltrepassata: molte eliminazioni logiche potrebbero non essere più replicabili.
- Un ripristino del DC più “vecchio” del suo USN attuale può causare USN rollback: in questo caso la correzione supportata è demotare il DC e promuoverne uno nuovo.
Strategia praticabile quando il DC è l’unico esistente
- Costruire un nuovo DC pulito e migrare i ruoli FSMO, invece di forzare il vecchio backup.
- Se si deve riutilizzare il DC vecchio, eseguire in isolamento un authoritative restore dei soli oggetti essenziali (KRBTGT, Admins, Domain Controllers OU) e poi introdurre un secondo DC nuovo per avere ridondanza.
Client ancora fuori dominio
- Spesso è più rapido rimuovere i PC dal dominio, riavviare e ri‑aggiungerli dopo che il DC è stabile, piuttosto che inseguire trust incrinati uno ad uno.
Prevenzione futura
- Almeno due DC per dominio in siti diversi.
- Backup System State frequente e off‑site; test periodici di ripristino.
- Monitoraggio repliche AD e alert su errori DFSR/NTDS.

Best practice di sicurezza e operatività

Usare account con privilegi minimi per gli script; elevare solo quando serve.
Tenere separati i ruoli: amministrazione AD, gestione DNS/DHCP, patching server.
Documentare le password di ripristino DSRM e custodirle in cassaforte digitale.
Evitare snapshot dei DC in produzione; preferire backup applicativi del System State.

Indicatori da monitorare a regime

repadmin /replsummary senza errori persistenti.
Eventi KDC e Kerberos puliti su DC e client.
DFSR privo di eventi critici; condivisione SYSVOL presente e accessibile.
Tempo e NTP in conformità su tutti i sistemi.

In sintesi: fissare tempo e DNS spesso risolve oltre metà dei casi di trust rotto. Per il resto, riparare o rigenerare il canale sicuro, e se il DC è stato riportato troppo indietro, pianificare rapidamente un nuovo DC e la migrazione dei ruoli. Una volta tornati operativi, investire in ridondanza, backup e monitoraggio facendo tesoro dell’incidente.

Hai un ambiente con vincoli particolari (RODC, siti remoti, client legacy)? Adatta il playbook: l’ordine resta tempo → DNS → secure channel → fallback; evita scorciatoie che compromettano sicurezza e coerenza dell’AD.