GPO : portée, héritage et où vit la configuration

Passer deux cents machines sur un poste verrouillé se fait une par une ou avec un GPO. Un objet de stratégie de groupe (GPO) est un objet avec une ou plusieurs configurations appliquées aux utilisateurs ou aux ordinateurs, et c'est la pièce avec laquelle un domaine standardise les postes et empêche les modifications non autorisées. Le problème habituel n'est pas d'écrire la stratégie mais de savoir à qui elle arrive et pourquoi elle ne s'applique pas sur cette machine en particulier. Ce qui suit vient du module « Group Policy Objects (GPO) implementation » de Microsoft Learn.

Ce que c'est et à quoi ça sert

Le cadre de stratégie de groupe a des composants dans AD DS, sur chaque contrôleur de domaine et sur chaque serveur ou client Windows : la stratégie se définit dans le répertoire, se distribue depuis les contrôleurs et s'exécute sur la machine. Un GPO s'applique à la connexion ou au démarrage.

Les usages typiques standardisent la configuration et verrouillent ce qui ne devrait pas bouger : bornes, salles de classe, postes des employés. Quand il faut l'appliquer à un sous-ensemble du parc, il y a deux filtres à portée de main : les attributs physiques (adresse IP ou MAC) et l'appartenance à des groupes.

Où ça arrive : portée, liens et héritage

La portée est la collection d'utilisateurs ou d'ordinateurs auxquels le GPO s'applique. Pour qu'un GPO arrive à quelqu'un, il doit être lié à un site, à un domaine ou à une unité d'organisation, et il peut être lié à plusieurs conteneurs à la fois (les utilisateurs des UO secondaires sont inclus).

L'avertissement pratique vient ensuite : dans les environnements avec forêts et sites dispersés, les GPO résident sur les contrôleurs de domaine du domaine où ils ont été créés, et le traitement peut traverser des liaisons WAN lentes. C'est-à-dire que la stratégie qui paraît locale voyage à chaque traitement si le lien pointe vers une agence lointaine.

flowchart TD
    S[Site] --> D[Domaine] --> OU[UO]
    OU --> GPO[GPO lié]
    GPO --> FS[Filtre de sécurité : Appliquer / Lire la stratégie]
    GPO --> FW[Filtre WMI : requête évaluée à chaque traitement]
    FS --> R[Utilisateur ou ordinateur concerné]
    FW --> R

Comment on décide qui la reçoit

Deux filtres posent les règles :

Filtre de sécurité. Donne Appliquer la stratégie et Lire la stratégie aux groupes, utilisateurs ou ordinateurs. Refuser Appliquer la stratégie laisse un groupe sans la stratégie, qui est la manière standard d'appliquer une stratégie à un sous-ensemble seulement : groupe de sécurité global avec les utilisateurs dedans et Appliquer la stratégie refusé pour le reste.
Filtre WMI. Associe un GPO à un filtre (un GPO par filtre ; un filtre peut couvrir plusieurs GPO) et s'évalue à chaque traitement, avec une surcharge ajoutée. Si la requête est invalide ou ne peut pas s'évaluer, elle est considérée comme fausse et la stratégie reste de côté.

Ensuite vient la priorité. Entre UO imbriquées l'héritage descend : ce qui est configuré sur une UO mère arrive aux filles, sauf si l'une d'elles bloque l'héritage. Quand un lien est marqué comme Obligatoire, il évite ce débat : il acquiert le niveau de priorité le plus haut, s'applique à tous les utilisateurs et ordinateurs du conteneur et l'emporte sur toute configuration en conflit, même si un autre GPO a l'héritage bloqué ou un ordre de lien plus élevé. C'est le niveau qui gagne les discussions, et c'est pourquoi il vaut mieux l'utiliser avec une seule raison.

Un cas qui se résout avec une règle

Trois pièces coexistent dans Adatum.com : le GPO de domaine par défaut marqué comme Obligatoire, un GPO de configuration de poste lié à l'UO Ventes et un GPO de redirection de dossiers avec l'ordre de lien 2. Pour un utilisateur de Ventes basé à Windsor, celui qui gagne est le domaine. Cela semble contre-intuitif car Ventes et la redirection paraissent plus spécifiques, mais dans ce schéma la priorité ne se gagne pas par proximité : la fixe la configuration du lien, et l'Obligatoire prend le niveau maximal.

Boucle inversée quand la stratégie de l'ordinateur prime sur celle de l'utilisateur

Il y a des environnements où la session de quiconque doit ressortir identique : bornes, salles de classe, hôtes de session Bureau à distance. C'est à cela sert la boucle inversée, qui se configure dans Stratégie de groupe de l'ordinateur \ Modèles d'administration \ Système \ Stratégie de groupe et a deux modes :

