Tiering Model Active Directory : Segmentation des : Guide

Le Tiering Model (modèle d'administration en tiers) est l'architecture fondamentale de sécurisation des privilèges dans Active Directory. Son principe est simple mais radical : segmenter les actifs en niveaux de criticité et interdire toute contamination entre ces niveaux. Un administrateur de domaine ne doit jamais se connecter à un poste utilisateur. Un administrateur de serveurs ne doit jamais administrer un contrôleur de domaine. Cette séparation stricte empêche les attaquants de progresser du niveau le plus bas (postes de travail) jusqu'au niveau le plus élevé (contrôleurs de domaine). Ce guide approfondi examine en detail les aspects fondamentaux et avances de Tiering Model Active Directory, en proposant une analyse structuree et documentee des enjeux actuels. Les professionnels y trouveront des recommandations concretes, des methodologies eprouvees et des retours d'experience terrain directement applicables en environnement de production.

La réalité observée lors de nos audits Active Directory est tout autre : dans plus de 85 % des environnements audités, un attaquant peut compromettre l'ensemble du domaine en moins de 48 heures à partir d'un simple poste utilisateur. Le chemin d'attaque est presque toujours le même : compromission initiale d'un poste Tier 2, extraction des credentials d'un compte d'administration qui s'est connecté sur ce poste (credential caching), utilisation de ces credentials pour accéder aux serveurs Tier 1, puis escalade vers les contrôleurs de domaine Tier 0 via Kerberoasting, NTLM Relay, ou exploitation AD CS. Pour plus d'informations, consultez les ressources de ANSSI.

Le tiering n'est pas une technologie -- c'est un modèle organisationnel et architectural qui s'implémente par une combinaison de GPO, de restrictions de connexion, de comptes dédiés, de stations d'administration sécurisées (PAW) et de monitoring. Microsoft a formalisé ce modèle sous le nom de Enterprise Access Model, qui étend le tiering classique au cloud et aux identités Entra ID. Pour plus d'informations, consultez les ressources de MITRE ATT&CK.

Point clé : Sans tiering, toutes les autres mesures de sécurité AD (LAPS, durcissement Kerberos, monitoring) sont compromises. Le tiering est la fondation sur laquelle repose l'ensemble de l'édifice. Un attaquant qui peut réutiliser des credentials Tier 0 depuis un poste Tier 2 contourne toutes les protections techniques en amont.

2. Le modèle de tiering : Tier 0, Tier 1, Tier 2

2.1 Définition des tiers

Le modèle de tiering divise l'infrastructure en trois niveaux de criticité, chacun avec ses propres comptes d'administration, ses propres stations de gestion et ses propres règles de connexion :

Tier	Périmètre	Exemples d'actifs	Impact en cas de compromission
Tier 0	Contrôle de l'identité	Contrôleurs de domaine, AD CS (PKI), AD FS, Entra Connect, SIEM (si collecte DC logs)	Compromission totale du domaine et de toutes les identités
Tier 1	Serveurs et applications	Serveurs de fichiers, bases de données, serveurs applicatifs, Exchange, SCCM/MECM, hyperviseurs	Accès aux données métier, pivot possible vers Tier 0
Tier 2	Postes et utilisateurs	Postes de travail, laptops, imprimantes, comptes utilisateurs standard	Compromission limitée (un poste), mais point d'entrée fréquent

2.2 La règle fondamentale : pas de connexion descendante

Le principe cardinal du tiering est simple : un compte d'un tier supérieur ne doit jamais exposer ses credentials sur un actif d'un tier inférieur. Concrètement :

• Un compte Tier 0 (Domain Admin, Enterprise Admin) ne doit JAMAIS se connecter sur un serveur Tier 1 ou un poste Tier 2.
• Un compte Tier 1 (Server Admin) ne doit JAMAIS se connecter sur un poste Tier 2.
• Un compte Tier 2 (Helpdesk, poste admin) ne doit JAMAIS avoir de privilèges Tier 1 ou Tier 0.

Pourquoi cette règle est-elle si critique ? Parce que Windows met en cache les credentials de tout utilisateur qui se connecte à une machine (hash NTLM en mémoire, Kerberos TGT, credentials en cache). Un attaquant contrôlant un poste Tier 2 peut extraire ces credentials avec Mimikatz et les réutiliser pour accéder aux systèmes du tier supérieur. C'est l'essence même du mouvement latéral et de l'escalade de privilèges dans Active Directory.

Une compromission d'un seul poste de travail pourrait-elle mener à votre contrôleur de domaine ?

3. Enterprise Access Model : l'évolution Microsoft

3.1 Du tiering classique au modèle d'accès entreprise

Microsoft a fait évoluer le tiering classique en un modèle plus complet appelé Enterprise Access Model (EAM). Ce modèle conserve les principes du tiering mais les étend pour intégrer le cloud (Entra ID), les environnements DevOps, et les workloads modernes. L'EAM redéfinit les niveaux en termes de planes d'accès :

Plan EAM	Équivalent Tier	Périmètre
Control Plane	Tier 0	Identité (AD, Entra ID, PKI), infrastructure de gestion (SCCM, Intune), hyperviseurs
Management Plane	Tier 1	Serveurs, applications, bases de données, pipelines CI/CD
User Access Plane	Tier 2	Postes de travail, accès utilisateur, email, productivité
Data/Workload Plane	(nouveau)	Données sensibles, API, workloads applicatifs

3.2 Intégration avec le cloud et Entra ID

L'EAM intègre nativement la dimension cloud. Dans un environnement hybride, les Global Administrators Entra ID sont des actifs Tier 0 au même titre que les Domain Admins AD. De même, les comptes Entra Connect (synchronisation AD vers Entra) sont des actifs Tier 0 critiques -- leur compromission permet souvent un Golden SAML ou une prise de contrôle totale de l'environnement cloud.

Le concept de Privileged Identity Management (PIM) dans Entra ID s'aligne parfaitement avec le tiering : les rôles sont attribués en just-in-time plutôt que de manière permanente, avec MFA et justification obligatoires. C'est l'équivalent cloud des restrictions de connexion GPO dans le tiering on-premises.

4. PAW : Privileged Access Workstations

4.1 Le concept de station d'administration sécurisée

Les PAW (Privileged Access Workstations) sont des stations de travail dédiées exclusivement à l'administration des systèmes du tier correspondant. Une PAW Tier 0 est utilisée uniquement pour administrer les contrôleurs de domaine et les systèmes d'identité. Elle ne permet pas la navigation web, l'ouverture d'emails, ni l'exécution d'applications non essentielles.

Le principe fondamental des PAW est la réduction de la surface d'attaque. En empêchant l'administrateur d'effectuer des actions à risque (navigation web, lecture d'emails) depuis la même machine que celle qui gère les actifs critiques, on élimine les vecteurs de compromission les plus courants : phishing, drive-by download, exploitation de vulnérabilités navigateur.

