Suite à l’installation de la mise à jour KB5124008 de septembre 2026, de nombreux admins système signalent des problèmes de connexion sur les machines Windows 11, avec à la clé des relations d’approbation cassées entre les postes et l’Active Directory. Voici ce que l’on sait.
Le 8 septembre 2026, Microsoft a publié la KB5124008 pour Windows 11 24H2 et 25H2. Et le moins que l’on puisse dire, c’est que tout ne se passe pas comme prévu puisqu’elle a déjà accumulé plusieurs problèmes : périphériques audio USB muets, partages inaccessibles dans WSL, blocage des services Bureau à distance…. Au point que Microsoft a publié des mises à jour hors bande, dont la KB5129195 pour Windows 11, pour corriger une partie de ces problèmes. Toutefois, un bug gênant pour les entreprises persiste et il n’a pas été corrigé par ces nouvelles mises à jour.
Tout est parti d’un fil de discussion sur Microsoft Q&A : après l’installation de KB5124008 sur des postes Windows 11 25H2, les machines perdent leur canal sécurisé avec le domaine. Ce qui a plusieurs conséquences, à commencer par le fait que les utilisateurs ne peuvent plus ouvrir de session interactive, sauf avec des identifiants en cache (donc hors ligne). En bon admin, il a fait son diagnostic et les nouvelles ne sont pas bonnes :
La commande Test-ComputerSecureChannel renvoie False,
La commande nltest /sc_query retourne l’erreur ERROR_NO_TRUST_LSA_SECRET (1786).
Côté contrôleurs de domaine, l’événement 4625 apparaît pour le compte ordinateur, avec le code d’erreur 0xC000006A.
6 machines Windows 11 avec le patch de septembre 2026, 6 machines touchées, dans un environnement avec des contrôleurs de domaine Windows Server 2019. “Retirez le correctif, tout fonctionne à nouveau après une nouvelle jonction complète au domaine. Réinstallez-le après la réparation, et ça casse immédiatement, sans le délai de quelques heures observé la première fois.”, écrit-il. D’autres admins ont ensuite constaté exactement la même chose, mais cette fois-ci avec des contrôleurs Windows Server 2022, patchés ou non.
Premier constat : le problème n’est donc pas lié à une version précise de Windows Server.
Machine Identity Isolation, le suspect numéro un
Pour l’instant, Microsoft ne s’est pas exprimé à propos de ce dysfonctionnement. Mais cela avance malgré tout, et il y a un potentiel coupable identifié : Machine Identity Isolation. Cette fonctionnalité liée à Credential Guard déplace le secret du compte ordinateur hors de la LSA pour le stocker dans l’environnement isolé par la virtualisation. Objectif : empêcher l’extraction de ce secret depuis le registre, notamment pour protéger les comptes gMSA et dMSA qui s’appuient sur les comptes machine.
Microsoft la documente pour Windows Server 2025, avec trois modes : désactivé (0), audit (1) et application (2). C’est important de le préciser, car les admins impactés par ce problème ont justement fait joujou avec cette valeur de Registre : la valeur de registre MachineIdentityIsolation était à 2 (application), ou à 1 (audit), sur les machines touchées. En la passant à 0 puis en réparant le canal sécurisé, la relation d’approbation cesse de se casser.
Reste une zone d’ombre : ils affirment n’avoir jamais activé cette fameuse option Machine Identity Isolation. L’un des admins affirme que sa GPO activait bien VBS et Credential Guard, mais le paramètre pour Machine Identity Isolation était resté sur “Non configuré”. Sauf qu’après la mise à jour, la valeur était pourtant positionnée à 2.
La mise à jour KB5124008 publiée par Microsoft aurait-elle réactivé quelque chose qui ne devait pas l’être ? En l’absence de réaction de Microsoft, cette question reste sans réponse.
La solution en attendant la réaction de Microsoft
Ce mardi 15 septembre, la page officielle de KB5124008 liste trois problèmes connus. Malheureusement, rien à propos de ce problème de relation d’approbation. Les mises à jour hors bande KB5129195 et KB5129242 ne corrigent pas ce bug… Donc en attendant, vous pouvez tenter de vous débrouiller.
Je n’ai pas de solution à vous proposer personnellement, mais la discussion Microsoft Q&A évoque une piste sérieuse et surtout qui semble porter ses fruits. Comme vous pouvez vous en douter, cette solution temporaire revient à désactiver la protection Machine Identity Isolation. Si vous souhaitez tester, voici les étapes à suivre.
Étape 1 : confirmer le diagnostic
Sur un poste touché, exécutez Test-ComputerSecureChannel dans une console PowerShell en tant qu’administrateur. Un retour False confirme que le canal sécurité est HS.
Étape 2 : contrôler Machine Identity Isolation
Ouvrez la clé HKLM\SYSTEM\CurrentControlSet\Control\Lsa et regardez la valeur MachineIdentityIsolation. Si elle vaut 1 ou 2, vous êtes dans le cas décrit par les admins sur Microsoft Q&A.
Étape 3 : désactiver la fonctionnalité
Deux options. La première par GPO : Configuration ordinateur, Modèles d’administration, Système, Device Guard, “Activer la sécurité basée sur la virtualisation”, puis passer “Machine Identity Isolation Configuration” sur Désactivé.
Sinon, vous pouvez directement pousser une clé de Registre par GPO afin de forcer MachineIdentityIsolation à 0 (via les paramètres de préférences). Sinon, avec PowerShell, une commande fera le même effet pour déjà tester sur une machine :
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Lsa” -Name MachineIdentityIsolation -Value 0 -Type DWord
À première vue, taper directement dans le Registre serait plus efficace que de passer par le paramètre de GPO destiné à configurer VBS.
Étape 4 : réinitialiser le mot de passe machine
Exécutez la commande PowerShell suivante avec un compte administrateur : Reset-ComputerMachinePassword -Server -Credential (Get-Credential)
Étape 5 : réparer le canal sécurisé
Lancez la commande suivante, toujours avec PowerShell :
Test-ComputerSecureChannel -Server VotreDC -Credential (Get-Credential) -Repair
Si cela échoue, redémarrez votre machine et tentez de nouveau.
Étape 6 : vérifier avec nltest
Effectuez une vérification du bon fonctionnement avec l’outil nltest, de cette façon : nltest /sc_verify:VotreDC. Cela doit renvoyer un succès.
En dernier recours, la désinstallation de la mise à jour KB5124008 est aussi une option même si c’est toujours embêtant (surtout avec un Patch Tuesday à près de 1000 failles). Pour les autres méthodes de réparation d’une relation d’approbation, mon tutoriel sur ce sujet reste d’actualité.
Et vous, avez-vous constaté ce problème sur votre parc après l’installation de la KB5124008 ?
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.