-
-
-
-
Configurer les permissions pour VDA antérieurs à XenDesktop 7
-
Résoudre les problèmes utilisateur
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
Configurer les permissions pour VDA antérieurs à XenDesktop 7
Si les utilisateurs possèdent des VDA antérieurs à XenDesktop 7, Director complète les informations sur le déploiement avec des données en temps réel sur l’état et des métriques via Windows Remote Management (WinRM).
En outre, utilisez cette procédure pour configurer WinRM pour une utilisation avec Remote PC dans XenDesktop 5.6 Feature Pack 1.
Par défaut, seuls les administrateurs locaux de la machine de bureau (c’est-à-dire, généralement, les administrateurs de domaine et autres utilisateurs privilégiés) disposent des permissions nécessaires pour afficher les données en temps réel.
Pour plus d’informations sur l’installation et la configuration de WinRM, veuillez consulter l’article CTX125243.
Pour autoriser d’autres utilisateurs à afficher les données en temps réel, vous devez leur accorder les permissions correspondantes. Par exemple, supposez qu’il existe plusieurs utilisateurs Director (HelpDeskUserA, HelpDeskUserB, etc) qui appartiennent au groupe de sécurité Active Directory appelé HelpDeskUsers. Le groupe a été attribué au rôle d’administrateur du bureau d’assistance dans Studio, leur offrant les permissions Delivery Controller requises. Toutefois, le groupe doit également pouvoir accéder aux informations de la machine de bureau.
Pour fournir l’accès nécessaire, vous pouvez configurer les permissions requises de l’une des façons suivantes :
- Accorder des permissions aux utilisateurs de Director (modèle d’usurpation d’identité)
- Accorder des permissions au service Director (modèle de sous-système autorisé)
Pour accorder des permissions aux utilisateurs de Director (modèle d’usurpation d’identité)
Par défaut, Director utilise le modèle d’usurpation d’identité : la connexion WinRM à la machine de bureau est établie en utilisant l’identité de l’utilisateur Director. C’est donc l’utilisateur qui doit disposer des permissions appropriées sur le bureau.
Vous pouvez configurer ces permissions de deux manières (décrites dans ce document) :
- Ajouter des utilisateurs au groupe d’administrateurs locaux sur la machine de bureau.
- Accorder aux utilisateurs les permissions spécifiques requises par Director. Cette option permet d’éviter de transmettre les permissions administratives de Director aux utilisateurs (par exemple, le groupe HelpDeskUsers) sur la machine.
Pour accorder des permissions au service Director (modèle de sous-système autorisé)
Au lieu d’accorder aux utilisateurs Director des permissions sur les machines de bureaux, vous pouvez configurer Director de sorte qu’il établisse les connexions WinRM à l’aide d’une identité de service et accorder à cette identité de service uniquement les permissions nécessaires.
Avec ce modèle, les utilisateurs Director ne sont pas autorisés à passer eux-mêmes des appels WinRM. Ils peuvent uniquement accéder aux données à l’aide de Director.
Le regroupement d’applications Director des services IIS est configuré pour être exécuté comme identité de service. Par défaut, il s’agit du compte virtuel APPPOOL\Director. Lorsque vous établissez des connexions à distance, ce compte apparaît en tant que compte d’ordinateur Active Directory du serveur, par exemple MonDomaine\ServeurDirector$. Vous devez configurer ce compte avec les permissions nécessaires.
Si plusieurs sites Web Director sont déployés, vous devez placer chaque compte d’ordinateur du serveur Web dans un groupe de sécurité Active Directory configuré avec les permissions appropriées.
Pour configurer Director pour utiliser l’identité de service pour WinRM au lieu de l’identité de l’utilisateur, configurez le paramètre suivant, comme décrit dans Configuration avancée :
Service.Connector.WinRM.Identity = Service
<!--NeedCopy-->
Vous pouvez configurer ces permissions de l’une des façons suivantes :
- Ajouter le compte de service au groupe d’administrateurs locaux sur la machine de bureau.
- Accorder au compte de service les permissions spécifiques requises par Director (décrit ci-après). Cette option évite d’accorder au compte de service l’ensemble des permissions administratives sur la machine.
Pour attribuer des permissions à un utilisateur ou à un groupe spécifique
Les permissions suivantes sont requises pour que Director puisse accéder aux informations relatives à la machine de bureau via WinRM :
- Permissions de lecture et d’exécution dans WinRM RootSDDL
- Permissions sur l’espace de nom WMI :
- root/cimv2 - accès distant
- root/citrix - accès distant
- root/RSOP - accès distant et exécution
- Membre de ces groupes locaux :
- Utilisateurs de type contrôle des performances
- Lecteurs de journaux d’événements
L’outil ConfigRemoteMgmt.exe, utilisé pour accorder automatiquement des permissions, est disponible sur le support d’installation dans les dossiers x86\Virtual Desktop Agent et x64\Virtual Desktop Agent et sur le support d’installation dans le dossier C:\inetpub\wwwroot\Director\tools. Vous devez accorder des permissions à tous les utilisateurs Director.
Pour accorder des permissions à un groupe de sécurité, utilisateur, compte d’ordinateur Active Directory, ou pour des actions telles que celles qui consistent à Mettre fin à l’application et Mettre fin au processus, exécutez l’outil avec les privilèges d’administration à partir d’une invite de commande qui utilise les arguments suivants :
ConfigRemoteMgmt.exe /configwinrmuser domain\name
<!--NeedCopy-->
où name correspond au compte du groupe de sécurité, de l’utilisateur ou de l’ordinateur.
Pour accorder les permissions nécessaires à un groupe de sécurité d’utilisateur :
ConfigRemoteMgmt.exe /configwinrmuser domain\HelpDeskUsers
<!--NeedCopy-->
Pour accorder les permissions à un compte d’ordinateur spécifique :
ConfigRemoteMgmt.exe /configwinrmuser domain\DirectorServer$
<!--NeedCopy-->
Pour les actions Mettre fin au processus, Mettre fin à l’application et Observer :
ConfigRemoteMgmt.exe /configwinrmuser domain\name /all
<!--NeedCopy-->
Pour accorder des permissions à un groupe d’utilisateurs :
ConfigRemoteMgmt.exe /configwinrmuser domain\HelpDeskUsers /all
<!--NeedCopy-->
Pour afficher l’aide de l’outil :
ConfigRemoteMgmt.exe
<!--NeedCopy-->
Partager
Partager
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.