Pb de droit admin sur profil itinérant

Bonjour,



sous Windows Server 2003, j’ai un souci avec mes profils itinérants. En effet, bien qu’ayant une stratégie pour ajouter les droits admin. aux profils itinérants, l’administrateur se voit refuser l’accès au répertoire (%username% créé par le système) dans lequel est redirigé le profil itinérant d’un utilisateur.



Comment vérifier que ma GPO est bien appliquée ?



[EDIT] : D’ailleurs, sachant que cette GPO concerne les ordinateurs (et non les utilisateurs), je suppose qu’il faut l’appliquer sur un ou plusieurs ordinateurs (serveurs).

Mais lesquels ? :

  • les serveurs CTX sur lesquels les utilisateurs se connectent ?
  • le serveur sur lequel le répertoire partagé est stocké ?



    Cordialement

    Alfred

Sur le serveur de fichier, pas sur les Citrix.

Et sur ce serveur tu peux utiliser Gpresult pour valider que ta GPO passe bien.

Chav, je crois que tu te trompe :angel: .



Il faut que tu applique la GPO en mode loopback (boucle de rappel) sur l’ou contenant tes serveurs Citrix.



Ce seront les créateurs des profils sur le serveur de fichier, c’est donc à ces serveurs qu’on définit les paramètres de génération de profils itinérants.

Donc si nous excluons Citrix de l’histoire, tu appliquerais cette GPO sur les postes utilisateurs. Tu me donne un doute la. le plus simple link ta GPO sur les deux OU ca ne mange pas de pain

Je suis sur de moi à 99,99%…

Il faut appliquer cette GPO sur l’OU contenant les serveurs Citrix. Attention, il faut isoler les serveurs Citrix dans une OU dédiée afin d’eviter des effets de bord avec d’autres objets qui pourraient être dans la même OU.

De plus, les paramètres de profils (chemins, droit admins, suppression du serveurs TS/Citrix à la déco, etc) sont des paramètres de GPO ordinateur.

oki doki …

J’essaie de suite cette GPO sur l’OU contenant mes serveurs CTX et vous tiens au courant.



Merci

Bonjour,



Le paramètre doit être configuré sur l’ordinateur client et pas sur le serveur: c’est le client qui définit les autorisations du profil itinérant au moment de sa création.



Si le paramètre est activé après la création du profil, il sera sans effet. Donc à appliquer avant création des profils



Je suis sûr à 100%… :stuck_out_tongue:

Bonjour,

Le client, c’est bien la machine sur laquelle le bureau (la seule application publiée) de l’utilisateur est exécuté, non ?



ça ne marche toujours pas, alors voici ce que j’ai fait:

  • sur mon DC, à partir de l’AD, dans l’OU de mes serveurs CTX, je crée une GPO dans laquelle:

    - à partir de config. ordinateur/modèle admin/système/profils utilisateurs, j’active l’ajout du droit admin…

    - à partir de config. ordinateur/modèle admin/système/stratégie de groupe, j’active le Mode de Traitement par boucle


  • à partir de l’AD, je crée un utilisateur en lui spécifiant un chemin UNC pour son profil \srv…%username%



    Qd cet utilisateur se connecte son répertoire %username% est bel et bien créé mais moi, en tant qu’admin., j’ai un accès refusé… ???



    D’avance merci

    Alfred
"Heunemann" wrote:
Bonjour,
Le client, c'est bien la machine sur laquelle le bureau (la seule application publiée) de l'utilisateur est exécuté, non ?

ça ne marche toujours pas, alors voici ce que j'ai fait:
- sur mon DC, à partir de l'AD, dans l'OU de mes serveurs CTX, je crée une GPO dans laquelle:
- à partir de config. ordinateur/modèle admin/système/profils utilisateurs, j'active l'ajout du droit admin...
- à partir de config. ordinateur/modèle admin/système/stratégie de groupe, j'active le Mode de Traitement par boucle

- à partir de l'AD, je crée un utilisateur en lui spécifiant un chemin UNC pour son profil \srv...%username%

Qd cet utilisateur se connecte son répertoire %username% est bel et bien créé mais moi, en tant qu'admin., j'ai un accès refusé... ???

D'avance merci
Alfred


Gpupdate /force voire reboot...

Je n’ai pas essayé le reboot mais avant cela…

En tapant GPRESULT /USER %username% sur le serveur CTX sur lequel je me connecte, je vois que les GPOs users sont bien appliquées. Mais je ne vois pas la GPO ordinateur en question. Mais peut-être est-ce normal, non ? Est-ce bien dans le résultat de cette commande que je devrais voir la GPO en question ?



