Tier 0 et accès à privilèges : verrouiller les Domain Admins

La plupart des compromissions d'Active Directory ne commencent pas par un zero-day sur un contrôleur de domaine : elles commencent par un compte surprivilégié qui ouvre une session sur une machine sous-protégée. Un administrateur se connecte en RDP sur un poste du support avec ses identifiants Domain Admin pour régler un problème d'imprimante, un outil de vol d'identifiants récupère le jeton, et l'attaquant file droit vers NTDS.dit. Le modèle en tiers existe pour rendre ce chemin impossible par construction, et non par simple note de service.

Ce guide présente le modèle d'accès d'entreprise, la manière de séparer physiquement et logiquement le Tier 0, ainsi que le travail concret de GPO, de groupes et de PowerShell nécessaire pour l'imposer.

Le modèle en tiers : Tier 0, 1 et 2

Le modèle classique à trois tiers de Microsoft (désormais intégré au modèle plus large Enterprise Access Model) sépare l'administration selon le rayon d'impact :

La règle qui fait fonctionner le modèle est directionnelle : un compte d'administration de Tier N ne peut ouvrir de session que sur des ressources de Tier N. Un identifiant Tier 0 ne doit jamais toucher une machine Tier 1 ou Tier 2, et un administrateur Tier 1 ne doit jamais utiliser ses identifiants sur un poste Tier 2. Enfreignez cette règle une seule fois — en ouvrant une session sur un PC du support avec un compte Domain Admin — et la frontière disparaît, car un vol d'identifiants sur cette machine donne alors un accès Tier 0.

Ce qui relève du Tier 0

Soyez strict : l'extension non maîtrisée du périmètre Tier 0 est l'échec le plus courant. Le Tier 0 comprend :

