Kerberos Armoring (FAST) Active Directory Flexible Authentication Secure Tunneling : désactivé par défaut

Kerberos Armoring, FAST, Active Directory Flexible Authentication Secure Tunneling

Kerberos armoring, FAST, Active Directory Flexible Authentication Secure Tunneling — Microsoft empile tous ces noms sur une seule fonctionnalité, et dans un domaine par défaut, cette fonctionnalité est désactivée. Les deux paramètres de stratégie de groupe qui l'activent arrivent en Non configuré, si bien que l'échange d'authentification qui transporte le matériel dérivé du mot de passe traverse le réseau sans aucun canal protégé autour de lui, alors même que toutes les versions prises en charge de Windows Server peuvent l'armurer depuis Windows Server 2012.

FAST est défini dans la RFC 6113, A Generalized Framework for Kerberos Pre-Authentication. L'IANA enregistre son type de données de pré-authentification PA-FX-FAST en tant que padata type 136, aux côtés de PA-FX-COOKIE (133), PA-FX-ERROR (137) et PA-ENCRYPTED-CHALLENGE (138). La description que Microsoft donne elle-même de l'implémentation Windows est courte et précise : « Flexible Authentication Secure Tunneling (FAST) fournit un canal protégé entre le client Kerberos et le KDC. FAST est implémenté sous forme de Kerberos armoring dans Windows Server 2012, et il n'est disponible que pour les échanges du service d'authentification (AS) et du service d'émission de tickets (TGS). »

Microsoft liste trois bénéfices pour les systèmes joints au domaine, et le premier est la raison d'être de cet article :

• Protection contre les attaques par dictionnaire hors ligne. « Le Kerberos armoring protège les données de pré-authentification de l'utilisateur, qui sont vulnérables aux attaques par dictionnaire hors ligne lorsqu'elles sont générées à partir d'un mot de passe. »
• Erreurs Kerberos authentifiées. L'armoring « protège les authentifications Kerberos de l'utilisateur contre l'usurpation d'erreurs Kerberos par le KDC, qui peut forcer un downgrade vers NTLM ou une cryptographie plus faible. »
• L'authentification composée (compound authentication), l'extension d'identité de périphérique utilisée par le contrôle d'accès dynamique (Dynamic Access Control).

Source : What's New in Kerberos Authentication, Microsoft Learn.

Comment fonctionne le Kerberos Armoring

FAST enveloppe la requête réelle dans un échange externe chiffré sous une clé d'armure (armor key). La RFC 6113 énonce clairement, dans les définitions ASN.1 de la requête armurée comme de la réponse armurée, que « la clé de chiffrement est la clé d'armure ». Un observateur sur le réseau voit l'enveloppe armurée, pas les données de pré-authentification qu'elle contient.

Quels échanges sont réellement armurés

La provenance de la clé d'armure est le point qui piège le plus souvent. Microsoft : « Le Kerberos armoring utilise un ticket-granting ticket (TGT) pour l'appareil afin de protéger les échanges du service d'authentification avec le KDC, si bien que l'échange du service d'authentification de l'ordinateur n'est pas armuré. Le TGT de l'utilisateur est utilisé pour protéger ses échanges TGS avec le KDC. »

Lisez cela deux fois, car cela définit la limite du contrôle :

La propre authentification initiale de la machine ne peut pas être armurée, car la clé d'armure est justement ce qu'elle cherche à obtenir. Chaque connexion utilisateur ultérieure sur cette machine, elle, peut l'être.

La RFC 6113 est explicite sur l'attaque qu'elle supprime : « Le padata de pré-authentification FAST de Kerberos défini dans cette section fournit un outil pour réduire significativement la vulnérabilité aux attaques par dictionnaire hors ligne. Combiné au challenge chiffré, FAST exige d'un attaquant qu'il mène une attaque de type man-in-the-middle réussie pour observer le texte chiffré. »

Pourquoi la pré-authentification non armurée est récoltable

Sans FAST, le flux de pré-authentification Windows standard est PA-ENC-TIMESTAMP — type de pré-authentification 2, que Microsoft documente comme « un type normal pour l'authentification par mot de passe standard ». Le client prouve sa connaissance du mot de passe en chiffrant un horodatage avec une clé dérivée de ce mot de passe, et le KDC renvoie un AS-REP dont la partie chiffrée est protégée par cette même clé dérivée du mot de passe.

Les deux moitiés sont du texte chiffré dérivé du mot de passe, et la RFC 6113 décrit directement la conséquence : « Un attaquant peut demander un AS-REP et essayer différents mots de passe pour voir s'ils permettent de déchiffrer le ticket obtenu. »

L'analyse du Kerberos armoring de Trimarc Security (publiée en juillet 2024) fait le même constat sur l'économie de l'attaque : « Le processus de tentative de cassage d'un mot de passe par l'une de ces méthodes est entièrement hors ligne, ce qui signifie qu'un attaquant peut y consacrer autant de temps que nécessaire. »

