En bref

  • Microsoft confirme que la mise à jour cumulative KB5082063 d''avril 2026 provoque des boucles de redémarrage sur certains contrôleurs Active Directory.
  • Le bug touche les serveurs configurés avec Privileged Access Management (PAM), de Windows Server 2016 à Windows Server 2025, et déclenche un crash répété du processus LSASS au démarrage.
  • Aucun correctif officiel n''est encore publié ; Microsoft renvoie les administrateurs concernés vers son support entreprise pour appliquer une mitigation manuelle.

Ce qui s''est passé

Points clés à retenir

  • Ce qui s''est passé
  • Pourquoi c''est important
  • Ce qu''il faut retenir

Microsoft a confirmé le 18 avril que la mise à jour cumulative KB5082063, diffusée lors du Patch Tuesday d'avril 2026, provoque des redémarrages en boucle sur certains contrôleurs de domaine Active Directory. Le phénomène, désormais identifié sous le nom de KB5082063 reboot loop, se manifeste par un crash systématique du service LSASS dès l'ouverture de session machine, immédiatement suivi d'un redémarrage automatique du serveur. Le contrôleur devient alors incapable de traiter la moindre requête d'authentification Kerberos ou NTLM, ce qui paralyse l'accès aux ressources du domaine pour l'ensemble des utilisateurs et des services applicatifs. Les environnements ne disposant que d'un seul contrôleur de domaine, ou dont les réplicas ont été patchés simultanément, subissent une interruption totale de l'annuaire. Microsoft recommande la désinstallation immédiate du correctif et travaille à la publication d'une version corrigée.

Pourquoi c''est important

Un contrôleur de domaine en boucle de reboot représente un incident majeur : sans authentification fonctionnelle, les sessions utilisateurs expirent, les partages de fichiers ne s''ouvrent plus et les applications métier dépendantes de Kerberos s''arrêtent. Les organisations qui ont déployé PAM le font précisément parce qu''elles gèrent des actifs sensibles ; voir leurs annuaires partir en vrille au lendemain d''un patch de sécurité est un coup dur. KB5082063 cumule désormais trois incidents reconnus en moins d''une semaine : ce reboot loop, mais aussi des invites BitLocker inopinées sur Windows Server 2025 et des dégradations sur certains scénarios d''authentification. La leçon classique se rappelle : tester le Patch Tuesday sur un sous-ensemble de DC avant un déploiement massif, surtout si l''environnement utilise des configurations non standards comme PAM.

Ce qu''il faut retenir

  • KB5082063 met en boucle de reboot les contrôleurs de domaine non Global Catalog si Privileged Access Management est activé.
  • Toutes les éditions serveur supportées (2016 → 2025) sont concernées, et aucun correctif officiel n''est encore publié.
  • Mitigation : contacter Microsoft Support for Business pour la procédure ; en attendant, retarder le déploiement sur les contrôleurs non-GC dans les environnements PAM.

Mon environnement n''utilise pas PAM, suis-je exposé ?

Non, ce reboot loop spécifique ne se déclenche que si Privileged Access Management est configuré sur le domaine. Les organisations qui n''utilisent pas PAM peuvent appliquer KB5082063 sans risque pour ce bug, mais doivent rester vigilantes sur les deux autres incidents reconnus (clé de récupération BitLocker demandée à tort sur Windows Server 2025, dégradations Kerberos).

Un historique de patches Patch Tuesday à risque pour les contrôleurs de domaine

KB5082063 n'est pas un cas isolé. Depuis 2022, Microsoft a dû gérer plusieurs incidents similaires touchant spécifiquement les contrôleurs de domaine après des mises à jour cumulatives : les correctifs Kerberos PAC de novembre 2022 avaient provoqué des échecs d'authentification sur les environnements à approbations multi-forêts, et les mises à jour Netlogon de 2023 avaient nécessité des clés de registre de contournement pendant plusieurs semaines avant qu'un correctif définitif ne soit publié. Le point commun de ces épisodes est la complexité de la matrice de compatibilité que Microsoft doit valider : chaque combinaison de version de Windows Server, de niveau fonctionnel de domaine et de fonctionnalités avancées comme PAM ou les Managed Service Accounts multiplie les scénarios de test. Les environnements PAM restent statistiquement minoritaires — Microsoft ne communique pas de chiffre précis, mais les retours du support entreprise suggèrent une adoption concentrée dans les secteurs finance, défense et administrations, où la séparation des comptes à privilèges dans une forêt bastion répond à des exigences réglementaires strictes (PCI-DSS, référentiels ANSSI, DORA). Cette faible base installée explique en partie pourquoi le bug a échappé aux cycles de validation en anneaux (Insider, Release Preview) avant la diffusion générale.

Impact opérationnel disproportionné pour les architectures à forte exigence de sécurité

L'ironie de cet incident est qu'il frappe en priorité les organisations les plus matures en matière de gestion des identités. PAM (Privileged Access Management for Active Directory), introduit avec Microsoft Identity Manager, repose sur une forêt bastion isolée qui héberge des comptes à privilèges temporaires et fortement audités. Un contrôleur de domaine PAM en boucle de redémarrage ne se contente pas de couper l'authentification standard : il interrompt aussi les flux de just-in-time administration, empêchant les équipes IT d'élever temporairement leurs droits pour intervenir — un paradoxe qui peut retarder la résolution de l'incident lui-même si aucun compte de secours local n'a été prévu. Plusieurs administrateurs ont rapporté sur les forums Microsoft Answers et sur des canaux communautaires spécialisés AD avoir dû recourir au mode de restauration des services d'annuaire (DSRM) pour reprendre la main sur les contrôleurs sinistrés, une procédure lourde qui suppose de connaître le mot de passe DSRM local — souvent oublié ou non documenté dans les environnements où PAM a justement été déployé pour réduire la dépendance aux comptes locaux à privilèges permanents.

Le calendrier joue également en défaveur des équipes concernées : la fenêtre entre la publication du 18 avril et la confirmation officielle du bug a duré plusieurs jours, période durant laquelle certaines organisations ont continué de déployer KB5082063 en production sans disposer d'un signal d'alerte clair. Cet enchaînement rappelle l'importance des anneaux de déploiement progressifs (pilote, préproduction, production) pour les mises à jour touchant les contrôleurs de domaine, en particulier lorsque des fonctionnalités avancées comme PAM, LAPS ou les stratégies de restriction Kerberos sont actives. Le fait que Microsoft n'ait publié à ce stade aucun correctif « hors bande » (Out-of-Band), préférant une mitigation manuelle via le support entreprise, allonge d'autant la fenêtre d'exposition pour les organisations qui n'ont pas encore été contactées ou qui ne disposent pas d'un contrat de support Premier.

Besoin d''un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact

Sources et références