Observation de session
L’observation de sessions permet aux administrateurs de domaine d’afficher les sessions ICA d’utilisateurs dans un intranet. La fonctionnalité utilise noVNC pour se connecter aux sessions ICA.
Remarque
Cette fonctionnalité requiert la version 7.16 de
Citrix Directorou une version ultérieure.
Installation et configuration
Dépendances
Pour observer des sessions, vous aurez besoin des deux nouvelles dépendances, python-websockify et x11vnc. Installez python-websockify et x11vnc manuellement après avoir installé le Linux VDA.
Amazon Linux 2 :
Pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure), exécutez les commandes suivantes :
sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->
Si vous utilisez RHEL 9.x/8.x et Rocky Linux 9.x/8.x :
Pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure), exécutez les commandes suivantes.
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 :
Pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure), exécutez les commandes suivantes :
sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
Pour SUSE :
Pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure), exécutez les commandes suivantes :
sudo pip3 install websockify
sudo zypper install x11vnc
<!--NeedCopy-->
Pour Debian 12 :
Pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure), exécutez les commandes suivantes :
apt install python3-websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
Pour Debian 11 :
Pour installer python-websockify et x11vnc (x11vnc version 0.9.13 ou ultérieure), exécutez les commandes suivantes :
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 entre le Linux VDA et 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-sessions.
Registre
Le tableau suivant répertorie les registres associés :
| Registre | Description | Valeur par défaut |
|---|---|---|
| EnableSessionShadowing | Active ou désactive la fonctionnalité d’observation de session | 1 (activé) |
| ShadowingUseSSL | Détermine si vous souhaitez crypter la connexion entre le Linux VDA et Citrix Director | 0 (désactivé) |
Exécutez la commande ctxreg sur le Linux VDA 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 Linux VDA et Citrix Director utilise le protocole WebSocket. Pour l’observation des sessions, le choix de ws:// ou de wss:// dépend du registre « ShadowingUseSSL » mentionné précédemment. Par défaut, ws:// est choisi. Toutefois, 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 Linux VDA. Citrix décline toute responsabilité en matière de sécurité en ce qui concerne l’observation de session de Linux VDA avec l’utilisation de ws://.
Pour activer le protocole SSL, exécutez la commande suivante :
/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "ShadowingUseSSL" -d "0x00000001"
<!--NeedCopy-->
Obtenir des certificats SSL serveur et racine
Les certificats doivent être signés par une autorité de certification (AC).
Un certificat de serveur distinct (y compris la clé) est requis pour chaque serveur Linux VDA sur lequel vous souhaitez configurer SSL. Un certificat de serveur identifie une machine. Vous devez donc connaître le nom de domaine complet (FQDN) de chaque serveur. Pour plus de commodité, pensez à 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 Linux VDA. Les autorités de certification émettant des certificats de serveur émettent aussi les certificats racines.
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 autorité de certification d’entreprise (une autorité de certification que votre organisation met à votre disposition)
- Une autorité de certification non fournie avec votre système d’exploitation
Consultez l’équipe des experts en sécurité de votre organisation afin de trouver parmi les méthodes celle requise pour l’obtention des certificats.
Important :
- Le nom commun d’un certificat de serveur doit être le nom de domaine complet exact du Linux VDA ou, au moins, les caractères générique + domaine corrects. Par exemple, vda1.basedomain.com ou *.basedomain.com.
- Les algorithmes de hachage, y compris SHA1 et MD5, sont trop faibles pour les signatures dans les certificats numériques pour certains navigateurs. SHA-256 est donc spécifié comme standard minimum.
- 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_INVALIDse produit lorsque le champ SAN (subjectAltName) est manquant sur le certificat généré. 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 qu’IIS (reposant sur le registre). Par conséquent, vous pouvez installer les certificats à l’aide d’IIS ou du composant logiciel enfichable MMC (Microsoft Management Console). Après avoir reçu un certificat d’une autorité de certification, vous pouvez redémarrer l’assistant Certificat de serveur Web d’IIS. L’assistant installe alors le certificat. Vous pouvez également afficher et importer des certificats sur l’ordinateur en utilisant la console 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 CA racine dans l’onglet Autorités du gestionnaire de certificats.
Installer un certificat de serveur et sa clé sur chaque serveur Linux VDA
Nommez les certificats de serveur « shadowingcert.* » et le fichier clé « shadowingkey.* » (* indique le format, par exemple, shadowingcert.pem et shadowingkey.key). Placez les certificats de serveur et les fichiers de clés sous le chemin /etc/xdl/shadowingssl et protégez-les correctement avec des autorisations restreintes, en autorisant uniquement ctxsrvr à disposer d’un accès en lecture. Si le nom ou le chemin est incorrect, le Linux VDA est incapable de trouver un certificat ou un fichier de clé spécifique et, par conséquent, cela entraîne une défaillance de la 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
Dans Citrix Director, recherchez la session cible et cliquez sur Observer dans la vue Détails de la session pour envoyer une demande d’observation à l’agent Linux VDA.
Une fois que la connexion s’initialise, une confirmation s’affiche sur le client de session ICA (pas le client Citrix Director) pour demander l’autorisation d’observer la session.
Si l’utilisateur clique sur Oui, une fenêtre s’affiche du côté Citrix Director, indiquant que la session ICA est en cours d’observation.
Pour de plus amples informations sur l’utilisation, veuillez consulter la documentation de Citrix Director.
Limitations
- Si vos VDA sont associés à un domaine et hébergés sur Microsoft Azure via Azure Active Directory (AAD) pour l’authentification, la fonctionnalité d’observation de session ne fonctionne pas.
- L’observation de session est conçue pour une utilisation dans un intranet uniquement. Elle ne fonctionne pas pour les réseaux externes même en se connectant via Citrix Gateway. Citrix décline toute responsabilité en ce qui concerne l’observation de session de 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, et n’a pas l’autorisation d’écrire dessus ou de le contrôler.
- Une fois qu’un administrateur a cliqué sur Observer depuis
Citrix Director, une confirmation s’affiche pour demander l’autorisation à l’utilisateur d’observer la session. Une session peut être observée uniquement lorsque l’utilisateur de la session en donne l’autorisation. - La confirmation mentionnée précédemment a un délai d’expiration, qui est de 20 secondes. Une demande d’observation échoue lorsque ce délai est écoulé.
- Une session peut être observée 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 d’obtention de l’autorisation de l’utilisateur réapparaît sur la machine utilisateur. Si l’utilisateur donne son autorisation, la connexion d’observation de l’administrateur A s’arrête et une nouvelle connexion d’observation est créée 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 créée.
- Pour utiliser l’observation de session, installez
Citrix Director7.16 ou version ultérieure. - Un client
Citrix Directorutilise un nom de domaine complet plutôt qu’une adresse IP pour se connecter au serveur Linux VDA cible. Par conséquent, le clientCitrix Directordoit pouvoir résoudre le nom de domaine complet du serveur Linux VDA.
Dépannage
Si l’observation de session échoue, procédez au débogage à la fois 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 dans l’onglet Console. Ou vérifiez la réponse de l’API ShadowLinuxSession dans l’onglet Réseau. Si la confirmation de l’autorisation de l’utilisateur s’affiche, mais que l’établissement de la connexion échoue, envoyez manuellement une requête ping au nom de domaine complet du VDA pour vérifier que Citrix Director peut résoudre le nom de domaine complet. En cas de problème avec la connexion wss://, vérifiez vos certificats.
Sur le Linux VDA
-
Consultez le fichier
/var/log/xdl/vda.logpour trouver des indices. -
Modifiez le fichier
/var/xdl/sessionshadowing.shet la variable « logFile » pour spécifier un fichier journal pouvant être suivi dans Director afin de rechercher des indices lors de l’observation des sessions. -
Vous pouvez également vérifier manuellement si vos certificats fonctionnent correctement via une connexion noVNC :
-
Exécutez ps aux |grep xorg pour trouver le numéro d’affichage Xorg $display-numde la session en cours, par exemple :3.
-
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--> -
Essayez de vous connecter via noVNC pour vérifier le mode SSL comme suit. Entrez le nom de domaine complet de votre VDA et le numéro de port. Dans cet exemple, le numéro de port est 6009.
-
Résolvez toutes les erreurs imprimées par Websockify sur le VDA ou signalées par le navigateur sur le client.
Principaux points de contrôle lors de l’établissement de la connexion :
- Recherchez toute limitation de pare-feu qui empêche 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 sous le bon chemin pour un scénario SSL.
- Vérifiez qu’il reste suffisamment de ports entre 6001 et 6099 pour les nouvelles demandes d’observation.
- Vérifiez que l’utilitaire « netstat » est installé, car il est nécessaire au fichier
/var/xdl/sessionshadowing.sh. - Exécutez
openssl x509 -in shadowingcert.pem -text -nooutpour vérifier que les certificats sont correctement configurés, en prêtant une attention particulière aux champs CN et SAN. -
Sur RHEL 8, un problème peut survenir selon lequel
rebind.soest introuvable. Pour résoudre ce problème, exécutez la commande suivante :ln -s /usr/bin/rebind.so /usr/local/bin/rebind.so <!--NeedCopy-->
-