A propos des GPO (Group Policy Object)

Les GPO sont une méthode de gestion de configuration du parc de postes de travail et de serveurs. Elles permettent de définir une configuration cible de sécurité et d’installation pour l’ensemble du parc.

Le fonctionnement des GPO se base principalement sur le client GPO qui tourne sur toutes les machines Windows, poste utilisateur ou bien serveur. Le serveur Active Directory ne sert que de stockage pour les GPO. C’est pour cela qu’il est possible de définir n’importe quelle GPO Windows sur un Samba-AD, car le Samba-AD ne fait que les stocker, un peu comme le ferait un serveur de fichiers.

Il existe des implémentations très partielles de clients GPO pour les environnements Linux. Toutefois la plupart des modèles de GPO qui sont proposés dans la console de Gestion des Stratégies de Groupe ne seront pas pris en compte par les client GPO Linux. Si l’on affecte une GPO à un client qui ne peut pas l’interpréter, la GPO sera alors ignorée.

Le contrôleur de domaine Samba-AD ne prend pas en compte les GPO qui pourraient lui être affectées. Il prend par contre en compte les objets PSO qui définissent les stratégies de mot de passe.

Du point de vu d’un administrateur Windows, les GPO avec Samba-AD se comportent à l’identique d’un contrôleur de domaine MS-AD. La console Gestion des Stratégies de Groupe se lance à l’identique sur le poste de l’administrateur, et les GPO s’appliquent à l’identique sur tous les postes Windows du domaine.

Anatomie d’une GPO

Une GPO est constituée de trois composantes :

Une entrée LDAP GPO situé sous CN=Policies,CN=System,DC=ad,DC=tranquil,DC=it dans la partition principale de l’AD, qui contient le nom, le GUID, ainsi que les droits d’édition de la GPO (notamment s’il y a une délégation de droits). En gros ce sont les informations administratives ;
Le contenu de la GPO qui se trouve dans le partage SYSVOL, qui contient dans un répertoire dont le nom est le GUID, plusieurs fichiers d’instructions. En gros c’est ce que va faire la GPO.
Un attribut gPLink affecté à une UO, ou bien à un site AD, qui définit à quels objets la GPO va s’appliquer.

Les droits sur les fichiers contenus dans le partage SYSVOL sont très importants pour que la GPO soit acceptée par le client GPO et pour qu’elle s’applique. Si les droits ne sont pas corrects, le client GPO refusera de l’appliquer.

Les GPO utilisateurs et les GPO machines

Chaque GPO est constituée de deux parties distinctes qui s’appliquent à deux types d’objet distincts. Ainsi dans une GPO on peut configurer :

Des paramètres machines qui s’appliqueront uniquement aux machines.
Des paramètres utilisateurs qui s’appliqueront uniquement aux utilisateurs.

Pour simplifier le travail de l’administrateur, il est conseiller de ne pas mixer dans une même GPO des configurations utilisateurs et des configuration machine.

Client Side Extension

Il existe plein de types de GPO différentes, certaines pour modifier des clefs de base de registre, d’autres pour faire l’installation d’un MSI, d’autres pour modifier des groupes locaux de la machine, etc. Ces différents types de GPO sont implémentés à travers le mécanisme de CSE. La GPO contient un fichier texte ou binaire contenant le paramétrage souhaité, il définit également le GUID du moteur CSE qui doit interpréter les fichiers de configuration. Il y a par exemple l’extension {35378EAC-683F-11D2-A89A-00C04FBBCFA2} qui correspond à la modification d’une clef de registre.

Il est possible d’installer des CSE supplémentaires, comme par exemple le CSE LAPS pour modifier automatiquement et régulièrement le mot de passe administrateur local des postes utilisateurs.

Les GPO Domaine par défaut

Deux GPO sont créés par défaut dans le domaine :

Default Domain Controller Policy, GUID {6AC1786C-016F-11D2-945F-00C04FB984F9}.
Default Domain Controller Policy, GUID {6AC1786C-016F-11D2-945F-00C04FB984F9}.

Il est préférable de NE PAS modifier ces GPO. Il ne faut PAS les supprimer non plus.

Filtres WMI

Quand on définit une GPO, il peut être intéressant de la restreindre à certain types de postes ou d’utilisateurs, par exemple une GPO qui s’appliquera uniquement aux postes Windows 7. Pour cela Microsoft propose d’utiliser des filtres WMI pour filtrer la GPO uniquement sur des objets qui respectent certaines conditions.

Il faut faire attention aux filtres WMI car le calcul du filtre peut consommer du CPU et prendre du temps.

Délégation des GPO

Il est possible de déléguer le contrôle d’une GPO à une personne ou à un groupe de personne. Cela permet à des administrateurs délégués de faire des modifications sur des GPO qui s’appliqueront à leur périmètre de responsabilité. Toutefois il sera quand même nécessaire de demander à un administrateur ayant les droits de créer une nouvelle GPO, c’est à dire soit à un membre du groupe Domain Admins ou soit à un membre du groupe Group Policy Owner de créer la nouvelle GPO et de la déléguer au bon groupe.

Il existe aussi un groupe AD présent par défaut, Group Policy Owner, qui peut créer et modifier toutes les GPO. La possibilité de modifier n’importe quelle GPO permet en pratique de facilement prendre le contrôle des postes des administrateurs informatiques, et donc ce droit s’apparente finalement à celui d’un administrateur du domaine. C’est pourquoi nous recommandons de ne pas appliquer ce groupe à des personnes qui ne sont pas elles-mêmes Domain Admins.

Limitation des GPO

Les GPO ont été imaginés dans les années 90 comme la solution ultime à tous les problèmes de gestion de parc, que ce soit l’installation, le paramétrage, la sécurisation, la configuration des sessions utilisateur, etc.

En pratique il y a plein de choses, comme l’installation de logiciel, qui s’adaptent mal au fonctionnement des GPO. D’ailleurs Microsoft conseille de ne pas utiliser des GPO pour le déploiement d’application.

De plus il n’y a aucun reporting intégré au système de GPO. Si l’on veut être sûr que tout s’est bien passé, il est nécessaire de lancer localement sur le poste la commande gpresult /Z pour avoir un compte rendu de l’état d’application des GPO. A défaut de lancer la commande sur le poste, on peut récupérer un compte rendu à distance pourvu que le poste soit joignable depuis le poste de l’administrateur informatique, et que les partages administratifs soient ouverts. De plus cette information n’est pas centralisée et il faudra alors se connecter à l’ensemble des machines du parc, une à une, pour avoir un retour exhaustif de l’état d’application des GPO.

L’utilisation de filtre WMI ou bien un trop grand nombre de GPO peut ralentir le démarrage d’une machine ou bien le lancement de la session de l’utilisateur.

Recommandations par rapports aux GPO

Comme mentionné plus tôt, il ne faut pas modifier les deux GPO par défaut du domaine. Il faut aussi faire attention lors de l’application de GPO de ne pas les appliquer trop haut dans l’arborescence. En effet une GPO liée à la racine de l’AD s’appliquera aussi aux objets système comme le compte Administrator, le groupe Domain Admins, etc. et pourrait avoir des conséquences dangereuses.

Il est donc préférable de créer une UO racine pour l’Organisation et de mettre tous les objets en dessous, cela permet d’affecter des GPO qui seront valables pour l’ensemble de la structure sans pour autant avoir d’effet inattendu en s’appliquant sur des objets système.