Active Directory : pourquoi les mises à jour Microsoft d’avril 2026 perturberont de nombreux accès Kerberos

Changements majeurs dans Active Directory et Kerberos

L’aggiornamento cumulatif de Microsoft prévu pour le 14 avril 2026 apporte des bouleversements significatifs pour les utilisateurs d’Active Directory. Les modifications du comportement de Kerberos, notamment, vont perturber de nombreux accès, en raison d’un paramètre crucial souvent négligé : l’attribut msDS-SupportedEncryptionTypes. Ce changement, bien qu’attendu, pose des défis concrets aux infrastructures existantes.

Historiquement, beaucoup d’environnements d’Active Directory ont profité de mécanismes de rétrocompatibilité implicites. Des comptes de service oubliés, des appliances réseau, et des applications legacy reposent souvent sur des systèmes de chiffrement obsolètes. Avec cette mise à jour, Microsoft rompt cet équilibre délicat.

Concrètement, à partir de mi-avril 2026, sans configuration explicite de l’attribut msDS-SupportedEncryptionTypes, le système abandonnera le recours à l’algorithme RC4 et adoptera AES-SHA1 comme nouveau standard. D’ici juillet 2026, ce changement sera irréversible, modifiant radicalement le fonctionnement des accès kerberos.

Impact sur l’authentification Kerberos et sécurité informatique

Kerberos est l’un des protocoles d’authentification les plus utilisés dans les domaines Windows. Ce mécanisme repose sur des tickets cryptés générés par le Key Distribution Center (KDC), un service opérant sur les contrôleurs de domaine. Chaque ticket est chiffré à l’aide d’un algorithme spécifique, selon les méthodes déclarées par l’account concerné.

L’attribut msDS-SupportedEncryptionTypes joue un rôle clé ici. Il s’agit d’un numéro utilisant une bitmask pour indiquer quels algorithmes de chiffrement un compte supporte. Jusque-là, l’absence de valeur explicite permettait l’utilisation d’algorithmes anciens comme RC4.

Avec ce changement, l’implicite ne sera plus toléré. Un contrôleur de domaine considérera qu’un compte supporte AES par défaut, provoquant ainsi des refus d’authentification si le service ne gère pas AES. C’est une nouveauté qui nécessite une adaptation rapide des configurations.

Retombées sur la gestion des identités et infrastructures réseau

L’ampleur de cet aggiornamento souligne un problème sous-jacent : la stratification des configurations au fil des ans. Compte de service établi il y a dix ans, NAS avec des piles Kerberos limitées, logiciels non mis à jour, tout cela crée une mosaïque complexe d’exigences.

RC4 a été le liant invisible permettant la continuité malgré les incohérences. Une fois enlevé, les dépendances cachées apparaissent subitement. Désormais, une authentification échouée peut survenir sans message d’erreur clair, seulement détectable dans les logs du contrôle de domaine grâce à des événements spécifiques, parfois négligés.

Un symptôme classique est une authentification échouée sans explication apparente. C’est là que les prises en compte des logs de sécurité sur les contrôleurs de domaine deviennent cruciales, permettant de surveiller et de corriger les anomalies d’accès.

Identifier les vulnérabilités et préparer les infrastructures

Prenons par exemple l’analyse des logs de sécurité sur les contrôleurs de domaine : les événements 4768 et 4769 enregistrent respectivement la demande et l’émission des tickets Kerberos. Dans le champ type de chiffrement apparaît un hexadécimal indiquant l’algorithme (0x17 pour RC4). Une simple commande PowerShell peut filtrer ces événements :

• Utiliser : Get-WinEvent -FilterHashtable @{LogName=’Security’; Id=4768,4769} -MaxEvents 20 | Where-Object { $_.Message -match ‘0x17’ } | Format-List TimeCreated, Id, Message

Chaque résultat nécessite une analyse, non seulement de la configuration des comptes mais aussi de la capacité des systèmes demandant le ticket. Microsoft propose également des outils pour identifier les utilisations actives d’RC4, permettant de cibler les comptes à ajuster en priorité.

Solutions pratiques pour adapter les accès Kerberos

La solution la plus directe est d’établir explicitement msDS-SupportedEncryptionTypes sur les comptes concernés. Le valoriser à 24 (0x18) permet AES128 et AES256, excluant ainsi RC4. Cette mise à jour doit être suivie d’une régénération des tickets via klist purge.

Un autre détail important est le renouvellement des mots de passe. Si un compte n’a pas mis à jour son mot de passe depuis l’introduction d’AES, il peut manquer les bonnes clés. Dans ces cas, la réinitialisation est indispensable pour éviter tout échec d’authentification.

Les politiques de groupe offrent des capacités de configurer les types de chiffrement côté client. Activer AES128 et AES256 tout en évitant d’imposer RC4 permet de maintenir un niveau de sécurité optimal sans compromettre l’ensemble du domaine.

Protéger contre les attaques Kerberoasting

L’enjeu va au-delà de la compatibilité. Utiliser RC4_HMAC_MD5 expose les systèmes à des attaques comme le Kerberoasting. Ce type d’attaque permet à une entité déjà authentifiée de requérir des tickets de service et de les analyser hors ligne pour déchiffrer les mots de passe.

En somme, le changement imposé par Microsoft pour avril 2026 vient renforcer la sécurité informatique tout en nécessitant des ajustements opérationnels pour garantir une authentification sans faille au sein des infrastructures réseau.