Dit comme cela, cela peut faire un peu peur mais mieux vaut sonner l’alarme. ;-). Ignorer cet événement pourrait avoir quelques conséquences non négligeables sur vos environnements de production.
Alors, si vous utilisez Windows Server AD, et si vous n’avez jamais entendu parler de ce retrait protocolaire, je vous conseille de prendre un peu de temps pour lire cet article.
Qu’est ce que RC4 au juste ?
RC4 (Rivest Cipher 4) est en fait un algorithme de chiffrement historique utilisé par Kerberos, le protocole d’authentification d’Active Directory. Lorsqu’un utilisateur ou un service s’authentifie, le contrôleur de domaine (KDC) lui délivre un « ticket » chiffré. Pendant près de vingt ans, RC4-HMAC a servi de chiffrement par défaut, puis de repli de compatibilité (fallback) pour les comptes et équipements ne supportant pas mieux.
Le problème : RC4 est aujourd’hui considéré comme cryptographiquement cassé. Conséquence directe : l’attaque Kerberoasting. N’importe quel compte du domaine peut demander un ticket de service ; si ce ticket est chiffré en RC4, l’attaquant le casse hors ligne en quelques minutes sur du matériel grand public et récupère le mot de passe du compte de service — souvent un compte à privilèges. C’est l’objet de la vulnérabilité CVE-2026-20833 (divulgation d’information, CVSS 5.5).
En fait, l’alternative existe depuis longtemps : c’est AES-SHA1 (AES128 et AES256) qui est disponible sur toutes les versions de Windows depuis Windows Server 2008. Il n’y a donc plus de justification technique à conserver RC4, hormis des dépendances héritées et c’est bien celles la dont il faut vous méfiez.
Les véritables enjeux de l’abandon de ce protocole ?
si l’on résume, 3 types d’enjeux se posent désormais.
- Enjeu de sécurité. Tant que RC4 reste négociable, l’environnement reste exposé au Kerberoasting et au vol d’identifiants à privilèges, donc à des mouvements latéraux et à une compromission de domaine.
- Enjeu opérationnel — le piège du patching. Les mises à jour de sécurité Windows durcissent progressivement Kerberos. Si l’environnement dépend encore de RC4, patcher casse l’authentification ; ne pas patcher laisse des serveurs vulnérables. Beaucoup d’organisations bloquent alors les mises à jour de leurs contrôleurs de domaine — créant une dette de sécurité qui se referme avec l’échéance d’enforcement.
- Enjeu d’outillage tiers. Les produits qui s’appuient sur RC4 (synchronisation de comptes/mots de passe inter-forêts, appliances de stockage, applications anciennes) cessent de fonctionner une fois RC4 retiré — d’où des projets de migration souvent contraints par le calendrier Microsoft.
Le calendrier annoncé par Microsoft
Le retrait de RC4 n’est pas une décision isolée : c’est l’aboutissement d’une trajectoire de plusieurs années comme le précise le tableau suivant.
| Date | Annonce / vecteur | Ce qui change |
| 8 nov. 2022 | CVE-2022-37966 — KB5021131 | AES devient le chiffrement par défaut des clés de session pour les comptes sans type explicite. Introduction de la clé DefaultDomainSupportedEncTypes (défaut 0x27 = DES, RC4, AES session keys). Microsoft recommande déjà 0x3C, ou 0x38 pour un environnement AES-only. |
| 8 nov. 2022 | CVE-2022-37967 — KB5020805 | Durcissement des signatures PAC Kerberos ; événement KDC ID 42 (« lacks strong keys ») signalant les comptes sans clé AES. |
| Janv. 2025 | Cumulative update | La journalisation de l’usage RC4 (événements 4768/4769 enrichis) est étendue à Windows Server 2016. |
| 3 déc. 2025 | Blog Microsoft Windows Server — « Beyond RC4 for Windows authentication » | Annonce officielle du changement du défaut des DC à mi-2026. Nouveaux outils d’audit : champs ajoutés aux événements 4768/4769 et scripts PowerShell List-AccountKeys.ps1 / Get-KerbEncryptionUsage.ps1 (dépôt GitHub Kerberos-Crypto). Mis à jour le 4 févr. 2026 avec la stratégie de déploiement. |
| 13 janv. 2026 | CVE-2026-20833 + mise à jour de sécurité | Démarrage du rollout en 3 phases. Nouveaux événements KDCSVC 201-209 et clé temporaire RC4DefaultDisablementPhase. |
| Avril 2026 | Mise à jour cumulative | Bascule du défaut des DC vers AES-SHA1 uniquement (0x18). |
| Juillet 2026 | Mise à jour de sécurité | Enforcement final : mode audit supprimé, dérogation globale supprimée. |
| Référence | Microsoft Learn — « Detect and Remediate RC4 Usage in Kerberos » | Guide officiel : Microsoft prévoit de désactiver RC4 comme type de chiffrement supposé par défaut des DC d’ici la fin du 2ᵉ trimestre 2026. |
NTLM suit la même trajectoire de retrait (déprécié, désactivation par défaut prévue pour une prochaine version de Windows Server). RC4 est la première étape.
Microsoft procède en trois phases pour laisser le temps d’inventorier et de remédier, selon le schéma détecter → avertir → appliquer → supprimer le repli.
Phase 1 — Audit (13 janvier 2026)
RC4 fonctionne toujours, aucun changement de comportement. Les DC patchés émettent les nouveaux événements KDCSVC (201-209). La clé RC4DefaultDisablementPhase peut être créée manuellement : 1 = audit, 2 = simuler par anticipation le comportement d’avril.
Phase 2 — Application « souple » (avril 2026)
Le défaut DefaultDomainSupportedEncTypes passe à 0x18 (AES uniquement) pour les comptes dont l’attribut msDS-SupportedEncryptionTypes est vide. Le KDC rejette les requêtes qui ne supportent que RC4 → les comptes de service et applications restés en RC4 commencent à échouer. Retour arrière encore possible ; si vous aviez déjà fixé ces clés, le correctif ne les écrase pas.
Phase 3 — Application « stricte » (juillet 2026)
La clé RC4DefaultDisablementPhase n’est plus lue, le mode audit disparaît. À partir de là, la seule façon d’autoriser RC4 est une dérogation explicite (par compte ou par domaine — voir section 6). C’est le point de non-retour pour toute dépendance non traitée.
Plusieurs services risquent de ne plus fonctionner comme ceux préciser ci dessous. Attention cette liste n’est évidement pas exhausive.
- Comptes de service sans clé AES explicite : SQL Server, pools d’applications IIS, tâches planifiées, comptes applicatifs.
- FSLogix (profils sur partages SMB en AVD / RDS) : échec de chargement des profils à l’ouverture de session.
- NAS et appliances de stockage (NetApp, Synology, QNAP…) joints au domaine et ne supportant pas AES-SHA1.
- Équipements et applications non-Windows, intégrations LDAP/Kerberos anciennes.
- Approbations inter-forêts (trusts) créées en RC4 et non repassées en AES.
- Outils tiers type Quest (synchronisation de comptes/mots de passe) — cas fréquent de blocage.
- Tout système antérieur à Windows Server 2008 (et a fortiori 2003), qui ne connaît pas AES.
Si vous êtes en retard 🙂
Vous pouvez gagner du temps et toujours au prix d’un risque de sécurité assumé. Voici les leviers, du plus global au plus ciblé.
Levier A — Rester en audit le plus longtemps possible
Tant que vous ne forcez pas RC4DefaultDisablementPhase à 2, la phase 1 ne change rien. Cela permet de continuer à patcher les DC sans casser RC4. Valable jusqu’en avril ; en avril le défaut bascule malgré tout, et en juillet ce levier disparaît.
Levier B — Réautoriser RC4 au niveau du domaine
Clé HKLM\System\CurrentControlSet\Services\KDC → DefaultDomainSupportedEncTypes (REG_DWORD). Valeurs utiles :
| Valeur | Signification |
| 0x27 | DES + RC4 + clés de session AES (ancien défaut pré-durcissement). |
| 0x1C | RC4 + AES128 + AES256 (rollback recommandé si l’on doit garder RC4). |
| 0x24 | RC4 + clé de session AES. |
| 0x3C | RC4 + AES + clé de session AES. |
| 0x18 | AES uniquement (défaut de durcissement — cible finale). |
En phase 2, fixer cette clé sur 0x1C rétablit RC4 pour tout le domaine. En phase 3, c’est l’un des deux seuls leviers survivants.
Levier C — Dérogation par compte (recommandé après juillet 2026)
Le levier le plus chirurgical : autoriser RC4 uniquement sur les comptes qui en ont réellement besoin, en posant l’attribut AD msDS-SupportedEncryptionTypes à 0x1C (RC4 + AES). Le reste du domaine reste en AES. Stratégie à privilégier : isoler la dette plutôt que rouvrir RC4 partout.
Repères de valeurs sur l’attribut de compte : 0x18 = AES128+256 (idéal) · 0x10 = AES256 · 0x8 = AES128 · 0x4 = RC4 seul (à proscrire) · null = dépend du défaut du domaine.
Levier D — La GPO d’encadrement
La stratégie « Sécurité réseau : configurer les types de chiffrement autorisés pour Kerberos » permet d’industrialiser, via GPO, les types autorisés sur les postes et serveurs — utile pour piloter la transition à l’échelle plutôt que machine par machine.
Bref vous avez encore quelques jours pour réagir si vous pensez etre concerné. pour savoir si vos comptes de services utilisent ce protocole il vous reste a auditer l’usage du RC4 en traquant les événements 4768/4769 (RC4 = 0x17 dans Ticket Encryption Type), événements KDCSVC 201-209, et utilisez les scripts Microsoft List-AccountKeys.ps1 / Get-KerbEncryptionUsage.ps1.
Bon courage
Cordialement
LAurent TERUIN
Travailler ensemble 