• Les contrôleurs de domaine (tous, y compris les RODC pour les besoins d'administration)
• Les autorités de certification racines et émettrices AD Certificate Services (une AC compromise peut forger des certificats d'authentification pour n'importe quel utilisateur)
• Les serveurs AD FS et leurs certificats de signature de jetons
• Les serveurs Microsoft Entra Connect / Entra Connect Sync
• Les systèmes de sauvegarde et de déploiement d'images capables de restaurer ou de lire les données AD
• Les Privileged Access Workstations eux-mêmes et tout serveur de rebond/bastion utilisé pour atteindre le Tier 0
• Les groupes de sécurité : Domain Admins, Enterprise Admins, Schema Admins, Administrators (sur les DC), Account Operators, Backup Operators, Print Operators, Server Operators

En cas de doute sur l'appartenance d'un système au Tier 0, posez-vous la question : « si ce système est compromis, l'attaquant peut-il compromettre le domaine ? » Si oui, c'est du Tier 0, point final — aussi contraignant que ce soit sur le plan opérationnel.

Des comptes d'administration séparés

Chaque administrateur humain qui touche au Tier 0 a besoin d'un compte dédié qui ne sert à rien d'autre : pas de messagerie, pas de navigation, pas de Teams. Une convention de nommage pratique :

florian.amette          -> standard user account (Tier 2, email, day-to-day)
adm-t0-famette          -> Tier 0 admin account (DCs, PKI, Entra Connect)
adm-t1-famette          -> Tier 1 admin account (member servers, apps)

Ne réutilisez pas un compte « admin » unique entre les tiers, et n'accordez au compte utilisateur standard aucune appartenance implicite à des groupes privilégiés. Imposez-le avec des groupes protégés par AdminSDHolder et des audits réguliers des appartenances, plutôt qu'en vous fiant à la bonne volonté de chacun.

Des GPO de refus d'ouverture de session pour imposer la frontière

L'appartenance aux groupes ne suffit pas à empêcher un administrateur d'ouvrir une session sur le mauvais tier : il faut des refus explicites de droits d'ouverture de session. Créez des GPO dédiées et liez-les par tier :

GPO : « Tier 0 – Deny Logon From Lower Tiers » (liée à l'UO Domain Controllers et à toute UO de serveurs Tier 0)

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment

Reproduisez ce schéma avec une GPO « Tier 1 – Deny Logon From Tier 0 and Tier 2 » sur les UO de serveurs membres, et une GPO « Tier 2 – Deny Logon From Tier 0 and Tier 1 » sur les UO de postes de travail. C'est ce qui empêche réellement un identifiant Domain Admin d'être exploitable s'il est hameçonné sur un poste : même avec des identifiants valides, le droit de refus bloque l'ouverture de session.

Le groupe Protected Users

Ajouter les comptes Tier 0 à Protected Users (disponible depuis Windows Server 2012 R2, appliqué par les DC et les clients à partir de 2012 R2) durcit l'identifiant lui-même :

• Bloque complètement l'authentification NTLM pour le compte
• Bloque DES et RC4 lors de la pré-authentification Kerberos, ce qui impose AES
• Désactive la mise en cache des identifiants (pas d'ouverture de session en cache, pas de CredSSP, pas de WDigest)
• Empêche le renouvellement des tickets Kerberos au-delà de 4 heures, ce qui force une nouvelle authentification

Add-ADGroupMember -Identity "Protected Users" -Members "adm-t0-famette"

Testez d'abord sur un groupe pilote — voir « Ce que cela casse » ci-dessous. Combinez cette mesure avec le durcissement du chiffrement décrit dans Durcissement de Kerberos pour un effet complet.

Les Privileged Access Workstations (PAW)

Une GPO de refus d'ouverture de session bloque la connexion sur le mauvais tier, mais l'administrateur a toujours besoin d'un endroit depuis lequel administrer le Tier 0. C'est le rôle du PAW : un poste durci, à usage unique, qui :

• N'exécute ni navigateur, ni client de messagerie, ni suite Office (ou un navigateur très verrouillé, limité au seul portail d'administration interne)
• Est joint à une UO Tier 0 dédiée, dotée de ses propres GPO restrictives
• N'accorde à l'utilisateur connecté aucun droit d'administration local au-delà du strict nécessaire
• Est le seul poste autorisé à ouvrir une session avec des identifiants Tier 0 (imposé par les GPO de refus ci-dessus, appliquées en sens inverse — les comptes Tier 0 sont refusés partout sauf sur l'UO des PAW)
• S'appuie sur BitLocker, Credential Guard et des correctifs à jour comme socle de base

PAW minimal viable : une VM verrouillée ou un Cloud PC réservé exclusivement aux tâches Tier 0, auquel on accède en RDP depuis un poste standard, sans jamais ouvrir de session avec des identifiants Tier 0 directement sur ce poste.

Stratégies et silos d'authentification

Les domaines Windows Server 2012 R2 et ultérieurs prennent en charge les Authentication Policies et les Authentication Policy Silos, qui imposent les frontières de tiers au niveau du KDC Kerberos plutôt que de reposer uniquement sur les droits d'ouverture de session par GPO — une couche de défense en profondeur qui tient même si une GPO ne s'applique pas.

# Créer un silo limitant les administrateurs Tier 0 aux PAW et aux DC
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" `
    -UserAuthenticationPolicy "Tier0-UserAuthPolicy" `
    -ComputerAuthenticationPolicy "Tier0-ComputerAuthPolicy" `
    -Enforce

# L'appartenance se fait des deux côtés : autoriser le compte dans le silo, puis affecter le silo au compte
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "adm-t0-famette"
Set-ADAccountAuthenticationPolicySilo -Identity "adm-t0-famette" -AuthenticationPolicySilo "Tier0-Silo"

Les stratégies d'authentification peuvent aussi plafonner la durée de vie du TGT Kerberos des membres du silo, ce qui réduit la fenêtre dont dispose un attaquant en cas de vol de ticket.

Faire le ménage dans Domain Admins et Enterprise Admins

Auditez régulièrement les appartenances : ces groupes accumulent des entrées obsolètes pendant des années.

# Lister les membres actuels de Domain Admins et Enterprise Admins
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

# Trouver les comptes sans ouverture de session depuis 90 jours ou plus mais toujours privilégiés
$cutoff = (Get-Date).AddDays(-90)
Get-ADGroupMember -Identity "Domain Admins" |
    Get-ADUser -Properties LastLogonDate |
    Where-Object { $_.LastLogonDate -lt $cutoff -or -not $_.LastLogonDate }

État cible : Enterprise Admins doit rester vide, sauf pendant les modifications planifiées au niveau de la forêt (mises à jour du schéma, ajout de domaines), puis être vidé à nouveau. Domain Admins ne doit contenir que le petit ensemble de comptes nominatifs d'administrateurs Tier 0 — pas de comptes de service, pas de comptes « au cas où », pas de comptes de prestataires.

# Vérifier qu'une attribution de droit utilisateur (par ex. deny log on locally) est appliquée par GPO
Get-ADGroup "Tier 1 Admins" | Select-Object -ExpandProperty SID
# Contrôler les droits utilisateur effectifs sur l'hôte cible (GPO de domaine incluses) :
secedit /export /cfg "$env:TEMP\rights.inf" /areas USER_RIGHTS
Select-String -Path "$env:TEMP\rights.inf" -Pattern "SeDenyInteractiveLogonRight"

Ce que cela casse

• Les tâches planifiées et les services exécutés sous des comptes Domain Admin sur des serveurs membres ou des postes de travail échoueront immédiatement dès que les droits de refus d'ouverture de session en tant que tâche/service s'appliqueront. Inventoriez chaque tâche planifiée et chaque service avec Get-ScheduledTask / Get-CimInstance Win32_Service filtrés sur les noms de comptes privilégiés avant le déploiement, puis migrez-les vers des Group Managed Service Accounts (gMSA) cantonnés au Tier 1.
• Les processus délégués du support qui reposent sur un compte « admin » partagé, à la fois pour les réinitialisations de mot de passe et le dépannage des serveurs, cessent de fonctionner entre les tiers — il faut déléguer les droits de réinitialisation de mot de passe par délégation au niveau des UO, et non par des comptes qui traversent les tiers.
• L'appartenance à Protected Users casse les applications héritées dépendantes de NTLM, l'ouverture de session en cache sur les machines autres que les DC et le renouvellement des tickets Kerberos au-delà de 4 heures — faites un pilote avant un déploiement large.
• L'accès au Tier 0 uniquement depuis un PAW ralentit la réponse aux incidents, sauf si vous prévoyez au moins une procédure bris de glace (documentée, surveillée et physiquement sécurisée) pour la restauration des DC lorsque le PAW lui-même est indisponible.

Pour aller plus loin : Durcissement de Kerberos pour la couche d'authentification sous-jacente à ces comptes, et Délégation pour les risques de délégation contrainte capables de contourner les frontières de tiers. Voir aussi les entrées du glossaire Protected Users et DCSync.