4.2 Implémentation des PAW par tier

Caractéristique	PAW Tier 0	PAW Tier 1	Poste Admin Tier 2
Matériel	Dédié, Secure Boot, TPM 2.0, BitLocker	Dédié ou VM sécurisée	VM ou poste durci
Accès Internet	Aucun (air-gapped ou proxy strict)	Restreint (Windows Update, repos)	Filtré
Email / Navigation	Interdit	Interdit	Autorisé sur un profil séparé
Applications	RSAT, PowerShell, outils AD uniquement	Consoles de gestion serveur	Outils helpdesk
Connexion autorisée	DC, AD CS, AD FS, Entra Connect	Serveurs Tier 1 uniquement	Postes Tier 2 uniquement
MFA	FIDO2/smartcard obligatoire	FIDO2/smartcard recommandé	MFA standard

# GPO pour PAW Tier 0 : restriction des applications via AppLocker
# Computer Configuration > Policies > Windows Settings > Security Settings
# > Application Control Policies > AppLocker

# Règle par défaut : bloquer tout sauf :
# - %WINDIR%\*                    (binaires système)
# - %PROGRAMFILES%\WindowsPowerShell\*  (PowerShell)
# - %PROGRAMFILES%\Windows Admin Center\*
# - %SYSTEMROOT%\System32\mmc.exe     (console MMC)
# - RSAT tools

# Script de vérification du durcissement PAW
$PAWChecks = @{
    "BitLocker"     = (Get-BitLockerVolume -MountPoint C:).ProtectionStatus
    "SecureBoot"    = Confirm-SecureBootUEFI
    "TPM"           = (Get-Tpm).TpmPresent
    "AppLocker"     = (Get-AppLockerPolicy -Effective).RuleCollections.Count -gt 0
    "WDAGEnabled"   = (Get-WindowsOptionalFeature -FeatureName Windows-Defender-ApplicationGuard -Online).State
    "CredentialGuard" = (Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root/Microsoft/Windows/DeviceGuard).VirtualizationBasedSecurityStatus
}
$PAWChecks | Format-Table -AutoSize

5. Jump Servers et bastions

5.1 Architecture des jump servers

Les jump servers (serveurs de rebond, ou bastions) sont des systèmes intermédiaires qui servent de point d'accès unique aux ressources d'un tier donné. Au lieu de se connecter directement aux serveurs depuis leur poste, les administrateurs se connectent d'abord au jump server, puis administrent les systèmes cibles depuis celui-ci. Cette architecture offre plusieurs avantages :

