Active Directory Tiering Model 2026 : Architecture et Bonnes Pratiques

Le modèle de tiers Active Directory, souvent désigné sous le terme de "Tiering Model" ou "Tier Model", représente en 2026 le fondement architectural de toute stratégie de sécurisation sérieuse d'un environnement Windows. Développé par Microsoft à partir de 2015 dans le cadre de la stratégie Privileged Access Strategy, ce modèle repose sur un principe simple mais fondamental : séparer les actifs et les comptes administratifs en niveaux d'isolation distincts pour empêcher la propagation latérale des compromissions. Malgré une décennie de recommandations de Microsoft et de l'ANSSI, la réalité des organisations françaises en 2026 reste souvent loin de cet idéal : lors d'une mission d'audit menée par notre équipe pour une ETI du secteur agroalimentaire, nous avons constaté que les mêmes comptes administrateurs accédaient indifféremment aux contrôleurs de domaine, aux serveurs applicatifs et aux postes utilisateurs. Un seul poste compromis via phishing aurait suffi à exposer les clés du domaine entier. Ce scénario, loin d'être exceptionnel, illustre pourquoi l'ANSSI place le Tiering Model au premier rang de ses recommandations dans son guide de sécurisation Active Directory (PA-022, mis à jour en 2024). Ce guide complet détaille l'architecture des trois niveaux, les Privileged Access Workstations (PAW), l'environnement ESAE (Enhanced Security Admin Environment), les mécanismes JIT et JEA, et les recommandations pratiques pour une implémentation progressive dans les organisations de toute taille.

Fondements du Tiering Model : Pourquoi Séparer les Niveaux ?

La logique du Tiering Model est intuitive : un attaquant qui compromet un poste utilisateur de niveau bas ne devrait pas pouvoir accéder directement aux ressources les plus sensibles de l'organisation. Sans séparation des niveaux, une seule compromission peut se propager à l'ensemble du domaine via les techniques de Pass-the-Hash, NTLM Relay ou Kerberoasting. Le Tiering crée des frontières imperméables entre les niveaux d'administration. La puissance du modèle tient à sa simplicité conceptuelle : cloisonner les actifs par niveau d'impact potentiel, et s'assurer que les credentials d'administration ne traversent jamais vers un niveau inférieur, même temporairement. Un compte Domain Admin qui s'authentifie sur un serveur applicatif ou un poste utilisateur expose ses credentials à tout attaquant ayant déjà compromis ces systèmes de niveau inférieur — une situation que le Tiering vient précisément éliminer.

Sans Tiering, voici ce que représente un poste utilisateur compromis dans un AD standard : Pass-the-Hash depuis la mémoire LSASS du poste, accès à d'autres machines via les tokens Kerberos mis en cache, et finalement escalade vers les comptes DA si ceux-ci se sont récemment connectés sur ce poste. Le Tiering brise chacun de ces maillons.

Le modèle définit trois niveaux principaux :

• Tier 0 — La Forêt Active Directory : contrôleurs de domaine, ADFS, AD CS, AAD Connect, DNS intégré à AD. Tout composant dont la compromission permettrait de contrôler l'ensemble du domaine.
• Tier 1 — Les Serveurs et Applications Critiques : serveurs applicatifs, bases de données, serveurs de fichiers, systèmes ERP, infrastructure cloud. Ressources importantes mais dont la compromission ne donne pas accès au domaine entier.
• Tier 2 — Les Endpoints et Utilisateurs Standards : postes de travail, tablettes, smartphones. Le niveau le plus exposé car en contact avec les menaces externes (phishing, navigation web, clés USB).

Principe de la Frontière de Tier : Ce qui Ne Peut Pas Traverser

La règle d'or du Tiering Model est que les credentials d'administration ne doivent jamais traverser vers un niveau inférieur. Un compte Tier 0 ne doit jamais se connecter à une machine Tier 1 ou Tier 2. Un compte Tier 1 ne doit jamais se connecter à un poste Tier 2. Cette règle s'applique même de manière indirecte : si un administrateur de domaine utilise son compte DA pour gérer un serveur applicatif (Tier 1), et que ce serveur est compromis, l'attaquant peut récupérer le hash ou le ticket Kerberos du DA depuis la mémoire du serveur.

L'implémentation technique de cette frontière passe par les restrictions de connexion via GPO :

# GPO pour bloquer les connexions Tier 0 sur Tier 1/2
# Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment
# "Deny log on locally" et "Deny access to this computer from the network"
# Ajouter : groupes Tier 0 Admins dans ces politiques sur les machines Tier 1 et Tier 2

# Exemple PowerShell : configurer les restrictions via GPO en ligne de commande
Import-Module GroupPolicy
$gpo = Get-GPO -Name "Tier Restrictions - Tier1 Servers"

