La fin de Kerberos RC4 : ce que l’échéance Microsoft de juillet 2026 signifie pour le SSO mobile

Lukas Schönbächler · Juillet 2026 · 7 min de lecture

En juin, nous avons détaillé le plan de Microsoft pour désactiver NTLM et ses conséquences pour les flottes mobiles. NTLM n’est pas le seul mécanisme d’authentification hérité que Microsoft démonte en 2026. L’autre, le chiffrement RC4 au sein même de Kerberos, vient d’atteindre son point de non-retour : avec la mise à jour cumulative de juillet 2026, la dernière porte de sortie disparaît définitivement. Voici ce qui a changé, pourquoi cela compte face au Kerberoasting et où cela peut casser discrètement l’authentification unique sur mobile.

Ce qui a changé le 14 juillet 2026

Il s’agit de la phase finale d’un déploiement lancé par Microsoft en janvier 2026 en réponse à la CVE-2026-20833, documenté dans la KB5073381 :

• 13 janvier 2026 (phase 1) : les contrôleurs de domaine commencent à journaliser des événements d’audit (événements Kdcsvc 201 à 209 dans le journal Système) dès qu’un ticket dépend de RC4. La valeur de registre RC4DefaultDisablementPhase sous HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters fait son apparition pour permettre aux administrateurs d’activer l’application stricte en avance.
• 14 avril 2026 (phase 2) : la suite de chiffrement par défaut du domaine bascule sur AES-SHA1 uniquement (0x18). Les comptes sans types de chiffrement explicites ne reçoivent plus de tickets RC4. En cas de casse, un retour au mode audit restait possible via la valeur de registre.
• 14 juillet 2026 (phase 3) : la valeur de retour en arrière est supprimée et n’est plus lue. L’application stricte est permanente.

L’équipe d’ingénierie AskDS de Microsoft l’a dit sans détour : « Après l’installation des mises à jour cumulatives Windows de juillet 2026, le comportement sera identique à celui d’avril 2026, mais vous ne pourrez plus revenir au mode audit. » RC4 ne fonctionne désormais que pour les comptes où il est explicitement activé dans msDS-SupportedEncryptionTypes, une exception par compte que Microsoft déconseille expressément.

Figure 1 : le retrait de RC4 en trois phases. Depuis le 14 juillet 2026, il n’existe plus de retour à RC4 à l’échelle du domaine.

Pourquoi RC4 devait disparaître : le Kerberoasting

L’attaque qui a condamné RC4 s’appelle le Kerberoasting. N’importe quel utilisateur authentifié du domaine, sans le moindre privilège élevé, peut demander un ticket de service Kerberos pour tout compte doté d’un nom de principal de service (SPN). Ce ticket est chiffré avec la clé du compte de service, et la demande ne déclenche aucune alerte. L’attaquant emporte le ticket hors ligne et en extrait le mot de passe par force brute.

Le chiffrement décide si cette attaque est praticable. Un ticket RC4-HMAC est chiffré avec une clé dérivée directement du hachage NT du mot de passe du compte, que des GPU grand public attaquent à très grande vitesse ; des mots de passe moyennement complexes tombent en quelques heures. Les clés AES sont dérivées via PBKDF2, avec des milliers d’itérations et un sel, ce qui ralentit la même attaque de plusieurs ordres de grandeur. Un compte de service qui ne possède que des clés RC4 peut être cassé hors ligne en toute tranquillité, et les comptes de service disposent souvent d’accès étendus.

Il y a aussi un angle conformité : la NIST SP 800-131A a proscrit RC4 dès 2016, PCI-DSS 4.0 exige des plans de remédiation documentés pour les chiffrements faibles, et les cyberassureurs ont commencé à interroger la posture de chiffrement Kerberos dans leurs questionnaires de renouvellement 2026.

Deux retraits, un même scénario

Si le schéma vous semble familier, c’est normal. Le retrait de RC4 suit le même déroulé en trois temps que celui de NTLM : d’abord les événements d’audit, ensuite la bascule des valeurs par défaut, enfin la suppression de la porte de sortie. RC4 a simplement parcouru le cycle complet en six mois. Considérez-le comme la répétition générale de ce que donnera l’application stricte de NTLM.

	Retrait de NTLM	Retrait de RC4 dans Kerberos
Phase d’audit	Événements 4020 / 4022 / 4032 (Win 11 24H2, Server 2025)	Événements Kdcsvc 201 à 209 (janvier 2026)
Bascule par défaut	BlockNTLMv1SSO sur Enforce, octobre 2026 (KB5066470)	AES seul par défaut (0x18), 14 avril 2026
Porte de sortie	Réactivation par stratégie de groupe (jusqu’au prochain LTSC)	Clé de registre RC4DefaultDisablementPhase
Point de non-retour	Prochain Windows Server LTSC (prévu pour 2027)	14 juillet 2026 : clé supprimée
Victimes habituelles	Appareils mobiles, clients hérités et en groupe de travail	Comptes de service, imprimantes, appliances, applications tierces
Détection	Événements 8003 / 4022 sur les serveurs applicatifs	Événement 4769 avec type de chiffrement de ticket 0x17
Correctif pour les flux mobiles	Certificats PKINIT via votre MDM	Des clés AES sur les comptes derrière vos applications

Ce que cela signifie pour le SSO Kerberos mobile

