Stratégies et silos d'authentification pour le Tier 0

Les GPO de refus d'ouverture de session sont la colonne vertébrale du tiering, mais elles sont appliquées par chaque ordinateur cible. Si une GPO ne s'applique pas, si un serveur est dans la mauvaise UO, ou si un attaquant contrôle une machine et ignore tout simplement sa stratégie locale, un mot de passe ou un hachage Tier 0 reste accepté par le domaine. Les stratégies et silos d'authentification déplacent cette décision vers le KDC : un compte Tier 0 ne peut obtenir un TGT que depuis un appareil approuvé, quoi qu'en pense l'appareil lui-même.

Ce guide explique comment les silos d'authentification sont réellement évalués, les prérequis (dont le blindage Kerberos), la construction d'un silo Tier 0, son déploiement en mode audit et sa vérification. La présentation courte figure dans Tier 0 et accès à privilèges. Ici, on passe à la mise en œuvre.

Fonctionnement des stratégies et des silos

Deux types d'objets résident dans CN=AuthN Policy Configuration,CN=Services de la partition de configuration :

• Stratégie d'authentification (msDS-AuthNPolicy) : pour chaque type d'objet (utilisateur, ordinateur, service), elle définit une durée de vie de TGT et deux conditions écrites en SDDL : allowed to authenticate from (quels appareils peuvent demander le TGT du compte) et allowed to authenticate to (quels comptes peuvent demander des tickets de service pour ce service).
• Silo de stratégies d'authentification (msDS-AuthNPolicySilo) : regroupe des comptes et affecte une stratégie par type d'objet. L'appartenance est bilatérale : le silo liste les membres autorisés dans msDS-AuthNPolicySiloMembers, et chaque compte pointe vers son silo dans msDS-AssignedAuthNPolicySilo. Les deux sont nécessaires.

Lorsqu'un membre du silo s'authentifie, le KDC ajoute une revendication de silo au TGT. Une condition de stratégie peut alors exiger que « l'appareil qui demande ce TGT soit membre du silo Tier0 ». Comme l'identité de l'appareil provient du propre TGT de l'ordinateur utilisé pour le blindage FAST, la fonctionnalité dépend de bout en bout de la prise en charge du blindage et des revendications.

Chaque stratégie et chaque silo possède un indicateur enforce. Sans lui, le KDC évalue les règles et journalise ce qui aurait échoué, mais autorise la requête. Ce mode audit est au cœur d'un déploiement sans risque.

Prérequis

• Niveau fonctionnel du domaine Windows Server 2012 R2 ou supérieur, et tous les DC sous Windows Server 2012 R2 ou ultérieur.
• Prise en charge des revendications et du blindage par le KDC sur tous les DC : Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring sur Enabled avec Supported. Ne passez pas à Always provide claims ni à Fail unarmored authentication requests dans le cadre de ce projet.
• Prise en charge côté client sur chaque appareil du silo : Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring sur Enabled. Windows 8 / Server 2012 et ultérieurs le prennent en charge.
• L'appartenance des mêmes comptes Tier 0 à Protected Users est fortement recommandée. Elle impose AES, bloque NTLM et la délégation, et fixe par défaut un TGT de 240 minutes, ce qui complète le silo. Voir Protected Users.
• Un inventaire complet des comptes et appareils Tier 0, PAW et serveurs de rebond Tier 0 compris.

# Vérifier le niveau fonctionnel et les systèmes d'exploitation des DC
(Get-ADDomain).DomainMode
Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem

Choix de conception

Réglez trois questions avant de créer quoi que ce soit.

Périmètre du silo. Commencez par un silo pour les administrateurs humains Tier 0 et les appareils qu'ils utilisent. Résistez à la tentation d'y ajouter, dès la première itération, des comptes de service, des comptes de synchronisation Entra Connect ou des comptes de sauvegarde. Leurs schémas d'authentification sont plus difficiles à prévoir, et un échec à ce niveau se traduit par une panne plutôt que par un administrateur gêné. Un second silo pour les comptes de service Tier 0 pourra suivre une fois le premier stable depuis quelques mois.

Durée de vie du TGT. Un TGT plus court limite la durée pendant laquelle un ticket volé peut être rejoué. Quatre heures (240 minutes) correspondent à la valeur par défaut de Protected Users et à une session de travail d'administration. Descendre plus bas produit surtout des demandes de réauthentification sans gain réel ; monter plus haut annule une partie du bénéfice. Si un compte est à la fois dans Protected Users et soumis à une stratégie, c'est la durée de la stratégie qui s'applique.

