Je cherche de l'aide par-rapport à un problème de stratégie de groupe assez incompréhensible. J'avoue y perdre mon latin !  Voici un résumé de la situation:
 
J'ai dans mon AD (DC: Win Server 2008) une simple stratégie de groupe déployant des MSI sur certains postes uniquement, et ce exclusivement pour les utilisateurs membres d'un groupe spécifique ouvrant une session sur ces machines.
 
- La GPO déploie un MSI via un paramètre utilisateur (Software Installation sous User Configuration)
- La GPO est liée à une OU contenant des objets de type Computer uniquement.
- La GPO est filtrée sur le groupe utilisateurs ayant l'autorisation d'accéder à l'application (console Group Policy Management -> onglet Scope -> Security Filtering).  Les cases Read et Apply Policy sont bien cochées pour ce groupe.  J'ai supprimé le groupe Authenticated Users de la liste.
- Le loopback processing est activé dans cette GPO (d'après Microsoft, l'activation de cette option permet précisément d'appliquer un paramètre utilisateur sur des objets computer, précisément ce que je souhaite)
 
Résultat: La GPO n'est pas appliquée sur les postes concernés.  L'utilitaire GPRESULT me retourne l'erreur suivante, sous "Computer Configuration": [Ma GPO] Filtrage: Refusé (Sécurité).
 
Il faut savoir que cette GPO se déploie avec succès si je laisse le groupe "Authenticated Users" dans Security Filtering (onglet Scope, console Group Policy Management).  C'est donc uniquement le filtrage par-rapport à un autre groupe de sécurité qui ne fonctionne pas.
 
J'ai essayé à tout hasard de déplacer mon groupe d'utilisateurs dans l'OU sur laquelle est appliquée la GPO, sans succès.  Je suis également tombé sur bon nombres d'articles préconisant d'appliquer des paramètres utilisateur uniquement à une OU contenant des objets users.  Ce qui est irréalisable dans mon cas, mon AD étant structurée  par départements et pas en fonction de droits d'accès à certains programmes (de plus, un objet pouvant se trouver dans une et une seule OU, utiliser ces dernières à cet usage semble peu indiqué).
 
Quelqu'un aurait-il une idée de ce qui aurait pu m'échapper dans ce cas ?
 
Ou, plus simplement   : quelqu'un ici a-t-il déjà réussi à appliquer des paramètres Users à des OU contenant des objets Computers tout en filtrant sur un groupe de sécurité ?
 
 
merci d'avance pour les coups de pouce éventuels ;-)

C'est en effet logique que ça ne marche pas.
 
Même si c'est du loopback, la GPO est appliquée à l'ordinateur et non à l'utilisateur donc si filtrage par groupe de sécurité il y a c'est un groupe contenant des machines qu'il faut configurer. Après dedans en effet tu configures des settings users et selon le mode de loopback tu auras un replace ou un merge des gpo users.  
 
Je ne sais pas si ta problématique (telle qu'exprimée ici) peut être adressée par les GPO.
 
Les utilisateurs changent de poste ? Si non, suffit que tu match users <=> computers et tu fais un déploiement via computers en utilisant des groupes de sécu selon les ordinateurs.

Bonjour, merci pour cette remarque.  Tout d'abord pour répondre à la question: oui, les utilisateurs changent fréquemment de poste et cette règle doit les "suivre".  Il s'agit du déploiement de fichiers MSI donnant accès à des applications en Remote App pour lesquelles nous sommes limités en terme de licences.  Je ne peux donc pas déployer ça chez tout le monde et il faut filtrer sur un groupe d'utilisateurs précis.  De plus, j'applique la GPO à une OU ne comprenant que les postes de travail fixes et les portables, ne souhaitant pas qu'elle soit appliquée lorsque je me logge à un serveur ou à d'autres machines particulières, par exemple.
 
Merci pour tes suggestions, mais il y a cependant plusieurs points qui restent flous pour moi:
 

• Comment se fait-il que la GPO fonctionne correctement si je filtre sur "Authenticated Users" ?  A quoi correspond réellement ce groupe ?
• Sachant qu'un GPResult me montre bien que la GPO est détectée pour l'utilisateur en cours sur une machine donnée (qui correspond respectivement à l'OU sur laquelle elle est appliquée pour la machine et au groupe de sécurité sur lequel je filtre pour l'utilisateur), mais qu'elle n'est pas appliquée pour une raison de sécurité.  Y a-t-il une possibilité de connaître cette raison de sécurité empêchant son application ?  J'ai épluché les logs du serveur et du client, aucune erreur en vue et pas moyen d'en savoir d'avantage.  Des permissions ne seraient-elles pas définies correctement à l'un ou l'autre endroit ?  
• Une chose étrange: j'avais déjà utilisé ce type de GPO (Appliquée à une OU Computer en filtrant sur un groupe de sécurité composé d'utilisateurs, loopback activé) auparavant lorsque j'avais des DC en Windows Server 2003, et ça fonctionnait.  J'ignore si cela a un rapport, mais on dirait que le problème avec cette GPO est survenu depuis que nous avons migré nos DC en 2008R2 et que le schéma de mon AD a été upgradé.  Est-ce une coïncidence ou cela pourrait-t-il avoir une corrélation quelconque ?

Merci pour le coup de pouce ;-)  

