Désactiver RC4 dans Kerberos : audit, correction, AES

RC4-HMAC est le type de chiffrement Kerberos qui rend le Kerberoasting bon marché : un ticket RC4 est chiffré avec le hachage NT non salé du compte, si bien que le casser coûte à peu près autant que casser un hachage NTLM, et un attaquant qui détient déjà le hachage NT peut forger des tickets RC4 sans connaître le mot de passe. Les tickets AES reposent sur une dérivation de clé salée et itérée, et sont des ordres de grandeur plus lents à attaquer. La plupart des domaines émettent encore des tickets RC4 pour au moins une partie des comptes, non pas parce que quelque chose en a besoin, mais parce que personne n'a prouvé que rien n'en avait besoin.

Ce guide est la version pas à pas de la section RC4 de Durcissement de Kerberos : comment le KDC choisit réellement un type de chiffrement, comment mesurer l'usage de RC4, comment corriger les comptes incapables d'utiliser AES et comment imposer le changement sans interruption de service.

Comment le KDC choisit un type de chiffrement

Trois éléments déterminent le type de chiffrement d'un ticket de service :

1. L'attribut msDS-SupportedEncryptionTypes du compte cible (indicateurs binaires : 0x4 RC4, 0x8 AES128, 0x10 AES256, 0x20 clés de session AES). S'il est défini, le KDC utilise le type le plus fort que le compte liste et pour lequel il détient une clé.
2. DefaultDomainSupportedEncTypes sur le KDC, utilisé lorsque l'attribut est vide. Les comptes sans attribut défini sont majoritaires : cette valeur de registre est donc la véritable valeur par défaut à l'échelle du domaine.
3. Les clés stockées pour le compte. Un type listé dans l'attribut ne sert à rien si le compte ne possède pas de clé correspondante.

Les comptes d'ordinateurs renseignent eux-mêmes msDS-SupportedEncryptionTypes à partir de la stratégie cliente. Les comptes de service de type utilisateur ne l'ont presque jamais défini ; ils suivent donc DefaultDomainSupportedEncTypes, ce qui signifiait historiquement des tickets RC4. Depuis les mises à jour Kerberos de novembre 2022 (CVE-2022-37966), la valeur supposée pour les comptes sans attribut est 0x27 (DES, RC4 et clés de session AES) : on obtient des clés de session AES, mais toujours un chiffrement de ticket RC4. Microsoft a annoncé de nouveaux changements pour faire passer les DC à des valeurs par défaut AES uniquement au cours de 2026 : vérifiez le comportement de votre niveau de mise à jour dans les notes de version avant de vous fier aux valeurs par défaut.

Mesurer : trouver où RC4 est utilisé

Activer le bon audit

Sur les DC : Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon, activez Audit Kerberos Authentication Service et Audit Kerberos Service Ticket Operations en succès et en échec. Cela produit les événements 4768 (TGT) et 4769 (ticket de service), tous deux dotés d'un champ TicketEncryptionType : 0x17 correspond à RC4, 0x11 à AES128, 0x12 à AES256. Les mises à jour récentes de Windows Server ont ajouté à ces événements des champs décrivant les clés disponibles et les types pris en charge par le compte, ce qui facilite les étapes suivantes si vos DC en disposent.

# Tickets de service RC4 des dernières 24 heures, regroupés par service et par client
$since = (Get-Date).AddHours(-24)
Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'Security'; Id = 4769; StartTime = $since
    } -ErrorAction SilentlyContinue
} | ForEach-Object {
    $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    if ($d.TicketEncryptionType -eq '0x17') {
        [pscustomobject]@{ Service = $d.ServiceName; Client = $d.TargetUserName; Address = $d.IpAddress }
    }
} | Group-Object Service, Client, Address | Sort-Object Count -Descending |
    Select-Object Count, Name

Exécutez la même requête sur les 4768 pour trouver les clients qui demandent des TGT RC4. Transférez ces événements vers votre SIEM pour disposer d'une véritable fenêtre de 30 à 90 jours ; sur des DC chargés, Get-WinEvent ne voit que ce que le journal local conserve. Microsoft publie également, dans son dépôt GitHub Kerberos-Crypto, des scripts d'aide qui synthétisent l'usage du chiffrement à partir de ces événements.