• Point de contrôle unique : toutes les sessions d'administration passent par un seul point, facilitant le monitoring et l'audit.
• Isolation des credentials : les credentials d'administration ne sont jamais exposés sur le poste utilisateur.
• Enregistrement des sessions : possibilité de capturer et rejouer les sessions RDP/SSH pour l'audit forensique.
• Gestion centralisée : contrôle d'accès centralisé, MFA, rotation de credentials.

# Configuration du jump server avec Windows Admin Center
# 1. Installer WAC sur le jump server (pas sur un DC !)
# 2. Configurer le certificat TLS (CA interne recommandé)
# 3. Restreindre l'accès réseau au jump server :

# Règle firewall : seuls les PAW peuvent accéder au jump server
New-NetFirewallRule -DisplayName "WAC - PAW Only" `
  -Direction Inbound -Protocol TCP -LocalPort 443 `
  -RemoteAddress @("10.0.0.10", "10.0.0.11") ` # IPs des PAW
  -Action Allow

# Bloquer tous les autres accès
New-NetFirewallRule -DisplayName "WAC - Block All Others" `
  -Direction Inbound -Protocol TCP -LocalPort 443 `
  -Action Block

# Configuration RDP restrictive via GPO sur le jump server :
# - NLA obligatoire
# - Timeout de session : 15 minutes d'inactivité
# - Pas de redirection de drives/clipboard (empêche l'exfiltration)
# - Audit des sessions RDP (Event ID 4624, 4634)

5.2 Solutions de bastion modernes

Les solutions de bastion modernes (CyberArk PAM, BeyondTrust, Wallix, Delinea) ajoutent des fonctionnalités avancées au concept de jump server : vaulting des credentials (les administrateurs ne connaissent jamais le mot de passe des systèmes cibles), injection automatique des credentials, enregistrement vidéo des sessions, et analyse comportementale des actions administratives. Ces solutions s'intègrent naturellement dans le modèle de tiering.

6. Restrictions techniques : GPO et Authentication Policy Silos

6.1 Restrictions de connexion via GPO

L'application technique du tiering repose en grande partie sur les GPO de restriction de connexion. Ces GPO définissent quels comptes peuvent se connecter à quels systèmes, et par quel type de connexion (interactive, réseau, RDP, service, batch) :

# GPO : Restrictions de connexion Tier 0 (appliquée aux DC)
# Computer Configuration > Policies > Windows Settings > Security Settings
# > Local Policies > User Rights Assignment

# "Allow log on locally" : 
#   - CORP\Tier0-Admins
#   - BUILTIN\Administrators (pour le compte DSRM)

# "Allow log on through Remote Desktop Services" :
#   - CORP\Tier0-Admins

# "Deny log on locally" :
#   - CORP\Tier1-Admins
#   - CORP\Tier2-Admins
#   - CORP\Domain Users

# "Deny log on through Remote Desktop Services" :
#   - CORP\Tier1-Admins
#   - CORP\Tier2-Admins

# "Deny access to this computer from the network" :
#   - CORP\Tier1-Admins (sauf comptes de service spécifiques)
#   - CORP\Tier2-Admins

# GPO : Restrictions de connexion Tier 1 (appliquée aux serveurs)
# "Deny log on locally" + "Deny log on through RDP" :
#   - CORP\Tier0-Admins  <-- CRITIQUE : empêche les T0 de se connecter aux serveurs
#   - CORP\Tier2-Admins

# GPO : Restrictions de connexion Tier 2 (appliquée aux postes)
# "Deny log on locally" + "Deny log on through RDP" :
#   - CORP\Tier0-Admins
#   - CORP\Tier1-Admins

6.2 Authentication Policy Silos (DFL 2012 R2+)

Les Authentication Policy Silos, introduits avec le Domain Functional Level 2012 R2, offrent un mécanisme plus granulaire et plus robuste que les GPO de restriction de connexion. Un silo définit un ensemble de comptes et de machines autorisés à interagir, avec des contraintes Kerberos strictes :

# Création d'un Authentication Policy Silo pour Tier 0

# 1. Créer la politique d'authentification
New-ADAuthenticationPolicy -Name "Tier0-AuthPolicy" `
  -Description "Politique d'authentification Tier 0" `
  -UserTGTLifetimeMins 240 `  # TGT limité à 4h (au lieu de 10h par défaut)
  -Enforce `
  -ProtectedFromAccidentalDeletion $true

# 2. Créer le silo
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" `
  -Description "Silo d'authentification Tier 0 - DC et admins T0" `
  -UserAuthenticationPolicy "Tier0-AuthPolicy" `
  -ComputerAuthenticationPolicy "Tier0-AuthPolicy" `
  -ServiceAuthenticationPolicy "Tier0-AuthPolicy" `
  -Enforce `
  -ProtectedFromAccidentalDeletion $true

# 3. Ajouter les comptes Tier 0 au silo
$Tier0Accounts = Get-ADGroupMember -Identity "Tier0-Admins" -Recursive
foreach ($Account in $Tier0Accounts) {
    Set-ADUser -Identity $Account.SamAccountName `
      -AuthenticationPolicySilo "Tier0-Silo"
}

