I. Présentation

Lorsque l’on déploie des stratégies de groupe au sein d’un domaine, il peut arriver que les choses ne se passent pas comme prévu… Surtout lorsque l’on commence à avoir beaucoup de GPO et que l’on utilise des paramètres spécifiques comme les filtres WMI...

Pour « débugger » la GPO et faire en sorte qu’elle fonctionne comme on a envie qu’elle fonctionne, il faudra vérifier sa configuration. Cet article référence une dizaine de points à vérifier pour que les GPO s’appliquent – enfin - correctement.

II. Les 14 pistes à étudier

A. Un paramètre non appliqué, vérifiez l’étendue

Si un paramètre ne s'applique pas, vérifier l'unité d'organisation sur laquelle s'applique la GPO. S'il s'agit d'un paramètre Ordinateur, la GPO doit s'appliquer sur l'OU qui contient l'objet ordinateur ciblé. Sur le même principe s'il s'agit d'un paramètre Utilisateur, la GPO doit s'appliquer sur l'OU qui contient cet utilisateur.

En fait, il faut surtout que l'objet cible soit dans l’étendue de la GPO (l’étendue est aussi appelée scope), c'est-à-dire qu'il soit dans la sous-arborescence sur laquelle s'applique la GPO.

Exemple de cette notion d’étendue :

En fait, vérifiez que l’objet ciblé n’est pas « hors de portée » de la GPO.

B. Le filtre de sécurité

Par défaut, le groupe "Utilisateurs authentifiés" dispose des autorisations nécessaires sur un objet GPO nouvellement créé. Pour rappel, ce groupe inclut tous les utilisateurs... et tous les ordinateurs du domaine !

De ce fait et si vous avez décidé de modifier ce filtre de sécurité, assurez-vous que l'objet cible de la GPO dispose des autorisations nécessaires. Dans les autorisations NTFS de la GPO, vous retrouverez « Utilisateurs authentifiés » avec le droit « Appliquer la stratégie de groupe » sur « Accepter », ce type d’autorisation est ajouté automatiquement lorsque vous ajoutez un utilisateur ou un groupe dans la zone « Filtrage de sécurité ».

Normalement, on ne modifie pas manuellement ces autorisations, sauf cas particulier. Par exemple, si l’on souhaite empêcher qu’une GPO s’applique sur un utilisateur, un ordinateur, ou un groupe, on passera par la modification manuelle des droits pour passer « Appliquer la stratégie de groupe » sur l’état « Refuser ». Ainsi, la GPO ne s’appliquera pas, d’ailleurs vous pourriez contrôler au sein de votre infrastructure que n’ayez pas ce genre de problème qui pourrait se manifester par des messages du type « Accès refusé ».

C. Filtre WMI

Il est possible d'appliquer un filtre dynamique sous forme de requête WMI sur une GPO. Par exemple, appliquer la GPO uniquement si le système d'exploitation de l'hôte cible est Windows 8.

De ce fait, si vous avez défini un filtre WMI, vérifiez qu'il est correct et qu'il ne pénalise pas votre cible. Autrement dit, vérifiez qu'il n'exclut pas votre cible plutôt que de la prendre en compte.

Par défaut, aucun filtre WMI n'est mis en place. Pour ceux qui souhaitent, voici deux articles qui expliquent la création de filtres WMI fonctionnels :

- Filtre WMI du système d’exploitation

- Filtre WMI machine virtuelle

D. Vérifier l’état de la GPO

- En sélectionnant une GPO et en cliquant sur l’objet « Détails », il est possible de donner différents états à la GPO (notamment des états de désactivation). Vérifiez que l’état est bien sûr « Activé » pour activer l’ensemble des paramètres (ordinateurs et utilisateurs) définis dans cette GPO.

E. La délégation

L’onglet délégation regroupe les autorisations appliquées sur l’objet GPO en question, notamment pour déléguer la création d’une GPO à un utilisateur (l’autoriser). De plus, ces autorisations sont importantes pour la réplication des GPO entre les contrôleurs de domaine, car elles régissent les droits d’accès.

On remarque que les informations que l’on retrouve dans cet onglet sont équivalentes à celles que l’on retrouve dans l’onglet « Sécurité », en accédant aux « Propriétés » d’un dossier d’un élément GPO (dans SYSVOL). Voyez par vous-mêmes :

