RC4 et Kerberos : la dernière phase de bascule est passée

Le 8 septembre 2026, la Zero Day Initiative a publié sa revue mensuelle des correctifs Microsoft. Pas une ligne sur Kerberos. Et pourtant, c’est le mois où la dernière phase d’un changement lancé en janvier est censée être derrière toi depuis juillet : la fin du repli automatique sur RC4 dans Active Directory. Si tu n’as pas suivi le dossier de près, il y a de bonnes chances qu’un ou deux comptes de service chez toi authentifient encore en RC4-HMAC sans que personne s’en soit rendu compte — jusqu’au jour où un client Windows patché refuse purement et simplement le ticket.

CVE-2026-20833, ou pourquoi RC4 devait sauter

Le sujet n’est pas nouveau. Depuis les correctifs de novembre 2022 liés à CVE-2022-37966, Windows préfère AES-SHA1 par défaut pour les comptes sans msDS-SupportedEncryptionTypes explicite. Mais « préférer » n’est pas « imposer » : tant qu’un compte ne supportait pas AES, le KDC continuait à délivrer du RC4-HMAC sans broncher. Cette tolérance est exactement ce qu’exploite le Kerberoasting — un attaquant demande un ticket de service, l’extrait, et le casse hors ligne parce que RC4 se prête bien mieux au brute-force qu’AES256.

CVE-2026-20833 formalise ce risque résiduel et pousse Microsoft à couper le filet de sécurité : le repli implicite sur RC4 devait être désactivé par défaut sur les contrôleurs de domaine d’ici la fin du deuxième trimestre 2026. Ce n’est plus une recommandation, c’est un calendrier avec des dates de bascule fixées dans les correctifs de sécurité mensuels.

Trois phases, et la troisième ne se rembobine pas

Le déploiement a suivi un rythme volontairement progressif, en trois temps :

• Janvier 2026 — mode audit. Aucune authentification ne casse. Les événements 4768/4769 se mettent à journaliser le type de chiffrement utilisé pour chaque demande de ticket, ce qui te donne enfin une visibilité réelle sur qui utilise encore RC4 dans ton annuaire.
• Avril 2026 — application avec filet de rattrapage. Le KDC passe en mode AES-only pour tout compte dont msDS-SupportedEncryptionTypes n’est pas défini. Tu peux encore configurer explicitement RC4 sur un compte précis pour gagner du temps, le temps de migrer proprement.
• Juillet 2026 — application définitive. Le mode audit et la possibilité de rollback disparaissent. RC4 ne fonctionne plus que si tu l’as explicitement autorisé compte par compte, ce qui reste fortement déconseillé.

Nous sommes fin septembre : la phase 3 est derrière nous depuis deux mois. Si un service authentifie encore silencieusement en RC4 sur un compte que personne n’a remis à niveau, ce n’est plus une fenêtre de tir qui se referme — c’est déjà fermé, et la panne surviendra au prochain redémarrage de service, à la prochaine rotation de mot de passe, ou dès qu’un client durci rejoindra le domaine.

Comment savoir si tu es exposé, concrètement

Pas besoin de deviner. La méthode documentée par Microsoft passe par les journaux d’événements Kerberos :