# Les comptes DA et Enterprise Admin ne peuvent pas se connecter aux serveurs Tier 1
# Verification de la politique
Get-GPOReport -Guid $gpo.Id -ReportType Xml | Select-String "DenyLogonLocally"

Privileged Access Workstations (PAW) : Les Machines Sacralisées

Les Privileged Access Workstations (PAW) sont des postes dédiés à l'administration des actifs de chaque niveau. Un administrateur disposant d'un compte Tier 0 doit utiliser une PAW Tier 0 (une machine physique ou virtuelle dédiée, sans accès à Internet, sans email, sans navigation web) pour administrer les contrôleurs de domaine. Il dispose d'un poste standard séparé pour ses tâches quotidiennes (email, navigation, applications métier).

La PAW est la mesure de sécurité la plus efficace contre les attaques de vol de credentials d'administration. Un attaquant qui compromet le poste standard d'un administrateur ne peut pas récupérer ses credentials d'administration car ceux-ci ne sont jamais présents sur la machine standard — ils sont utilisés exclusivement depuis la PAW.

# Configuration PAW Tier 0 recommandee par l'ANSSI :
# - Windows 11 Pro/Enterprise en derniere version
# - Chiffrement BitLocker activé avec TPM 2.0
# - Firewall entrant : tout bloque sauf domaine et administration
# - Firewall sortant : liste blanche des serveurs cibles uniquement
# - Internet : AUCUN acces (blocage DNS et route)
# - Email : AUCUN client email installe
# - Antivirus : Defender for Endpoint avec tamper protection
# - Credential Guard : active pour proteger les credentials en memoire
# - AppLocker ou WDAC : seuls les binaires signes autorises

# GPO PAW : interdire l'acces Internet
# Computer Configuration > Windows Settings > Security Settings > Windows Firewall
# Outbound Rules : Block All Programs (puis exceptions pour admin tools)

# Verifier Credential Guard sur une machine
(Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard).EnableVirtualizationBasedSecurity

Comptes Dédiés par Niveau : La Triple Identité de l'Administrateur

Dans un Tiering Model correctement implémenté, un administrateur système type dispose de trois comptes distincts :

• Compte utilisateur standard (ex: jmartin) — pour les tâches quotidiennes, email, navigation, applications métier. Tier 2.
• Compte d'administration Tier 1 (ex: jmartin-T1) — pour administrer les serveurs applicatifs. Utilisé uniquement depuis une PAW Tier 1.
• Compte d'administration Tier 0 (ex: jmartin-T0) — pour administrer les contrôleurs de domaine et l'infrastructure critique. Utilisé uniquement depuis une PAW Tier 0 dédiée.

Ces comptes doivent avoir des mots de passe distincts, des durées de vie distinctes, et être membres de groupes distincts. L'utilisation des Protected Users Security Group est recommandée pour les comptes Tier 0 : ce groupe interdit l'utilisation de NTLM, DES et RC4, force Kerberos AES, et ne permet pas la mise en cache des credentials sur les machines.

ESAE (Enhanced Security Admin Environment) : L'Architecture Forteresse

