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 offline de Kerberoasting pertinente, même dans des domaines qui paraissent déjà modernes sur le papier.

Cet article n’est pas un deuxième guide sur Kerberoasting. Il ne recouvre pas non plus l’angle Silver Ticket. 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 maintenant clairement. Dans sa guidance 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 préférer 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 pour cela que ce sujet a sa place à la fois dans un audit AD orienté preuve et dans un plan de durcissement AD orienté priorités.

Pourquoi RC4 apparaît encore dans des environnements AD modernes

L’erreur la plus courante consiste à supposer que voir RC4 dans un ticket signifie toujours qu’un seul mauvais GPO est en cause. La documentation Microsoft actuelle pointe plusieurs causes racines différentes, et elles ne se remédient pas toutes de la même façon.

Deux points Microsoft comptent ici.

D’abord, les changements Kerberos du 8 novembre 2022 n’ont pas supprimé RC4 partout. Microsoft Support dit 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 dit que RC4 apparaît encore pour les comptes qui ne prennent pas en charge AES-SHA1.

Ensuite, les comptes ordinateur et les comptes utilisateur ou de service ne se comportent pas de la même manière. Microsoft Support dit que les ordinateurs Windows définissent automatiquement msDS-SupportedEncryptionTypes pour leurs comptes machine à partir de la policy Kerberos locale, mais que les comptes utilisateur, group Managed Service Accounts et autres comptes AD ne reçoivent pas automatiquement cette valeur. Cette différence est l’une des raisons principales pour lesquelles les comptes de service reviennent constamment 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 dit que les détails d’usage de Kerberos RC4 sont enregistrés dans les Security logs sur les KDC sous Windows Server 2019 et versions ultérieures, et que Windows Server 2016 a lui aussi gagné cette visibilité après la cumulative update de janvier 2025.

Commencez avec ces sources de données :

Si vous centralisez déjà la télémétrie DC, cela doit vivre à côté des événements Kerberos couverts dans Supervision Sécurité AD : Événements Clés, pas dans un rapport ad hoc séparé.

Ce que dit réellement Event ID 4769

Event ID 4769 est l’endroit le plus pratique pour prouver le fallback Kerberos RC4 parce que Microsoft documente à la fois la valeur de chiffrement du ticket et les champs de contexte autour.

Deux détails comptent immédiatement :

1. Microsoft documente Ticket Encryption Type = 0x17 comme RC4-HMAC, et 0x18 comme RC4-HMAC-EXP.
2. Microsoft dit aussi que, depuis Windows Vista et Windows Server 2008, les valeurs attendues pour le chiffrement des tickets de service sont 0x11 et 0x12, qui sont des algorithmes de la famille AES.

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

Note : ne confondez pas Ticket Encryption Type = 0x17 dans Event ID 4769 avec msDS-SupportedEncryptionTypes = 0x18 ou DefaultDomainSupportedEncTypes = 0x18. Dans Event 4769, 0x17 et 0x18 sont des valeurs de ticket de la famille RC4. Dans le contexte du bitmask AD et KDC, 0x18 signifie uniquement AES128 plus AES256.

Cette distinction compte parce qu’il est facile de construire la mauvaise remédiation si vous mélangez les valeurs d’événement et les bitmasks AD.

Quand vous investiguez 4769, utilisez-le avec le contexte de compte autour :

• Si Ticket Encryption Type appartient à la famille RC4 et que le compte de service n’a pas de clés AES, l’historique de mot de passe est souvent la vraie cause.
• Si le client ou la cible n’annonce pas AES, la compatibilité de policy ou de plateforme est généralement impliquée.
• Si les champs de l’événement suggèrent qu’un compte ne supporte qu’un comportement par défaut, revoyez si le compte a réellement une valeur msDS-SupportedEncryptionTypes brute dans AD ou si le KDC retombe sur le défaut du domaine.

Causes racines courantes derrière l’émission de tickets RC4

Anciens comptes sans clés AES régénérées

Microsoft Learn dit que si un compte utilisateur a été créé avant l’ajout de la prise en charge AES-SHA1 dans Windows Kerberos et que son mot de passe n’a jamais été réinitialisé après cet ajout, le compte peut ne pas avoir de clés AES-SHA1. Microsoft rattache cela à l’introduction historique du support AES dans Windows Server 2003 et indique explicitement que le changement de mot de passe du compte génère les clés manquantes.

