Fallback Kerberos RC4 Active Directory : comment le détecter, pourquoi il persiste et comment le supprimer

Le fallback Kerberos RC4 Active Directory désigne le fait qu'un contrôleur de domaine émet encore du matériel Kerberos avec RC4 parce que le client, le service, les clés du compte ou la configuration effective des types de chiffrement ne permettent pas à l'échange de rester sur AES. Cela compte encore en 2026 parce que des tickets de service appuyés sur RC4 maintiennent la dimension cracking hors ligne du Kerberoasting pertinente, même dans des domaines qui paraissent déjà modernes sur le papier.

Cet article n'est pas un second guide sur le Kerberoasting. C'est un guide de détection et de remédiation pour prouver où RC4 est encore utilisé, pourquoi le KDC continue de le choisir, et comment supprimer cette dépendance sans casser l'authentification.

Fallback Kerberos RC4 Active Directory : ce que cela signifie

En pratique, le fallback Kerberos RC4 n'est pas un paramètre unique. C'est le résultat du choix de RC4 par le KDC pour un ticket ou une clé de session parce que AES est indisponible, non annoncé, pas encore généré pour le compte, ou exclu par la configuration effective.

Microsoft l'énonce désormais clairement. Dans sa documentation Kerberos actuelle, Microsoft indique que RC4 est en cours de retrait, que les mises à jour Windows publiées le 8 novembre 2022 ou après ont modifié le comportement Kerberos par défaut pour privilégier AES-SHA1 pour les comptes dont aucun type de chiffrement n'était explicitement défini, et que RC4 reste encore utilisé pour les comptes qui ne prennent pas en charge AES-SHA1. C'est pourquoi ce sujet a sa place à la fois dans une revue de sécurité AD orientée audit et dans un plan de nettoyage AD orienté durcissement.

Pourquoi RC4 apparaît encore dans des environnements AD modernes

L'erreur la plus fréquente consiste à supposer que voir RC4 dans un ticket signifie toujours une seule GPO mal configurée. La documentation actuelle de Microsoft pointe vers plusieurs causes racines différentes, et elles ne se corrigent pas toutes de la même manière.

Deux points de Microsoft comptent ici.

Premièrement, les changements Kerberos du 8 novembre 2022 n'ont pas supprimé RC4 partout. Microsoft Support indique que ces mises à jour ont défini AES comme type de chiffrement par défaut pour les clés de session sur les comptes qui n'étaient pas déjà marqués avec un type de chiffrement par défaut, tandis que Microsoft Learn indique que RC4 apparaît encore pour les comptes qui ne prennent pas en charge AES-SHA1.

Deuxièmement, les comptes d'ordinateur et les comptes utilisateur ou de service ne se comportent pas de la même manière. Microsoft Support indique que les ordinateurs Windows définissent automatiquement msDS-SupportedEncryptionTypes pour leurs comptes de machine en fonction de la stratégie Kerberos locale, mais que les comptes utilisateur, les comptes de service gérés de groupe (group Managed Service Accounts) et les autres comptes AD n'ont pas cette valeur définie automatiquement. Cette différence explique en grande partie pourquoi les comptes de service reviennent sans cesse dans les investigations RC4.

Comment détecter le fallback Kerberos RC4

Dans la plupart des environnements, la détection commence sur les contrôleurs de domaine, pas sur l'hôte de service qui reçoit finalement le ticket. Microsoft Learn indique que les détails d'utilisation de RC4 par Kerberos sont enregistrés dans les journaux de sécurité des KDC pour Windows Server 2019 et versions ultérieures, et que Windows Server 2016 a également gagné une visibilité sur l'utilisation de RC4 dans ces événements après la mise à jour cumulative de janvier 2025.

Commencez par ces sources de données :

Si vous centralisez déjà la télémétrie des DC, cela doit figurer à côté des événements Kerberos traités dans Supervision Active Directory : les ID d'événements de sécurité qui comptent, et non dans un rapport ad hoc séparé.

Ce que l'ID d'événement 4769 vous indique réellement

L'ID d'événement 4769 est l'endroit le plus pratique pour prouver le fallback Kerberos RC4, car Microsoft documente à la fois la valeur de chiffrement du ticket et les champs de contexte qui l'entourent.

Deux détails comptent immédiatement :

1. Microsoft documente Ticket Encryption Type = 0x17 comme RC4-HMAC, et 0x18 comme RC4-HMAC-EXP.
2. Microsoft indique également qu'à partir de Windows Vista et Windows Server 2008, les valeurs de chiffrement attendues pour le ticket de service sont 0x11 et 0x12, qui sont des algorithmes de la famille AES.