Merci

Alfred

Après avoir essayé Gpupdate /force puis un reboot … rien n’y fait.

Ceci dit, sur le serveur sur lequel mes utilisateurs se connectent, la commande gpresult /user %username% me renvoie l’erreur suivant concernant les stratégies ordinateur:

Les objets stratégies de groupe n’ont pas été exécutés car ils ont été refusés:

AjoutDroitAdmin

Filtrage: Refusé (Sécurité)




Vous l’aurez compris, AjoutDroitAdmin étant la stratégie que j’essaie d’appliquer pour faire en sortes que l’administrateur est l’accès aux profils utilisateurs.



Que signifie ce “Filtrage: Refusé (Sécurité)” et surtout comment le résoudre ?



Cordialement,

Alfred

avec l’outil de gestion des GPO (gpmc) tu peux choisir, gpo par gpo, qui peux la modifier ou l’appliquer (lire)

"Heunemann" wrote:
Après avoir essayé Gpupdate /force puis un reboot ... rien n'y fait.
Ceci dit, sur le serveur sur lequel mes utilisateurs se connectent, la commande gpresult /user %username% me renvoie l'erreur suivant concernant les stratégies ordinateur:
Les objets stratégies de groupe n'ont pas été exécutés car ils ont été refusés:
AjoutDroitAdmin
Filtrage: Refusé (Sécurité)


Vous l'aurez compris, AjoutDroitAdmin étant la stratégie que j'essaie d'appliquer pour faire en sortes que l'administrateur est l'accès aux profils utilisateurs.

Que signifie ce "Filtrage: Refusé (Sécurité)" et surtout comment le résoudre ?

Cordialement,
Alfred
"Filtrage refusé" indique que l'objet de GPO n'est pas appliqué car l'utilisateur avec lequel tu réalise le gpresult ne fais pas partie d'un groupe d'ulitisateur sur lequel l'"action appliquer la GPO" est activée.

Comme le disait Laurent, les droits du profil sont appliqués à la création de ce dernier, il est donc normal que le droit admin ne s'ajoute pas sur les profils existants. Tu devrais constater des erreurs dans le journal d'évènement des serveurs Citrix, généralement avec comme source UserEnv.

Pour ajouter le droit admin sur tous tes profils sans avoir à les passer un par un, je te conseille security explorer (http://www.scriptlogic.com/products/security-explorer/windows/), c'est payant mais le gain de temps est considérable ...

Pour vérifier que la GPO fonctionne, réalise le test suivant :
Crée un utilisateur de test (indeed but défini le profil itinérant TS) et connecte toi avec ce dernier, ferme la session et tu devrais pouvoir acceder au profil en tant qu'admin.
"jolebarjo" wrote:
"Filtrage refusé" indique que l'objet de GPO n'est pas appliqué car l'utilisateur avec lequel tu réalise le gpresult ne fais pas partie d'un groupe d'ulitisateur sur lequel l'"action appliquer la GPO" est activée.
Ok ... Si ce n'est que je suis en administrateur quand j'exécute ce gpresult /u %username%. Je vérifierai si il (l'administrateur) a les droits pour appliquer la GPO.
"jolebarjo" wrote:
Comme le disait Laurent, les droits du profil sont appliqués à la création de ce dernier, il est donc normal que le droit admin ne s'ajoute pas sur les profils existants. Tu devrais constater des erreurs dans le journal d'évènement des serveurs Citrix, généralement avec comme source UserEnv.
C'est normal sauf que je supprime et recrée un user test pour faire ce test.
"jolebarjo" wrote:
Pour ajouter le droit admin sur tous tes profils sans avoir à les passer un par un, je te conseille security explorer (http://www.scriptlogic.com/products/security-explorer/windows/), c'est payant mais le gain de temps est considérable ...

Pour vérifier que la GPO fonctionne, réalise le test suivant :
Crée un utilisateur de test (indeed but défini le profil itinérant TS) et connecte toi avec ce dernier, ferme la session et tu devrais pouvoir acceder au profil en tant qu'admin.
C'est justement ce test que je fais mais lorsque je me connecte en tant qu'admin sur le serveur de fichier qui contient les profils, je n'ai pas les droits d'accès aux profils utilisateurs. C'est la raison pour laquelle je veux vérifier que pour mon utilisateur 'test', la stratégie AjoutDroitAdmin est appliquée ou non (et pour quelle raison).