Stratégies d'authentification et silos Active Directory, Tier 0 : le contrôle Kerberos que (presque) personne ne déploie

Stratégies d'authentification et silos Active Directory, Tier 0 : de quoi il s'agit vraiment

La protection par stratégies d'authentification et silos Active Directory Tier 0 est une fonctionnalité unique de Windows Server 2012 R2 que la plupart des environnements n'ont toujours pas activée, même une décennie après sa sortie. Un silo de stratégie d'authentification est un conteneur AD (objectClass msDS-AuthNPolicySilos) qui regroupe les comptes utilisateur, ordinateur et service que vous voulez protéger ensemble. Une stratégie d'authentification (objectClass msDS-AuthNPolicies) est l'ensemble de règles appliqué à ce conteneur — combien de temps un ticket Kerberos (TGT, ticket-granting ticket) peut vivre, depuis quels appareils un compte est même autorisé à ouvrir une session, et quels principaux sont autorisés à s'authentifier auprès d'un service qui tourne sous ce compte.

L'idée est simple : vos comptes Domain Admins ne devraient jamais s'authentifier ailleurs que depuis une poignée de postes d'administration privilégiés (PAW) et de contrôleurs de domaine. Les stratégies d'authentification et les silos sont le mécanisme qui transforme cette hypothèse en quelque chose que le KDC applique réellement, au lieu d'une règle qui ne vit que dans un document d'onboarding.

Un compte ne peut appartenir qu'à un seul silo. Une fois affecté, le contrôleur de domaine attache une revendication de silo de stratégie d'authentification au ticket Kerberos du compte à l'ouverture de session, revendication que les ressources compatibles peuvent utiliser pour leurs propres contrôles d'accès — en plus de ce que la stratégie du silo restreint déjà.

L'exemple de référence de Microsoft illustre bien l'intention : construire un silo « Administrateurs de forêt » contenant les comptes Enterprise Admins, Schema Admins et Domain Admins, puis attacher une stratégie pour qu'une ouverture de session par mot de passe ou carte à puce depuis autre chose qu'un contrôleur de domaine ou une console d'administration désignée échoue purement et simplement. Le silo se moque de la façon dont l'identifiant a été obtenu — hameçonné, rejoué, ou tapé correctement par le vrai administrateur — il ne regarde que si l'appareil source figure sur la liste autorisée.

Un même silo peut contenir les trois classes de comptes Active Directory — utilisateur, ordinateur et compte de service managé — mais la stratégie se comporte différemment selon la classe. Les comptes de service et d'ordinateur ne devraient jamais rejoindre le groupe Protected Users : la raison donnée par Microsoft est que toute authentification entrante échoue pour ces types de comptes, et l'appartenance ne leur apporte aucune protection locale de toute façon puisque le mot de passe ou le certificat est toujours présent sur l'hôte. Microsoft déconseille également de configurer une durée de vie de TGT pour les comptes ordinateur. La distinction par type de compte compte autant que l'appartenance au silo elle-même.

Fonctionnement : durée de vie du TGT, revendications et l'exigence de blindage

Les stratégies d'authentification agissent à deux points de l'échange Kerberos : l'échange AS (ouverture de session initiale, émission du TGT) et l'échange TGS (demandes de ticket de service). Trois choses peuvent être restreintes :

1. Durée de vie du TGT — fixée à une valeur plus courte et non renouvelable que celle par défaut du domaine (4 heures est ce que les membres du groupe Protected Users obtiennent automatiquement). Un compte Tier 0 avec un TGT non renouvelable d'1 heure offre une fenêtre bien plus réduite à un attaquant qui vole un ticket.
2. AllowedToAuthenticateFrom — l'ensemble des appareils depuis lesquels un utilisateur peut ouvrir une session. Appliqué lors de l'échange AS.
3. AllowedToAuthenticateTo — l'ensemble des principaux autorisés à s'authentifier auprès d'un service tournant sous ce compte. Appliqué lors de l'échange TGS.

Les restrictions d'appareil sont ce qui bloque la plupart des déploiements. Vérifier AllowedToAuthenticateFrom nécessite le blindage Kerberos (FAST) : le KDC a besoin du propre TGT de l'appareil demandeur pour valider son identité avant de pouvoir décider si cet appareil figure sur la liste autorisée. Les deux paramètres de stratégie de groupe qui activent le blindage arrivent en Non configuré sur un domaine par défaut — nous avons couvert cet écart séparément — donc sur un domaine non modifié, la restriction d'ouverture de session ne fonctionne tout simplement pas en silence, même si la restriction de durée de vie du TGT, elle, continue de fonctionner. C'est un prérequis ici, pas un durcissement optionnel en plus.

Chaque silo de stratégie d'authentification démarre en mode audit uniquement — l'équivalent PowerShell de -WhatIf. Le mode audit journalise ce qui échouerait sans rien bloquer, ce qui est la façon prévue de roder une stratégie avant qu'un administrateur ne se verrouille lui-même hors de son propre domaine.

