I. Présentation
Dans cet article, nous allons voir comment déléguer les droits et attribuer des permissions sur les GPOs à d’autres membres que les administrateurs du domaine.
Cela permet à certaines équipes de gérer et modifier les GPOs appartenant à leur service ou périmètre, de la même manière que l’on peut déléguer des droits dans Active Directory.
II. Pourquoi déléguer les permissions sur les GPOs ?
Bien que la délégation des droits de modification et de création des GPOs ne soit pas courante en raison des risques et de l’impact potentiels, elle peut s’avérer utile dans les entreprises de taille moyenne à grande. Comme pour la délégation de droits dans Active Directory (exemple : réinitialisation des mots de passe par le service helpdesk), accorder des permissions sur les GPOs à des équipes qualifiées (ingénieurs poste de travail, ingénieurs applicatifs, DBA, sécurité, etc.) peut représenter un réel avantage.
Si ces équipes ont besoin d’effectuer des modifications régulières, leur donner un accès contrôlé permet :
Un gain de temps pour les administrateurs du domaine, qui n’auront plus à gérer chaque demande de validation et de création de GPOs.
Un suivi et une traçabilité des modifications.
Une gestion plus agile des stratégies de groupe, tout en gardant le contrôle via une supervision adéquate.
A. Un peu d’histoire
Par le passé, Microsoft avait développé AGPM (Advanced Group Policy Management), une solution permettant de gérer les permissions et la délégation sur les GPOs. Bien que pratique, AGPM était complexe à mettre en place et son adoption a été limitée. Avec l’évolution vers des interfaces web et des outils modernes, Microsoft a finalement abandonné cette solution. Aujourd’hui, il ne reste que des solutions tierces ou des méthodes de délégation manuelles, que nous allons explorer dans cet article.
B. Déléguer les autorisations sur les GPO
Par défaut, les utilisateurs du domaine disposent uniquement de droits en lecture sur les GPOs, tandis que les administrateurs du domaine ont un contrôle total.
Pour déléguer des droits à un utilisateur ou à un groupe, il suffit de l’ajouter via l’onglet « Délégation » dans la console de Gestion des stratégies de groupe (GPMC). Comme bonne pratique, il est préférable d’utiliser un groupe de sécurité plutôt qu’un utilisateur individuel. Dans notre exemple, nous utiliserons le groupe « PDT_GPO_Edit » (Poste de Travail _ GPO _ Modification).
Au niveau de votre GPO, cliquez sur « Ajouter » à partir de l’onglet « Délégation ».
Dans la fenêtre qui s’affiche, entrez le nom de votre groupe et choisissez le niveau de droit souhaité puis, validez par OK.
Le groupe apparaît désormais dans la liste des délégations.
Les membres du groupe concerné peuvent maintenant modifier la GPO depuis leur machine d’administration, à condition d’avoir installé les outils RSAT.
A titre d’exemple, pour installer les outils RSAT sur Windows 11, vous pouvez suivre ce tutoriel :
C. Déléguer la création et la liaison des GPOs sur une OU
Il peut être plus pratique de déléguer la gestion des GPOs sur une Unité Organisationnelle (OU) plutôt que sur des GPOs individuelles. Cependant, il est important de noter qu’il n’existe pas réellement de délégation sur une OU pour la gestion des GPOs.
Deux actions sont nécessaires pour permettre à un groupe de gérer les GPOs sur une OU spécifique :
Autoriser la création de GPOs → Cette permission s’applique sur l’ensemble des objets GPOs.
Autoriser la liaison de GPOs → Cette permission s’applique sur une OU spécifique.
Note : Accorder ces droits sans contrôle peut être risqué ! Un utilisateur mal informé peut créer une GPO et l’appliquer à un groupe sans la lier à une OU, ce qui peut entraîner des dysfonctionnements.
Déléguer la création et la liaison des GPOs sur une OU :
Ouvrez la console GPMC, puis accédez à « Objets de stratégie de groupe ». Cliquez ensuite sur le bouton « Ajouter », puis entrez le nom du groupe concerné.
Déléguer le droit de lier des GPOs sur une OU :
Retournez sur l’OU concernée dans GPMC, en accédant à l’onglet « Délégation », cliquez sur « Ajouter ».
Sélectionnez le groupe et assurez-vous d’attribuer l’autorisation « Lier des objets GPO ».
Cliquez sur « OK » pour valider.
Notre groupe a bien été ajouté. Il suffit de sélectionner l’autorisation en question pour le vérifier.
Les membres du groupe peuvent maintenant lier les GPOs à leur OU sans avoir besoin d’un administrateur.
Option : Autoriser uniquement la liaison des GPOs
Il est également possible de limiter les permissions du groupe en lui accordant uniquement le droit de lier une GPO à son OU, sans lui permettre d’en créer. La création des GPOs peut ainsi être réservée aux administrateurs système, permettant une meilleure répartition des tâches. Dans notre exemple, le groupe « PDT_GPO_Edit » se chargera uniquement de vérifier que les paramètres des GPOs demandées sont conformes, puis de les lier à l’OU concernée ou de les désactiver en cas de problème. Il pourra également ajuster le ciblage en appliquant des filtres sur des utilisateurs ou des groupes spécifiques.
Pour affiner ces permissions, accédez aux paramètres avancés de votre OU en cliquant deux fois sur « Avancé », puis ajoutez les autorisations nécessaires via l’onglet « Autorisations ».
Sélectionnez « Objets GroupPolicyContainer descendants », puis cochez les droits correspondant précisément à votre besoin. Cette approche permet d’affiner la délégation des permissions, en définissant des autorisations spécifiques, comme la modification des sous-OUs ou la lecture de certains paramètres, par exemple, pour restreindre qui peut lier une GPO.
Cependant, il est important de noter que ces permissions n’affectent en aucun cas l’application des paramètres des GPOs. Elles ne peuvent ni empêcher ni limiter leur déploiement sur les objets auxquels elles sont assignées.
D. Les bonnes pratiques
Avant de conclure, voici un ensemble de bonnes pratiques à respecter.
Ne pas accorder un contrôle total (CT) inutilement : Certaines entreprises accordent par défaut un contrôle total sur les OUs ou sur les GPOs elles-mêmes, ce qui est rarement nécessaire. Il vaut mieux accorder uniquement les permissions strictement requises.
Activer l’audit des GPOs : Cela permet de tracer les créations, modifications et liaisons de GPOs pour assurer un suivi rigoureux des changements.
Éviter la délégation sur les OUs sensibles : Ne déléguez jamais la gestion des GPOs sur des OUs critiques comme Users, Domain Controllers ou Builtin, car cela peut compromettre la sécurité du domaine.
Restreindre la création de GPOs aux admins qualifiés : Il est préférable de limiter la création de GPOs aux administrateurs de niveau 3 ou aux équipes T1/T0 qualifiées, afin de s’assurer que les politiques sont bien conçues et maîtrisées.
Travailler avec un environnement de préproduction : Tester les GPOs en préproduction permet de limiter les erreurs en production. Une fois validées, les paramètres peuvent être exportés et appliqués en production, sans nécessité de déléguer trop de droits aux équipes.
III. Conclusion
Avec l’évolution des écosystèmes IT, la spécialisation des équipes et l’extension des périmètres (SecOps, DevOps, poste de travail, administration système, sécurité, etc.), le modèle traditionnel où l’administrateur système gérait tout devient obsolète. Il est désormais courant de voir les tâches se répartir et certaines responsabilités être déléguées pour optimiser la gestion des infrastructures.
Cet article avait pour objectif d’encadrer cette délégation des droits sur les GPOs afin d’apporter une approche sécurisée et organisée. Si vous êtes amené à mettre en place une telle délégation, ces bonnes pratiques vous permettront d’éviter toute confusion et de garantir une gestion efficace et maîtrisée des stratégies de groupe.
Consultant et formateur expert Windows Server et Cloud Azure. Chercheur en Cybersécurité.