L'ESAE (Enhanced Security Admin Environment), aussi appelé "Red Forest" ou "Admin Forest", est une architecture avancée qui consiste à déployer une forêt Active Directory séparée et dédiée à l'administration de la forêt de production. Cette forêt ESAE est extrêmement durcie (peu d'utilisateurs, accès physique limité, pas de connexion à Internet) et contient tous les comptes d'administration Tier 0.

La logique est qu'une forêt de production compromise ne peut pas compromettre la forêt ESAE, car la relation de confiance est unidirectionnelle : la forêt ESAE fait confiance à la forêt de production pour les ressources, mais la forêt de production ne peut pas initier d'actions administratives dans la forêt ESAE.

Just-In-Time (JIT) Administration : Les Droits à la Demande

Le Just-In-Time (JIT) Access est un mécanisme qui permet d'accorder des droits administratifs temporaires uniquement lorsqu'ils sont nécessaires, et de les révoquer automatiquement après un délai défini. Contrairement aux droits permanents qui restent actifs 24h/24, les droits JIT n'existent que pendant la fenêtre d'utilisation, réduisant drastiquement la surface d'attaque.

Microsoft fournit deux mécanismes JIT natifs :

• PAM (Privileged Access Management) avec MIM : via Microsoft Identity Manager, l'administrateur demande des droits temporaires pour une durée définie. Ces droits expirent automatiquement.
• PIM (Privileged Identity Management) dans Entra ID : pour les rôles cloud, PIM permet une activation temporaire des rôles avec approbation optionnelle et MFA obligatoire.

# Activer PAM dans Active Directory (requis pour JIT on-prem)
Enable-ADOptionalFeature "Privileged Access Management Feature" -Scope ForestOrConfigurationSet -Target "domaine.local"

# Verifier que PAM est active
Get-ADOptionalFeature -Filter {Name -eq "Privileged Access Management Feature"}

# Creer un groupe PAM avec TTL (Time-To-Live)
# Les membres sont automatiquement supprimes apres le TTL
Add-ADGroupMember -Identity "Domain Admins" -Members "jmartin-T0" -MemberTimeToLive (New-TimeSpan -Minutes 60)

# Via PowerShell Entra ID : activer PIM pour un role Azure AD
# Requiert Azure AD Premium P2
Enable-PIMRole -RoleId "62e90394-69f5-4237-9190-012177145e10" -UserId "[email protected]" -Duration 4

Just Enough Administration (JEA) : Délégation Fine des Droits PowerShell

JEA (Just Enough Administration) est une fonctionnalité PowerShell qui permet de déléguer des tâches d'administration spécifiques à des utilisateurs non-admin, sans leur donner de droits administratifs complets. Un opérateur helpdesk peut, via JEA, être autorisé à redémarrer un service spécifique sur des serveurs spécifiques, sans jamais avoir accès à un shell administratif complet.

# Creer une configuration JEA permettant uniquement le redemarrage d'IIS
# Fichier de session JEA (IISManagement.pssc)
New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer `
    -VisibleCmdlets "Get-Service", "Restart-Service" `
    -VisibleFunctions "Restart-IIS" `
    -RunAsVirtualAccount `
    -Path "C:\JEAConfig\IISManagement.pssc"

# Enregistrer la configuration JEA
Register-PSSessionConfiguration -Name "IISManagement" -Path "C:\JEAConfig\IISManagement.pssc" -Force

# Connecter via JEA (l'utilisateur ne voit que les commandes autorisees)
Enter-PSSession -ComputerName serveur-iis -ConfigurationName "IISManagement"

# Creer un role capabilities file pour le helpdesk
New-PSRoleCapabilityFile -Path "C:\JEAConfig\HelpDesk.psrc" -VisibleCmdlets @{
    Name = "Restart-Service"
    Parameters = @{Name="Name"; ValidateSet="Spooler", "W32Time", "BITS"}
}

Protected Users Security Group : Protection Kerberos Renforcée

Le groupe Protected Users, introduit dans Windows Server 2012 R2, applique automatiquement un ensemble de protections aux comptes membres :

• Interdiction d'utilisation de NTLM (seul Kerberos est autorisé)
• Interdiction de délégation Kerberos (le compte ne peut pas être délégué)
• Interdiction du chiffrement DES et RC4 dans les tickets Kerberos (AES uniquement)
• Durée de vie des TGT limitée à 4 heures (non renouvelables)
• Pas de mise en cache des credentials sur les machines locales

Ces protections éliminent plusieurs vecteurs d'attaque courants : Pass-the-Hash (car NTLM est désactivé), Kerberos Delegation Abuse (car la délégation est interdite), et la récupération de credentials depuis la mémoire lsass (car pas de cache). Tous les comptes Tier 0 devraient être membres du groupe Protected Users, sans exception. Certains administrateurs hésitent à ajouter leurs comptes DA dans Protected Users par crainte de problèmes de compatibilité avec des applications nécessitant la délégation Kerberos ou NTLM — mais justement, si un compte DA est délégué ou utilise NTLM, c'est un problème de configuration à corriger, pas une raison de ne pas protéger le compte. La règle devrait être : si un compte DA a besoin de NTLM ou de délégation pour fonctionner, c'est un indicateur que l'architecture doit être revue, pas que Protected Users doit être évité.

# Ajouter les comptes Tier 0 au groupe Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "jmartin-T0", "Administrator", "DA-Service"

# Verifier qu'un compte est bien protege
Get-ADUser -Identity "jmartin-T0" -Properties MemberOf | Select-Object -ExpandProperty MemberOf | Where-Object {$_ -like "*Protected Users*"}

# Tester l'impact : verifier qu'NTLM est refuse pour ce compte
# Utiliser un scan Netexec avec hash NTLM : devrait echouer
netexec smb dc01.domaine.local -u jmartin-T0 -H :NTLM_HASH

Recommandations ANSSI sur le Tiering Model

L'ANSSI détaille le Tiering Model dans plusieurs documents de référence dont son guide de sécurisation Active Directory (PA-022 version 2024) et ses "Recommandations relatives à l'Active Directory". Les points clés des recommandations ANSSI incluent :

• Identifier et cartographier tous les assets Tier 0 (pas uniquement les DC) avant d'implémenter le Tiering
• Implémenter les restrictions de connexion GPO comme première mesure technique (délai court)
• Déployer les PAW pour les administrateurs Tier 0 en priorité absolue
• Activer Protected Users pour tous les comptes d'administration
• Mettre en place l'audit des connexions inter-tiers pour détecter les violations de politique

Notre article sur le guide de sécurisation Active Directory 2025 présente l'ensemble du référentiel ANSSI. Pour les outils d'audit permettant de vérifier l'implémentation du Tiering, consultez notre liste des 10 outils d'audit Active Directory 2025.

Implémentation Progressive : Roadmap sur 6 Mois

L'implémentation complète du Tiering Model dans un SI existant ne peut pas se faire en une semaine. Voici la roadmap en six phases que nous recommandons :

Identifier les Assets Tier 0 : La Cartographie Indispensable

L'une des erreurs les plus communes dans l'implémentation du Tiering Model est de sous-estimer le périmètre du Tier 0. Les assets Tier 0 ne se limitent pas aux contrôleurs de domaine : tout système dont la compromission permettrait de contrôler l'AD appartient au Tier 0.

La liste complète des assets Tier 0 typiques inclut :

• Contrôleurs de domaine (DC) — évidemment
• ADFS et WAP — permettent le Golden SAML
• AD CS (Certificate Authority) — permettent le forging de certificats
• Azure AD Connect / Entra Connect — synchronise les hashes vers le cloud
• SCCM/ConfigMgr — peut déployer du code sur tous les membres du domaine
• Solutions de backup qui sauvegardent les DC — contiennent potentiellement les hashes
• Solutions de virtualisation hébergeant les DC (vCenter, Hyper-V cluster)
• PKI offline root CA

# BloodHound : identifier les chemins vers Domain Admin
# Lancer le collecteur SharpHound
.\SharpHound.exe -c All --zipfilename bloodhound_data.zip

# Importer dans BloodHound et executer les requetes:
# "Shortest Paths to Domain Admins from Owned Principals"
# "Find All Paths from Domain Users to Domain Admins"

# PowerShell : lister les membres des groupes Tier 0
$tier0_groups = @("Domain Admins","Enterprise Admins","Schema Admins","Group Policy Creator Owners","BUILTIN\Administrators")
foreach ($g in $tier0_groups) {
    Get-ADGroupMember -Identity $g -Recursive | Select-Object Name, ObjectClass
}

Sécuriser l'Accès Distant aux Ressources Tier 0 : Bastion et Jump Server

Dans les environnements distribués avec plusieurs sites ou datacenters, l'accès distant aux ressources Tier 0 (DC, CA) doit transiter par un Jump Server (aussi appelé Bastion Host) dédié et durci. Ce serveur intermédiaire est la seule machine autorisée à initier des connexions RDP ou SSH vers les ressources Tier 0. Toutes les sessions sont enregistrées et auditées, et l'accès au Jump Server lui-même nécessite une authentification forte (MFA physique).

Les solutions PAM (Privileged Access Management) comme CyberArk, BeyondTrust ou Thales (anciennement Cipherstone) offrent des fonctionnalités avancées de bastioning avec enregistrement de sessions, rotation automatique des mots de passe et intégration avec les outils de ticketing ITSM. Ces solutions permettent d'implémenter le JIT natif sans développement custom, et sont particulièrement adaptées aux grandes organisations avec de nombreux administrateurs Tier 0.

# Configuration minimale d'un Jump Server Windows Server Tier 0
# 1. Windows Server 2022 Core (sans interface graphique = surface reduite)
# 2. Rejoindre le domaine mais dans un OU dedie avec GPO Tier 0
# 3. RDP activé uniquement depuis les PAW Tier 0 (via Windows Firewall GPO)
# 4. Credential Guard activé
# 5. Windows Defender Application Control (WDAC) en mode enforcement
# 6. Journaux de sessions RDP activés et envoyés au SIEM

# Verifier la configuration RDP du Jump Server
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name "fDenyTSConnections"

# Activer l'audit des sessions RDP
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Other Logon/Logoff Events" /success:enable

Délégation Administrative Fine sans Tier 0 : Les Groupes Administratifs Délégués

Le Tiering Model ne signifie pas que seuls les Domain Admins peuvent administrer Active Directory. Une bonne architecture de délégation permet de distribuer les tâches administratives à des groupes dédiés avec uniquement les droits nécessaires, réduisant le nombre de comptes Tier 0 au strict minimum :

• Groupe "Gestionnaires de Comptes" : peut créer, modifier et désactiver des comptes utilisateurs, mais pas les comptes admin ni les comptes machines
• Groupe "Gestionnaires de Groupes" : peut gérer les membres des groupes de sécurité non-admin
• Groupe "Opérateurs DNS" : peut créer et modifier des entrées DNS, mais pas modifier la structure d'AD
• Groupe "Opérateurs de Backup" : peut sauvegarder et restaurer des fichiers, mais pas lire les secrets LSASS

# Creer une delegation pour la gestion des comptes utilisateurs standard
$ou_path = "OU=Utilisateurs,DC=domaine,DC=local"
$delegation_group = Get-ADGroup "Gestionnaires-Comptes"

# Permettre la creation/modification de comptes utilisateurs dans l'OU
dsacls $ou_path /G "$($delegation_group.SID):CCDC;user" /I:T

# Permettre la modification du mot de passe
Set-ACL -Path "AD:\$ou_path" -AclObject (New-ADObjectAcl ... )

# Verifier les ACL delegues sur une OU
Get-Acl -Path "AD:\OU=Utilisateurs,DC=domaine,DC=local" | Select-Object -ExpandProperty Access | Where-Object {$_.IsInherited -eq $false}

Impact du Tiering Model sur la Productivité et la Résistance au Changement

L'un des principaux obstacles à l'implémentation du Tiering Model est la résistance des équipes IT habituées à utiliser un compte DA unique pour toutes leurs tâches quotidiennes. La nécessité de switcher entre plusieurs comptes et de passer par une PAW dédiée pour les tâches Tier 0 est perçue comme une contrainte. Cette perception est compréhensible mais doit être mise en perspective avec le risque réel.

Notre expérience sur le terrain montre que la résistance disparaît rapidement une fois que les équipes comprennent concrètement ce qu'un attaquant peut faire avec un compte DA compromis. Une simulation de compromission (ethical hacking interne ou red team) montrant comment un seul poste compromis peut aboutir à un DCSync complet est souvent le meilleur argument pour obtenir l'adhésion des équipes à l'implémentation du Tiering.

Du point de vue productivité, les outils modernes comme Remote Desktop Manager, CyberArk Privileged Session Manager, ou simplement une PAW bien configurée avec des raccourcis vers les outils admin rendent l'expérience utilisateur acceptable. L'investissement initial dans la configuration et la formation est compensé dès le premier incident évité.

Surveillance des Violations de Tier : Détection SIEM

La surveillance des tentatives de violation de tier est un indicateur de compromission précoce. Les événements à surveiller incluent :

• Connexion d'un compte Tier 0 sur une machine Tier 1 ou Tier 2 (événement 4624, filtré sur les comptes Tier 0)
• Utilisation de NTLM par un compte membre de Protected Users (indicateur d'attaque en cours)
• Tentative de connexion refusée d'un compte Tier 0 sur une machine Tier 1 (4625 avec des comptes admin) — peut indiquer une tentative de mouvement latéral

# KQL Microsoft Sentinel : detecter les connexions Tier 0 hors PAW
let tier0_accounts = dynamic(["jmartin-T0", "Administrator", "svc-backup"]);
let paw_computers = dynamic(["PAW-TIER0-01", "PAW-TIER0-02"]);
SecurityEvent
| where EventID == 4624
| where Account in (tier0_accounts)
| where Computer !in (paw_computers)
| where LogonType in (2, 3, 10)  // Interactive, Network, RemoteInteractive
| project TimeGenerated, Account, Computer, IpAddress, LogonType
| sort by TimeGenerated desc

Micro-Segmentation Réseau Alignée sur le Tiering Model

Le Tiering Model ne se limite pas aux comptes et aux politiques GPO : il doit être reflété dans l'architecture réseau. La micro-segmentation réseau aligne les VLAN et les règles de firewall sur les niveaux du Tiering Model :

• VLAN Tier 0 : VLAN dédié aux DC, ADFS, AD CS et autres assets Tier 0. Les connexions entrantes n'autorisent que les protocoles d'administration nécessaires (RDP depuis les PAW Tier 0 uniquement, LDAP/Kerberos depuis les serveurs Tier 1/2).
• VLAN PAW : VLAN dédié aux PAW. Connexions sortantes uniquement vers les DC et les outils d'administration. Aucune connexion Internet.
• VLAN Tier 1 : Serveurs applicatifs. Connexions autorisées depuis les PAW Tier 1, et vers les ressources Tier 2 pour les services métier.
• VLAN Tier 2 : Postes utilisateurs. Accès aux ressources Tier 1 (serveurs applicatifs) mais AUCUN accès direct aux ressources Tier 0.

Cette segmentation réseau est complémentaire aux GPO de restriction : même si un attaquant parvient à contourner une GPO via une technique avancée, la segmentation réseau empêche les connexions directes aux ressources Tier 0 depuis les machines Tier 2. La double barrière (logique via GPO + physique via VLAN) est le principe de défense en profondeur appliqué au Tiering.

Tiering Model et Systèmes Hérités : Gérer les Exceptions

La réalité des grands SI est que certaines applications legacy nécessitent des droits d'administration élevés et ne peuvent pas être facilement intégrées dans un Tiering Model strict. La gestion de ces exceptions doit être documentée, limitée dans le temps (plan de migration), et compensée par des contrôles alternatifs :

• Isolation réseau renforcée de l'application legacy (VLAN dédié)
• Monitoring intensif des connexions vers/depuis ces systèmes
• Revue trimestrielle des exceptions pour vérifier si elles peuvent être résolues
• Plan de migration documenté avec jalons et responsables

Contrairement aux idées reçues, le Tiering Model n'est pas un projet tout-ou-rien qui nécessite une transformation radicale du SI avant de produire ses premiers effets. Chaque amélioration partielle réduit la surface d'attaque de manière significative, et une implémentation à 70% est infiniment préférable à l'absence de séparation. L'ANSSI recommande explicitement une approche itérative plutôt qu'un projet waterfall qui pourrait s'étirer sur plusieurs années sans produire de bénéfices intermédiaires. La pragmatique recommandée est de commencer par les mesures à fort impact et faible effort (Protected Users, comptes dédiés Tier 0, GPO de restriction), puis de progresser vers les mesures plus complexes (PAW, JIT) sur 6 à 12 mois selon la taille et les ressources de l'organisation.

Un système legacy particulièrement problématique est le SCCM (System Center Configuration Manager) / Microsoft Endpoint Configuration Manager. SCCM nécessite des droits d'admin local sur toutes les machines qu'il gère, ce qui en fait mécaniquement un asset Tier 0 dans de nombreuses organisations. La remédiation passe par la mise en place du mode CMG (Cloud Management Gateway) ou la restriction stricte des droits d'accès SCCM via des collections et des scopes d'administration limités. Si SCCM ne peut pas être retiré du Tier 0, il doit au moins être traité comme tel en termes d'accès et de monitoring.

Interaction Tiering Model et Entra ID / Azure

Dans les environnements hybrides, le Tiering Model doit être étendu au cloud de manière cohérente. Le Tier 0 cloud inclut les rôles Global Admin, Privileged Role Admin, Exchange Admin et User Admin dans Entra ID. Ces rôles doivent être gouvernés via PIM (Privileged Identity Management) avec activation JIT, MFA physique (FIDO2) et approbation par un pair pour les rôles les plus sensibles.

La cohérence entre le Tiering on-premises et le Tiering cloud est critique car les deux environnements sont liés via Entra Connect. Un compte Tier 0 cloud qui se connecte à une machine Tier 2 on-premises peut exposer ses tokens cloud (Primary Refresh Tokens, access tokens Microsoft Graph) à un attaquant ayant compromis ce poste. Ces tokens cloud peuvent être utilisés pour accéder aux ressources Microsoft 365 et Azure avec les droits du compte, indépendamment de l'état de l'AD on-premises. La cohérence du Tiering entre les deux environnements est donc une exigence absolue dans les architectures hybrides.

Les outils permettant d'identifier les comptes hybrides mal classifiés (par exemple, un compte Tier 0 on-premises synchronisé vers un tenant Entra ID sans PIM activé) incluent BloodHound Azure (AzureHound), ROADtools et Microsoft Graph Explorer. Un audit semestriel des comptes hybrides et de leur classification Tier est recommandé pour maintenir la cohérence au fil des évolutions de l'infrastructure. L'article de référence sur le bilan des attaques AD en 2025 illustre comment ces vecteurs hybrides ont été exploités dans des incidents réels, confirmant l'importance d'étendre le Tiering au-delà de l'AD on-premises.

Pour les PME qui utilisent Azure AD DS (Active Directory Domain Services) managé par Microsoft, les principes du Tiering Model s'appliquent différemment : les administrateurs du domaine managé ont des droits limités par conception (pas d'accès aux DC directement), mais les comptes membres du groupe "AAD DC Administrators" doivent tout de même être traités comme des comptes Tier 0 avec les protections correspondantes (MFA fort, PIM, Conditional Access restrictif).

Tiering Model et Reprise Après Sinistre : Planification PCA/PRA

Le Tiering Model doit être intégré dans la planification de reprise après sinistre (PCA/PRA) de l'organisation. En cas de compromission de la forêt Active Directory, la procédure de reconstruction doit respecter l'ordre des tiers : reconstruire d'abord le Tier 0 (DC, CA) dans un environnement isolé, valider l'intégrité avant de restaurer le Tier 1, puis le Tier 2. Cette approche évite de recontaminer un DC sain depuis des backups de serveurs Tier 1 ou Tier 2 potentiellement compromis.

Les sauvegardes des systèmes Tier 0 doivent être stockées séparément, avec une protection renforcée (chiffrement, accès restreint aux seuls comptes Tier 0, rotation régulière des clés de chiffrement). Un backup de DC conservé dans le même espace de stockage que les backups de serveurs applicatifs et accessible avec les mêmes credentials est une vulnérabilité majeure que le Tiering doit corriger.

PingCastle et BloodHound : Mesurer la Maturité du Tiering

Deux outils sont particulièrement utiles pour mesurer objectivement la maturité d'une implémentation Tiering :

• PingCastle : génère un score de sécurité AD de 0 à 100 (100 = risque maximal) avec des tests spécifiques sur les comptes admin, les chemins d'attaque, la configuration des groupes privilégiés et les violations de politiques. Disponible gratuitement pour les organisations non commerciales.
• BloodHound : cartographie graphiquement les chemins d'attaque dans l'AD via des relations de confiance, permissions et délégations. Permet de visualiser concrètement combien de clics séparent un compte utilisateur standard des Domain Admins — et donc de mesurer l'efficacité du Tiering en termes de réduction des chemins d'attaque.

# PingCastle : audit complet de securite AD
PingCastle.exe --healthcheck --server dc01.domaine.local

# BloodHound : collecte des donnees (SharpHound)
.\SharpHound.exe -c All --zipfilename bloodhound_$(Get-Date -Format yyyyMMdd).zip

# Requetes BloodHound utiles pour evaluer le Tiering :
# - "Shortest Paths to Domain Admins from Computers" : combien de sauts depuis une machine ?
# - "Find All Paths from Domain Users to Domain Admins" : chemins disponibles
# - "Computers with Unsupported Operating Systems" : machines legacy dans le scope
# - "Users with Foreign Domain Group Membership" : risques de confiance inter-domaine

Outils Microsoft pour Implémenter le Tiering Model

Microsoft fournit plusieurs outils et ressources pour aider à l'implémentation du Tiering Model :

• MDCA (Microsoft Defender for Cloud Apps) : surveillance des activités admin dans les applications cloud
• Microsoft Defender for Identity (MDI) : détection comportementale des attaques AD, inclut des alertes sur les violations de tier
• PIM (Privileged Identity Management) : gestion JIT des rôles Entra ID
• Enterprise Access Model : la documentation Microsoft mise à jour en 2025 décrit le modèle actualisé

Tiering Model et Authentification Sans Mot de Passe

En 2026, l'authentification sans mot de passe (Passwordless) s'impose comme l'évolution naturelle du Tiering Model pour les comptes Tier 0. Les technologies disponibles incluent Windows Hello for Business (biométrie ou PIN lié au TPM), les clés FIDO2/passkeys (YubiKey, clés Titan), et les certificats sur smartcard.

L'utilisation d'une clé FIDO2 pour les comptes Tier 0 offre plusieurs avantages sur le Tiering : la clé physique ne peut pas être volée à distance (elle doit être présente physiquement), elle résiste aux attaques de phishing et de relay MFA, et elle génère des événements d'authentification facilement traçables. Notre recommandation est que tous les comptes Tier 0 utilisent une authentification FIDO2 d'ici fin 2026.

Consultez notre analyse des 10 attaques Active Directory les plus critiques pour comprendre pourquoi le Tiering Model est la défense architecturale la plus efficace contre ces vecteurs.

Tiering Model et Audit de Conformité

Le Tiering Model est de plus en plus référencé dans les cadres d'audit de conformité. Les référentiels ISO 27001 (contrôle A.9.2.3 sur les droits d'accès privilégiés), NIS 2 (mesures de sécurité pour les systèmes critiques), et les Exigences de Sécurité Opérationnelle (ESO) de l'ANSSI mentionnent explicitement la nécessité de ségrégation des accès administratifs.

Lors d'audits ISO 27001, les auditeurs vérifient régulièrement : l'existence d'une politique de gestion des accès privilégiés, la séparation des comptes admin des comptes utilisateurs standard, et la traçabilité des actions admin. Le Tiering Model fournit un cadre documentaire solide pour répondre à ces exigences. Pour approfondir la relation entre Tiering et conformité, consultez notre article sur le durcissement Active Directory 2026.

AdminSDHolder et sdProp : La Protection des Comptes Sensibles

AdminSDHolder est un objet Active Directory qui définit un template de permissions (Security Descriptor) appliqué automatiquement à tous les comptes membres des groupes protégés (Domain Admins, Enterprise Admins, Schema Admins, etc.). Toutes les heures, le processus sdProp (Security Descriptor Propagator) vérifie et remet à l'identique les permissions de ces comptes selon le template AdminSDHolder, annulant toute modification manuelle effectuée entre-temps.

Ce mécanisme est à double tranchant : il protège les comptes admin contre des modifications non autorisées de leurs permissions, mais il signifie aussi que si l'AdminSDHolder lui-même est modifié par un attaquant, toutes les ACL des comptes protégés seront corrompues de manière persistante toutes les heures. C'est pourquoi l'AdminSDHolder doit lui-même être traité comme un asset Tier 0 et être surveillé pour toute modification.

# Verifier les ACL de l'AdminSDHolder
Get-Acl -Path "AD:\CN=AdminSDHolder,CN=System,DC=domaine,DC=local" | Select-Object -ExpandProperty Access | Where-Object {$_.IsInherited -eq $false}

# Surveillance des modifications de l'AdminSDHolder (evenement 5136)
# Surveiller les modifications sur l'objet CN=AdminSDHolder dans le SIEM

# Verifier quels comptes ont l'attribut adminCount=1 (proteges par AdminSDHolder)
Get-ADUser -Filter {adminCount -eq 1} -Properties adminCount | Select-Object Name, DistinguishedName
Get-ADGroup -Filter {adminCount -eq 1} -Properties adminCount | Select-Object Name

Credential Tiering dans Active Directory Certificate Services

Un aspect souvent négligé du Tiering Model est l'intégration des Active Directory Certificate Services (AD CS). Les Certificate Authorities (CA) font partie du Tier 0 car un attaquant qui contrôle une CA peut émettre des certificats pour n'importe quel compte du domaine, permettant l'authentification Kerberos PKINIT sans connaître le mot de passe.

Les mesures de Tiering spécifiques à AD CS incluent :

• Héberger la CA racine sur une machine offline (root CA) qui n'est jamais connectée au réseau
• Utiliser des CA subordonnées en ligne (issuing CA) pour l'émission courante, réduisant l'impact d'une compromission
• Appliquer EPA sur le Web Enrollment d'AD CS pour bloquer ESC8
• Auditer régulièrement les templates de certificats avec Certipy pour détecter ESC1-ESC13
• Limiter les droits d'enrollment aux seuls groupes qui en ont besoin

Formation et Sensibilisation : La Dimension Humaine du Tiering

La technique seule ne suffit pas : le Tiering Model ne sera efficace que si les administrateurs comprennent son principe et respectent les règles au quotidien. Un programme de formation dédié doit couvrir les scénarios d'attaque que le Tiering protège, les comportements interdits (utiliser un compte DA pour accéder à Internet, depuis un poste standard), et les procédures d'urgence si un compte Tier 0 est suspecté de compromission.

Les violations involontaires du Tiering sont fréquentes au début de l'implémentation : un administrateur qui "vérifie rapidement" quelque chose depuis son poste standard avec son compte DA, ou qui utilise RDP depuis un poste Tier 2 vers un DC "pour gagner du temps". Ces violations, même involontaires, créent des fenêtres d'attaque. Les alertes SIEM sur les violations de tier ont autant une fonction de sécurité que de coaching comportemental pour les équipes en phase de transition.

Cas Pratique : Tiering Model dans une ETI de 1000 Personnes

Pour illustrer l'implémentation concrète, voici l'approche que nous avons suivie lors d'une mission pour une ETI industrielle française de 1000 collaborateurs avec 3 sites géographiques :

Lors de la cartographie initiale, nous avons identifié 47 assets Tier 0 (vs 4 DC théoriques que l'équipe IT pensait être les seuls assets critiques) incluant notamment le serveur SCCM qui avait des droits d'admin local sur toutes les machines du domaine, et le serveur de backup qui contenait des snapshots des DC avec les hashes NTLM. La découverte de la vraie surface Tier 0 a été une révélation pour l'équipe IT.

La priorisation des actions a conduit à traiter en premier le serveur SCCM (réduction des droits au minimum nécessaire via les scopes d'administration SCCM) et le serveur backup (chiffrement des sauvegardes et restriction des accès), avant même de créer des comptes dédiés Tier 0 — car ces deux systèmes représentaient les chemins d'attaque les plus simples vers un contrôle total du domaine. Cette approche pragmatique a réduit le score de risque PingCastle de 87 à 34 en trois mois, une amélioration significative obtenue sans disruption des opérations quotidiennes. Le budget total de la mission de conseil et d'implémentation représentait moins de 15% du coût estimé d'un incident de compromission du domaine — un argument financier décisif pour convaincre la direction générale d'approuver les travaux.

La phase suivante de cette mission a porté sur la création des comptes Tier 0 dédiés pour les 4 administrateurs AD de l'ETI, le déploiement de 2 PAW Tier 0 physiques (un laptop durci par site principal), et l'activation du groupe Protected Users pour tous les comptes Tier 0. Ces mesures, combinées, ont éliminé les 3 chemins d'attaque critiques identifiés par BloodHound lors de la cartographie initiale.

Foire Aux Questions sur le Tiering Model Active Directory