# 4. Ajouter les machines Tier 0 (DC) au silo
$DCs = Get-ADDomainController -Filter *
foreach ($DC in $DCs) {
    Set-ADComputer -Identity $DC.Name `
      -AuthenticationPolicySilo "Tier0-Silo"
}

# 5. Configurer la condition d'accès (Kerberos armoring)
# Le TGT ne sera émis que si le compte s'authentifie depuis une machine du silo
Set-ADAuthenticationPolicy -Identity "Tier0-AuthPolicy" `
  -UserAllowedToAuthenticateFrom "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"Tier0-Silo`"))"

6. Restrictions techniques : GPO et Authentication Policy Silos : analyse approfondie

L'avantage des silos par rapport aux GPO : ils opèrent au niveau Kerberos. Même si un attaquant contourne les GPO (par exemple en modifiant la registry locale), le KDC refusera d'émettre un TGT pour un compte du silo si la machine n'en fait pas partie. C'est une protection beaucoup plus robuste.

6.3 Credential Guard et isolation des credentials

En complément du tiering, Windows Credential Guard utilise la virtualisation matérielle (VBS - Virtualization Based Security) pour isoler les credentials NTLM et Kerberos dans un processus protégé inaccessible depuis le kernel Windows. Même avec des droits SYSTEM, un attaquant ne peut pas extraire les hashes NTLM ou les tickets Kerberos des sessions actives :

# Activation de Credential Guard via GPO
# Computer Configuration > Administrative Templates > System > Device Guard
# > Turn on Virtualization Based Security : Enabled
#   - Credential Guard Configuration : Enabled with UEFI lock
#   - Secure Launch Configuration : Enabled

# Vérification du statut
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root/Microsoft/Windows/DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesRunning

# Statut attendu :
# VirtualizationBasedSecurityStatus : 2 (Running)
# SecurityServicesRunning : {1, 2} (Credential Guard + HVCI)

Credential Guard ne protège pas contre toutes les attaques de credentials : les Kerberoasting et AS-REP roasting ciblent les tickets chiffrés hors du processus protégé. Mais combiné avec le tiering, il élimine le vecteur le plus courant : le vol de credentials en mémoire via Mimikatz sur une machine compromise.

7. Implémentation pratique : plan de déploiement par phases

7.1 Phase 1 : Quick wins (Semaines 1-4)

L'implémentation du tiering est un projet d'envergure qui nécessite une approche progressive. La première phase cible les victoires rapides qui réduisent immédiatement la surface d'attaque sans nécessiter de restructuration majeure de l'AD :

# Phase 1 - Quick Wins : Séparation des comptes administratifs

# 1. Créer la structure d'OU pour le tiering
$BaseDN = (Get-ADDomain).DistinguishedName
$TierOUs = @(
    "OU=Tier0-Admin,OU=Administration,$BaseDN",
    "OU=Tier1-Admin,OU=Administration,$BaseDN",
    "OU=Tier2-Admin,OU=Administration,$BaseDN",
    "OU=Tier0-Servers,OU=Servers,$BaseDN",
    "OU=Tier1-Servers,OU=Servers,$BaseDN",
    "OU=PAW,OU=Workstations,$BaseDN"
)

foreach ($OU in $TierOUs) {
    if (-not (Get-ADOrganizationalUnit -Filter "DistinguishedName -eq '$OU'" -ErrorAction SilentlyContinue)) {
        New-ADOrganizationalUnit -Name ($OU -split ',')[0].Replace('OU=','') `
          -Path ($OU -replace '^OU=[^,]+,','') `
          -ProtectedFromAccidentalDeletion $true
        Write-Host "[+] OU créée : $OU" -ForegroundColor Green
    }
}

# 2. Créer les groupes de tiering
$Groups = @{
    "Tier0-Admins" = "OU=Tier0-Admin,OU=Administration,$BaseDN"
    "Tier1-Admins" = "OU=Tier1-Admin,OU=Administration,$BaseDN"
    "Tier2-Admins" = "OU=Tier2-Admin,OU=Administration,$BaseDN"
    "PAW-Users"    = "OU=PAW,OU=Workstations,$BaseDN"
}

foreach ($Group in $Groups.GetEnumerator()) {
    New-ADGroup -Name $Group.Key `
      -GroupScope Global `
      -GroupCategory Security `
      -Path $Group.Value `
      -Description "Groupe d'administration $($Group.Key)"
}

# 3. Créer des comptes d'administration dédiés par tier
# Convention de nommage : t0-prenom.nom, t1-prenom.nom, t2-prenom.nom
$AdminUsers = @(
    @{Name="t0-admin.dupont"; Tier="Tier0"; Description="Admin Tier 0 - Jean Dupont"}
    @{Name="t1-admin.dupont"; Tier="Tier1"; Description="Admin Tier 1 - Jean Dupont"}
    @{Name="t2-admin.dupont"; Tier="Tier2"; Description="Admin Tier 2 - Jean Dupont"}
)

foreach ($User in $AdminUsers) {
    $OU = "OU=$($User.Tier)-Admin,OU=Administration,$BaseDN"
    $SecurePassword = Read-Host "Mot de passe pour $($User.Name)" -AsSecureString
    New-ADUser -Name $User.Name `
      -SamAccountName $User.Name `
      -UserPrincipalName "$($User.Name)@$((Get-ADDomain).DNSRoot)" `
      -Path $OU `
      -Description $User.Description `
      -AccountPassword $SecurePassword `
      -Enabled $true `
      -PasswordNeverExpires $false `
      -ChangePasswordAtLogon $true
    
    Add-ADGroupMember -Identity "$($User.Tier)-Admins" -Members $User.Name
}

7.2 Phase 2 : Restrictions de connexion (Semaines 5-8)

La deuxième phase applique les restrictions de connexion qui constituent le coeur du modèle de tiering. C'est la phase la plus critique car elle casse les habitudes des administrateurs qui utilisent un seul compte pour tout administrer :

# Phase 2 - GPO de restrictions de connexion

# GPO Tier 0 : appliquée aux contrôleurs de domaine
# Interdire les comptes Tier 1/2 de se connecter aux DC
$GPO_T0 = New-GPO -Name "[SEC] Tier0 - Logon Restrictions" -Comment "Restrictions Tier 0 - DC only"
$GPO_T0 | Set-GPPermission -PermissionLevel GpoApply -TargetName "Domain Controllers" -TargetType Group
$GPO_T0 | New-GPLink -Target "OU=Domain Controllers,$BaseDN" -LinkEnabled Yes

# Configuration via script (les User Rights Assignment ne sont pas configurables via PowerShell natif)
# Utiliser secedit ou LGPO.exe pour appliquer les paramètres

# Template secedit pour Tier 0
$SecTemplate = @"
[Privilege Rights]
SeDenyInteractiveLogonRight = *$((Get-ADGroup 'Tier1-Admins').SID),*$((Get-ADGroup 'Tier2-Admins').SID)
SeDenyRemoteInteractiveLogonRight = *$((Get-ADGroup 'Tier1-Admins').SID),*$((Get-ADGroup 'Tier2-Admins').SID)
SeDenyNetworkLogonRight = *$((Get-ADGroup 'Tier2-Admins').SID)
SeDenyBatchLogonRight = *$((Get-ADGroup 'Tier1-Admins').SID),*$((Get-ADGroup 'Tier2-Admins').SID)
SeDenyServiceLogonRight = *$((Get-ADGroup 'Tier1-Admins').SID),*$((Get-ADGroup 'Tier2-Admins').SID)
"@
$SecTemplate | Out-File -FilePath "C:\Temp\Tier0-Restrictions.inf" -Encoding Unicode

# Appliquer le template
secedit /configure /db C:\Temp\Tier0.sdb /cfg C:\Temp\Tier0-Restrictions.inf /areas USER_RIGHTS

# GPO Tier 1 : appliquée aux serveurs membres
# Interdire les comptes Tier 0 et Tier 2
# CRITIQUE : les comptes Tier 0 NE DOIVENT PAS se connecter aux serveurs membres
# pour éviter l'exposition de leurs credentials

# GPO Tier 2 : appliquée aux postes de travail
# Interdire les comptes Tier 0 et Tier 1

7.3 Phase 3 : PAW et silos d'authentification (Semaines 9-16)

7. Implémentation pratique : plan de déploiement par phases : analyse approfondie

La troisième phase déploie les Privileged Access Workstations et configure les Authentication Policy Silos pour les comptes Tier 0. C'est la phase qui verrouille définitivement le modèle :

# Phase 3 - Déploiement des PAW et configuration des silos

# 1. Vérification des prérequis pour les Authentication Policy Silos
$DFL = (Get-ADDomain).DomainMode
if ($DFL -lt "Windows2012R2Domain") {
    Write-Warning "DFL $DFL insuffisant ! Les silos nécessitent DFL 2012 R2 minimum."
    Write-Warning "Procédure : Mettre à jour tous les DC, puis élever le DFL."
    exit 1
}

# 2. Vérifier que Kerberos armoring (FAST) est activé
# GPO : Computer Configuration > Policies > Administrative Templates
#   > System > KDC > KDC support for claims, compound authentication and Kerberos armoring
# Doit être "Always provide claims" sur les DC

# 3. Créer les silos pour chaque tier
$Tiers = @(
    @{Name="Tier0-Silo"; TGT=240; Desc="Silo Tier 0 - DC, ADFS, PKI, PAW-T0"}
    @{Name="Tier1-Silo"; TGT=480; Desc="Silo Tier 1 - Serveurs membres, PAW-T1"}
)

foreach ($Tier in $Tiers) {
    # Politique d'authentification
    New-ADAuthenticationPolicy -Name "$($Tier.Name)-Policy" `
      -Description $Tier.Desc `
      -UserTGTLifetimeMins $Tier.TGT `
      -Enforce `
      -ProtectedFromAccidentalDeletion $true
    
    # Silo
    New-ADAuthenticationPolicySilo -Name $Tier.Name `
      -Description $Tier.Desc `
      -UserAuthenticationPolicy "$($Tier.Name)-Policy" `
      -ComputerAuthenticationPolicy "$($Tier.Name)-Policy" `
      -ServiceAuthenticationPolicy "$($Tier.Name)-Policy" `
      -Enforce `
      -ProtectedFromAccidentalDeletion $true
}

# 4. Assigner les comptes et machines aux silos
# Tier 0
Get-ADGroupMember -Identity "Tier0-Admins" -Recursive | ForEach-Object {
    Set-ADUser -Identity $_.SamAccountName -AuthenticationPolicySilo "Tier0-Silo"
}
Get-ADDomainController -Filter * | ForEach-Object {
    Set-ADComputer -Identity $_.Name -AuthenticationPolicySilo "Tier0-Silo"
}

# 5. Configurer les conditions d'accès FAST
Set-ADAuthenticationPolicy -Identity "Tier0-Silo-Policy" `
  -UserAllowedToAuthenticateFrom `
  "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"Tier0-Silo`"))"

Write-Host "[+] Phase 3 terminée. Tester avec :" -ForegroundColor Green
Write-Host "    klist  # depuis une PAW Tier 0 avec un compte T0" -ForegroundColor Cyan
Write-Host "    # Le TGT doit montrer le silo d'authentification" -ForegroundColor Cyan

7.4 Phase 4 : Monitoring et audit continu (Semaines 17+)

Le tiering sans monitoring est un château de cartes. La phase 4 met en place la détection des violations du modèle -- un administrateur qui contourne les restrictions, un nouveau chemin d'attaque créé par une modification d'ACL, ou une dérive de la configuration des silos :

# Phase 4 - Monitoring des violations de tiering

# Event IDs critiques pour le monitoring du tiering
$TieringEvents = @{
    # Violations de connexion
    4625 = "Échec de connexion (tentative de connexion cross-tier)"
    4768 = "TGT demandé (vérifier le silo et la machine source)"
    4769 = "Ticket de service demandé (vérifier la machine cible)"
    4771 = "Pré-authentification Kerberos échouée"
    
    # Violations Authentication Policy Silo
    4820 = "Un TGT Kerberos a été refusé car le compte n'est pas dans le silo"
    4821 = "Un ticket de service Kerberos a été refusé (violation de silo)"
    
    # Modifications de la configuration du tiering
    5136 = "Modification d'un objet AD (ACL, membership, silo)"
    4728 = "Membre ajouté à un groupe global (Tier0/1/2-Admins)"
    4729 = "Membre retiré d'un groupe global"
}

# Requête PowerShell pour détecter les connexions cross-tier
# Connexions Tier 0 sur des machines non-Tier 0
$Tier0Users = (Get-ADGroupMember -Identity "Tier0-Admins" -Recursive).SamAccountName
$DCs = (Get-ADDomainController -Filter *).Name

$Events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624  # Logon réussi
    StartTime = (Get-Date).AddDays(-1)
} | Where-Object {
    $xml = [xml]$_.ToXml()
    $TargetUser = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'} | Select-Object -ExpandProperty '#text'
    $Workstation = $xml.Event.EventData.Data | Where-Object {$_.Name -eq 'WorkstationName'} | Select-Object -ExpandProperty '#text'
    
    ($TargetUser -in $Tier0Users) -and ($Workstation -notin $DCs) -and ($Workstation -notlike "PAW-T0*")
}