Ce point est à vérifier si vous avez des problèmes de réplication de vos GPOs, ce qui peut impliquer des erreurs d’application par la suite…

F. Les héritages : un nid à problèmes...

Il existe des notions d’héritages pour les stratégies de groupe. Par exemple, si l’on souhaite que la GPO « Default Domain Policy » ne s’applique pas sur une OU en particulier, il suffira de faire clic droit sur l’OU concernée puis « Bloquer l’héritage ».

Les héritages bloqués sont facilement visibles grâce à un icône bleu contenant un point d’exclamation, comme ceci :

Si vous avez des blocages en place, vérifiez donc qu’ils ne posent pas problème...

À savoir également, le fait que si on désactive l’héritage sur l’OU « Collaborateurs » comme ci-dessus, mais que la GPO « Default Domain Policy » est « Appliqué » (Enforced), elle sera appliquée malgré tout. Autrement dit, elle outrepasse le blocage et s’applique quand même.

G. LSDOU : Kézako ?

L'acronyme LSDOU spécifie l'ordre d'application des stratégies de groupe. De ce fait, la stratégie Locale est appliquée en première et ensuite : Site, Domaine et Unité d'Organisation (Organizational Unit).

Cette notion est très importante puisque si vous activez un paramètre sur une GPO appliquée au niveau du domaine, et qu'une autre GPO placée au niveau de l'OU désactive ce même paramètre, ce sera la GPO placée la plus proche de la cible qui gagnera.

En fait, en dehors de la stratégie locale, on remarque que plus la GPO est appliquée sur une unité d'organisation proche de l'objet ciblé, plus elle sera prioritaire.

