Windows 11 e Active Directory: perché il login può smettere di funzionare dopo KB5124008

Gli aggiornamenti di sicurezza di settembre 2026 per Windows 11 hanno introdotto un ulteriore problema, questa volta uno particolarmente delicato per gli ambienti aziendali: alcuni PC regolarmente aggiunti a un dominio Active Directory possono perdere il canale sicuro con il dominio ed essere impossibilitati ad accedere, anche quando nome utente e password sono corretti. Microsoft ha ora riconosciuto formalmente il malfunzionamento e pubblicato una procedura temporanea per ripristinare i sistemi interessati.

Il bug è apparso dopo l’installazione degli aggiornamenti distribuiti l’8 settembre 2026: KB5124008 per Windows 11 24H2 e 25H2, che porta rispettivamente le build 26100 e 26200 alla 9445, e KB5124012 per Windows 11 26H1, build 28000.2954.

Le prime segnalazioni degli amministratori risalgono praticamente alle ore successive al Patch Tuesday: in diversi casi la rimozione dell’aggiornamento faceva scomparire il problema, che puntualmente ricompariva provando a reinstallare la patch.

La causa della problematica risiede nel fatto che gli aggiornamenti Microsoft di settembre hanno cambiato il comportamento di Windows nei confronti di Machine Identity Isolation, una funzione legata a Credential Guard che protegge le credenziali dell’account computer. L’anomali scaturisce nel momento in cui sul PC esiste già una configurazione che richiede la modalità Machine Identity Isolation, per esempio tramite registro, Group Policy o Intune.

Perché un PC Windows usa una password anche per il proprio account computer

Quando un PC entra nel dominio, Active Directory crea un account computer, identificato normalmente da un nome che termina con il simbolo $.

Anche la macchina possiede quindi una propria credenziale segreta, distinta dalla password dell’utente, utilizzata per autenticarsi verso i domain controller e mantenere il cosiddetto secure channel.

Windows modifica periodicamente il segreto dell’account computer, normalmente con una rotazione automatica. Il client e Active Directory devono naturalmente mantenere copie coerenti della credenziale. Se questa relazione si rompe, Windows può mostrare il noto messaggio secondo cui “la relazione di trust tra questa workstation e il dominio non è riuscita“. Da quel momento l’utente può trovarsi davanti a un login impossibile pur digitando credenziali perfettamente valide.

Nelle segnalazioni raccolte dopo l’installazione del pacchetto cumulativo KB5124008, alcuni amministratori hanno verificato il problema con Test-ComputerSecureChannel, che restituiva False, mentre nltest poteva segnalare ERROR_NO_TRUST_LSA_SECRET. Sono stati inoltre osservati errori NETLOGON e tentativi di autenticazione dell’account computer non riusciti.

Un dettaglio interessante è che l’accesso con credenziali memorizzate nella cache, scollegando il PC dalla rete aziendale, può ancora funzionare: il dominio non riesce a validare la macchina, ma Windows può consentire l’accesso locale utilizzando informazioni già archiviate sul dispositivo.

Che cos’è Machine Identity Isolation e perché Microsoft l’ha introdotta

La password dell’account computer risiede in un segreto gestito da LSA, Local Security Authority. Machine Identity Isolation nasce per ridurre il rischio che tale segreto possa essere estratto e riutilizzato in attacchi contro Active Directory. La funzione sposta la protezione della credenziale della macchina verso Credential Guard, sfruttando la sicurezza basata sulla virtualizzazione e un ambiente isolato dal normale sistema operativo.

Microsoft prevede 3 stati principali. Con il valore 0, la funzione è disattivata e il segreto della macchina resta associato a LSA. Con il valore 1 entra in modalità audit: Windows mantiene una copia protetta tramite Isolated User Mode, ma conserva anche un percorso di fallback. Il valore 2 corrisponde invece al cosiddetto enforcement: la password della macchina rimane soltanto nell’area protetta e Windows elimina il vecchio segreto disponibile attraverso LSA.