if ($Events) {
    Write-Warning "ALERTE : $($Events.Count) connexions Tier 0 détectées sur des machines non-autorisées !"
    $Events | ForEach-Object {
        $xml = [xml]$_.ToXml()
        [PSCustomObject]@{
            Time = $_.TimeCreated
            User = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
            Machine = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'WorkstationName'}).'#text'
            LogonType = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'LogonType'}).'#text'
        }
    } | Format-Table -AutoSize
}

8. Erreurs courantes et pièges à éviter

L'implémentation du tiering échoue souvent non pas pour des raisons techniques, mais pour des raisons organisationnelles et opérationnelles. Voici les erreurs les plus fréquentes observées en audit :

8.1 Erreur n°1 : le compte unique multi-tier

L'erreur la plus courante est de permettre à un administrateur d'utiliser un seul compte pour tous les tiers. Même avec des restrictions GPO, si le même compte est membre de Tier0-Admins et se connecte occasionnellement sur un poste de travail (pour "tester quelque chose rapidement"), le modèle est compromis. La solution : chaque administrateur possède un compte nominatif par tier plus son compte utilisateur standard sans privilèges.

8.2 Erreur n°2 : les comptes de service oubliés

Les comptes de service sont souvent les grands oubliés du tiering. Un compte de service SQL qui tourne sur un serveur Tier 1 mais possède des droits de réplication AD (DCSync) détruit le cloisonnement entre les tiers. L'audit des comptes de service doit identifier tous les comptes avec des privilèges cross-tier et les migrer vers des Group Managed Service Accounts (gMSA) qui peuvent être confinés dans un tier spécifique. Consultez notre article sur les attaques Kerberoasting pour comprendre les risques liés aux comptes de service.