Cela fait de 4769 l'un des moyens les plus nets de prouver que RC4 est encore émis.

Cette distinction compte, car il est facile de construire la mauvaise remédiation si vous mélangez les valeurs d'événement avec les valeurs de masque de bits AD.

Lorsque vous investiguez sur 4769, utilisez-le avec le contexte du compte environnant :

• Si Ticket Encryption Type appartient à la famille RC4 et que le compte de service n'a pas de clés AES, l'historique des mots de passe est souvent le véritable problème.
• Si le client ou la cible n'annonce pas AES, c'est généralement une question de stratégie ou de compatibilité de plateforme.
• Si les champs d'événement suggèrent qu'un compte ne prend en charge que le comportement par défaut, vérifiez si le compte possède réellement une valeur msDS-SupportedEncryptionTypes brute dans AD, ou si le KDC se replie sur la valeur par défaut du domaine.

Causes racines courantes de l'émission de tickets RC4

Comptes anciens sans clés AES régénérées

Microsoft Learn indique que si un compte utilisateur a été créé avant que la prise en charge d'AES-SHA1 soit ajoutée à Kerberos Windows, et que le mot de passe n'a jamais été réinitialisé après l'ajout de cette prise en charge, il se peut que le compte n'ait pas de clés AES-SHA1, et que le changement du mot de passe du compte génère ces clés manquantes.

Une réserve sur les dates s'impose, car les pages de Microsoft se contredisent entre elles. La page de remédiation RC4 indique que la prise en charge d'AES-SHA1 dans Kerberos Windows « a été ajoutée dans Windows Server 2003 », alors que la même page qualifie aussi Windows Server 2003 de dernière version de Windows à ne pas prendre en charge AES-SHA1. Les autres références Microsoft sont cohérentes avec cette seconde lecture : la documentation de la stratégie Kerberos indique que AES128_HMAC_SHA1 et AES256_HMAC_SHA1 ne sont « pas pris en charge sous Windows 2000 Server, Windows XP ou Windows Server 2003 », et la documentation de l'ID d'événement 4769 indique que 0x11 et 0x12 sont « pris en charge à partir de Windows Server 2008 et Windows Vista ». Considérez Windows Vista et Windows Server 2008 comme le point à partir duquel AES-SHA1 est devenu disponible, et Windows Server 2003 comme la dernière plateforme Windows à en être dépourvue.

C'est pourquoi le nettoyage de RC4 est en partie un problème de cycle de vie des mots de passe, et pas seulement un problème de stratégie de protocole. Cela explique aussi pourquoi le problème recoupe souvent les problèmes d'hygiène des comptes de service décrits dans Sécurité des mots de passe Active Directory : les erreurs qui comptent.

msDS-SupportedEncryptionTypes est absent, incomplet ou mal interprété

Microsoft Support indique que si un compte n'a pas de valeur msDS-SupportedEncryptionTypes définie, ou si elle est définie à 0, les contrôleurs de domaine supposent une valeur par défaut de 0x27 ou utilisent le paramètre de registre DefaultDomainSupportedEncTypes. Microsoft Learn indique également que le KDC utilise la valeur par défaut du domaine lorsque la machine source ou cible n'a aucune valeur définie.

Cela signifie que RC4 peut encore apparaître sans qu'un administrateur ait jamais explicitement coché de case RC4 sur le compte lui-même.

Utilisez les commandes propres à Microsoft pour inspecter ce qui est réellement configuré.

Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 -and -not msDS-supportedEncryptionTypes -bor 0x18"

Cette requête provient de Microsoft Support et est spécifiquement destinée à trouver les comptes où DES ou RC4 est explicitement activé mais pas AES.

Pour la revue d'un objet unique, Microsoft Learn montre ce modèle :

$accountName = "<computer account name>"
$parameters = @{
     Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
     Properties = "msDS-SupportedEncryptionTypes"
}
Get-ADObject @parameters | FL "DistinguishedName","msDS-SupportedEncryptionTypes","Name","ObjectClass"

Appareils et services hérités qui ne prennent toujours pas en charge AES

La documentation de la stratégie Kerberos de Microsoft avertit toujours que le paramètre Network security: Configure encryption types allowed for Kerberos « peut affecter la compatibilité avec les ordinateurs clients ou les services et applications ». Séparément — et cela provient du guide de détection et de remédiation RC4 de Microsoft, pas de la page de stratégie — Microsoft indique que la dernière version de Windows à ne pas prendre en charge AES-SHA1 était Windows Server 2003, et recommande de migrer vers une version de Windows qui prend en charge AES-SHA1.

