L’aggiornamento cumulativo di settembre 2026 per Windows 11, KB5124008, ha portato con sé un effetto collaterale che molti amministratori di dominio stanno scoprendo a proprie spese: alcune postazioni perdono il trust relationship con Active Directory, con conseguente impossibilità di autenticarsi usando le credenziali di dominio. Non è un bug generico di rete, ma il risultato di un’interazione precisa tra una patch di sicurezza e una funzionalità introdotta di recente per proteggere gli account macchina: la Machine Identity Isolation.

Se gestite ambienti ibridi con Windows 11 24H2/25H2 joinati a un dominio on-premises, vale la pena capire esattamente cosa succede prima che il problema si presenti in produzione — o per diagnosticarlo rapidamente se è già successo.

Cosa succede in pratica

I dispositivi colpiti mostrano il classico messaggio:

The trust relationship between this workstation and the primary domain failed.

oppure, nella variante italiana:

Non è stato possibile stabilire una relazione di trust protetta tra questa workstation e il dominio primario.

Gli utenti che hanno già effettuato l’accesso in precedenza possono spesso continuare a lavorare grazie alla cache delle credenziali, ma qualunque nuova autenticazione verso il dominio — accesso a share di rete, applicazioni Kerberos-aware, nuovi login — fallisce. Microsoft ha confermato che il problema non interessa la replica di Active Directory né i servizi dei domain controller: è circoscritto ai client (e in alcuni casi ai server membri) che ricevono l’aggiornamento.

La causa: Machine Identity Isolation e configurazioni pregresse

La Machine Identity Isolation è una funzionalità di sicurezza pensata per isolare e proteggere meglio le credenziali dell’account macchina, riducendo la superficie d’attacco per tecniche come il pass-the-hash o il furto del computer account. Il problema emerge nelle configurazioni dove:

• Credential Guard è abilitato sul dispositivo Windows 11;
• il dispositivo è joinato a un dominio Active Directory on-premises tradizionale;
• la Machine Identity Isolation era stata abilitata in precedenza tramite Intune, Group Policy o direttamente via registro di sistema, in un ambiente che non dispone ancora del supporto al Domain Functional Level di Windows Server 2025.

In sintesi: KB5124008 inizia a far rispettare (to honor, nella formulazione Microsoft) impostazioni che erano già presenti nel sistema ma che finora venivano tollerate in modo permissivo. Se il dominio non è ancora pronto ad accettare quella postura di isolamento più rigida, il canale sicuro tra client e domain controller si rompe silenziosamente al successivo tentativo di autenticazione.

È un pattern piuttosto comune nelle patch di hardening Microsoft: la funzionalità di sicurezza esisteva già, ma l’aggiornamento la rende effettiva, e gli ambienti che l’avevano attivata “per prova” o per errore ne pagano il conto mesi dopo.

Come verificare se siete a rischio

Prima di applicare KB5124008 su larga scala, controllate se la Machine Identity Isolation risulta configurata sui vostri endpoint. Da PowerShell, con privilegi amministrativi:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
  -Name "MachineIdentityIsolation" -ErrorAction SilentlyContinue

Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" `
  -Name "MachineIdentityIsolation" -ErrorAction SilentlyContinue

Se uno dei due percorsi restituisce un valore diverso da zero (o comunque configurato), e il dominio è ancora su un Domain Functional Level precedente a Windows Server 2025, è opportuno valutare un test controllato prima del rollout esteso della patch, oppure prepararsi in anticipo con la remediation descritta di seguito.

Come risolvere (o prevenire) il problema

Microsoft indica un percorso di remediation in tre passaggi, da applicare tramite lo stesso canale con cui la policy era stata originariamente distribuita:

1. Disabilitare la Machine Identity Isolation usando lo stesso meccanismo di deployment originale — Intune, Group Policy o registro — così da garantire che la modifica si propaghi correttamente e non venga sovrascritta al successivo refresh delle policy;
2. Riavviare il dispositivo per applicare la modifica alla configurazione di sicurezza;
3. Riparare il canale sicuro con Active Directory, ad esempio con il classico comando PowerShell (richiede il modulo Active Directory RSAT):

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

Su dispositivi dove il canale è irrimediabilmente compromesso e Test-ComputerSecureChannel non risolve, resta l’opzione, più invasiva, di rimuovere e ri-aggiungere il computer al dominio:

Remove-Computer -UnjoinDomainCredential (Get-Credential) -PassThru -Restart
Add-Computer -DomainName "contoso.local" -Credential (Get-Credential) -Restart

Indicazioni operative per chi gestisce parchi macchine Windows 11

Alcuni suggerimenti pratici prima di distribuire KB5124008 su larga scala:

• Verificate il Domain Functional Level del vostro dominio (Get-ADDomain | Select DomainMode) e pianificate l’upgrade a Windows Server 2025 se non è già in programma;
• Fate un audit delle policy GPO e delle configurazioni Intune relative a Credential Guard e Machine Identity Isolation prima di approvare l’update sui canali di distribuzione (WSUS, Intune, Autopatch);
• Distribuite la patch a un anello ring pilota che includa dispositivi con Credential Guard attivo, non solo macchine “generiche”, per intercettare il problema prima del rollout esteso;
• Documentate la procedura di ripristino del canale sicuro nel vostro runbook di incident response: è uno scenario che, una volta noto, si risolve in pochi minuti, ma solo se il team di supporto sa cosa cercare.

Conclusione

Il caso KB5124008 è un promemoria utile: le patch che rafforzano funzionalità di sicurezza già presenti nel sistema possono comportarsi in modo imprevisto quando incontrano configurazioni legacy o parzialmente implementate. La Machine Identity Isolation è, di per sé, un miglioramento importante per la protezione degli account macchina — ma la sua piena efficacia richiede un dominio allineato al Domain Functional Level più recente. Prima di ogni patch Tuesday che tocca l’autenticazione, vale sempre la pena controllare le note di rilascio con l’occhio rivolto non solo a “cosa fa” l’aggiornamento, ma a “cosa inizia finalmente a far rispettare”.

Fonte: Petri IT Knowledgebase