In questo articolo Indice dei contenuti 3 sezioni
Chi gestisce reti aziendali con Windows 11 ha trovato una brutta sorpresa dopo l’installazione di KB5124008: alcuni PC regolarmente aggiunti a un dominio Active Directory hanno perso il canale sicuro con il dominio, con il risultato che l’accesso diventa impossibile anche digitando nome utente e password perfettamente validi. Microsoft ha riconosciuto il malfunzionamento e ha pubblicato una procedura temporanea per rimettere in piedi le macchine coinvolte, in attesa di una correzione definitiva.
Il problema si manifesta dopo gli aggiornamenti distribuiti l’8 settembre 2026, cioè KB5124008 per Windows 11 24H2 e 25H2, che porta le build 26100 e 26200 alla 9445, e KB5124012 per Windows 11 26H1, build 28000.2954. Le prime segnalazioni degli amministratori sono arrivate a poche ore dal Patch Tuesday. In diversi casi la rimozione dell’aggiornamento faceva sparire il guaio, che però tornava puntualmente al tentativo di reinstallare la patch. La radice di tutto sta in un cambio di comportamento verso Machine Identity Isolation, funzione legata a Credential Guard che protegge le credenziali dell’account computer. L’anomalia scatta quando sul PC esiste già una configurazione che richiede quella modalità, impostata via registro, Group Policy oppure Intune.
Anche il computer ha una sua password, e quando si rompe il trust cade tutto
Quando una macchina entra nel dominio, Active Directory crea un account computer, riconoscibile dal nome che termina con il simbolo del dollaro. Quell’account possiede una credenziale segreta, diversa da quella dell’utente, usata per autenticarsi verso i domain controller e mantenere il cosiddetto secure channel. Windows cambia periodicamente quel segreto con una rotazione automatica, e client e Active Directory devono conservarne copie coerenti. Se la relazione si rompe, compare il classico messaggio sulla relazione di trust tra workstation e dominio non riuscita, e da quel momento il login si blocca.
Diversi amministratori hanno verificato la situazione con Test-ComputerSecureChannel, che restituiva False, mentre nltest segnalava ERRORNOTRUSTLSASECRET. Sono stati osservati anche errori NETLOGON e tentativi di autenticazione dell’account computer non riusciti. Curiosamente, l’accesso con credenziali memorizzate nella cache può ancora funzionare scollegando il PC dalla rete aziendale: il dominio non riesce a validare la macchina, ma Windows consente l’ingresso locale sfruttando informazioni già archiviate sul dispositivo.
Machine Identity Isolation, i tre stati e il nodo dell’enforcement
La password dell’account computer vive in un segreto gestito da LSA, la Local Security Authority. Machine Identity Isolation è nata per ridurre il rischio che quel segreto venga estratto e riutilizzato in attacchi contro Active Directory, spostandone la protezione su Credential Guard, quindi su sicurezza basata sulla virtualizzazione e ambiente isolato dal sistema operativo.
Gli stati previsti sono 3. Con valore 0 la funzione è spenta e il segreto resta legato a LSA. Con valore 1 si entra in modalità audit, con una copia protetta tramite Isolated User Mode e un percorso di fallback ancora disponibile. Il valore 2 è l’enforcement: la password della macchina rimane solo nell’area protetta e il vecchio segreto accessibile da LSA viene eliminato. Proprio qui sta il punto delicato, perché disattivare la funzione non riporta sempre allo stato precedente e la documentazione Microsoft avverte da tempo che il ritorno dall’enforcement può richiedere un nuovo join al dominio.
Microsoft precisa che KB5124008 e KB5124012 non abilitano direttamente l’enforcement. Gli aggiornamenti fanno invece rispettare a Windows impostazioni già presenti o distribuite via policy. Un’azienda può quindi ritrovarsi con MachineIdentityIsolation impostato a 2 perché il parametro era già nel registro, perché arrivava da una Group Policy o perché una configurazione MDM lo spingeva ai client. Alcuni amministratori hanno dichiarato di non ricordare alcuna attivazione consapevole, e qui entrano in gioco baseline precedenti, modelli ADMX aggiornati, profili Intune, strumenti di sicurezza o modifiche locali.
La procedura consigliata per rimettere in sesto le macchine
Il primo passo indicato è disabilitare Machine Identity Isolation con lo stesso strumento usato per attivarla. Se l’impostazione arriva da Microsoft Intune va corretta in Intune, se arriva da una Group Policy bisogna agire sul relativo GPO. Toccare solo il registro mentre una policy centrale continua a imporre il valore vecchio produce un rimedio effimero, perché al successivo aggiornamento dei criteri il problema torna.
Se invece la configurazione è applicata direttamente dal Registro di sistema, le posizioni da controllare sono HKLMSYSTEMCurrentControlSetControlLsaMachineIdentityIsolation e HKLMSOFTWAREPoliciesMicrosoftWindowsDeviceGuardMachineIdentityIsolation. Su Windows 11 24H2 e 25H2, se il valore è 2, va portato a 0, seguito da riavvio. Poi si ripara il secure channel da PowerShell con Test-ComputerSecureChannel -Repair -Credential (Get-Credential), che verifica e ricostruisce il rapporto di fiducia usando credenziali adeguate. Per alcuni è bastato quel comando, altri hanno dovuto rimuovere la workstation dal dominio, spostarla temporaneamente in un workgroup, riavviare e rifare il join.
Fonte: TecnoAndroid