Get-ADObject -Filter "Name -eq 'nomducompte' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')" `
    -Properties "msDS-SupportedEncryptionTypes" |
    Format-List DistinguishedName, msDS-SupportedEncryptionTypes, Name, ObjectClass

Une valeur de 28 (0x1C en hexadécimal) signifie RC4 + AES128 + AES256 encore acceptés. Tu veux arriver à 24 (0x18) — AES128 et AES256 uniquement, RC4 explicitement exclu. Si l’attribut n’est pas défini du tout, le KDC retombe sur DefaultDomainSupportedEncTypes, une clé de registre sous HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC — un cas plus délicat à traiter parce qu’il touche potentiellement tout le domaine d’un coup plutôt qu’un compte isolé.

Pour repérer les échecs déjà en cours plutôt que d’attendre les tickets, l’outil de diagnostic le plus direct reste klist en ligne de commande :

klist get HOST/serveur.contoso.com

Un message 0xc00002fd avec le texte « The encryption type requested is not supported by the KDC » ne laisse aucune ambiguïté : le compte cible n’a pas les clés AES nécessaires. Le correctif le plus simple, quand c’est un compte utilisateur ou une machine plutôt qu’un compte de service historique, est souvent de simplement réinitialiser le mot de passe — ça régénère les clés AES-SHA1 manquantes sans toucher à quoi que ce soit d’autre.

Le cas particulier de Microsoft Entra Domain Services

Si tu exploites un domaine géré via Microsoft Entra Domain Services, la même logique s’applique côté cloud, avec une alerte dédiée : AADDS123 — Kerberos RC4 usage detected for service ticket issuance. Le principe de résolution est identique — désactiver RC4 dans les paramètres de sécurité du domaine managé, activer les audits de sécurité, surveiller les événements 4768/4769 — à un détail près : pour un compte de service synchronisé depuis un AD on-premises via Microsoft Entra Connect qui a temporairement besoin de RC4, c’est l’attribut msDS-SupportedEncryptionTypes côté AD local qu’il faut modifier, la valeur se synchronisant ensuite vers le domaine managé. L’état de santé du domaine se met à jour automatiquement sous deux heures une fois la dépendance corrigée.

Ce qui casse en pratique (et ce qui ne prévient pas avant)

Deux scénarios reviennent le plus souvent dans les tickets de support après une bascule AES-only mal préparée. Le partage SMB qui refuse soudain la connexion, avec une simple boîte de dialogue d’erreur réseau côté client — sans détail exploitable sans creuser côté serveur. Et la session PowerShell distante via New-PSSession, qui échoue silencieusement parce que WMI s’appuie sur le même mécanisme d’authentification. Dans les deux cas, le réflexe à avoir est le même : lancer klist pour confirmer que le problème vient bien d’un type de chiffrement non supporté, plutôt que de partir sur une fausse piste réseau ou pare-feu.

Il y a un piège classique à éviter : penser qu’un compte utilisateur sans SPN (Service Principal Name) a besoin d’un msDS-SupportedEncryptionTypes configuré. Ce n’est pas le cas — c’est la configuration de l’appareil qui détermine le type de chiffrement pour les demandes de tickets de service et les clés de session, pas celle du compte utilisateur lui-même. Perdre du temps à modifier cet attribut sur des centaines de comptes utilisateurs alors que le vrai problème vient de trois comptes de service oubliés, ça arrive plus souvent qu’on ne le pense.

FAQ

RC4 est-il complètement supprimé de Windows en 2026 ?

Non. Il reste utilisable, mais uniquement si tu le configures explicitement compte par compte (valeur 0x1C ou proche sur msDS-SupportedEncryptionTypes). Ce qui a disparu en juillet 2026, c’est le repli automatique et silencieux vers RC4 quand rien n’est configuré.

Comment auditer sans casser la production ?

Active les catégories d’audit « Kerberos Authentication Service » et « Kerberos Service Ticket Operations » via une stratégie de groupe, puis corrèle les événements 4768/4769 sur tes contrôleurs de domaine. C’est en lecture seule — aucun risque d’interrompre une authentification en cours.

Et si je découvre la dépendance RC4 seulement maintenant, en septembre ?

Tu peux temporairement réautoriser RC4 sur le compte concerné en fixant msDS-SupportedEncryptionTypes à une valeur qui l’inclut (0x1C par exemple), le temps de traiter la cause racine — généralement une application legacy ou un compte de service jamais réinitialisé depuis des années. Ce n’est pas un rollback de la politique KDC elle-même, juste une dérogation ciblée.

Ce qu’il faut retenir

Le plus gros risque n’est pas technique, il est organisationnel : découvrir la dépendance RC4 le jour où un applicatif métier tombe, plutôt qu’en amont via les journaux d’événements. Si tu n’as jamais lancé l’audit sur tes contrôleurs de domaine, c’est le moment de le faire — la fenêtre de tolérance, elle, est close depuis juillet. Pour le reste de ta feuille de route sécurité Windows Server, notre article sur la faille critique WSUS de 2026 et celui sur les changements de sécurité Active Directory dans Windows Server 2025 couvrent les deux autres chantiers qui méritent ta priorité ce trimestre.