C'est là que le fallback RC4 se transforme en problème d'ingénierie plutôt qu'en simple case à cocher. Si vous désactivez RC4 avant de comprendre quels clients et services en ont encore besoin, vous échangez un problème de sécurité contre une panne d'authentification.

Cas particuliers liés à l'intégration Linux

Microsoft documente désormais un scénario spécifique lié à l'intégration Linux où AD DS émet encore des tickets chiffrés en RC4. Dans ce cas, l'ID d'événement 4769 affiche Ticket Encryption Type: 0x17, et Microsoft indique que forcer msDS-SupportedEncryptionTypes à 24 (0x18) ou basculer la GPO de type de chiffrement Kerberos ne résout pas le problème.

La raison documentée est plus étroite que « Linux cause RC4 ». Microsoft indique que le problème survient parce que l'attribut operatingSystemVersion est interprété d'une manière qui amène le KDC à traiter le compte comme si les types de chiffrement pris en charge n'étaient pas renseignés, ce qui pousse le KDC à utiliser à la place des types de chiffrement pris en charge présumés.

Les correctifs documentés par Microsoft sont tout aussi ciblés : supprimer l'attribut operatingSystemVersion, définir sa valeur de sorte que le premier caractère ne soit pas un chiffre, ou passer à une version de système conforme à la spécification.

Il s'agit d'un cas particulier qu'il vaut la peine de connaître, car il prouve que certains constats RC4 sont causés par la sémantique des métadonnées de l'annuaire, et pas seulement par une dérive de stratégie évidente.

Comment remédier aux dépendances RC4 sans risque (Remediation)

L'ordre de remédiation le plus sûr est progressif.

1. Prouver où RC4 est émis avant de modifier les valeurs par défaut

Ne commencez pas par désactiver RC4 à l'échelle du domaine. Commencez par prouver où RC4 est encore émis dans 4769 et à quel compte ou service chaque événement correspond. Sur les contrôleurs de domaine mis à jour avec les mises à jour Windows du 13 janvier 2026 ou ultérieures, surveillez également les événements d'audit Kdcsvc introduits pour le parcours de durcissement des tickets de service RC4.

2. Régénérer les clés AES manquantes lorsque c'est la véritable cause

Si un ancien compte utilisateur ou de service n'a pas de clés AES, Microsoft indique que le changement du mot de passe du compte les génère. Cela doit se produire avant d'apporter des changements plus larges côté KDC. Pour les comptes de service dotés de SPN, c'est également le point où le risque recoupe le Kerberoasting : les tickets appuyés sur RC4 sont plus faciles à transformer en travail de cracking hors ligne lorsque des mots de passe faibles ou réutilisés sont également présents.

3. Séparer la configuration AD brute du comportement effectif du KDC

Vérifiez l'attribut brut msDS-SupportedEncryptionTypes, puis comparez-le à ce que montre l'événement. Si l'attribut est vide ou à 0, le KDC utilise peut-être DefaultDomainSupportedEncTypes à la place. Si un compte de machine définit la valeur automatiquement en fonction de la stratégie locale, corrigez la stratégie de l'appareil. Si un compte utilisateur ou de service a besoin d'une valeur explicite, modifiez ce compte de manière délibérée plutôt que de changer d'abord la valeur par défaut de tout le domaine.

4. Supprimer les dépendances héritées avant de durcir la stratégie Kerberos

Si le client, le service, l'appliance ou la pile non-Windows ne prend pas réellement en charge AES, les recommandations de Microsoft consistent à le migrer ou le remplacer lorsque c'est possible. C'est aussi pourquoi la documentation de la GPO Kerberos continue d'avertir sur l'impact en matière de compatibilité. Le nettoyage de RC4 doit d'abord supprimer les dépendances héritées, et non faire comme si elles n'existaient pas.

5. N'utiliser Protected Users que là où c'est réellement pertinent

Microsoft documente que Protected Users restreint ses membres à AES pour Kerberos, arrête de créer des clés DES ou RC4, et empêche DES ou RC4 dans la pré-authentification Kerberos. Cela rend le groupe utile pour certains comptes humains sélectionnés qui peuvent déjà fonctionner proprement sur AES.