Trouver les comptes sans clés AES

Les clés AES sont créées lorsqu'un mot de passe est défini sur un DC sous Windows Server 2008 ou ultérieur, dans un domaine au niveau fonctionnel 2008 ou supérieur. La date de création du groupe Read-only Domain Controllers (RID 521) est un repère fiable du moment où le domaine a été préparé pour ce niveau. Tout compte dont le mot de passe est antérieur à cette date ne possède pas de clés AES.

$domainSid = (Get-ADDomain).DomainSID.Value
$aesDate = (Get-ADGroup -Identity "$domainSid-521" -Properties whenCreated).whenCreated

Get-ADUser -Filter 'Enabled -eq $true' -Properties PasswordLastSet, ServicePrincipalName |
    Where-Object { $_.PasswordLastSet -lt $aesDate } |
    Select-Object SamAccountName, PasswordLastSet, @{n='HasSPN';e={[bool]$_.ServicePrincipalName}}

Incluez krbtgt et les comptes d'approbation dans la revue. Un mot de passe krbtgt antérieur à cette date constitue à lui seul une non-conformité ; renouvelez-le en suivant la procédure de rotation du krbtgt.

Vérifier les paramètres RC4 explicites

# Comptes autorisant explicitement RC4 ou DES (l'un des bits 0x1, 0x2, 0x4)
Get-ADObject -LDAPFilter '(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.804:=7)' `
    -Properties msDS-SupportedEncryptionTypes, objectClass |
    Select-Object Name, objectClass, msDS-SupportedEncryptionTypes

# Approbations : les TDO sans indicateurs AES se replient sur des tickets de référence RC4
Get-ADObject -Filter 'objectClass -eq "trustedDomain"' -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

Auditer : lever les blocages

Traitez la liste issue de la phase de mesure :

• Comptes sans clés AES : réinitialisez le mot de passe. Pour les comptes de service, coordonnez-vous avec le responsable de l'application ou, mieux, migrez vers un gMSA (voir la migration vers les gMSA).
• Comptes de service utilisés par des systèmes non Windows : régénérez les keytabs en AES, par exemple ktpass /crypto AES256-SHA1 pour le mappage du SPN, et mettez à jour permitted_enctypes dans le krb5.conf du client. Les anciens keytabs ne contenant que des clés RC4 échouent dès que RC4 est retiré.
• Équipements et logiciels hérités qui demandent explicitement RC4 : mettez-les à niveau, reconfigurez-les, ou documentez une exception limitée dans le temps en réglant msDS-SupportedEncryptionTypes sur 0x1C (RC4 plus AES) sur ce seul compte.
• Approbations : activez AES des deux côtés via The other domain supports Kerberos AES Encryption dans les propriétés de l'approbation, ou ksetup /setenctypeattr <trusted domain> AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96.

Marquez explicitement les comptes de service comme compatibles AES pour qu'ils ne dépendent plus de la valeur par défaut du KDC :

# AES128 + AES256 sur les comptes utilisateurs porteurs de SPN
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.SamAccountName -ne 'krbtgt' } |
    ForEach-Object { Set-ADUser $_ -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 } }

Planifier le déploiement

Le retrait de RC4 est peu risqué lorsqu'il est ennuyeux : de petites étapes, chacune réversible et mesurée. Un plan qui fonctionne dans la plupart des domaines de taille moyenne :

1. Semaines 1 à 4 : mesurer uniquement. Audit activé, événements transférés, rapport des comptes sans clés AES produit. Dressez la liste de chaque client et service apparu dans un événement RC4, avec un responsable pour chacun.
2. Semaines 3 à 8 : corriger les comptes. Réinitialisez les mots de passe des comptes sans clés AES, réglez msDS-SupportedEncryptionTypes sur 24 pour les comptes de service, régénérez les keytabs, activez AES sur les approbations. Chaque correction doit faire disparaître une ligne du rapport RC4 ; si ce n'est pas le cas, la cause racine est ailleurs.
3. Semaines 6 à 10 : stratégie cliente par anneaux. Postes pilotes, puis tous les postes de travail, puis les serveurs membres. Les clients qui cessent de demander RC4 n'ont pas besoin que le KDC le refuse ; cet anneau fait donc rarement mal.
4. Après deux semaines calmes : le KDC. Réglez DefaultDomainSupportedEncTypes et la stratégie Kerberos sur les DC, en commençant par les DC d'un seul site si votre topologie le permet.
5. En continu : les exceptions. Chaque compte qui conserve RC4 fait l'objet d'un ticket avec un responsable et une date d'expiration, et figure dans un groupe tel que Kerberos-RC4-Exceptions, afin que l'exception soit visible dans AD plutôt que dans un tableur.

À chaque étape, le retour arrière se résume à une valeur de registre ou à un lien de GPO. Prévoyez un redémarrage des DC à chaque anneau KDC pour que la modification du registre soit prise en compte de façon fiable, et de même en cas de retour arrière. Les tickets existants restent valides jusqu'à leur expiration ; les problèmes peuvent donc mettre jusqu'à la durée de vie d'un ticket (10 heures par défaut) à apparaître. Laissez la fenêtre de changement ouverte assez longtemps pour les voir, et n'empilez pas la modification du KDC avec d'autres changements d'authentification, comme l'application de la signature LDAP, la même semaine : vous ne sauriez plus lequel a cassé une application donnée.

Imposer

Imposez en deux couches, un anneau à la fois.

Valeur par défaut du KDC. Sur chaque DC, définissez la valeur qui s'applique à tous les comptes sans attribut explicite :

# 0x18 = AES128 + AES256. Utilisez 0x38 pour annoncer aussi les clés de session AES.
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' `
    -Name 'DefaultDomainSupportedEncTypes' -Type DWord -Value 0x18

