Mise en miroir de session

La mise en miroir de sessions permet aux administrateurs de domaine d’afficher les sessions ICA® des utilisateurs dans un intranet. Cette fonctionnalité utilise noVNC pour se connecter aux sessions ICA.

Remarque :

Pour utiliser cette fonctionnalité, utilisez Citrix Director 7.16 ou version ultérieure.

Installation et configuration

Dépendances

Deux nouvelles dépendances, python-websockify et x11vnc, sont requises pour la mise en miroir de session. Installez python-websockify et x11vnc manuellement après avoir installé le VDA Linux.

Pour Amazon Linux2 :

Exécutez les commandes suivantes pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure) :

sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->

Pour RHEL 9.x/8.x et Rocky Linux 9.x/8.x :

Exécutez les commandes suivantes pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure).

sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->

Résolvez x11vnc en activant les référentiels EPEL et CodeReady Linux Builder :

dnf install -y --nogpgcheck https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

subscription-manager repos --enable "codeready-builder  -for-rhel-8-x86_64-rpms"
<!--NeedCopy-->

Pour Ubuntu :

Exécutez les commandes suivantes pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure) :

sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->

Pour SUSE :

Tout d’abord, activez le module « SUSE Linux Enterprise Workstation Extension 15 SP6 » à l’aide de YaST ou de la commande SUSEConnect suivante :

suseconnect -p sle-we/15.6/x86_64 -r <regcode>
<!--NeedCopy-->

Pour plus d’informations, consultez la documentation SUSE : https://documentation.suse.com/fr-fr/sles/15-SP6/html/SLES-all/article-modules.html.

Ensuite, exécutez les commandes suivantes pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure) :

sudo pip3 install websockify
sudo zypper install x11vnc
<!--NeedCopy-->

Pour Debian 12 :

Exécutez les commandes suivantes pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure) :

apt install python3-websockify
sudo apt-get install x11vnc
<!--NeedCopy-->

Pour Debian 11 :

Exécutez les commandes suivantes pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure) :

sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->

Port

La fonctionnalité d’observation de session sélectionne automatiquement les ports disponibles entre 6001 et 6099 pour établir des connexions du VDA Linux vers Citrix Director. Par conséquent, le nombre de sessions ICA que vous pouvez observer simultanément est limité à 99. Assurez-vous que suffisamment de ports sont disponibles pour répondre à vos besoins, en particulier pour l’observation multi-session.

Registre

Le tableau suivant répertorie les entrées de registre associées :

Exécutez la commande ctxreg sur le VDA Linux pour modifier les valeurs de registre. Par exemple, pour désactiver l’observation de session, exécutez la commande suivante :

/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "EnableSessionShadowing" -d "0x00000000"
<!--NeedCopy-->

SSL

La connexion noVNC entre le VDA Linux et Citrix Director utilise le protocole WebSocket. Pour l’observation de session, le choix de ws:// ou wss:// dépend du registre « ShadowingUseSSL » mentionné précédemment. Par défaut, ws:// est choisi. Cependant, pour des raisons de sécurité, nous vous recommandons d’utiliser wss:// 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 l’observation de session du VDA Linux en utilisant ws://.

Pour activer SSL, exécutez la commande suivante :

/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "ShadowingUseSSL" -d "0x00000001"
<!--NeedCopy-->

Obtenir les certificats SSL de serveur et racine

Les certificats doivent être signés par une autorité de certification (CA) fiable.

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 de commodité, envisagez d’utiliser un certificat générique pour l’ensemble du domaine.

Un certificat racine est également requis pour chaque client Citrix Director qui communique avec le VDA Linux. Les certificats racines sont disponibles auprès des mêmes autorités de certification qui émettent les certificats de serveur.

Vous pouvez installer des certificats de serveur et de client à partir des autorités de certification suivantes :

• Une autorité de certification fournie avec votre système d’exploitation
• Une CA d’entreprise (une CA que votre organisation vous rend accessible)
• Une CA non fournie avec votre système d’exploitation

Consultez l’équipe de sécurité de votre organisation pour savoir quelles méthodes elle exige pour obtenir des certificats.

Important :

• Le nom commun d’un certificat de serveur doit être le FQDN exact du 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 les signatures de certificats numériques pour que certains navigateurs les prennent en charge. SHA-256 est donc spécifié comme norme minimale.
• Chrome a cessé d’accepter les certificats SSL auto-signés, les considérant comme non sécurisés. L’erreur NET::ERR_CERT_COMMON_NAME_INVALID se produit car le certificat généré ne contient pas le champ SAN (subjectAltName). Pour résoudre ce problème, fournissez un certificat avec des attributs étendus (extensions X509 v3) qui incluent le champ SAN.

Installer un certificat racine sur chaque client Citrix Director