Dans quel sens restreindre. Allowed to authenticate from sur la stratégie utilisateur est le contrôle de tiering : il tient les identifiants Tier 0 à l'écart des appareils de tiers inférieurs. Allowed to authenticate to sur une stratégie ordinateur ou service fait l'inverse : il limite les comptes autorisés à obtenir des tickets de service vers les serveurs Tier 0. Ce second contrôle est puissant pour des systèmes Tier 0 dédiés, comme un coffre PAM ou l'hôte de gestion d'une AC hors ligne, mais sur les DC il bloquerait tous les utilisateurs du domaine : ne l'y appliquez pas.

Construire le silo Tier 0 en mode audit

Le schéma : un silo, une stratégie utilisateur qui restreint les appareils depuis lesquels les utilisateurs Tier 0 peuvent s'authentifier, et une stratégie ordinateur pour les appareils Tier 0 eux-mêmes (en général uniquement la durée de vie, sans condition restrictive).

$siloName = 'Tier0-Silo'

# Condition : l'appareil qui demande le TGT doit être membre du silo Tier0
$fromSilo = "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"$siloName`"))"

# Stratégie utilisateur : TGT de 4 heures, uniquement depuis les appareils du silo. Pas encore de -Enforce : mode audit.
New-ADAuthenticationPolicy -Name 'Tier0-Users' `
    -Description 'Tier 0 admins: TGT only from Tier 0 devices' `
    -UserTGTLifetimeMins 240 `
    -UserAllowedToAuthenticateFrom $fromSilo `
    -ProtectedFromAccidentalDeletion $true

# Stratégie ordinateur pour les PAW et serveurs Tier 0 : aucune condition, durée par défaut
New-ADAuthenticationPolicy -Name 'Tier0-Computers' `
    -Description 'Tier 0 devices' -ProtectedFromAccidentalDeletion $true

# Silo en mode audit
New-ADAuthenticationPolicySilo -Name $siloName `
    -UserAuthenticationPolicy 'Tier0-Users' `
    -ComputerAuthenticationPolicy 'Tier0-Computers' `
    -ServiceAuthenticationPolicy 'Tier0-Computers' `
    -ProtectedFromAccidentalDeletion $true

Dans une condition allowed to authenticate from, @USER désigne le compte de l'appareil qui blinde la requête, et non l'administrateur. C'est voulu, et c'est la principale source de confusion à la lecture de ces stratégies.

Affecter les membres

Ajoutez les utilisateurs Tier 0, les PAW, les serveurs de rebond Tier 0 et, si des administrateurs ouvrent une session sur la console des DC, les DC eux-mêmes. Chaque membre nécessite les deux étapes :

$members = @(
    Get-ADGroupMember 'Tier0-Accounts' | ForEach-Object { Get-ADUser $_ }
    Get-ADGroupMember 'Tier0-Devices'  | ForEach-Object { Get-ADComputer $_ }
)

foreach ($m in $members) {
    # Autoriser le compte dans le silo (msDS-AuthNPolicySiloMembers)
    Grant-ADAuthenticationPolicySiloAccess -Identity $siloName -Account $m
    # Faire pointer le compte vers le silo (msDS-AssignedAuthNPolicySilo)
    Set-ADAccountAuthenticationPolicySilo -Identity $m -AuthenticationPolicySilo $siloName
}

N'ajoutez ni comptes de service, ni gMSA, ni comptes bris de glace à ce silo pendant la première phase. Les comptes bris de glace doivent rester hors du silo, étroitement surveillés, avec leur mot de passe dans un coffre physique.

Collecter les données d'audit

Les décisions du silo sont journalisées sur les DC dans des journaux opérationnels dédiés, désactivés par défaut :

# À exécuter sur chaque DC
wevtutil sl "Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController" /e:true
wevtutil sl "Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController" /e:true

Dans AuthenticationPolicyFailures-DomainController, les événements du mode audit sont le 305 (un TGT aurait été refusé par la stratégie) et le 306 (un ticket de service aurait été refusé). Leurs équivalents en mode application sont le 105 et le 106, et le 101 enregistre une authentification NTLM bloquée par une stratégie. Laissez le mode audit tourner pendant au moins un cycle d'administration complet, y compris les tâches de fin de mois, les nuits de correctifs et les rotations d'astreinte.

Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController'
        Id      = 305, 306
    } -ErrorAction SilentlyContinue
} | Select-Object MachineName, TimeCreated, Id, Message