- Parce que authenticated users = n'importe qui (ou quoi dans ton cas puisque ce sont les objets ordinateurs) qui s'est authentifié sur un DC
- c'est le principe du loopback. Refusé parce que tu as pas l'ACE Apply the settings pour l'objet computer. Non pas de droits définis autre part
- Je pense que tu avais fumé
 
Ta solution serait de faire des GPO au niveau root (ou plus bas si tu peux ou en linkant plusieurs fois) et de filtrer directement par user.
Ou de gérer ça par login script.

Ok, compris pour le coup de Authenticated users.  (alias "authenticated computers"... tout ça est très clair, merci Microsoft  ! )
 

Et pourtant, cette GPO fonctionnait bel et bien !  Les users se trouvant dans le groupe de sécurité sur lequel était activé "apply policy" se voyaient déployer leurs .MSI lors d'une ouverture de session sur tout ordinateur se trouvant dans l'OU sur laquelle était appliquée la GPO (de type user, donc).  Par contre, je ne parviens cependant pas à m'expliquer par quel miracle ça fonctionnait, ton explication semblant parfaitement logique.
 
Merci pour ta dernière proposition, mais elle sous-entend qu'il faudrait se servir des OU en guise d'ACL. Ce serait effectivement la solution de simplicité, parfaitement réalisable et ça fonctionnerait sans accroc.  Le hic, c'est que dans Active Directory, un objet ne peut être membre que d'une et une seule OU.  Il est donc irréaliste de se servir de ces dernières à cet usage.  Ou alors, il faudrait une OU par user et linker la GPO à toutes les OU souhaitées !  Malheureusement ingérable...  :-/

G pas pris la notion "sur certains postes uniquement".
 
Je le ferais en login script alors perso. (je sais plus si les msi que tu génères pour du remote desktop fonctionnent sans droit admin ya des chances que non)

Malheureusement non, il faut les droits d'admin local pour les exécuter... (après les avoir préalablement copié en local d'ailleurs, pour une raison que j'ignore, sinon depuis un partage même accessible ils ne s'installent pas)  
 
J'avais aussi penser gérer les droits d'accès depuis Remote App, mais pas fonctionnel chez moi: malgré la mise en place d'ACL dans la console de gestion RemoteApp, n'importe quel user lançant le MSI a accès à l'appli (bug...?)  
 
Voilà les raison de ma volonté première de déployer ces MSI chez les users concernés en filtrant par GPO.  Bon, je sens qu'il va falloir trouver autre chose...

C'est quoi comme OS les clients ?

XP / Windows 7 à 50/50 +-

Ok, sur Win 7 tu peux publier l'adresse du remote web app directement pour déployer tes applis mais sur XP ouais tu peux pas

Ah ?  Ca a un rapport avec ce qu'ils appellent RD Web Access ?  Je n'ai jamais essayé cette fonctionnalité.  Tu aurais un lien vers un tuto sur le site de 'crosoft ou autre ?  A priori ça m'intéresserait beaucoup de pouvoir déployer les apps. sans passer par une GPO, même si ça ne fonctionne que sous 7 !
 
merci

Hmm doit bien y avoir un guide chez technet

Tu ne peux pas installer l'appli sur le serveur RDS et n'autoriser que le groupe spécifique à y accéder ?

Je pense que les ACL définies au niveau des applis via la console RemoteApp ne servent qu'à afficher (ou pas) les icônes pour les personnes se loggant via RD Web Access.  Cela ne limite pas l'accès à l'application en elle-même, et cela n'empêchera pas par exemple un user de lancer un Explorer dans sa session RemoteApp, de naviguer jusqu'au folder de son choix et de lancer ce que bon lui semble.  Il faut régler la sécu directement au niveau des folders sur le serveur pour éviter cela, ou alors passer par un outil tiers permettant de paramétrer des ACL par-rapport aux applications, mais je n'ai jamais testé ça.