Un flux Kerberos mobile comporte deux moitiés. D’abord, l’appareil obtient un ticket d’octroi de tickets (TGT) pour l’utilisateur. Cette moitié ne pose aucun problème. Hypergate Authenticator négocie AES par défaut : aucune mise à jour d’application, aucun changement de configuration managée, rien à préparer côté appareil pour cette échéance. Seule exception : si vous avez un jour forcé des chiffrements hérités via une configuration Kerberos personnalisée, retirez cette dérogation à l’occasion de ce nettoyage. Ensuite, pour chaque application interne que l’utilisateur ouvre, l’appareil demande un ticket de service pour le SPN de cette application, et ce ticket est chiffré avec la clé du compte de service.

C’est dans cette seconde moitié que le 14 juillet frappe. Si le compte qui porte votre intranet, votre SharePoint sur site ou une API métier ne possède que des clés RC4, le KDC ne peut plus émettre de ticket pour lui. L’application renvoie des 401 en boucle. L’expérience utilisateur est identique à celle d’un blocage NTLM, et c’est précisément pour cela que le diagnostic déraille facilement : les équipes qui viennent de migrer leur flotte mobile de NTLM vers Kerberos soupçonneront la migration, alors que le vrai coupable est un compte AD dont le mot de passe a été défini pour la dernière fois en 2009.

Une distinction réduit nettement le périmètre de recherche. Les SPN enregistrés sur des comptes d’ordinateur posent rarement problème : les comptes machine changent leur mot de passe tous les 30 jours et ont généré leurs clés AES depuis longtemps. L’exposition se concentre sur les comptes de service de type utilisateur, ceux que l’on trouve derrière SAP, des applications web héritées ou un pool d’applications IIS configuré une fois puis oublié. Leurs clés ne se renouvellent qu’au changement de mot de passe, et pour certains de ces comptes, cela n’est jamais arrivé.

Figure 2 : l’appareil obtient son TGT AES sans difficulté. La casse survient une étape plus loin, quand le ticket de service pour le SPN d’une application dépend d’un compte de service qui n’a jamais reçu de clés AES.

Trouvez vos dépendances à RC4

Deux endroits vous disent où vous en êtes. Sur les contrôleurs de domaine, le journal Système contient les événements Kdcsvc de la KB5073381 : 201 et 202 sont les avertissements d’audit ; 203, 204, 208 et 209 signalent qu’un ticket a réellement été refusé. Dans le journal Sécurité, l’événement 4769 avec le type de chiffrement de ticket 0x17 identifie chaque ticket de service encore émis en RC4 (AES256 apparaît comme 0x12).

Côté annuaire, listez tous les comptes porteurs d’un SPN et vérifiez leurs types de chiffrement :

# Tous les comptes de service (SPN défini) et leurs types de chiffrement Kerberos
Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
    -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes |
    Select-Object Name,
        @{N='EncTypes';E={'0x{0:X}' -f [int]$_.'msDS-SupportedEncryptionTypes'}},
        @{N='SPNs';E={$_.ServicePrincipalName -join ', '}}

Lecture des valeurs : 0x18 signifie AES uniquement, le nouveau défaut et la cible à atteindre. 0x4 signifie RC4 uniquement, qui a cessé de fonctionner le 14 juillet. 0x0 (jamais défini) bascule désormais sur AES, mais cela n’aide que si le compte possède réellement des clés AES ; les comptes dont le mot de passe est antérieur au passage du domaine au niveau fonctionnel Windows Server 2008 ne les ont jamais générées. 0x24 est la solution de repli d’interopérabilité documentée (RC4 avec clés de session AES) et doit rester temporaire.

Le correctif : des clés AES, pas des exceptions

Pour chaque compte que l’audit fait remonter, le correctif est le même et prend quelques minutes :

1. Réinitialisez le mot de passe du compte. Une réinitialisation génère du matériel de clé neuf, y compris les clés AES manquantes. Pour la plupart des comptes, cela suffit.
2. Définissez msDS-SupportedEncryptionTypes sur 0x18 pour les comptes de service critiques, afin que la configuration soit explicite plutôt qu’héritée d’un défaut.
3. Vérifiez depuis le côté mobile. Ouvrez les applications protégées par Kerberos qu’utilise votre flotte et confirmez que les événements 4769 affichent désormais le type de chiffrement 0x12 pour leurs SPN.
4. Là où vous maîtrisez le service, envisagez un gMSA. Les comptes de service administrés de groupe font tourner automatiquement des mots de passe aléatoires de 240 caractères, portent des clés AES par conception et ne laissent aucun mot de passe choisi par un humain à casser.

Ce qu’il ne faut pas faire, en revanche, c’est semer des exceptions RC4 compte par compte. Chaque exception recrée exactement la cible exposée au Kerberoasting que tout cet exercice vise à éliminer, et les recommandations de Microsoft sont claires : la voie de l’exception est un dernier recours pour les appliances héritées, pas une stratégie de migration.

Où cela vous mène

La direction est à sens unique : RC4 a perdu son retour en arrière en juillet, NTLMv1 sera bloqué en octobre (KB5066470) et le NTLM réseau s’éteindra avec le prochain Windows Server LTSC. Chaque étape aboutit au même point : Kerberos avec AES et, de plus en plus, des certificats à la place des mots de passe. Pour les flottes mobiles, la bonne nouvelle est qu’une architecture fondée sur PKINIT parle déjà AES de bout en bout ; le travail restant relève de l’hygiène Active Directory sur les comptes derrière vos applications. Auditez dès maintenant les types de chiffrement des événements 4769, réinitialisez les retardataires, et la prochaine échéance de protocole hérité passera sans que personne ne s’en aperçoive.

---