C’est pour cela que le nettoyage RC4 est en partie un sujet de cycle de vie des mots de passe et pas seulement un sujet de policy protocolaire. Cela explique aussi pourquoi le sujet recoupe souvent les problèmes d’hygiène des comptes de service décrits dans Active Directory Password Security: Misconfigurations That Matter.

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

Microsoft Support dit que si un compte n’a pas msDS-SupportedEncryptionTypes défini, ou s’il est défini à 0, les contrôleurs de domaine supposent une valeur par défaut 0x27 ou utilisent le paramètre de registre DefaultDomainSupportedEncTypes. Microsoft Learn dit aussi que le KDC utilise le défaut du domaine quand la machine source ou cible n’a pas de valeur définie.

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

Utilisez les commandes de 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 vient de Microsoft Support et sert précisément à trouver les comptes où DES ou RC4 est explicitement activé alors que AES ne l’est pas.

Pour la revue d’un seul objet, Microsoft Learn montre ce schéma :

$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 legacy qui ne prennent toujours pas en charge AES

La documentation Microsoft sur la policy Kerberos avertit encore que le paramètre Network security: Configure encryption types allowed for Kerberos peut affecter la compatibilité avec les ordinateurs clients, les services et les applications. La même guidance Microsoft Learn dit que la dernière plateforme Windows qui ne prenait pas en charge AES-SHA1 était Windows Server 2003 et recommande la migration pour les appareils qui dépendent encore de l’ancien comportement.

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

Cas limites Linux intégrés

Microsoft documente maintenant un scénario spécifique Linux intégré dans lequel AD DS émet encore des tickets chiffrés en RC4. Dans ce cas, Event ID 4769 montre Ticket Encryption Type: 0x17, et Microsoft dit que forcer msDS-SupportedEncryptionTypes à 24 (0x18) ou modifier le GPO Kerberos des types de chiffrement ne résout pas le problème.

La raison documentée est plus étroite que « Linux provoque RC4 ». Microsoft dit que le problème survient parce que l’attribut operatingSystemVersion est interprété d’une manière qui fait que le KDC traite le compte comme si les types de chiffrement supportés n’étaient pas renseignés, ce qui pousse le KDC à utiliser à la place les types de chiffrement supposés supportés.

C’est un cas limite utile à connaître parce qu’il prouve que certaines constatations RC4 sont causées par la sémantique des métadonnées d’annuaire, pas seulement par une dérive de policy évidente.

Comment remédier aux dépendances RC4 sans risque

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

Actionable next steps

Commencez par confirmer l’émission RC4, classer les comptes concernés, puis traiter ce nettoyage dans le même flux qu’un plan de durcissement AD orienté priorités avant tout durcissement global.

1. Prouver où RC4 est émis avant de changer les défauts

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. Si vous avez mis à jour les contrôleurs de domaine avec les mises à jour Windows du 13 janvier 2026 ou après, surveillez aussi les événements d’audit Kdcsvc introduits pour le durcissement des tickets de service RC4.

2. Régénérer les clés AES manquantes quand c’est la vraie cause

Si un ancien compte utilisateur ou de service n’a pas de clés AES, Microsoft dit que changer le mot de passe du compte les génère. Cela doit se produire avant d’appliquer des changements plus larges côté KDC. Pour les comptes de service avec SPN, c’est aussi le point où le risque recoupe Kerberoasting : des tickets appuyés sur RC4 sont plus faciles à transformer en cracking offline quand des mots de passe faibles ou réutilisés sont aussi présents.

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

Vérifiez l’attribut msDS-SupportedEncryptionTypes brut, puis comparez-le à ce que montre l’événement. Si l’attribut est vide ou vaut 0, le KDC peut utiliser DefaultDomainSupportedEncTypes à la place. Si un compte machine définit la valeur automatiquement à partir de la policy locale, corrigez la policy de l’appareil. Si un compte utilisateur ou de service a besoin d’une valeur explicite, modifiez ce compte délibérément au lieu de changer d’abord tout le défaut du domaine.

4. Supprimer les dépendances legacy avant de durcir la policy Kerberos

