Récemment, j’ai été confronté à un comportement inattendu après l’installation de la mise à jour de sécurité Microsoft d’avril 2026 sur deux contrôleurs de domaine Windows Server 2025 issus d’une migration historique Active Directory.
La mise à jour concernée était celle d’avril 2026, dans la continuité de KB5082063, avec les sujets de durcissement autour de Kerberos et de l’évolution des mécanismes d’authentification.
Microsoft a d’ailleurs publié quelques jours plus tard une mise à jour hors bande, KB5091157, destinée à corriger plusieurs problèmes identifiés après son déploiement.
Les recommandations Microsoft autour de ces mises à jour évoquaient principalement le durcissement de Kerberos et la transition progressive vers AES, au détriment de mécanismes plus anciens comme RC4.
Mais le problème rencontré ne correspondait pas exactement aux scénarios documentés.
Le symptôme
Après installation de la mise à jour, une partie importante des utilisateurs n’était plus en mesure de s’authentifier sur le domaine.
Les erreurs ne pointaient pas clairement vers Kerberos, la réplication Active Directory semblait correcte et les contrôleurs de domaine étaient fonctionnels.
Pourtant, un comportement particulier a rapidement attiré mon attention :
Comptes historiques
Certains comptes anciens ne parvenaient plus à s’authentifier après la mise à jour.
Comptes récents
Les comptes créés récemment continuaient de fonctionner sans intervention particulière.
Mot de passe ressaisi
La mise ressaisie du mot de passe dans Active Directory rétablissait immédiatement l’authentification.
L’indice qui a tout changé
Un compte administrateur secondaire, créé directement sur l’infrastructure Windows Server 2025, continuait de fonctionner sans aucune intervention.
À l’inverse, les comptes hérités de l’ancienne infrastructure nécessitaient une mise à jour du mot de passe pour retrouver un fonctionnement normal.
Cette différence de comportement a orienté les investigations vers l’historique des comptes plutôt que vers la mise à jour elle-même.
Retour terrain
Dans ce cas précis, le problème visible n’était pas un contrôleur de domaine complètement hors service. Le domaine répondait, la réplication semblait saine, mais certains comptes hérités refusaient de s’authentifier tant que leurs informations de sécurité n’étaient pas régénérées.
Analyse des comptes
L’extraction des attributs Active Directory a révélé une situation assez surprenante :
- ➡️certains mots de passe n’avaient jamais été modifiés depuis la fin des années 1990
- ➡️de nombreux comptes applicatifs affichaient des dates de changement remontant à 2001, 2005 ou 2010
- ➡️plusieurs comptes présentaient des numéros de version de clé Kerberos, les KVNO, extrêmement faibles
- ➡️les attributs liés au chiffrement Kerberos étaient souvent absents ou hérités de configurations historiques.
En parallèle, les comptes créés ou modifiés récemment ne présentaient aucun dysfonctionnement.
Comptes historiques -> clés et attributs parfois hérités
Comptes récents -> authentification fonctionnelle
Reset mot de passe -> régénération des informations KerberosCommande PowerShell utile
Pour lister rapidement les comptes avec la date de dernier changement de mot de passe, le KVNO et les types de chiffrement Kerberos déclarés :
Get-ADUser -Filter * `
-Properties PwdLastSet,msDS-KeyVersionNumber,msDS-SupportedEncryptionTypes |
Select-Object `
SamAccountName,
@{Name='PwdLastSet';Expression={[datetime]::FromFileTime($_.PwdLastSet)}},
@{Name='KVNO';Expression={$_.msDS-KeyVersionNumber}},
@{Name='EncryptionTypes';Expression={$_.msDS-SupportedEncryptionTypes}} |
Sort-Object PwdLastSetUne hypothèse cohérente
Même si Microsoft ne documente pas explicitement ce scénario, plusieurs publications techniques Microsoft autour du durcissement Kerberos RC4 → AES indiquent que les comptes créés avant la prise en charge d’AES peuvent nécessiter une réinitialisation du mot de passe afin de générer de nouvelles clés Kerberos compatibles avec les mécanismes de chiffrement modernes. Microsoft précise également que certains comptes dont le mot de passe n’a jamais été renouvelé peuvent continuer à utiliser uniquement des clés RC4 historiques.
Dans notre cas, la simple ressaisie du mot de passe régénérait immédiatement les clés Kerberos du compte et rétablissait l’authentification. Tout laisse donc penser que la mise à jour n’a pas cassé les comptes Active Directory, mais a révélé l’existence de comptes historiques dont les informations de sécurité n’avaient jamais été modernisées depuis plusieurs générations de contrôleurs de domaine.
Oui, 20 ans...
Je vous vois déjà derrière votre écran faire des bonds en lisant « le même mot de passe depuis 20 ans » 😱
Et pourtant, ce n’est pas si rare dans certaines PME. Quand une infrastructure fonctionne depuis longtemps et qu’il n’y a pas forcément de ressource IT dédiée, certaines bonnes pratiques passent parfois au second plan.
La décision
Plutôt que de chercher à contourner la mise à jour, le choix a été fait de profiter de cette situation pour améliorer la sécurité globale de l’annuaire :
- 🔐 obligation de renouvellement du mot de passe pour les utilisateurs ;
- 🧩 conservation temporaire des comptes applicatifs critiques ;
- 🔎 identification des comptes de service encore utilisés ;
- 🛠️ mise en conformité progressive des mots de passe historiques ;
- 📋 revue des comptes dont les mots de passe n’avaient jamais été renouvelés depuis plusieurs années.
Cette approche permet non seulement de résoudre le problème observé, mais également de réduire une dette technique accumulée depuis plusieurs générations d’Active Directory.
À vérifier dans vos domaines historiques
Une migration Active Directory réussie ne signifie pas forcément que tous les objets hérités sont au même niveau que l’infrastructure actuelle. Les comptes très anciens, les comptes applicatifs oubliés et les mots de passe jamais renouvelés méritent une vraie revue avant de pousser des changements de sécurité sensibles.
Ce qu’il faut retenir
Lorsqu’un domaine a traversé plusieurs versions de Windows Server, certains comptes peuvent continuer à fonctionner pendant des années avec des paramètres ou des clés hérités.
Les mises à jour de sécurité modernes ne créent pas toujours le problème. Elles révèlent parfois simplement une situation qui existait déjà depuis longtemps.
Dans notre cas, la mise à jour a surtout servi de révélateur sur des comptes dont certains mots de passe n’avaient pas été renouvelés depuis plus de vingt ans.
La leçon est simple : une migration Active Directory réussie ne garantit pas que tous les objets hérités ont réellement été modernisés. Parfois, il faut qu’une mise à jour de sécurité vienne mettre en lumière une dette technique devenue invisible avec le temps.
Sources
Cet article vous a-t-il été utile ?
Votre retour aide à mieux choisir les prochains sujets.