L’observation de session utilise 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 par défaut les certificats installés sur votre système d’exploitation. Pour Mozilla Firefox, vous devez importer vos certificats CA racines dans 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.* » (* indique le format, par exemple, shadowingcert.pem 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, en n’autorisant que ctxsrvr à avoir un accès en lecture. Un nom ou un chemin incorrect empêche le VDA Linux de trouver un certificat ou un fichier de clé spécifique et provoque donc un échec de connexion avec Citrix Director. Les commandes sont les suivantes :

cp <vda's-public-key> /etc/xdl/shadowingssl/shadowingcert.pem
cp <vda's-server-private-key> /etc/xdl/shadowingssl/shadowingkey.key
sudo chown ctxsrvr:ctxadm  /etc/xdl/shadowingssl/shadowingcert.pem
sudo chown ctxsrvr:ctxadm  /etc/xdl/shadowingssl/shadowingkey.key
<!--NeedCopy-->

Utilisation

Depuis Citrix Director, recherchez la session cible et cliquez sur Observer dans la vue Détails de la session pour envoyer une demande d’observation 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 d’observer la session.

Si l’utilisateur clique sur Oui, une fenêtre apparaît du côté Citrix Director, indiquant que la session ICA est en cours d’observation.

Pour plus d’informations sur l’utilisation, consultez la documentation de Citrix Director.

Limitations

• Si vos VDA sont joints à un domaine et sont hébergés sur Microsoft Azure à l’aide d’Azure Active Directory (AAD) pour l’authentification, la fonction d’observation de session ne fonctionne pas.
• L’observation de session est conçue pour être utilisée uniquement dans un Intranet. Elle ne fonctionne pas pour les réseaux externes, même en se connectant via Citrix Gateway. Citrix décline toute responsabilité concernant l’observation de session Linux VDA dans un réseau externe.
• Lorsque l’observation de session est activée, 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 Observer depuis Citrix Director, une confirmation apparaît pour demander à l’utilisateur l’autorisation d’observer la session. Une session ne peut être observée que lorsque l’utilisateur de la session donne son autorisation.
• La confirmation mentionnée précédemment a une limite de temps d’attente de 20 secondes. Une demande d’observation échoue lorsque le temps est écoulé.
• Une session ne peut être observée que par un seul administrateur. Par exemple, si l’administrateur B envoie une demande d’observation pour une session que l’administrateur A est en train d’observer, la confirmation pour obtenir l’autorisation de l’utilisateur réapparaît sur le périphérique de l’utilisateur. Si l’utilisateur accepte, la connexion d’observation de l’administrateur A s’arrête et une nouvelle connexion d’observation est établie pour l’administrateur B. Si un administrateur envoie une autre demande d’observation pour la même session, une nouvelle connexion d’observation peut également être établie.
• 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 VDA Linux cible. Par conséquent, le client Citrix Director doit être capable de résoudre le FQDN du serveur VDA Linux.

Dépannage

Si l’observation de session échoue, effectuez un débogage à la fois sur le client Citrix Director et sur le VDA Linux.

Sur le client Citrix Director

Via les outils de développement du navigateur, vérifiez les journaux de sortie dans l’onglet Console. Ou, vérifiez la réponse de l’API ShadowLinuxSession dans l’onglet Réseau. Si la confirmation d’obtention de l’autorisation de l’utilisateur apparaît mais que l’établissement de la connexion échoue, effectuez un ping manuel du FQDN du 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 VDA Linux

1. Vérifiez le fichier /var/log/xdl/vda.log pour des indices.

2. Modifiez le fichier /var/xdl/sessionshadowing.sh et changez la variable ‘logFile’ pour spécifier un fichier journal qui peut être suivi pour des indices pendant l’observation de session depuis le directeur.

3. Vous pouvez également vérifier manuellement si vos certificats fonctionnent correctement avec la connexion noVNC :

   1. Exécutez ps aux | grep xorg pour trouver le numéro d’affichage Xorg de la session actuelle $display-num, par exemple, :3.

   2. Exécutez la commande suivante pour démarrer un serveur x11vnc et attendre une connexion entrante.

      Remarque :

      Avant d’exécuter la commande suivante, définissez les variables $passwd, $port, $display-num.

      runuser -l "ctxsrvr" -s /bin/bash -c "websockify <port> -v --cert  /etc/xdl/shadowingssl/shadowingcert.pem --key  /etc/xdl/shadowingssl/shadowingkey.key -- x11vnc  -viewonly  -shared -passwd $passwd -rfbport $port -display $display-num -many -o /var/log/xdl/x11vnc.log"
      <!--NeedCopy-->
      

   3. Essayez de vous connecter à l’aide de noVNC pour vérifier le mode SSL comme suit. Saisissez le FQDN de votre VDA et le numéro de port. Dans cet exemple, le numéro de port est 6009.

      

   4. Résolvez toutes les erreurs affichées par Websockify sur le VDA ou signalées par le navigateur sur le client.

      Points de contrôle clés lors de l’établissement de la connexion :

      1. Vérifiez toute limitation de pare-feu qui empêche l’observation de session d’ouvrir le port.
      2. Vérifiez que vous avez correctement nommé les certificats et les fichiers de clés et que vous les avez placés au bon endroit s’il s’agit du scénario SSL.
      3. Vérifiez qu’il reste suffisamment de ports entre 6001 et 6099 pour les nouvelles requêtes d’observation de session.
      4. Exécutez openssl x509 -in shadowingcert.pem -text -noout pour vérifier que les certificats sont configurés correctement, en accordant une attention particulière aux champs CN et SAN.

      5. Sur RHEL 8, il peut y avoir un problème où rebind.so est introuvable. Pour résoudre ce problème, exécutez la commande suivante :

         ln -s /usr/bin/rebind.so /usr/local/bin/rebind.so
         <!--NeedCopy-->