8.3 Erreur n°3 : les exceptions permanentes

8. Erreurs courantes et pièges à éviter : analyse approfondie

Le tiering génère inévitablement des demandes d'exceptions : "J'ai besoin de me connecter en RDP au DC depuis mon poste pour dépanner rapidement." Ces exceptions, si elles deviennent permanentes, créent des chemins d'attaque que BloodHound identifie immédiatement. Chaque exception doit être :

• Temporaire : avec une date d'expiration automatique (max 24h)
• Documentée : ticket de changement avec justification et approbation
• Auditée : logs centralisés de toutes les connexions effectuées pendant l'exception
• Revue régulièrement : revue trimestrielle de toutes les exceptions actives

8.4 Erreur n°4 : ignorer les chemins d'attaque indirects

Le tiering protège contre les attaques directes (connexion cross-tier), mais les attaquants exploitent des chemins indirects : délégation Kerberos non contrainte, ACL permissives sur les OU, GPO modifiables par des comptes Tier 1 mais liées aux DC, partages réseau accessibles depuis tous les tiers contenant des scripts avec des credentials hardcodés. L'analyse régulière avec BloodHound est indispensable pour détecter ces chemins.

9. Validation du tiering : tests et audit

Un modèle de tiering ne vaut que s'il est testé et validé régulièrement. Voici les tests essentiels à réaliser pour vérifier l'intégrité du cloisonnement :

# Script de validation du tiering - à exécuter mensuellement

function Test-TieringCompliance {
    [CmdletBinding()]
    param()
    
    $Results = @()
    $BaseDN = (Get-ADDomain).DistinguishedName
    
    # Test 1 : Vérifier qu'aucun compte Tier 0 n'a de SPN (Kerberoasting)
    Write-Host "[*] Test 1 : Comptes Tier 0 avec SPN..." -ForegroundColor Yellow
    $T0WithSPN = Get-ADGroupMember -Identity "Tier0-Admins" -Recursive |
        Get-ADUser -Properties ServicePrincipalName |
        Where-Object { $_.ServicePrincipalName.Count -gt 0 }
    
    if ($T0WithSPN) {
        $Results += [PSCustomObject]@{
            Test = "T0-SPN"; Status = "FAIL"; Count = $T0WithSPN.Count
            Details = "Comptes Tier 0 avec SPN : $($T0WithSPN.SamAccountName -join ', ')"
        }
    } else {
        $Results += [PSCustomObject]@{Test="T0-SPN"; Status="PASS"; Count=0; Details="OK"}
    }
    
    # Test 2 : Vérifier qu'aucun compte Tier 0 n'a de session ouverte hors DC/PAW
    Write-Host "[*] Test 2 : Sessions Tier 0 actives..." -ForegroundColor Yellow
    $DCs = (Get-ADDomainController -Filter *).HostName
    # Utiliser PSLoggedOn ou quser sur chaque serveur pour détecter les sessions cross-tier
    
    # Test 3 : Vérifier les ACL sur les OU Tier 0
    Write-Host "[*] Test 3 : ACL sur les OU Tier 0..." -ForegroundColor Yellow
    $T0OU = "OU=Domain Controllers,$BaseDN"
    $ACL = Get-Acl "AD:\$T0OU"
    $DangerousACE = $ACL.Access | Where-Object {
        $_.IdentityReference -notmatch "S-1-5-32-544|Domain Admins|Enterprise Admins|SYSTEM" -and
        $_.ActiveDirectoryRights -match "WriteProperty|WriteDacl|WriteOwner|GenericAll|GenericWrite"
    }
    
    if ($DangerousACE) {
        $Results += [PSCustomObject]@{
            Test = "T0-ACL"; Status = "FAIL"; Count = $DangerousACE.Count
            Details = "ACE dangereuses : $($DangerousACE.IdentityReference -join ', ')"
        }
    } else {
        $Results += [PSCustomObject]@{Test="T0-ACL"; Status="PASS"; Count=0; Details="OK"}
    }
    
    # Test 4 : Vérifier les silos d'authentification
    Write-Host "[*] Test 4 : Configuration des silos..." -ForegroundColor Yellow
    $Silos = Get-ADAuthenticationPolicySilo -Filter *
    $UnenforcesSilos = $Silos | Where-Object { -not $_.Enforce }
    
    if ($UnenforcesSilos) {
        $Results += [PSCustomObject]@{
            Test = "SILOS"; Status = "WARN"; Count = $UnenforcesSilos.Count
            Details = "Silos non enforced : $($UnenforcesSilos.Name -join ', ')"
        }
    } else {
        $Results += [PSCustomObject]@{Test="SILOS"; Status="PASS"; Count=0; Details="OK"}
    }
    
    # Test 5 : Vérifier l'absence de délégation non contrainte hors DC
    Write-Host "[*] Test 5 : Délégation Kerberos non contrainte..." -ForegroundColor Yellow
    $UnconstrainedDeleg = Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
        Where-Object { $_.DistinguishedName -notmatch "Domain Controllers" }
    
    if ($UnconstrainedDeleg) {
        $Results += [PSCustomObject]@{
            Test = "DELEG"; Status = "FAIL"; Count = $UnconstrainedDeleg.Count
            Details = "Machines avec délégation non contrainte hors DC : $($UnconstrainedDeleg.Name -join ', ')"
        }
    } else {
        $Results += [PSCustomObject]@{Test="DELEG"; Status="PASS"; Count=0; Details="OK"}
    }
    
    # Affichage des résultats
    Write-Host "`n========== RÉSULTATS AUDIT TIERING ==========" -ForegroundColor Cyan
    $Results | Format-Table -AutoSize
    
    $FailCount = ($Results | Where-Object {$_.Status -eq "FAIL"}).Count
    if ($FailCount -gt 0) {
        Write-Host "[!] $FailCount test(s) en échec -- actions correctives nécessaires" -ForegroundColor Red
    } else {
        Write-Host "[+] Tous les tests passent -- tiering conforme" -ForegroundColor Green
    }
    
    return $Results
}

