Active Directory Tiered Admin Model : construire des tiers qui tiennent (d'ESAE à RAMP)

Qu'est-ce que l'Active Directory Tiered Admin Model

L'Active Directory Tiered Admin Model est l'architecture de sécurité qui empêche un attaquant ayant compromis un poste du help-desk de rejoindre directement Domain Admin. Il répartit chaque identité, poste de travail et serveur en niveaux de confiance — Tier 0 (le plan de contrôle de l'identité lui-même), Tier 1 (serveurs et applications métier) et Tier 2 (postes utilisateurs et comptes standards) — et impose une règle dans les deux sens : les identifiants d'un tier supérieur ne doivent jamais être exposés à un tier inférieur, et les identifiants d'un tier inférieur ne doivent jamais pouvoir contrôler un tier supérieur (Microsoft Learn, AD DS Tier Model).

La plupart des environnements qui prétendent exploiter un modèle en tiers ne l'appliquent pas réellement. Des Domain Admins font du RDP sur des serveurs membres pour « juste vérifier un truc ». Une GPO du service desk de Tier 1 est liée une OU trop haut et atterrit sur l'OU des contrôleurs de domaine. Un compte break-glass reste hors du groupe Protected Users parce que personne n'a pensé à l'y ajouter. Chacun de ces écarts est petit pris isolément ; ensemble, ils font s'effondrer la frontière entre tiers que le modèle est censé protéger — exactement le type de dérive des accès privilégiés qui se réinstalle après un durcissement tant que rien ne revérifie en continu.

Se tromper sur cette frontière coûte cher, car une compromission de Tier 0 n'est pas un incident localisé — elle est totale. Un attaquant qui obtient un identifiant Tier 0 (via un logon cross-tier, une GPO mal cadrée, ou un compte oublié hors de Protected Users) peut généralement faire un DCSync de l'annuaire entier et forger des tickets Kerberos pour n'importe quelle identité du domaine. Le modèle en tiers existe précisément pour contenir ce résultat à une brèche Tier 0, plutôt que de laisser un simple poste de helpdesk compromis se transformer en cette brèche.

Des OU à l'application concrète : comment le tiering fonctionne réellement

Le tiering n'est pas un schéma — c'est une structure d'OU, un ensemble de GPO à la portée bien définie, et une frontière stricte sur les postes où les comptes privilégiés peuvent ouvrir une session interactive.

Structure des OU

Les actifs Tier 0 (contrôleurs de domaine, AD FS, serveurs PKI/ADCS, infrastructure de sauvegarde capable de restaurer un DC, ainsi que les comptes et groupes qui les administrent) vivent dans une arborescence d'OU Tier 0 dédiée, séparée des serveurs Tier 1 et des postes Tier 2. La délégation et les liaisons de GPO suivent la même frontière — une GPO de durcissement des postes Tier 2 ne doit jamais être liée à proximité de l'OU Tier 0, et inversement (Microsoft Community Hub, Initially Isolate Tier 0 Assets with Group Policy).

Privileged Access Workstations (PAW)

Les comptes admin Tier 0 ne devraient pouvoir ouvrir une session interactive que sur un petit ensemble dédié de postes Tier 0 — des PAW rattachées à leur propre OU, avec des GPO de durcissement (pas de navigation internet, pas de messagerie, allow-listing d'applications) cantonnées exclusivement à cette OU (Microsoft Learn, PAW legacy guidance). C'est l'application concrète de la règle n° 1 : si un identifiant Tier 0 peut s'authentifier sur un poste Tier 1 ou Tier 2, la frontière est déjà rompue, quel que soit ce qu'affirment l'organigramme ou le schéma du wiki.

Discipline de portée des GPO

Ne liez les GPO de durcissement qu'à l'OU du tier concerné — jamais à la racine du domaine, jamais à la Default Domain Policy. Lier une GPO à travers plusieurs OU de tiers différents est l'une des façons les plus courantes dont les frontières entre tiers s'érodent silencieusement au fil des mois, car personne ne remarque l'ajout d'une liaison comme il remarquerait un nouveau compte admin.

Détection : repérer les violations de tier avant qu'elles ne soient exploitées

Une violation de tier n'est pas un événement isolé — c'est un motif où une identité privilégiée ou une liaison de GPO apparaît là où elle ne devrait pas. Construisez vos détections autour de ces signaux :

Pourquoi l'Event ID 4672 est le signal à haute fiabilité

L'Event ID 4672 (« privilèges spéciaux attribués à un nouveau logon ») se déclenche immédiatement après un 4624 réussi pour tout compte disposant de droits équivalents admin, et son Logon ID est la clé de jointure sur tout le cycle de vie de la session — 4624 → 4672 → activité → 4634/4647 (Microsoft Learn, Event 4672). Sur un poste où un Domain Admin ne devrait jamais ouvrir de session interactive, un seul 4672 pour ce compte est une alerte à haute fiabilité et à faible effort — pas besoin d'outillage UEBA pour attraper le cas évident, juste la bonne règle de corrélation sur la bonne portée d'OU.

Remédiation : construire des tiers qui tiennent

1. Déplacez les comptes privilégiés dans une OU d'admin Tier 0 dédiée. C'est le contrôle que l'ANSSI cite directement — des comptes adminCount=1 vivant hors d'une OU dédiée et strictement déléguée cassent la segmentation dont dépend le reste du modèle (ANSSI-PA-099, « Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory », oct. 2023).

2. Ajoutez tous les comptes Tier 0 à Protected Users. Cela bloque l'authentification NTLM, le chiffrement Kerberos DES/RC4, la délégation unconstrained/constrained et les TGT longue durée pour ces comptes — fermant plusieurs des chemins de vol d'identifiants que les lacunes de délégation exposent.

3. Appliquez une Fine-Grained Password Policy sur les groupes Tier 0. Les Domain et Enterprise Admins ne devraient pas hériter de la politique de mot de passe par défaut du domaine ; une PSO dédiée, avec des exigences de longueur et de rotation plus strictes, limite le rayon d'impact si un identifiant Tier 0 est malgré tout exposé.

4. Cantonnez strictement chaque GPO à son OU de tier. Auditez les liaisons de GPO existantes pour repérer tout ce qui touche à la fois une OU Tier 0 et une OU Tier 1/2, et séparez-les. N'ajoutez jamais de paramètres d'application du tiering à la Default Domain Policy — créez des GPO dédiées et liez-les uniquement à l'OU de tier concernée.

5. Déployez des PAW pour le logon interactif Tier 0, puis appliquez-le techniquement. Utilisez des GPO de droits de logon (Deny log on locally / Deny log on through Remote Desktop Services) sur les actifs Tier 1/2 pour les comptes Tier 0, pas seulement de la documentation de politique — une règle écrite que personne ne peut violer techniquement ne survit pas à un incident.

6. Refaites la baseline trimestriellement, pas une seule fois. Les frontières entre tiers dérivent au fil du travail admin courant — un nouvel admin serveur ajouté au mauvais groupe, une GPO reliée pendant une migration, ou des comptes privilégiés obsolètes que personne n'a désactivés depuis Tier 0. Un projet de tiering ponctuel sans audit récurrent redégénère en administration à plat en moins d'un an ; voir le guide plus large des priorités de durcissement pour la place de ce sujet dans une séquence de durcissement AD plus complète, et les recommandations ANSSI en pratique pour la checklist complète orientée conformité dont ce modèle fait partie.

Comment EtcSec détecte cela

L'audit Active Directory d'EtcSec vérifie les violations du modèle en tiers directement sur votre annuaire en production : ANSSI_R15_TIER_MODEL_VIOLATION signale les comptes privilégiés hors d'une OU d'admin dédiée, ANSSI_R40_NO_PSO_TIER0 signale les groupes Tier 0 sans Fine-Grained Password Policy, ANSSI_R86_ADMIN_FOREST_SEGREGATION vérifie la ségrégation de confiance de la forêt d'administration lorsqu'elle est utilisée, NOT_IN_PROTECTED_USERS signale les comptes privilégiés absents du groupe Protected Users, et EXCESSIVE_PRIVILEGED_ACCOUNTS signale les frontières de tier devenues trop larges pour être auditées manuellement.