Ce n'est pas un levier universel de remédiation RC4. Microsoft avertit explicitement de ne jamais ajouter de comptes de services ou d'ordinateurs à Protected Users. Autrement dit, Protected Users est un contrôle ciblé pour les bons comptes utilisateur, pas un substitut à la correction de la configuration des comptes de service, des appareils ou du KDC — le même problème de périmètre traité dans Comptes privilégiés Active Directory : Protected Users, délégation et angles morts des comptes de service.

6. Tenir compte des changements de valeur par défaut RC4 de 2026, déjà déployés

Le guide de Microsoft sur les tickets de service RC4 ajoute une seconde chronologie qui compte opérationnellement. Ses trois phases appartiennent désormais toutes au passé : il ne s'agit donc plus d'un travail de préparation, mais de l'état que vous devez présumer sur les contrôleurs de domaine mis à jour :

• 13 janvier 2026 : la phase de déploiement initiale a été livrée, avertissant de l'application à venir et ajoutant des événements d'audit pour le comportement RC4 par défaut à risque.
• 14 avril 2026 : la phase d'application a changé la valeur par défaut de DefaultDomainSupportedEncTypes pour les opérations du KDC à 0x18, c'est-à-dire AES-SHA1 uniquement, pour les comptes qui n'ont pas de valeur msDS-SupportedEncryptionTypes explicite. À ce stade, l'application pouvait encore être annulée manuellement.
• Juillet 2026 : les mises à jour Windows publiées en juillet 2026 ou après ont supprimé la prise en charge de la sous-clé de registre RC4DefaultDisablementPhase, si bien que le contrôle de retour en arrière manuel a disparu et que l'application est désormais le mode permanent.

Si vous avez encore besoin de RC4 aujourd'hui, Microsoft indique de le configurer explicitement dans l'attribut msDS-SupportedEncryptionTypes du compte de service plutôt que de dépendre de l'ancien comportement par défaut, car la valeur par défaut du domaine ne le fournit plus.

Validation après le passage à AES

Vous avez terminé lorsque les preuves changent, pas lorsque la GPO paraît plus propre.

Validez le changement dans cet ordre :

1. Confirmez que les nouvelles entrées de l'ID d'événement 4769 pour les services corrigés n'affichent plus de valeurs de ticket de la famille RC4.
2. Confirmez que les valeurs de ticket attendues de la famille AES apparaissent à la place, généralement 0x11 ou 0x12.
3. Confirmez que le compte dispose désormais de clés AES si une réinitialisation de mot de passe était le correctif visé.
4. Confirmez que l'authentification du service fonctionne toujours après les réinitialisations de mot de passe, les redémarrages de service ou les modifications de paramètres de compte.
5. Sur les contrôleurs de domaine mis à jour pour le parcours de durcissement 2026, confirmez l'absence d'avertissements ou d'erreurs Kdcsvc 201-209 pertinents pour les chemins corrigés.
6. Testez explicitement l'interopérabilité non-Windows. Microsoft indique que l'absence d'événements d'audit ne garantit pas que tous les appareils non-Windows accepteront avec succès l'authentification Kerberos après la mise à jour d'avril 2026.

Si vous souhaitez suivre ce point dans la durée plutôt que comme un nettoyage ponctuel, intégrez-le à un workflow d'audit récurrent et gardez-le dans la même famille de contrôles que les mauvaises configurations de sécurité Active Directory plus larges qui alimentent la dérive d'identité.

Comment EtcSec détecte le fallback Kerberos RC4

EtcSec détecte le fallback Kerberos RC4 en corrélant les preuves que Microsoft expose désormais de manière opérationnelle :

• l'émission de tickets de la famille RC4 dans la télémétrie des tickets de service Kerberos
• les comptes qui dépendent encore de paramètres de chiffrement par défaut ou explicites compatibles RC4
• les principaux qui manquent de clés AES utilisables en raison de l'ancienneté du compte ou d'une dérive de l'historique des mots de passe
• les chemins de comptes de service où le fallback RC4 et l'exposition à des tickets cassables se recoupent

Cela permet aux équipes de remesurer après les réinitialisations de mot de passe, les modifications de paramètres de compte, le nettoyage des services hérités et le durcissement du KDC, plutôt que de traiter RC4 comme un élément de revue ponctuel.

Références primaires

• Detect and remediate RC4 usage in Kerberos
• Event 4769: A Kerberos service ticket was requested
• KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966
• How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833
• CVE-2026-20833 in the NVD
• Protected Users security group
• Preventing Kerberos change password that uses RC4 secret keys
• Linux accounts can't get AES-encrypted tickets in AD DS
• Network security: Configure encryption types allowed for Kerberos