Relazione di trust con il dominio non riuscita dopo KB5124008: Machine Identity Isolation, cause e soluzione

Se dopo l’aggiornamento di settembre alcuni PC Windows 11 a dominio non fanno più entrare gli utenti e mostrano il messaggio “Relazione di trust tra la workstation e il dominio primario non riuscita” (in inglese The trust relationship between this workstation and the primary domain failed), non è il solito account computer scaduto o il PC rimasto spento per mesi. Questa volta c’entra un aggiornamento cumulativo.

Microsoft ha confermato che dopo l’aggiornamento di sicurezza KB5124008 dell’8 settembre 2026, e i cumulativi successivi, alcuni PC perdono il canale sicuro con Active Directory. Il colpevole è una funzione di sicurezza che si chiama Machine Identity Isolation, parte di Credential Guard.

Chi è coinvolto

Il problema non colpisce tutti i PC a dominio, ma solo quelli che hanno Machine Identity Isolation configurata in modalità enforcement, tramite Group Policy, Intune o registro. Le versioni interessate sono:

• Windows 11 24H2, 25H2, 26H1 e 26H2
• dispositivi con Credential Guard attivo
• domini con domain controller che non sono a livello funzionale (DFL) Windows Server 2025.

I server e i domain controller non hanno problemi: la replica AD e i servizi di dominio continuano a funzionare. I sintomi tipici sono:

• l’utente non riesce ad accedere con le credenziali di dominio, anche se sono corrette
• l’accesso con le credenziali memorizzate in cache funziona, quindi chi era già entrato su quel PC spesso non si accorge di nulla, almeno finché non scollega il cavo o cambia password
• compare il messaggio sulla relazione di trust con il dominio.

Cosa è successo davvero

Machine Identity Isolation sposta la password dell’account computer dal registro (LSA) dentro Credential Guard, in un ambiente isolato dalla virtualizzazione. È un’ottima idea per la sicurezza, ma funziona solo con domain controller a livello funzionale Windows Server 2025.

Fino ad agosto Windows ignorava di fatto quell’impostazione. Con KB5124008 la funzione è stata riabilitata e Windows ha cominciato a rispettare le policy già presenti. Chi l’aveva attivata tempo fa, magari in un baseline di sicurezza o in un profilo Intune “hardening” applicato in blocco, si è ritrovato con PC che non riescono più ad autenticarsi su domain controller più vecchi.

La mia regola in questi casi: prima di toccare i PC, capire da dove arriva l’impostazione. Se la correggete a mano su un PC e la GPO la riapplica al successivo gpupdate, tra un’ora siete al punto di partenza.

Come verificare se siete coinvolti

Da un PowerShell come amministratore sul PC che dà problemi (accedete con l’account amministratore locale, o con un account di dominio ancora in cache):

# Controlla le due chiavi di registro indicate da Microsoft
$paths = @(
  'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa',
  'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard'
)
foreach ($p in $paths) {
  $v = (Get-ItemProperty -Path $p -Name MachineIdentityIsolation -ErrorAction SilentlyContinue).MachineIdentityIsolation
  "{0} -> MachineIdentityIsolation = {1}" -f $p, ($(if ($null -eq $v) { 'non presente' } else { $v }))
}

# Stato del canale sicuro con il dominio
Test-ComputerSecureChannel -Verbose

Se una delle due chiavi vale 2 e Test-ComputerSecureChannel restituisce False, avete trovato il colpevole.

Per capire chi ha impostato il valore, generate un report delle policy applicate:

gpresult /h C:\Temp\gpresult.html

Nel report cercate la voce Attiva sicurezza basata su virtualizzazione (Turn On Virtualization Based Security). Per i PC gestiti con Intune, controllate invece i profili con il setting DeviceGuard/MachineIdentityIsolation.

La soluzione

Microsoft è chiara: la funzione va disattivata con lo stesso strumento con cui è stata attivata.

• Group Policy: in Configurazione computer > Modelli amministrativi > Sistema > Device Guard > Attiva sicurezza basata su virtualizzazione impostate Machine Identity Isolation Configuration su Disabled. Lasciate il resto della policy (VBS, Credential Guard) com’è.
• Intune: modificate il profilo e impostate MachineIdentityIsolation su disabilitato.
• Registro: se il valore è stato scritto a mano o da uno script, portatelo a 0.

Per i casi da registro, sul singolo PC:

# Da PowerShell come amministratore: porta a 0 il valore dove vale 2
$paths = @(
  'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa',
  'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard'
)
foreach ($p in $paths) {
  $v = (Get-ItemProperty -Path $p -Name MachineIdentityIsolation -ErrorAction SilentlyContinue).MachineIdentityIsolation
  if ($v -eq 2) {
    Set-ItemProperty -Path $p -Name MachineIdentityIsolation -Value 0
    "Impostato a 0 in $p"
  }
}

Attenzione: prima di modificare il registro fatene un backup. Dopodiché riavviate il PC e ripristinate il canale sicuro con un account di dominio che abbia i permessi sull’oggetto computer:

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

Se il comando restituisce True, gli utenti possono tornare ad accedere con le credenziali di dominio senza altri interventi.

Cosa non fare

• Disinstallare KB5124008? Meglio di no. Vi riportate dietro tutte le vulnerabilità chiuse a settembre e il mese dopo il cumulativo successivo ripropone la stessa situazione.
• Disattivare Credential Guard per intero: non serve, basta spegnere la sola Machine Identity Isolation.
• Togliere e rimettere a dominio tutti i PC come prima mossa: funziona, ma è lavoro inutile se basta correggere la policy e ripristinare il canale sicuro.

Nel frattempo: la soluzione di Microsoft

Microsoft ha annunciato che in un prossimo aggiornamento bloccherà temporaneamente l’enforcement di Machine Identity Isolation, finché la funzione non sarà migliorata. Ricordatevi però che la correzione della policy va fatta comunque: quando la funzione tornerà attiva, i PC con il valore a 2 e i domain controller non ancora a livello Windows Server 2025 si ritroverebbero con lo stesso problema.

Se avete in programma di portare i domain controller a Windows Server 2025 e alzare il livello funzionale, questa è una buona occasione per pianificarlo. Una volta fatto, Machine Identity Isolation torna a essere una protezione utile.

Se il problema persiste

Se dopo il riavvio e il -Repair il canale sicuro non torna, procedete in quest’ordine:

• verificate con gpresult che la policy corretta sia davvero arrivata al PC (gpupdate /force e un altro riavvio)
• controllate data e ora del PC: con più di 5 minuti di differenza dal domain controller Kerberos non funziona comunque
• come ultima spiaggia, togliete il PC dal dominio e rimettetelo. La documentazione Microsoft lo indica come necessario quando il PC era in enforcement e non riesce più ad autenticarsi. Usate l’account amministratore locale, perché con quello di dominio non riuscirete a entrare, e assicuratevi di conoscerne la password prima di iniziare. Se il disco è cifrato con BitLocker, tenete a portata di mano la chiave di ripristino.

Vi è capitato su qualche PC dopo gli aggiornamenti di settembre? Raccontate nei commenti versione di Windows, livello funzionale del dominio e soluzione che ha funzionato: possono essere utili ad altri.