# Exécution
Test-TieringCompliance

Pour approfondir ce sujet, consultez notre outil open-source kerberos-toolkit qui facilite l'analyse et le test des mécanismes Kerberos.

Questions frequentes

10. Conclusion : le tiering comme fondation de la sécurité AD

Le Tiering Model reste, en 2025, le pilier fondamental de toute stratégie de sécurisation d'Active Directory. Malgré l'évolution vers l'Enterprise Access Model de Microsoft et l'intégration cloud avec Entra ID, les principes fondamentaux demeurent inchangés : séparer les niveaux de privilèges, isoler les identités critiques et interdire toute contamination entre les tiers.

Les organisations qui implémentent correctement le tiering observent une réduction drastique de leur surface d'attaque AD. Les chemins d'attaque identifiés par BloodHound diminuent de 80 à 95 % après une implémentation complète, et les incidents de type compromission totale du domaine (Golden Ticket, DCSync) deviennent quasiment impossibles sans exploitation de vulnérabilités zero-day.

Les clés du succès sont :

• Approche progressive : déployer par phases avec des quick wins immédiats
• Comptes dédiés par tier : pas de compromis sur la séparation des identités
• PAW pour le Tier 0 : l'investissement le plus rentable en sécurité AD
• Authentication Policy Silos : protection au niveau Kerberos, plus robuste que les GPO seules
• Monitoring continu : détecter et corriger les violations du modèle en temps réel
• Soutien de la direction : le tiering impacte les habitudes de travail et nécessite un mandat clair

Enfin, le tiering ne doit pas être vu comme un projet ponctuel mais comme un processus continu. Chaque nouvelle application, chaque nouveau compte de service, chaque modification d'infrastructure doit être évaluée à travers le prisme du tiering. Combiné avec les protections techniques comme LAPS, le hardening via GPO et la protection des secrets NTDS.dit, le tiering constitue la fondation sur laquelle toute la sécurité AD repose.

En résumé : Le tiering n'est pas optionnel. Toute organisation utilisant Active Directory sans modèle de tiering offre aux attaquants un chemin direct du poste de travail compromis au contrôleur de domaine -- et cela prend en moyenne 48 heures dans un environnement non segmenté.