Chaque occurrence correspond soit à un administrateur qui s'authentifie depuis un appareil hors Tier 0 (un problème de processus à corriger), soit à un appareil Tier 0 absent du silo (un problème d'appartenance à corriger).

Appliquer

Une fois le journal d'audit silencieux, appliquez d'abord la stratégie, puis le silo :

Set-ADAuthenticationPolicy -Identity 'Tier0-Users' -Enforce $true
Set-ADAuthenticationPolicySilo -Identity 'Tier0-Silo' -Enforce $true

Passez en application un mardi matin avec un administrateur devant la console d'un DC, pas un vendredi soir. En cas de problème, -Enforce $false sur le silo prend effet dès sa réplication.

Une stratégie comportant des conditions allowed to authenticate from bloque aussi les ouvertures de session réseau NTLM de ses utilisateurs, sauf si vous les autorisez explicitement via le paramètre UserAllowedNTLMNetworkAuthentication de la stratégie. Laissez-le désactivé pour le Tier 0.

Surveiller le silo lui-même

Une fois appliqué, le silo devient un contrôle Tier 0, et toute altération constitue un signal d'attaque. Avec Audit Directory Service Changes activé sur les DC, les modifications de msDS-AssignedAuthNPolicySilo sur les comptes ainsi que des objets stratégie et silo de la partition de configuration génèrent l'événement 5136. Déclenchez une alerte sur toute modification de ce type hors fenêtre de changement, ainsi que sur tout événement 105 ou 106 en mode application concernant un compte Tier 0 : il signale soit une erreur, soit une tentative d'utilisation d'un identifiant Tier 0 depuis le mauvais endroit.

Vérifier

# Configuration du silo et état d'application
Get-ADAuthenticationPolicySilo -Identity 'Tier0-Silo' -Properties * |
    Select-Object Name, Enforce, UserAuthenticationPolicy, ComputerAuthenticationPolicy, msDS-AuthNPolicySiloMembers

# Chaque compte Tier 0 est affecté au silo
Get-ADGroupMember 'Tier0-Accounts' | Get-ADUser -Properties msDS-AssignedAuthNPolicySilo |
    Where-Object { -not $_.'msDS-AssignedAuthNPolicySilo' } | Select-Object SamAccountName
# Ne doit rien renvoyer

Testez ensuite fonctionnellement. Depuis un PAW, connectez-vous avec un compte Tier 0 et exécutez klist : l'heure de fin du TGT doit refléter la durée de 240 minutes. Depuis un poste standard, tentez un runas /user: avec le même compte : il doit échouer, et le DC doit journaliser l'événement 105 accompagné d'un échec 4768 avec le code de résultat 0xC (KDC_ERR_POLICY). Conservez ces deux tests comme preuves pour les audits.

Ce que cela casse

• Les administrateurs sur des appareils hors Tier 0 : toute ouverture de session Tier 0 depuis un portable, un serveur Tier 1 ou un poste du support échoue. C'est l'objectif, mais toutes les habitudes non documentées remontent dès le premier jour.
• Les tâches planifiées et services exécutés sous des membres du silo échouent s'ils tournent sur un appareil hors du silo. Migrez-les vers des gMSA hors Tier 0 ou faites entrer délibérément l'hôte dans le Tier 0.
• Les clients non Windows et hérités sans prise en charge du blindage (anciennes distributions Linux, outils macOS, équipements réseau utilisant les identifiants AD d'un administrateur) ne peuvent pas s'authentifier en tant que membres du silo.
• L'administration inter-forêts : les revendications d'appareil ne traversent pas les approbations par défaut ; les administrateurs Tier 0 d'une forêt ne peuvent donc pas être restreints par silo à des appareils d'une autre forêt sans travail supplémentaire de transformation des revendications.
• La restauration des DC : lors d'une restauration de forêt où les DC sont reconstruits, le silo s'applique toujours. Conservez un compte bris de glace documenté hors du silo, comme expliqué dans le plan de restauration de forêt.

Pour aller plus loin : Kerberos et authentification pour la couche de blindage et de chiffrement sous-jacente aux silos, les postes d'administration à privilèges pour les appareils à placer dans le silo, et la vue d'ensemble du domaine Tier 0.