Remplacer. La configuration utilisateur de l'utilisateur n'est pas traitée.
Fusionner. La configuration utilisateur de l'utilisateur est traitée d'abord puis celle de l'ordinateur ; en cas de conflit, c'est celle de l'ordinateur qui l'emporte.

La boucle n'affecte que la configuration utilisateur : celle de l'ordinateur suit son chemin normal.

Les deux qui existent par défaut

Le domaine livre deux GPO basés sur domaine par défaut :

Default Domain Policy. Lié au domaine, appliqué aux utilisateurs authentifiés et sans filtre WMI. Contient les stratégies de groupe Kerberos v5, de verrouillage de compte et de mot de passe. On ne doit pas y ajouter de configuration étrangère : c'est là que vit la politique de mot de passe du domaine, et la mélanger avec autre chose transforme n'importe quel diagnostic en chasse au trésor.
Default Domain Controllers Policy. Lié à l'UO Domain Controllers et appliqué uniquement aux contrôleurs de domaine.

Où vit la configuration

Un GPO a deux composants, et les confondre est la cause de la moitié des « je l'ai modifié et ça n'a pas changé » :

flowchart LR
    G[GPO] --> C[Conteneur dans Active Directory : métadonnées, GUID, version]
    G --> T[Modèle dans SYSVOL : la configuration réelle]
    T --> PDC[Écriture par défaut sur l'émulateur de PDC]
    PDC --> R[Réplication via AD DS et DFS-R]
    R --> K[Client : détecte les changements par numéro de version]

Le conteneur de stratégie de groupe dans Active Directory ne stocke que des métadonnées : dates de création et de modification, version, GUID, état. La configuration n'est pas dedans.
Le modèle de stratégie de groupe dans SYSVOL (%SystemRoot%\SYSVOL\Domain\Policies\{GPO GUID}) est la collection de fichiers avec la configuration réelle, celle qui s'applique.

Les changements sont enregistrés par défaut avec le contrôleur qui détient le rôle d'émulateur de PDC, puis répliqués via AD DS et DFS-R. Les clients identifient les GPO mis à jour par le numéro de version : une version qui n'avance pas explique donc un client qui ne s'en aperçoit pas.

Pour diagnostiquer, l'ordre est rapide : le conteneur d'abord (le GPO existe-t-il et quelle version déclare-t-il ?) et le modèle ensuite (quels fichiers y a-t-il dans SYSVOL ?). Si la version du conteneur a avancé et que le modèle ne s'est pas répliqué, le problème est dans la réplication. Si les deux ont avancé, la pièce à regarder est le traitement côté client.

Modèles d'administration et magasin central

Les modèles d'administration permettent de configurer des stratégies basées sur le registre : HKLM pour la configuration de l'ordinateur et HKCU pour celle de l'utilisateur, avec celle de l'ordinateur qui l'emporte en cas de conflit. La configuration vit dans les fichiers .admx (réglages, en XML) et les descriptions dans les .adml (une par langue) ; dans Windows, elles sont stockées dans Windows\PolicyDefinitions.

Le magasin central est le dossier PolicyDefinitions créé à la main sous \\FQDN\SYSVOL\FQDN\Policies. Il se réplique via AD DS et DFS-R, garde le modèle cohérent dans toute la forêt et se met à jour avec chaque mise à jour de fonctionnalités de Windows.

Quand Microsoft publie de nouveaux modèles, la recette est simple : télécharger et installer les fichiers de modèles d'administration et régler la configuration souhaitée dans le nœud Modèles d'administration du GPO correspondant. Avec le magasin central en place, il suffit de mettre à jour le dossier PolicyDefinitions répliqué.

Avec quoi on travaille

La console de gestion des stratégies de groupe et l'éditeur de GPO couvrent le visuel ; en PowerShell, il reste les cmdlets New-GPO, New-GPLink, Get-GPInheritance, Set-GPInheritance et Get-GPO, qui est ce qu'il y a à automatiser quand le domaine a plus d'une poignée de stratégies.

Ce qui se décite en premier

L'ordre, comme dans toute conception : d'abord qui reçoit quoi (groupes, UO, portée), ensuite comment on filtre (sécurité et WMI), et seulement ensuite quelle priorité a chaque lien. Écrire le GPO d'abord et chercher ensuite pourquoi il ne s'applique pas est le chemin le plus long.

Limite de cette source : elle explique le cadre et ses règles de priorité, et n'apporte ni diagnostics de traitement pas à pas ni temps de réplication de SYSVOL mesurés ; un « ça ne s'applique pas » concret a donc encore besoin de sa propre enquête.

*Source : le module « Group Policy Objects (GPO) implementation » de Microsoft Learn.*