Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
1019 connectés 

  FORUM HardWare.fr
  Systèmes & Réseaux Pro
  Infrastructures serveurs

  GPO user appliquée sur OU computers (loopback actif): refusée ?

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

GPO user appliquée sur OU computers (loopback actif): refusée ?

n°86009
urbain
dittonophile
Posté le 12-10-2011 à 16:45:45  profilanswer
 

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  :D : 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 ;-)


Message édité par urbain le 12-10-2011 à 16:46:19

---------------
http://blogs.hifi-legends.com
mood
Publicité
Posté le 12-10-2011 à 16:45:45  profilanswer
 

n°86019
Je@nb
Modérateur
In ze cloud
Posté le 12-10-2011 à 20:41:03  profilanswer
 

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.

n°86035
urbain
dittonophile
Posté le 13-10-2011 à 09:45:56  profilanswer
 

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


---------------
http://blogs.hifi-legends.com
n°86043
Je@nb
Modérateur
In ze cloud
Posté le 13-10-2011 à 10:13:34  profilanswer
 

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

n°86047
urbain
dittonophile
Posté le 13-10-2011 à 11:06:21  profilanswer
 

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

Je@nb a écrit :


- Je pense que tu avais fumé


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...  :-/


---------------
http://blogs.hifi-legends.com
n°86054
Je@nb
Modérateur
In ze cloud
Posté le 13-10-2011 à 11:20:54  profilanswer
 

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)

n°86059
urbain
dittonophile
Posté le 13-10-2011 à 12:16:12  profilanswer
 

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) :pfff:  
 
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... :D


---------------
http://blogs.hifi-legends.com
n°86060
Je@nb
Modérateur
In ze cloud
Posté le 13-10-2011 à 12:18:18  profilanswer
 

C'est quoi comme OS les clients ?

n°86061
urbain
dittonophile
Posté le 13-10-2011 à 12:40:28  profilanswer
 

XP / Windows 7 à 50/50 +-


---------------
http://blogs.hifi-legends.com
n°86066
Je@nb
Modérateur
In ze cloud
Posté le 13-10-2011 à 14:07:25  profilanswer
 

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 :/

mood
Publicité
Posté le 13-10-2011 à 14:07:25  profilanswer
 

n°86071
urbain
dittonophile
Posté le 13-10-2011 à 14:52:15  profilanswer
 

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


---------------
http://blogs.hifi-legends.com
n°86072
Je@nb
Modérateur
In ze cloud
Posté le 13-10-2011 à 14:58:38  profilanswer
 

Hmm doit bien y avoir un guide chez technet

n°86086
nebulios
Posté le 13-10-2011 à 17:25:36  profilanswer
 

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

n°86097
urbain
dittonophile
Posté le 14-10-2011 à 09:43:40  profilanswer
 

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.


Message édité par urbain le 14-10-2011 à 09:43:50

---------------
http://blogs.hifi-legends.com

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Systèmes & Réseaux Pro
  Infrastructures serveurs

  GPO user appliquée sur OU computers (loopback actif): refusée ?

 

Sujets relatifs
Création répertoire perso via GPOFiltre WMI sur IE8 pour GPO - help
[RESOLU] Deployer Adobe X GPO problémeGPO Access Runtime 2010
Redirection dossiers sur windows 7 par GPOModifier paramètre GPO local dans un domaine via script/GPO
[quasi-resolu]GPO totalement ignoré (2008r2 AD et TSE)Authentification 802.1x sur serveur NPS - PC+User?
Active Directory et GPOcommand DOS pour connaitre domain, site, user..
Plus de sujets relatifs à : GPO user appliquée sur OU computers (loopback actif): refusée ?


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR