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 :
Pour utiliser cette fonctionnalité, utilisez
Citrix Director7.16 ou une version ultérieure.
Installation et configuration
Dépendances
Deux nouvelles dépendances, python-websockify et x11vnc, sont nécessaires pour l’observation de session. Installez manuellement python-websockify et x11vnc après avoir installé le Linux VDA.
Pour RHEL 7.x et 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 7.x) Résolvez python-websockify et x11vnc en activant Extra Packages for Enterprise Linux (EPEL) et les référentiels RPM facultatifs :
-
EPEL
Le référentiel EPEL est requis pour
x11vnc. Pour activer le référentiel EPEL, exécutez la commande suivante :yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm <!--NeedCopy--> -
RPM facultatifs
Exécutez la commande suivante pour activer le référentiel de
RPMsfacultatifs pour l’installation de certains packages de dépendances dex11vnc:subscription-manager repos --enable rhel-7-server-optional-rpms --enable rhel-7-server-extras-rpms <!--NeedCopy-->
Pour RHEL 9.4/9.3/9.2/9.0/8.x et Rocky Linux 9.4/9.3/9.2/9.0/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 :
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 :
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 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 de session, le choix entre ws:// ou 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 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, car le champ SAN (subjectAltName) ne figure pas dans le certificat généré. Pour résoudre ce problème, fournissez un certificat dont les attributs étendus (extensions X509 v3) 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
Appelez les certificats de serveur « shadowingcert.* » et le fichier de clé « shadowingkey.* » (* peut indiquer le format, par exemple, shadowingcert.pem et shadowingkey.key). Placez les certificats de serveur et les fichiers de clés sous le chemin d’accès /etc/xdl/shadowingssl et protégez-les correctement avec des autorisations restreintes, pour ne permettre l’accès en lecture qu’à ctxsrvr. 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 appartiennent à un domaine et sont hébergés sur Microsoft Azure à l’aide d’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 accepte, la connexion d’observation pour 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, effectuez le 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’obtention de l’autorisation de l’utilisateur s’affiche mais que la connexion ne parvient pas à être établie, envoyez une commande ping manuelle 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
-
Recherchez des indices dans le fichier
/var/log/xdl/vda.log. -
Modifiez le fichier
/var/xdl/sessionshadowing.shet modifiez la variable « logFile » pour spécifier un fichier journal qui peut être consulté pour rechercher des indices lors de l’observation de la session par Director. -
Vous pouvez également vérifier manuellement si vos certificats fonctionnent correctement avec la connexion noVNC :
-
Exécutez ps aux | grep xorg pour trouver le numéro d’affichage Xorg de la session en cours
<display-num>, par exemple,:3. -
Exécutez la commande suivante pour démarrer un serveur x11vnc, puis attendez une connexion entrante.
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 à l’aide de 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 « netstat » est installé, car il est requis par
/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-->
-