È proprio quest’ultima configurazione a rendere la situazione più delicata. Una volta spostato il segreto e cancellata la vecchia copia, disattivare semplicemente la funzione non equivale sempre a tornare allo stato precedente. La documentazione Microsoft avverte da tempo che il passaggio dall’enforcement alla modalità disattivata può rendere necessaria una nuova associazione del computer al dominio.

La patch di settembre non imposta necessariamente MachineIdentityIsolation a 2

L’azienda di Redmond afferma che KB5124008 e KB5124012 non abilitano direttamente l’enforcement. Gli aggiornamenti fanno invece sì che Windows inizi a rispettare eventuali impostazioni già configurate o distribuite attraverso policy.

In pratica, un’organizzazione potrebbe ritrovarsi con MachineIdentityIsolation=2 perché il parametro era già presente nel registro, perché arrivava tramite Group Policy oppure perché una configurazione MDM lo distribuiva ai client.

Alcuni amministratori hanno riferito di non ricordare di avere mai attivato consapevolmente la funzione. È un elemento che rende opportuna una verifica delle configurazioni effettive prima di attribuire automaticamente la modifica alla patch.

Baseline precedenti, modelli ADMX aggiornati, profili Intune, strumenti di sicurezza o modifiche locali possono aver lasciato valori che gli aggiornamenti precedenti non applicavano nello stesso modo.

La soluzione arriva da Microsoft: prima disattivare la funzione, poi riparare il secure channel

In attesa di una patch correttiva, Microsoft consiglia innanzi tutto di disabilitare Machine Identity Isolation usando lo stesso sistema impiegato per abilitarla.

Se l’impostazione arriva da Microsoft Intune, va corretta in Intune; se arriva da una Group Policy, bisogna intervenire sul relativo GPO. Modificare soltanto il registro mentre una policy centrale continua a imporre il valore precedente rischia infatti di produrre una soluzione temporanea: al successivo aggiornamento dei criteri Windows potrebbe ripristinare l’impostazione problematica.

Se la configurazione risulta invece applicata direttamente attraverso il Registro di sistema, Microsoft indica due posizioni da controllare:

• HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MachineIdentityIsolation
• HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\MachineIdentityIsolation

Sui dispositivi Windows 11 24H2 e 25H2, se MachineIdentityIsolation contiene il valore 2, Microsoft suggerisce di portarlo a 0. Dopo la modifica occorre riavviare Windows.

A questo punto Microsoft suggerisce di riparare il secure channel tramite PowerShell eseguendo la cmdlet seguente (verifica e ricostruisce il rapporto di fiducia usando credenziali con i privilegi necessari):

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

Alcuni amministratori riferiscono che il comando PowerShell è sufficiente per riportare la situazione alla normalità; altri hanno dovuto rimuovere completamente la workstation dal dominio, associarla temporaneamente a un workgroup, riavviare e quindi effettuare nuovamente il join.

Come recuperare un PC sul quale l’utente non riesce più ad accedere

Se il computer rifiuta le credenziali di dominio, l’accesso offline con credenziali memorizzate nella cache può offrire una via di recupero.

Scollegando temporaneamente Ethernet e WiFi, un utente che abbia già effettuato l’accesso in precedenza potrebbe ancora riuscire a entrare nel proprio profilo. Da lì un amministratore può ripristinare la connettività e intervenire sulla configurazione, naturalmente disponendo dei privilegi necessari.

La documentazione Microsoft sottolinea inoltre l’importanza di avere a disposizione un account amministratore locale. Se diventa necessario rimuovere il dispositivo dal dominio e aggiungerlo nuovamente, l’operazione richiede proprio credenziali locali adeguate.

A questo proposito, ricordiamo anche che Windows integra un account amministratore nascosto, normalmente disattivato ma riattivabile quando necessario.