Pour vérifier ceci, vous pouvez utiliser GPResult notamment en générant un rapport HTML (avec l'option /H) pour avoir un résumé complet.

H. Le lien est-il actif ?

Dans la console de gestion des stratégies de groupe, les différentes GPO sont stockées dans un container nommé « Objets de stratégie de groupe ». Ensuite, chaque GPO est liée sur une ou plusieurs OUs, ce qui crée des liens.

Un lien représente un raccourci entre la GPO dans le container et l'OU sur laquelle s'applique cette GPO.

Ces liens peuvent être activé ou désactivé, cela signifie que l'on peut temporairement désactiver un lien pour désactiver l'application de la GPO sur une OU. Ceci est pratique puisque ça évite de devoir supprimer le raccourci et le recréer ultérieurement.

Vous devez vérifier que les liens sont corrects, notamment actif pour la GPO qui doit s'appliquer.

En faisant un clic droit sur un raccourci, il sera possible de savoir si le lien est activé ou non :

I. Les GPOs « Enforced » - « Appliqué »

Que la traduction de cette option est mauvaise ! En fait, dans la version française de Windows « Enforced » est traduit par « Appliqué », ce qui peut laisser penser que si on n’active pas ce paramètre la GPO ne sera pas appliquée. Ceci est totalement faux.

Il serait plus judicieux de traduire « Enforced » par « Forcé », de ce fait comprenez « Appliqué » par « Forcé » (ou « forcer l’application ») et là ça change la donne...

Cette possibilité remet en cause le schéma d’application LSDOU et offre de nouvelles perspectives pour appliquer les GPOs. En effet, si on active ce paramètre pour une GPO on force son application et on la rend prioritaire par rapport à une autre.

De plus, si deux GPOs sont forcées ce sera celle de plus haut niveau qui sera prioritaire ! Par exemple, si je force la GPO « Default Domain Policy » et la GPO « Utilisateurs_IE », ce sera la première qui gagnera sur la deuxième, car elle est placée « plus haut ».

On reconnaît facilement une GPO sur laquelle le paramètre « Appliqué » est définit à « Oui », car l’icône contient un verrou.

J. Le loopback processing

Pour faire simple sur la notion de loopback processing, lorsque vous démarrez l’ordinateur, il applique les paramètres ordinateurs définis dans la GPO qui s’applique sur lui. Ensuite, lorsqu’un utilisateur se connecte, les paramètres utilisateurs présents dans la GPO qui s’applique sur l’utilisateur sont alors appliqués. Jusque-là, tout est normal...

Par contre, si vous activez le loopback processing au niveau de la GPO concernée il peut y avoir des surprises… En effet, si c’est actif, les paramètres utilisateurs contenus dans la GPO appliquée sur l’ordinateur seront appliqués à l’utilisateur qui se connecte, alors que cette GPO n’est pas directement appliquée à cet utilisateur ! Les paramètres utilisateurs provenant réellement de la GPO appliquée à l’utilisateur seront traités de différentes façons.

Le traitement dépend de ce que vous avez décidé : cumul des deux (avec priorité aux paramètres de la GPO ordinateur en cas de conflit) ou appliquer en priorité les paramètres définis sur la GPO qui s’applique à l’utilisateur.

Ce paramètre est configurable par GPO :

Configuration de l’ordinateur, Modèles d’administration, Système, Stratégie de groupe, Mode de traitement par boucle de rappel de la stratégie de groupe utilisateur

K. Attention à la fausse piste...

Certains paramètres se ressemblent beaucoup et les différences sont parfois minimes sur le papier, mais « conséquente » dans la réalité. Soyez vigilant et lisez bien la description d’un paramètre, en fait posez-vous la question suivante : « Ce paramètre est-il vraiment celui qui répond à mes attentes ? »

Peut-être que toute votre configuration est parfaite, mais si vous ne choisissez pas le bon paramètre, ça ne marchera pas.

L. Le Best Practice Analyzer

Si vos investigations ne donnent rien, vous pouvez générer une analyse avec le Best Practice Analyzer. En cas de configuration incorrecte, il sera capable de remonter l’information et cela peut fortement aider dans certains cas.

Consultez mon article sur le BPA : Best Practice Analyzer (BPA)

M. L’observateur d’événements

Aussi bien au niveau du contrôleur de domaine que de la cible, l’observateur d’événements fournit bien souvent des informations intéressantes sur l’erreur rencontrée (tout dépend de son origine...).

De ce fait, n’hésitez pas à consulter l’observateur d’événements sur un ordinateur cible sur lequel la GPO ne s’applique pas, mais aussi sur votre contrôleur de domaine.

Une fois dans l’observateur d’événements, au sein du journal créez une nouvelle vue et sélectionnez en source « GroupPolicy (Microsoft-Windows-GroupPolicy) ». Ceci permettra d’afficher tous les événements liés au GPO et provenant de l’ensemble des journaux (Système, Application, etc.).

Ce qui permettra d’afficher uniquement les événements liés aux GPOs :

N. L’outil RSOP

L’outil RSOP (Resultant Set Of Policy – Résultats de stratégie de groupe) est un outil intéressant pour tester l’application des GPOs, sans courir à droite et à gauche sur les PCs de votre parc informatique.

Choisissez un ordinateur, un utilisateur et l’outil RSOP se chargera de vous afficher un rapport quant à l’application des GPOs pour cet utilisateur sur la machine indiquée. Cet outil permet d’une part de contrôler que tout s’applique bien comme on le souhaite, d’autre part de débugger les GPOs en cas de besoin.

C’est en quelque sorte une exécution à distance d’un GPResult, ce qui rend l’outil plus pratique et plus flexible. De plus, vous pouvez sauvegarder les rapports directement dans la console.

Voici un aperçu de RSOP :

Pour générer un rapport, utilisez la console de gestion de stratégie de groupe, effectuez un clic droit sur « Résultats de stratégie de groupe » et suivez l’assistant.

III. Conclusion

En conclusion, lorsque vous mettez en place des GPOs faites le plus simple possible, il ne faut pas que ça devienne « une usine à gaz » et limitez également le nombre d’objets de stratégie de groupe. Il y a des chances pour que ça limite les ennuis... Pensez également à adopter un système de nommage clair et parlant, par exemple pour différencier facilement une GPO Utilisateur d'une GPO Ordinateur.

Avec les points cités ci-dessus, vous devriez pouvoir vous en sortir dans de nombreuses situations, bien qu’il puisse y avoir des cas extrêmes. Si votre problème n'est pas résolu, utilisez notre forum pour exposer votre problème à la communauté. Par ailleurs, si vous souhaitez apporter un complément, veuillez laisser un commentaire sur cet article, ce sera appréciable.