Pourquoi ce contrôle reste inutilisé dans la plupart des architectures Tier 0

Trois points de friction expliquent pourquoi les stratégies d'authentification et les silos quittent rarement le stade pilote, même dans des environnements qui prennent par ailleurs au sérieux l'administration par tiers.

Un niveau fonctionnel de domaine que personne ne revisite

Des durées de vie de TGT personnalisées nécessitent le niveau fonctionnel de domaine Windows Server 2012 R2 sur le domaine de compte. Restreindre l'ouverture de session utilisateur nécessite ce même DFL sur le domaine de compte avec la prise en charge du contrôle d'accès dynamique, plus des appareils clients qui supportent eux-mêmes le contrôle d'accès dynamique. Restreindre l'émission de tickets de service est une exigence sur le domaine de ressource, qui doit lui-même être au DFL 2012 R2 — donc une architecture Tier 0 inter-domaines a deux niveaux fonctionnels à vérifier, pas un seul. De nombreux domaines ont relevé leur DFL il y a des années pour une raison sans rapport — une migration de trust de forêt, une extension de schéma pour un autre projet — et ne sont jamais revenus vérifier ce que ce niveau fonctionnel débloquait par ailleurs. Les silos de stratégie d'authentification restent sur cette liste, inutilisés, parce que rien ne pousse un administrateur à aller les chercher.

Aucun contournement, aucune exception

Une fois qu'un compte tombe sous le coup des restrictions d'authentification, il n'existe aucune solution de contournement — un Domain Admin verrouillé par un silo appliqué est verrouillé, point final (RID 500 mis à part). Microsoft formule sa version brutale de cet avertissement à propos du groupe Protected Users plutôt qu'à propos des silos, mais le mode d'échec est le même : les restrictions d'authentification n'ont pas de solution de contournement, les Enterprise Admins et Domain Admins y sont soumis comme n'importe qui d'autre, et inscrire tous les membres de ces groupes d'un coup peut tous les verrouiller — y compris les comptes qui permettraient normalement de résoudre le problème. La recommandation propre à Microsoft pour les stratégies d'authentification et les silos est procédurale plutôt que rassurante : garder les clients et les contrôleurs de domaine connectés au réseau, changer les mots de passe des comptes protégés après coup, et désactiver l'ouverture de session en cache là où c'est possible. Ce profil de risque suffit à faire en sorte que la plupart des équipes s'arrêtent à un pilote d'un ou deux comptes de test et n'aillent jamais plus loin.

La dépendance au blindage

Tirer une vraie valeur des restrictions d'appareil suppose que le blindage Kerberos fonctionne déjà, et le blindage lui-même est un changement GPO séparé sur les contrôleurs de domaine comme sur les clients que la plupart des équipes n'ont pas fait — voir l'exigence ci-dessus. Piloter les stratégies d'authentification sans blindage au préalable revient à piloter une fonctionnalité qui, en silence, ne fait que la moitié de ce qu'elle est censée faire.

Rien de tout cela n'est une raison de l'ignorer. Un TGT raccourci et non renouvelable sur les comptes Tier 0 réduit directement la fenêtre pour un ticket volé — le cas du pass-the-ticket, où un attaquant extrait un TGT légitime de la mémoire et le rejoue tant qu'il reste valide.

Soyons précis sur ce que cela ne couvre pas. Une stratégie d'authentification façonne le ticket que le KDC émet : le contrôleur de domaine renvoie un TGT non renouvelable avec la durée de vie configurée quand il répond à une requête AS, et il vérifie la restriction d'ouverture de session contre la requête AS blindée. Un Golden Ticket est forgé hors ligne avec la clé krbtgt et ne passe jamais par un échange AS, donc il porte la durée de vie et l'identité que l'attaquant a choisies — la durée de vie du TGT du silo et sa restriction d'ouverture de session n'ont aucune prise sur lui. Ce qui peut encore mordre un ticket forgé, c'est le contrôle côté TGS : un service dont le compte porte une condition AllowedToAuthenticateTo est évalué au moment où le ticket de service est demandé, pas au moment où le TGT a été créé. Même cela a une limite — c'est encore un contrôle côté KDC, et un Silver Ticket est forgé contre la clé propre du service et présenté directement à l'hôte sans que le contrôleur de domaine ne soit jamais sollicité, donc aucune stratégie d'authentification ne le voit jamais.

Configurer un silo de stratégie d'authentification

Le guide complet se trouve dans le guide Microsoft pour configurer les comptes protégés ; les grandes lignes :

1. Activer le blindage Kerberos

Via une stratégie de groupe, sur les contrôleurs de domaine et les clients :

Configuration ordinateur > Modèles d'administration > Système > KDC
  « Prise en charge par le client du centre de distribution de clés (KDC) des revendications,
    de l'authentification composée et du blindage Kerberos » → Activé, « Toujours fournir des revendications »