C'est là que les conseils de remédiation habituels s'arrêtent trop tôt. Les correctifs classiques pour l'AS-REP roasting et le Kerberoasting — mots de passe plus longs, comptes de service gérés de groupe, suppression du fallback RC4 — rendent tous le cassage plus difficile. Aucun d'eux n'empêche la collecte du matériel. FAST s'attaque plutôt à l'étape de collecte elle-même, en plaçant l'échange dans un canal que le collecteur ne peut pas lire.

Ce que l'armoring change structurellement, c'est la position du collecteur non authentifié. Lorsque le KDC est configuré pour rejeter les messages Kerberos non armurés, une AS-REQ produite par un outil qui ne détient aucun TGT d'appareil ne peut pas être armurée, et elle est donc refusée avant qu'un quelconque AS-REP ne soit renvoyé. Ce comportement découle directement de l'option documentée « Fail unarmored authentication requests » décrite plus loin.

Les paramètres de stratégie de groupe désactivés par défaut

Trois paramètres gouvernent cela, répartis sur deux nœuds de modèles d'administration. Les trois sont Non configuré par défaut.

Les chemins de registre, les noms conviviaux et les descriptions citées proviennent des références Policy CSP ADMX_kdc et Kerberos.

Les quatre options du paramètre KDC

Le paramètre KDC propose quatre options, et les différences ne sont pas cosmétiques :

Deux conséquences méritent d'être notées sur un post-it avant de toucher à l'UO Domain Controllers :

🚨 Danger : l'avertissement de Microsoft lui-même sur la stratégie KDC — « Lorsque 'Fail unarmored authentication requests' est activé, les postes clients qui ne prennent pas en charge le Kerberos armoring échoueront à s'authentifier auprès du contrôleur de domaine. » Tout client Kerberos incapable d'armurer — appliances, hôtes non Windows, systèmes embarqués, tout ce qui est antérieur à Windows 8 / Windows Server 2012 — cesse de s'authentifier. Faites l'inventaire avant d'imposer, pas après.

Le second point : les deux options strictes ne font silencieusement rien en dessous du niveau fonctionnel de domaine Windows Server 2012. Microsoft indique que ces deux options « provoquent des échecs intermittents d'authentification ou de contrôle d'accès s'il existe des contrôleurs de domaine qui n'exécutent pas Windows Server 2012 dans le domaine. Donc aucune de ces options ne prendra effet tant que le domaine n'est pas au niveau fonctionnel Windows Server 2012. Jusque-là, les contrôleurs de domaine sous Windows Server 2012 se comporteront comme si l'option Supported était configurée. » Un domaine encore au niveau fonctionnel 2008 R2 peut configurer « Fail unarmored » et obtenir à la place le comportement Supported : l'armoring est proposé aux clients qui le demandent, rien n'est imposé.

Détection

L'état de l'armoring se mesure sous trois angles indépendants : la configuration, la télémétrie d'authentification en direct, et les événements de santé du KDC.

Les indicateurs qui révèlent l'état de l'armoring

Le tableau des types de pré-authentification et les conseils de supervision proviennent de la référence Microsoft 4768(S, F) A Kerberos authentication ticket (TGT) was requested, qui recommande d'alerter lorsque la « valeur n'est pas 138 alors que le Kerberos Armoring est activé pour toutes les communications Kerberos de l'organisation ». Les Events 33 et 34 ainsi que les compteurs de performance FAST sont documentés dans What's New in Kerberos Authentication.

Vérifier si les stratégies sont configurées

Commencez par l'état de configuration. À exécuter sur un contrôleur de domaine :

# Les options d'application nécessitent le niveau fonctionnel de domaine Windows Server 2012 ou supérieur
Get-ADDomain | Select-Object DNSRoot, DomainMode

# Côté KDC : rien de retourné signifie que la stratégie est Non configurée
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\KDC\Parameters' `
                 -Name EnableCbacAndArmor -ErrorAction SilentlyContinue

Puis côté client, sur un poste de travail ou un serveur membre :

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
                 -Name EnableCbacAndArmor, RequireFast -ErrorAction SilentlyContinue

Mesurer combien de connexions sont réellement armurées

La configuration ne donne que l'intention. Pour mesurer ce qui se passe réellement, regroupez les requêtes TGT en direct par type de pré-authentification sur un contrôleur de domaine :

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4768 } -MaxEvents 5000 |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        [pscustomobject]@{
            PreAuthType = ($x.Event.EventData.Data |
                Where-Object { $_.GetAttribute('Name') -eq 'PreAuthType' }).'#text'
        }
    } |
    Group-Object PreAuthType |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Sélectionner le champ par son attribut Name plutôt que par sa position compte : Microsoft a livré une version mise à jour de l'Event 4768 avec des champs supplémentaires dans la mise à jour cumulative de janvier 2025 pour Windows Server 2016 et versions ultérieures, si bien que la position des champs diffère entre versions d'événement.

Pour ne récupérer que les requêtes non armurées directement :

Get-WinEvent -LogName Security -MaxEvents 50 -FilterXPath @"
*[System[EventID=4768] and EventData[Data[@Name='PreAuthType'] != '138']]
"@

Injectez ce même flux 4768 dans l'outil que vous utilisez déjà pour la supervision des événements Active Directory. Le ratio du type 138 par rapport au reste est le chiffre unique qui indique jusqu'où un déploiement a réellement progressé.

Remédiation

Le déploiement par étapes

Déployez dans cet ordre. La recommandation de Trimarc est sans ambiguïté sur le séquençage : « Assurez-vous que le Kerberos Armoring est activé pour les clients en premier… Ce changement doit être appliqué à tous les clients avant d'être configuré sur les contrôleurs de domaine. »

1. Confirmer le niveau fonctionnel du domaine. Get-ADDomain | Select-Object DomainMode doit indiquer Windows Server 2012 ou supérieur avant que les options d'application ne fassent quoi que ce soit. Si vous êtes encore en dessous, cela devient d'abord un projet de mise à niveau du niveau fonctionnel.

2. Activer la stratégie client sur tous les clients. Configuration ordinateur > Stratégies > Modèles d'administration > Système > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring → Enabled. Liez-la aux UO de postes de travail et de serveurs membres, pas seulement à un groupe pilote. Vérifiez que la stratégie s'est réellement appliquée — une GPO mal configurée ou mal ciblée est la raison la plus courante pour laquelle un déploiement se bloque silencieusement :

gpupdate /force
gpresult /h C:\Temp\kerberos-armoring.html

3. Positionner la stratégie KDC sur Supported sur l'UO Domain Controllers. Configuration ordinateur > Stratégies > Modèles d'administration > Système > KDC > KDC support for claims, compound authentication and Kerberos armoring → Enabled, option Supported. Si un contrôleur de domaine journalise ensuite l'event System 33, la résolution documentée par Microsoft consiste à exécuter gpupdate /force sur un contrôleur de domaine.

4. Mesurer avant d'imposer. Surveillez les compteurs de performance KDC AS Requests with FAST et KDC armored TGS Requests ainsi que la distribution des types de pré-authentification dans 4768. Chaque principal affichant encore le type 2 est un client qui cassera sous l'application stricte.

5. Faire l'inventaire des clients incapables d'armurer. La prise en charge de l'armoring commence avec les clients Windows 8 et Windows Server 2012. Les appliances, les hôtes Linux et UNIX, les équipements réseau et les piles Kerberos legacy nécessitent chacun une décision explicite : mise à niveau, exemption par ciblage d'UO, ou acceptation du fait que l'application stricte les exclura.

6. Alors seulement, imposer. Côté KDC, passez à Fail unarmored authentication requests. Côté client, activez Fail authentication requests when Kerberos armoring is not available. Faites-le une étape à la fois, avec un plan de retour arrière, et jamais les deux dans la même fenêtre de changement.

Capacité et coût avant d'imposer

Déployez suffisamment de contrôleurs de domaine capables d'armoring pour absorber la charge avant d'imposer. La référence ADMX_kdc avertit qu'un « nombre insuffisant de contrôleurs de domaine prenant en charge cette stratégie entraîne des échecs d'authentification chaque fois que le contrôle d'accès dynamique ou le Kerberos armoring est requis ».

Enfin, budgétez le coût. Microsoft est direct dans la même référence : « le Kerberos armoring chiffre entièrement les messages Kerberos et signe les erreurs Kerberos, ce qui augmente le temps de traitement, mais ne change pas la taille du ticket de service. » Le gonflement des tickets n'est pas le sujet ici ; le CPU des DC l'est.

Comment EtcSec détecte cela

Le catalogue de vulnérabilités d'EtcSec porte ce contrôle sous forme de deux vérifications distinctes, parce que la moitié client et la moitié KDC échouent indépendamment et qu'un domaine peut facilement avoir l'une sans l'autre :

• KERBEROS_ARMORING_DC_DISABLED — Kerberos Armoring (FAST) non imposé sur les DC
• KERBEROS_ARMORING_CLIENT_DISABLED — Kerberos Armoring (FAST) non exigé sur les clients
• ANSSI_R27_KERBEROS_PREAUTH_NOT_FAST — la lecture orientée conformité du même contrôle

Ces vérifications sont corrélées avec les entrées de surface d'attaque qu'elles atténuent réellement — ASREP_ROASTING_RISK, KERBEROASTING_RISK et KERBEROS_RC4_FALLBACK — si bien qu'un rapport montre à la fois les comptes exposés au cassage hors ligne et si le contrôle protocolaire qui limite la collecte est activé. Cette mise en relation est tout l'intérêt : un audit qui signale des comptes vulnérables à l'AS-REP roasting sans signaler l'état de l'armoring ne décrit que la moitié du problème. Si vous menez une revue plus large, ce contrôle s'inscrit naturellement aux côtés du reste d'un audit de sécurité Active Directory.