Dans l’article Sécuriser Active Directory avec le Tiering Model, nous avons vu comment mettre en place une structure Tiering Active Directory pour mieux organiser et isoler les différents environnements (T0, T1, T2).
Comme indiqué, cette première étape ne suffit pas : pour que le modèle soit réellement efficace, il est nécessaire d’appliquer une sécurisation adaptée aux unités d’organisation et de protéger les objets qu’elles contiennent.
Dans cet article, nous allons voir comment :
- Sécuriser les OU du Tiering Model.
- Appliquer des GPO afin de limiter l’accès et protéger les comptes à privilèges contre les compromissions.
1. Sécurisation des OU
Principe
Chaque OU doit être protégée afin que seuls les administrateurs du tier concerné puissent :
- créer, modifier ou supprimer des objets (utilisateurs, ordinateurs, serveurs, services, etc.)
- gérer les délégations de droits et permissions.
Ainsi :
- Les administrateurs T0 (Privileged) gèrent uniquement les ressources critiques.
- Les administrateurs T1 (Secured) gèrent uniquement les serveurs applicatifs.
- Les administrateurs T2 (Managed) gèrent uniquement les postes de travail et comptes utilisateurs.
Si votre annuaire est multi-site, la sécurisation doit être appliquée indépendamment sur chaque site.
Procédure : Sécurisation des OU
- Ouvrir la console Active Directory Users and Computers (ADUC).
- Activer l’option Advanced Features dans le menu affichage.
- Pour chaque OU (T0, T1, T2) :
- Clic droit → Properties.
- Onglet Security.
- Ajouter le groupe d’administrateurs du Tier correspondant (ex. T1-Admins) avec les droits de gestion necessaires
- Create/delete Computer objects (This object and all descendant objects)
- Create/delete Group objects (This object and all descendant objects)
- Create/delete User objects (This object and all descendant objects)
- Full Control (Descendant Computer objects)
- Full Control (Descendant Group objects)
- Full Control (Descendant User objects)
- Vérifier que les autres groupes n’ont pas de droits excessifs.
Résultat :
Chaque OU est isolée, seuls les administrateurs du bon Tier ont la capacité de gérer les objets de leur périmètre.
2. GPO : Limitation d’accès & protection des comptes à privilèges
Principe
Un des points critiques du Tiering Model est d’éviter que les administrateurs d’un Tier puissent agir sur un autre Tier.
Exemple :
- Un administrateur T2 (poste de travail) ne doit pas avoir la possibilité d’administrer un serveur T1.
- Un administrateur T0 (domaine) ne doit jamais se connecter sur un poste T2, au risque d’exposer son hash de mot de passe en cas de compromission de la machine.
Pour cela, il est nécessaire de créer des GPO spécifiques appliquées aux OU principales.
Procédure : Création des GPO
- Ouvrir la console Group Policy Management (GPMC).
- Créer une nouvelle GPO pour chaque niveau (T0, T1, T2).
- Lier chaque GPO à l’OU correspondante (T0 – PRIVILEGED, T1 – SECURED, T2 – MANAGED).
- Configurer les paramètres suivants :
a) Restreindre l’accès aux comptes à privilèges
- Accéder à :
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment. - Modifier les stratégies :
- Deny log on locally
- Deny log on through Remote Desktop Services
- Ajouter les groupes administratifs des autres Tiers.
b) Sécuriser l’utilisation des comptes
- Dans la même GPO, limiter :
- Allow log on locally → uniquement les administrateurs du Tier correspondant.
- Allow log on through RDP → uniquement les administrateurs du Tier correspondant.
Résultat :
- Un administrateur T0 ne peut pas se connecter sur un poste T2.
- Un administrateur T1 ne peut pas gérer des postes ou serveurs hors de son périmètre.
- Les administrateurs T2 n’ont aucun impact sur les environnements critiques.
La mise en place du Tiering Model n’est réellement efficace que si elle est accompagnée d’une sécurisation stricte des OU et des accès.
- La sécurisation des OU garantit que chaque administrateur agit uniquement sur son périmètre.
- Les GPO de restriction d’accès empêchent la compromission des comptes à privilèges par exposition de leurs mots de passe.
Ces mesures constituent une seconde étape indispensable après la création de la structure. Dans un prochain article, nous aborderons la logique du moindre privilège et la mise en place d’un modèle où chaque administrateur dispose d’un accès spécifique par serveur ou poste de travail, afin de réduire encore davantage les risques de compromission.