Configuration ordinateur > Modèles d'administration > Système > Kerberos (clients)
  « Prise en charge client Kerberos des revendications, de l'authentification composée
    et du blindage Kerberos » → Activé

Confirmez avec une ouverture de session de test depuis un client joint au domaine avant de toucher à la moindre stratégie — les échecs de blindage sont silencieux sinon, et vous ne voulez pas déboguer deux nouvelles fonctionnalités en même temps.

2. Créer la stratégie d'authentification

Définir une durée de vie de TGT en minutes :

New-ADAuthenticationPolicy -Name "Tier0-AdminPolicy" `
  -UserTGTLifetimeMins 60 `
  -Description "Comptes admin Tier 0 - TGT non renouvelable d'1h"

3. Créer le silo — non appliqué par défaut

New-ADAuthenticationPolicySilo -Name "Tier0-Silo"

Chaque nouveau silo démarre en mode audit. N'ajoutez -Enforce qu'une fois la période d'audit propre — c'est l'équivalent intégré de -WhatIf, et il est là précisément pour qu'une faute de frappe dans une condition de contrôle d'accès ne verrouille pas le compte qui aurait pu résoudre le problème.

4. Accorder l'accès et affecter les comptes

Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "da-jsmith"

Get-ADUser -Filter 'Name -like "da-*"' |
  Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo "Tier0-Silo" `
    -AuthenticationPolicy "Tier0-AdminPolicy"

Un compte doit à la fois recevoir l'accès au silo et se voir affecter la paire silo/stratégie — accorder l'accès seul n'inscrit pas le compte.

5. Roder, puis appliquer

Set-ADAuthenticationPolicySilo -Identity "Tier0-Silo" -Enforce $true
Set-ADAuthenticationPolicy -Identity "Tier0-AdminPolicy" -Enforce $true

Le silo et la stratégie portent chacun leur propre indicateur Enforce — n'en basculer qu'un seul laisse l'autre en mode audit, ce qui est une source fréquente de confusion du type « pourquoi ça n'a rien bloqué » au moment du déploiement.

Détection

Les événements vivent dans un journal opérationnel désactivé par défaut — l'activer est l'étape zéro pour que tout ceci devienne visible :

Observateur d'événements > Journaux des applications et des services > Microsoft > Windows >
Authentication > AuthenticationPolicyFailures-DomainController → Activer le journal

Un pic de 105/106 après le passage d'un silo de l'audit à l'application est soit un blocage légitime à corriger (un PAW qui n'est pas encore sur la liste autorisée), soit une véritable tentative d'utiliser un identifiant Tier 0 depuis un endroit qui ne devrait pas — les deux cas méritent une alerte.

Remédiation (Remediation)

1. Inventoriez les comptes Tier 0 et l'ensemble exact des hôtes depuis lesquels ils devraient pouvoir s'authentifier (PAW, contrôleurs de domaine — rien d'autre).
2. Activez le blindage Kerberos via GPO sur les contrôleurs de domaine et les clients éligibles Tier 0 ; confirmez avec une ouverture de session de test avant de toucher à la moindre stratégie.
3. Créez la stratégie d'authentification et le silo en mode audit ; laissez-les non appliqués pendant au moins un cycle opérationnel complet.
4. Activez le journal AuthenticationPolicyFailures-DomainController et examinez les événements 305/306 pour repérer les faux positifs — PAW manquants, jump hosts oubliés.
5. Appliquez le silo et la stratégie. Changez immédiatement le mot de passe de chaque compte inscrit.
6. Associez ceci à l'appartenance au groupe Protected Users pour les comptes qui n'ont pas besoin de délégation Kerberos — Protected Users bloque en plus NTLM, la pré-authentification DES/RC4, et la délégation contrainte comme non contrainte purement et simplement. N'ajoutez jamais de comptes de service ou d'ordinateur à Protected Users : toute authentification entrante échoue pour ces types de comptes.

Comment EtcSec détecte ceci

L'audit Active Directory d'EtcSec signale l'absence de ce contrôle sous plusieurs angles plutôt qu'avec une seule vérification : NOT_IN_PROTECTED_USERS détecte les comptes privilégiés absents du groupe Protected Users, WEAK_KERBEROS_POLICY signale un domaine dont la durée de vie maximale de ticket dépasse encore 10 heures ou dont la fenêtre de renouvellement dépasse 7 jours, FGPP_NOT_CONFIGURED signale un domaine sans aucune stratégie de mot de passe affinée, et les contrôles alignés ANSSI ANSSI_R40_NO_PSO_TIER0 et ANSSI_R82_R83_ADMIN_ARCHITECTURE signalent spécifiquement les groupes admin Tier 0 non couverts par une stratégie affinée dédiée ou par un contrôle de restriction d'ouverture de session.