Les GPO ne s’appliquent pas ? 14 pistes à étudier

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 :

gpo-debug-1

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 !

Filtre de sécurité - GPO
Filtre de sécurité - GPO

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.

Ajout d'un filtre WMI - GPO
Ajout d'un filtre WMI - GPO

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.

Vérifier l'état de la GPO
Vérifier l'état de la 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 :

gpo-debug-5

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 :

Blocage de l'héritage d'une GPO
Blocage de l'héritage d'une GPO

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).

Modèle LSDOU

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 :

Le lien de la GPO est-il actif ?
Le lien de la GPO est-il actif ?

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 ».

GPO Enforced
GPO Enforced

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.).

Créer une vue sur "GroupPolicy (Microsoft-Windows-GroupPolicy)"
Créer une vue sur "GroupPolicy (Microsoft-Windows-GroupPolicy)"

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

Exemple d'événements liés aux GPOs générés
Exemple d'événements liés aux GPOs générés

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 :

Aperçu d'un RSOP
Aperçu d'un 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.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Florian Burnel

Co-Fondateur d'IT-Connect, je souhaite partager mes connaissances et expériences avec vous, et comme la veille techno' est importante je partage aussi des actus.

florian a publié 1604 articles sur IT-Connect.See all posts by florian

17 réactions sur “Les GPO ne s’appliquent pas ? 14 pistes à étudier

  • 29/03/2015 à 05:49
    Permalink

    Hello,

    Très très très bon article pour qui travaille avec des GPO. Merci !

    Tcho !

    Répondre
  • 30/04/2015 à 13:38
    Permalink

    Article super intéressant ! Continuez les gars !

    Répondre
  • 07/05/2015 à 14:51
    Permalink

    Très bon article en soit ! Mais il existe un paramètre qui permet  » D’attendre la connectivité réseau avec d’appliquer les autres GPO », je m’explique quand l’ordinateur démarre trop vite, les GPO n’ont pas le temps de s’appliquer.. En espérant aider quelque personne..

    Répondre
  • 17/06/2015 à 18:15
    Permalink

    Super article merci!
    Je rajouterai pour un vrai débug détaillé l’activation du mode verbose via la clé de registre « GPSvcDebugLevel ».

    Article incontournable du technet: http://blogs.technet.com/b/csstwplatform/archive/2010/11/09/how-to-enable-gpo-logging-on-windows-7-2008-r2.aspx

    To enable logging in the Gpsvc.log file, follow these steps.

    1. Click Start , click Run , type regedit , and then click OK .

    2. Locate and then click the following registry subkey:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion

    3. On the Edit menu, point to New , and then click Key .

    4. Type Diagnostics , and then press ENTER.

    5. Right-click the Diagnostics subkey, point to New , and then click DWORD Value .

    6. Type GPSvcDebugLevel , and then press ENTER.

    7. Right-click GPSvcDebugLevel , and then click Modify .

    8. In the Value data box, type 0x30002 , and then click OK .

    9. Exit Registry Editor.

    10. At a command prompt, type the following command, and then press ENTER:

    gpupdate /force

    11. View the Gpsvc.log file in the following folder:

    %windir%\debug\usermode

    Répondre
  • 25/11/2015 à 15:53
    Permalink

    Merci beaucoup pour votre article très complet, plus les comms.

    Répondre
  • 13/12/2015 à 10:22
    Permalink

    Super Topo sur les possibilités ! Merci à toi ! De mon côté, je débute sur Windows serveur et mon erreur était bien plus bête que cela, j’avais simplement pas les droits en lecture sur mon dossier « sysvol » depuis mes profils… un simple « gpupdate /force » sur le poste me l’a vite fait comprendre ^^ Encore merci

    Répondre
  • 11/02/2016 à 03:59
    Permalink

    Bonjour,
    Super article.
    Je suis en train de mettre en place un serveur RDS Windows 2012R2 et je souhaiterais savoir s’il est possible de créer une GPO utilisateur, la lier à une OU computer qui contient mon serveur RDS et de filtrer pour un groupe utilisateur. Je souhaite en fait configurer des chemins de profiles RDS différents en fonction des utilisateurs.
    J’ai créé une GPO Loopbak en mode fusion et une GPO utilisateur qui positionne le chemin du profil. Sur cette dernière, je filtre en mettant un groupe d’utilisateur mais ça ne fonctionne pas. Si je filtre en mettant le groupe utilisateur authentifié, ma GPO fonctionne.
    Avez-vous une idée d’où peut venir le problème ?

    Répondre
  • 18/07/2016 à 15:26
    Permalink

    Bonjour,
    à rajouter depuis la maj KB3163622 de windows les gpo ne fonctione plus si il n y’a pas d’intégrer dans le groupe Ordinateur du domaine avec lecture (à partir du filtrage de sécurité)

    Répondre
    • 18/07/2016 à 21:19
      Permalink

      Bonjour Cédric

      Effectivement cette mise à jour récente pose des soucis dans certains environnements, merci d’avoir pris le temps d’apporter la précision au sien de ce commentaire.

      Florian

      Répondre
  • 26/07/2016 à 15:28
    Permalink

    Merci pour l’explication et au contraire si je veux etre sur que la GPO s’applique pas sur un PC windows 10 Pro x64 que dois je faire ?

    parce que stopper le service gpsvc ne suffit, au prochain reboot, toute la gpo est poussé

    Répondre
  • 19/08/2016 à 12:35
    Permalink

    Très bon article. On peut ajouter le cas suivant :
    Soit un domaine DOM1, avec une unité d’organisation OU1 et une politique GPO1.
    On désactive l’héritage au niveau de OU1.
    On créée un lien vers GPO1 au niveau de DOM1 et au niveau de OU1.

    La GPO ne s’applique pas dans OU1.

    Il faut supprimer le lien au niveau de DOM1 pour que GPO1 s’applique au niveau de OU1.

    Répondre
    • 19/08/2016 à 20:52
      Permalink

      Bonsoir Loïc,

      Effectivement c’est un cas de figure particulier, mais c’est un genre de bug non ? Car au final certes l’héritage est retiré mais vu que la GPO est appliquée directement sur l’OU, ça devrait fonctionner. Surement comme c’est la même GPO… Il s’emmêle les pinceaux ?

      Florian

      Répondre
  • 20/12/2016 à 16:38
    Permalink

    bonjour
    je suis un ad 2012 R2, j ai une gpo qui ne s’applique pas alors qu elle apparait dans mes gpo quand je fais un gpresult /r, je n arrive pas a comprendre ce qui cloche ou ce qui l empeche d executer mon script .VBS
    alors que celui-ci fonctionne tout seul quand je l execute sous un win7.

    merci.

    Répondre
  • 27/01/2017 à 10:06
    Permalink

    Bonjour,
    Il manque un chapitre, s’il existe, qui traite de l’état des lieux des GPO du domaine et local, pour un serveur, non pas en mode « graphique » mais uniquement au travers de lignes de commandes et de scripts.
    Cela présente un intérêt pour l’inventaire des GPO appliquées , pour des centaines de serveurs.
    Cdlt,

    Répondre
  • 25/09/2017 à 08:41
    Permalink

    Bonjour Florian,
    Excellent article, dommage qu’il y ai une petite boulette sur la 1ere illustration. « Default Domain Policy » (qui défini essentiellement les mots de passe) s’applique à tous les objets du domaine (y compris les contrôleurs de domaine !…). Ces derniers reçoivent ensuite en complément le GPO spécifique (Default Domain Controler Policy) qui affine la sécurité de ces derniers. Donc pour que l’affirmation « Hormis les contrôleurs de domaine » soit vraie, il faudrait positionner un blocage d’héritage sur l’OU « Domain Controlers ». Ce qui serait déconseillé et sans véritable intérêt autre que pédagogique.
    Bonne continuation.

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *