Sessions fantômes
La fonctionnalité de sessions fantômes permet aux administrateurs de domaine d’afficher les sessions ICA des utilisateurs au sein d’un intranet. Cette fonctionnalité utilise noVNC pour se connecter aux sessions ICA et est prise en charge uniquement avec RHEL 7.x et Ubuntu 16.04.
Remarque :
Pour utiliser la fonctionnalité de sessions fantômes, la version de Citrix Director doit être 7.16 ou ultérieure.
Installation et configuration
Dépendances
Deux nouvelles dépendances, python-websockify et x11vnc, sont requises pour les sessions fantômes. Les dépendances python-websockify et x11vnc sont automatiquement installées lorsque vous installez le VDA Linux sur Ubuntu 16.04. Sur RHEL 7.x, vous devez installer manuellement python-websockify et x11vnc après avoir installé le VDA Linux.
Exécutez la commande suivante sur RHEL 7.x pour installer python-websockify et x11vnc (version 0.9.13 ou ultérieure de x11vnc).
sudo yum install -y python-websockify x11vnc
<!--NeedCopy-->
Pour résoudre python-websockify et x11vnc, activez les dépôts suivants sur RHEL 7.x :
-
Packages supplémentaires pour Enterprise Linux (EPEL)
Le dépôt EPEL est requis pour
python-websockifyetx11vnc. Exécutez la commande suivante pour activer le dépôt EPEL :sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E '%{rhel}').noarch.rpm <!--NeedCopy--> -
RPM facultatifs
Exécutez l’une des commandes suivantes pour activer le dépôt de RPM facultatifs afin d’installer certains packages de dépendance de x11vnc :
Pour les postes de travail :
subscription-manager repos --enable=rhel-7-workstation-optional-rpms <!--NeedCopy-->Pour les serveurs :
subscription-manager repos --enable=rhel-7-server-optional-rpms <!--NeedCopy--> -
Port
La fonctionnalité de sessions fantômes sélectionne automatiquement les ports disponibles entre 6001 et 6099 pour établir des connexions entre le VDA Linux et Citrix Director. Par conséquent, le nombre de sessions ICA® que vous pouvez mettre en session fantôme simultanément est limité à 99. Assurez-vous qu’un nombre suffisant de ports est disponible pour répondre à vos besoins, en particulier pour les sessions fantômes multisessions.
Registre
Le tableau suivant répertorie les entrées de registre associées :
| Registre | Description | Valeur par défaut |
|---|---|---|
| EnableSessionShadowing | Active ou désactive la fonctionnalité de sessions fantômes | 1 (Activé) |
| ShadowingUseSSL | Détermine s’il faut chiffrer la connexion entre le VDA Linux et Citrix Director | 0 (Désactivé) |
-
Exécutez la commande
ctxregsur le VDA Linux pour modifier les valeurs de registre. Par exemple, pour désactiver les sessions fantômes, exécutez la commande suivante : -
/opt/Citrix/VDA/bin/ctxreg update -k “HKLM\Software\Citrix\VirtualDesktopAgent” -v “EnableSessionShadowing” -d 0x00000000
-
SSL
- La connexion noVNC entre le VDA Linux et Citrix Director utilise le protocole WebSocket. Pour les sessions fantômes, le choix entre
ws://ouwss://est déterminé par l’entrée de registre « ShadowingUseSSL » mentionnée précédemment. Par défaut,ws://est choisi. Cependant, pour des raisons de sécurité, Citrix vous recommande d’utiliserwss://et d’installer des certificats sur chaque client Citrix Director et sur chaque serveur VDA Linux. Citrix décline toute responsabilité en matière de sécurité pour les sessions fantômes du VDA Linux utilisantws://.
Obtenir les certificats SSL de serveur et racine
Les certificats doivent être signés par une autorité de certification (CA) approuvée.
Un certificat de serveur distinct (y compris la clé) est requis pour chaque serveur VDA Linux sur lequel vous souhaitez configurer SSL. Un certificat de serveur identifie un ordinateur spécifique, vous devez donc connaître le nom de domaine complet (FQDN) de chaque serveur. Pour des raisons pratiques, vous pouvez utiliser un certificat générique pour l’ensemble du domaine. Dans ce cas, vous devez connaître au moins le nom de domaine.
En plus d’installer un certificat de serveur sur chaque serveur, vous devez installer un certificat racine de la même CA sur chaque client Citrix Director qui communique avec le serveur VDA Linux. Les certificats racines sont disponibles auprès des mêmes CA qui émettent les certificats de serveur. Vous pouvez installer des certificats de serveur et de client à partir d’une CA fournie avec votre système d’exploitation, d’une CA d’entreprise (une CA que votre organisation met à votre disposition) ou d’une CA non fournie avec votre système d’exploitation. Consultez l’équipe de sécurité de votre organisation pour connaître les méthodes qu’elle exige pour l’obtention des certificats.
Important :
- Le nom commun d’un certificat de serveur doit être le FQDN exact du serveur VDA Linux ou au moins le caractère générique correct plus les caractères de domaine. Par exemple, vda1.basedomain.com ou *.basedomain.com.
- Les algorithmes de hachage, y compris SHA1 et MD5, sont trop faibles pour que les signatures des certificats numériques soient prises en charge par certains navigateurs. SHA-256 est donc spécifié comme norme minimale.
Installer un certificat racine sur chaque client Citrix Director
Les sessions fantômes utilisent le même magasin de certificats basé sur le registre qu’IIS, vous pouvez donc installer des certificats racines à l’aide d’IIS ou du composant logiciel enfichable Certificats de la console de gestion Microsoft (MMC). Lorsque vous recevez un certificat d’une CA, vous pouvez redémarrer l’Assistant Certificat de serveur Web dans IIS et l’assistant installe le certificat. Vous pouvez également afficher et importer des certificats sur l’ordinateur à l’aide de la MMC et ajouter le certificat en tant que composant logiciel enfichable autonome. Internet Explorer et Google Chrome importent les certificats installés sur votre système d’exploitation par défaut. Pour Mozilla Firefox, vous devez importer vos certificats SSL racines sous l’onglet Autorités du Gestionnaire de certificats.
Installer un certificat de serveur et sa clé sur chaque serveur VDA Linux
Nommez les certificats de serveur « shadowingcert.* » et le fichier de clé « shadowingkey.* » (* peut indiquer le format, par exemple, shadowingcert.csr et shadowingkey.key). Placez les certificats de serveur et les fichiers de clé sous le chemin /etc/xdl/shadowingssl et protégez-les correctement avec des autorisations restreintes. Un nom ou un chemin incorrect empêche le VDA Linux de trouver un certificat ou un fichier de clé spécifique et entraîne donc un échec de connexion avec Citrix Director.
Utilisation
Dans Citrix Director, recherchez la session cible et cliquez sur Fantôme dans la vue Détails de la session pour envoyer une demande de session fantôme au VDA Linux.
Une fois la connexion initialisée, une confirmation apparaît sur le client de session ICA (pas le client Citrix Director) pour demander à l’utilisateur l’autorisation de mettre la session en session fantôme.
Si l’utilisateur clique sur Oui, une fenêtre apparaît du côté de Citrix Director, indiquant que la session ICA est en cours de session fantôme.
Pour plus d’informations sur l’utilisation, consultez la documentation de Citrix Director.
Limitations
- Les sessions fantômes sont conçues pour être utilisées uniquement dans un intranet. Elles ne fonctionnent pas pour les réseaux externes, même en se connectant via Citrix Gateway. Citrix décline toute responsabilité concernant les sessions fantômes du VDA Linux dans un réseau externe.
- Lorsque les sessions fantômes sont activées, un administrateur de domaine peut uniquement afficher les sessions ICA, mais n’a pas l’autorisation de les écrire ou de les contrôler.
- Après qu’un administrateur a cliqué sur Fantôme dans Citrix Director, une confirmation apparaît pour demander à l’utilisateur l’autorisation de mettre la session en session fantôme. Une session ne peut être mise en session fantôme que lorsque l’utilisateur de la session donne l’autorisation.
- La confirmation mentionnée précédemment a une limitation de délai d’attente de 20 secondes. Une demande de session fantôme échoue lorsque le délai est écoulé.
-
Une session ICA ne peut être mise en session fantôme que par un seul administrateur dans une seule fenêtre Citrix Director. Si une session ICA a été mise en session fantôme par l’administrateur A et qu’entre-temps, l’administrateur B envoie une demande de session fantôme, la confirmation d’obtention de l’autorisation de l’utilisateur réapparaît sur le périphérique de l’utilisateur. Si l’utilisateur accepte, la connexion de session fantôme pour l’administrateur A s’arrête et une nouvelle connexion de session fantôme est établie pour l’administrateur B. Il en va de même si une autre demande de session fantôme pour la même session ICA est envoyée par le même administrateur.
- Pour utiliser l’observation de session, installez Citrix Director 7.16 ou une version ultérieure.
- Un client Citrix Director utilise un nom de domaine complet (FQDN) plutôt qu’une adresse IP pour se connecter au serveur Linux VDA cible. Par conséquent, le client Citrix Director doit être en mesure de résoudre le FQDN du serveur Linux VDA.
Dépannage
Si l’observation de session échoue, effectuez un débogage sur le client Citrix Director et sur le Linux VDA.
Sur le client Citrix Director
À l’aide des outils de développement du navigateur, vérifiez les journaux de sortie sous l’onglet Console. Vous pouvez également vérifier la réponse de l’API ShadowLinuxSession sous l’onglet Réseau. Si la confirmation d’obtention de l’autorisation de l’utilisateur apparaît mais que la connexion ne peut pas être établie, effectuez un ping manuel sur le FQDN du Linux VDA pour vérifier que Citrix Director peut résoudre le FQDN. S’il y a un problème avec la connexion wss://, vérifiez vos certificats.
Sur le Linux VDA
Vérifiez que la confirmation d’obtention de l’autorisation de l’utilisateur apparaît en réponse à une demande d’observation. Si ce n’est pas le cas, vérifiez les fichiers vda.log et hdx.log pour trouver des indices. Pour obtenir le fichier vda.log, procédez comme suit :
-
Recherchez le fichier /etc/xdl/ctx-vda.conf. Supprimez la mise en commentaire de la ligne suivante pour activer la configuration de vda.log :
Log4jConfig=”/etc/xdl/log4j.xml” -
Ouvrez /etc/xdl/log4j.xml, localisez la partie com.citrix.dmc et remplacez « info » par « trace » comme suit :
<!-- Broker Agent Plugin - Director VDA plugin Logger --> <logger name="com.citrix.dmc"> <level value="trace"/> </logger> <!--NeedCopy--> -
Exécutez la commande
service ctxvda restartpour redémarrer le servicectxvda.
S’il y a une erreur lors de l’établissement de la connexion :
- Vérifiez toute limitation de pare-feu qui empêcherait l’observation de session d’ouvrir le port.
- Vérifiez que les certificats et les fichiers de clés sont correctement nommés et placés dans le chemin d’accès correct s’il s’agit d’un scénario SSL.
- Vérifiez qu’il reste suffisamment de ports entre 6001 et 6099 pour les nouvelles demandes d’observation.