Si le client, le service, l’appliance ou la pile non Windows ne prend pas réellement en charge AES, la guidance Microsoft elle-même est de migrer ou remplacer quand c’est possible. C’est aussi pour cela que la documentation du GPO Kerberos continue d’avertir sur l’impact de compatibilité. Le nettoyage RC4 doit d’abord supprimer les dépendances legacy, pas prétendre qu’elles n’existent pas.

5. Utiliser Protected Users uniquement là où cela convient vraiment

Microsoft documente que Protected Users limite ses membres à AES pour Kerberos, cesse de créer des clés DES ou RC4, et empêche DES ou RC4 dans la preauthentication Kerberos. Cela rend le groupe utile pour des comptes humains ciblés capables d’opérer proprement avec AES.

Ce n’est pas un levier universel de remédiation RC4. Microsoft avertit explicitement de ne pas ajouter de comptes de service ou de comptes machine à Protected Users. Autrement dit, Protected Users est un contrôle ciblé pour les bons comptes utilisateur, pas un substitut à la correction des comptes de service, des appareils ou de la configuration KDC.

6. Se préparer aux changements par défaut RC4 de 2026 avec des dates explicites

La guidance Microsoft sur les tickets de service RC4 ajoute une seconde timeline qui compte opérationnellement :

• January 13, 2026: début de la phase de déploiement initiale et ajout d’événements d’audit pour le comportement RC4 par défaut risqué.
• April 14, 2026: la phase d’application change la valeur par défaut DefaultDomainSupportedEncTypes pour les opérations KDC vers 0x18, c’est-à-dire AES-SHA1 uniquement, pour les comptes qui n’ont pas de valeur msDS-SupportedEncryptionTypes explicite.
• July 2026: Microsoft dit que le contrôle temporaire de rollback pour ce comportement est retiré et que l’application devient le mode permanent.

C’est la timeline Microsoft actuelle. Si vous avez encore besoin de RC4 après le 14 avril 2026, Microsoft dit de l’activer explicitement dans le bitmask msDS-SupportedEncryptionTypes du compte de service au lieu de dépendre de l’ancien comportement par défaut.

Validation après le passage à AES

Vous avez terminé quand la preuve change, pas quand le GPO paraît plus propre.

Validez le changement dans cet ordre :

1. Confirmer que les nouveaux Event ID 4769 pour les services remédiés n’affichent plus de valeurs de ticket de la famille RC4.
2. Confirmer que des valeurs AES attendues apparaissent à la place, généralement 0x11 ou 0x12.
3. Confirmer que le compte dispose maintenant de clés AES si une réinitialisation de mot de passe était la correction visée.
4. Confirmer que l’authentification du service fonctionne toujours après réinitialisation de mot de passe, redémarrage de service ou changement de paramètres du compte.
5. Sur les contrôleurs de domaine mis à jour pour le chemin de durcissement 2026, confirmer qu’il n’existe plus d’avertissements ou d’erreurs Kdcsvc 201-209 pertinents pour les chemins remédiés.
6. Tester explicitement l’interopérabilité non Windows. Microsoft dit que l’absence d’événements d’audit ne garantit pas que chaque appareil non Windows continuera à fonctionner après la mise à jour d’application du 14 avril 2026.

Si vous voulez suivre cela dans le temps au lieu d’en faire un nettoyage ponctuel, intégrez-le dans 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 les plus courantes qui alimentent la dérive identitaire. Dans les environnements où des comptes de service fragiles s’alignent avec des délégations et permissions faibles, ce constat recoupe aussi les chemins d'attaque AD.

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 :

• émission de tickets de service Kerberos de la famille RC4
• comptes qui dépendent encore de paramètres de chiffrement par défaut ou explicites compatibles RC4
• principaux qui ne disposent pas de clés AES utilisables après dérive liée à l’âge du compte ou à l’historique de mot de passe
• chemins de comptes de service où le fallback RC4 et l’exposition à des tickets crackables se recoupent

Cela permet aux équipes de remesurer après réinitialisation de mot de passe, changement de paramètres de compte, nettoyage de services legacy et durcissement KDC au lieu de traiter RC4 comme un sujet à vérifier une seule fois.

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
• 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