Déployez-la via les préférences de stratégie de groupe (Computer Configuration > Preferences > Windows Settings > Registry) dans une GPO liée à l'UO Domain Controllers, afin que chaque nouveau DC la reçoive.

Stratégie Kerberos. Appliquez Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos (types de chiffrement autorisés pour Kerberos) en ne cochant que AES128_HMAC_SHA1, AES256_HMAC_SHA1 et Future encryption types. Ce paramètre écrit SupportedEncryptionTypes sous HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. Sur les ordinateurs membres, il limite ce que le client demande et met à jour l'attribut du compte d'ordinateur ; sur les DC, il limite ce que le KDC délivre. Déployez-le d'abord sur une UO pilote de postes et de serveurs, puis sur le Tier 1, et enfin sur les DC.

Vérifier

Après chaque anneau, relancez la requête sur les 4769. L'objectif : zéro ticket 0x17 en dehors des exceptions documentées.

# Sur un DC : confirmer les paramètres effectifs
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' -Name DefaultDomainSupportedEncTypes
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
    -Name SupportedEncryptionTypes

# Sur un client : les tickets en cache doivent afficher AES-256-CTS-HMAC-SHA1-96
klist

Surveillez aussi les échecs 4768 et 4769 avec le code de résultat 0xE (KDC_ERR_ETYPE_NOTSUPP) : chacun correspond à un client ou un service qui a perdu la capacité de s'authentifier et doit être traité.

Ce que cela casse

• Les comptes sans clés AES, y compris les anciens comptes de service que personne n'osait réinitialiser, n'obtiennent plus de tickets. La correction est une réinitialisation du mot de passe, qui peut elle-même casser l'application si le mot de passe est codé en dur quelque part.
• Les intégrations à base de keytabs sous Linux, Java et sur des équipements (SSO Web, SAP, stockage) cessent de s'authentifier tant que les keytabs n'ont pas été régénérés avec des clés AES.
• Les anciennes versions de NAS et de Samba qui ne prennent pas en charge AES pour les comptes d'ordinateurs ou de service, ainsi que certaines applications métier héritées qui imposent RC4.
• Les approbations inter-forêts et externes sans AES activé sur l'objet d'approbation cassent les tickets de référence une fois RC4 retiré.
• Les systèmes de l'époque Windows XP / Server 2003 : ils ne prennent pas du tout en charge AES. Ils ne devraient plus exister, mais s'ils existent, ils cessent de s'authentifier.

Pour aller plus loin : le domaine Kerberos et authentification, la défense contre le Kerberoasting pour comprendre l'importance d'AES sur les comptes de service, et restreindre NTLM pour fermer l'exposition du hachage NT que le retrait de RC4 ne traite pas.