14 septembre 2026 | Microsoft Windows | Active Directory | Sécurité informatique
Avec la mise à jour de sécurité de septembre 2026 KB5124008 pour Windows 11, les signalements d'un problème inhabituel dans les environnements Active Directory classiques se multiplient actuellement.
Le problème touche notamment les postes clients Windows 11 membres d’un domaine Active Directory local. Après l’installation de la mise à jour, le canal sécurisé entre l’ordinateur et le contrôleur de domaine peut être endommagé.
Conséquence : la machine reste certes physiquement joignable sur le réseau, mais l'ouverture de session sur le domaine ne fonctionne soudainement plus.
Qu’est-ce que KB5124008 ?
Microsoft a publié KB5124008 le 8 septembre 2026 en tant que mise à jour de sécurité pour Windows 11 24H2 et 25H2.
Sous Windows 11 25H2, la mise à jour fait passer le système à la build 26200.9445, et sous Windows 11 24H2 à la build 26100.9445. Microsoft la présente de manière générale comme une mise à jour de sécurité et de qualité.
Microsoft documente déjà plusieurs problèmes connus liés à KB5124008, notamment avec les services Bureau à distance, les périphériques audio USB et les machines virtuelles Linux exécutées sous Hyper-V. Toutefois, aucun problème concernant le canal sécurisé d’Active Directory ne figure encore parmi les problèmes connus dans la documentation officielle de cette mise à jour.
Le cœur du problème : le canal sécurisé avec le domaine
Un ordinateur membre d’un domaine possède son propre compte d’ordinateur dans Active Directory.
Un canal sécurisé, appelé Secure Channel, relie l’ordinateur à un contrôleur de domaine. Il est notamment nécessaire à la relation d’approbation entre l’ordinateur et le domaine.
Si ce canal est endommagé, il peut arriver qu'un utilisateur ne puisse soudainement plus ouvrir de session sur le domaine.
Ce qui est particulièrement sournois :
Le nom d'utilisateur et le mot de passe restent pourtant corrects.
Windows affiche par exemple :
« Le nom d’utilisateur ou le mot de passe est incorrect. »
En réalité, le problème ne vient pas du mot de passe de l’utilisateur, mais de la relation d’approbation entre l’ordinateur et le domaine.
Symptômes typiques
Dans un cas reproductible publié par un administrateur, le comportement suivant a été observé :
Windows 11 25H2
Build 26200.9445
Mise à jour KB5124008
Domaine Active Directory classique
Contrôleur de domaine sous Windows Server 2019
Après l’installation de la mise à jour, l’ouverture de session fonctionnait encore dans un premier temps. Au bout d’un certain temps, la relation d’approbation était toutefois rompue.
L’administrateur a pu reproduire le problème sur plusieurs appareils : installation de la mise à jour → le problème apparaît → désinstallation de la mise à jour → le problème disparaît. Après une nouvelle installation de KB5124008, le problème est réapparu.
Il est également intéressant de noter qu’un autre administrateur signale des problèmes avec des contrôleurs de domaine sous Windows Server 2022. D’autres témoignages font même état du problème avec différentes versions de contrôleurs de domaine. À ce stade, ces éléments incitent à ne pas conclure trop vite que le problème touche exclusivement Windows Server 2019.
Comment vérifier la présence du problème
S’il est encore possible d’ouvrir une session sur un ordinateur concerné à l’aide d’un compte administrateur local ou d’identifiants de domaine mis en cache, la connexion au canal sécurisé peut être vérifiée avec PowerShell.
En tant qu’administrateur :
Test-ComputerSecureChannel
Si le canal sécurisé fonctionne correctement, la commande devrait renvoyer :
True
Sur un ordinateur touché, en revanche, la valeur :
False
peut s’afficher.
On peut également effectuer une vérification avec nltest :
nltest /sc_query:DOMAIN
Il peut alors apparaître, par exemple, l'erreur
ERROR_NO_TRUST_LSA_SECRET (1786)
apparaître.
C’est précisément ce problème qui a été documenté dans le cas signalé sur Microsoft Q&A.
Important : ne pas réinitialiser immédiatement le mot de passe de l’utilisateur
Face à ces symptômes, on peut être tenté de commencer par réinitialiser le mot de passe de l’utilisateur concerné.
Dans ce cas, ce n’est toutefois généralement pas la bonne approche.
Si plusieurs utilisateurs ne parviennent soudainement plus à se connecter au domaine depuis le même PC, alors qu’une connexion hors ligne à l’aide d’identifiants mis en cache fonctionne encore, par exemple, il convient de vérifier d’abord la relation d’approbation de l’ordinateur.
Un signe caractéristique est le suivant :
Test-ComputerSecureChannel
renvoie :
False
Tentative de réparation possible
Comme première tentative de réparation, on peut rétablir le canal sécurisé (Secure Channel) :
Test-ComputerSecureChannel -Repair
le cas échéant avec les identifiants d'un compte de domaine disposant des autorisations nécessaires.
Il est également possible de réinitialiser le mot de passe du compte d’ordinateur à l’aide de PowerShell.
La prudence s’impose toutefois :
Dans les cas signalés jusqu’à présent, la réparation ne résout pas toujours le problème durablement.
Dans le cas initialement signalé sur Microsoft Q&A, par exemple, la commande Test-ComputerSecureChannel -Repair n’a pas suffi. Il a finalement fallu retirer l’ordinateur du domaine, puis l’y joindre à nouveau.
D’autres administrateurs indiquent en revanche que la commande de réparation a été efficace, au moins temporairement. Le problème ne semble donc pas se manifester de manière identique sur tous les systèmes concernés.
Si la réparation ne suffit pas
Si le canal sécurisé reste défaillant, il peut être nécessaire de recourir à une opération plus lourde : joindre à nouveau l’ordinateur au domaine.
Schématiquement :
Autoriser l'ouverture de session locale avec un compte administrateur
Retirer l’ordinateur du domaine
Redémarrer l’ordinateur
Joindre à nouveau l’ordinateur au domaine
Redémarrer une nouvelle fois
Tester l’ouverture de session sur le domaine
Dans le cas documenté où le problème a été reproduit, c'est précisément cette procédure qui s'est avérée nécessaire pour corriger durablement le dysfonctionnement.
Faut-il pour l'instant suspendre le déploiement de KB5124008 ?
La réponse doit être nuancée.
KB5124008 est une mise à jour de sécurité et ne devrait pas être désinstallée systématiquement dans tous les environnements.
Parallèlement, les administrateurs d'environnements Active Directory classiques devraient actuellement surveiller l'installation avec une attention particulière.
Avec KB5124008, Microsoft publie d'importantes améliorations de sécurité. La mise à jour est en outre distribuée via Windows Update, Windows Update for Business et WSUS.
Pour les environnements de production, un déploiement contrôlé est donc recommandé :
Groupe de test → observation → groupe plus large → déploiement complet
et pas nécessairement :
Mettre à jour tous les clients en même temps.
En particulier sur les appareils nécessaires à la connexion quotidienne des utilisateurs, il convient par ailleurs de disposer d'un compte administrateur local ou d'une solution de récupération fonctionnelle.
Ce que nous recommandons actuellement
Pour les entreprises disposant d'un Active Directory classique, nous recommandons actuellement :
1. Vérifier les versions de Windows 11 concernées
Sur un client :
winver
ou :
Get-ComputerInfo | Select WindowsProductName, WindowsDisplayVersion, OsBuildNumber
2. Vérifier si KB5124008 a été installée
Get-HotFix -Id KB5124008
3. En cas de problèmes de connexion, vérifier le Secure Channel
Test-ComputerSecureChannel
4. Si le résultat est False, tenter d'abord une réparation
Test-ComputerSecureChannel -Repair
5. En cas de problèmes récurrents, documenter la cause
Il convient notamment de consigner les informations suivantes :
Version de Windows
Build du système d'exploitation
Mises à jour KB installées
Version du contrôleur de domaine
Moment de l'apparition du problème
Résultat de Test-ComputerSecureChannel
Résultat de nltest /sc_query
Événements sur le client et le contrôleur de domaine
Cela permet de déterminer bien plus précisément s'il existe réellement un lien avec la mise à jour.
Aucune cause définitive confirmée pour l'instant
Une précision importante s'impose ici :
Le lien entre KB5124008 et des canaux sécurisés de domaine endommagés est actuellement signalé de manière reproductible par des administrateurs, mais, en l'état actuel des choses, il ne figure pas comme problème connu (Known Issue) correspondant dans la documentation KB officielle de Microsoft.
Le rapport initial publié sur Microsoft Q&A décrit une situation reproductible avec Windows 11 25H2 et des contrôleurs de domaine Windows Server 2019. D'autres administrateurs signalent des problèmes similaires, notamment avec Windows Server 2022.
C'est aussi pour cette raison qu'il ne faut pas affirmer hâtivement que KB5124008 est définitivement la cause de chaque erreur « Trust Relationship » actuelle.
D'autres causes, comme des problèmes DNS, des décalages d'horloge, des problèmes liés au compte d'ordinateur ou des composants réseau/VPN, doivent toujours être écartées.
Conclusion
KB5124008 doit actuellement être surveillée avec une attention particulière dans les environnements Active Directory.
Si, après la mise à jour de septembre, plusieurs utilisateurs d'un PC Windows 11 ne parviennent soudainement plus à ouvrir une session sur le domaine alors que leurs identifiants sont corrects, il vaut la peine d'examiner la relation d'approbation de l'ordinateur.
Le premier test, et le plus important, est le suivant :
Test-ComputerSecureChannel
Si la commande renvoie False, il y a très probablement un problème avec le canal sécurisé entre l'ordinateur et le domaine.
Comme les retours disponibles jusqu'à présent montrent qu'une simple réparation ne résout pas durablement le problème sur tous les systèmes, il convient de documenter précisément les appareils concernés et de ne pas modifier précipitamment les comptes d'utilisateurs ou les mots de passe.
Dernière mise à jour de cet article : 14 septembre 2026.
Nous suivons l'évolution de la situation autour de KB5124008 et mettrons cet article à jour dès que Microsoft publiera une déclaration officielle ou un correctif correspondant.