Sombreado de sesiones

El sombreado de sesiones permite a los administradores de dominio ver las sesiones ICA® de los usuarios en una intranet. La función utiliza noVNC para conectarse a las sesiones ICA.

Nota:

Para usar la función, utilice Citrix Director 7.16 o posterior.

Instalación y configuración

Dependencias

Se requieren dos nuevas dependencias, python-websockify y x11vnc, para el sombreado de sesiones. Instale python-websockify y x11vnc manualmente después de instalar el VDA de Linux.

Para Amazon Linux2:

Ejecute los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior):

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

Para RHEL 9.x/8.x y Rocky Linux 9.x/8.x:

Ejecute los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior).

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

Resuelva x11vnc habilitando los repositorios EPEL y 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-->

Para Ubuntu:

Ejecute los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior):

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

Para SUSE:

Primero, habilite el módulo “SUSE Linux Enterprise Workstation Extension 15 SP6” usando YaST o el siguiente comando de SUSEConnect:

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

Para obtener más información, consulte la documentación de SUSE: https://documentation.suse.com/es-es/sles/15-SP6/html/SLES-all/article-modules.html.

Luego, ejecute los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior):

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

Para Debian 12:

Ejecute los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior):

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

Para Debian 11:

Ejecute los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior):

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

Puerto

La función de shadowing de sesión selecciona automáticamente los puertos disponibles dentro del rango 6001-6099 para establecer conexiones desde el VDA de Linux a Citrix Director. Por lo tanto, el número de sesiones ICA que puede sombrear simultáneamente está limitado a 99. Asegúrese de que haya suficientes puertos disponibles para satisfacer sus requisitos, especialmente para el shadowing de múltiples sesiones.

Registro

La siguiente tabla enumera los registros relacionados:

Ejecute el comando ctxreg en el VDA de Linux para cambiar los valores del registro. Por ejemplo, para inhabilitar la proyección de sesiones, ejecute el siguiente comando:

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

SSL

La conexión noVNC entre el VDA de Linux y Citrix Director utiliza el protocolo WebSocket. Para la proyección de sesiones, la elección de ws:// o wss:// depende del registro “ShadowingUseSSL” mencionado anteriormente. De forma predeterminada, se elige ws://. Sin embargo, por motivos de seguridad, le recomendamos que utilice wss:// e instale certificados en cada cliente de Citrix Director y en cada servidor VDA de Linux. Citrix declina cualquier responsabilidad de seguridad por la proyección de sesiones del VDA de Linux al usar ws://.

Para habilitar SSL, ejecute el siguiente comando:

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

Obtener certificados SSL de servidor y raíz

Los certificados deben estar firmados por una entidad de certificación (CA) de confianza.

Se requiere un certificado de servidor independiente (incluida la clave) para cada servidor VDA de Linux en el que desee configurar SSL. Un certificado de servidor identifica un equipo específico, por lo que debe conocer el nombre de dominio completo (FQDN) de cada servidor. Para mayor comodidad, considere la posibilidad de utilizar un certificado comodín para todo el dominio.

También se requiere un certificado raíz para cada cliente de Citrix Director que se comunica con el VDA de Linux. Los certificados raíz están disponibles en las mismas CA que emiten los certificados de servidor.

Puede instalar certificados de servidor y cliente de las siguientes CA:

• Una CA que se incluye con su sistema operativo
• Una CA empresarial (una CA a la que su organización le da acceso)
• Una CA no incluida en el sistema operativo

Consulte al equipo de seguridad de su organización para averiguar qué métodos requieren para obtener certificados.

Importante:

• El nombre común de un certificado de servidor debe ser el FQDN exacto del VDA de Linux o, al menos, el comodín correcto más los caracteres de dominio. Por ejemplo, vda1.basedomain.com o *.basedomain.com.
• Los algoritmos de hash, incluidos SHA1 y MD5, son demasiado débiles para las firmas en certificados digitales para que algunos exploradores los admitan. Por lo tanto, SHA-256 se especifica como el estándar mínimo.
• Chrome ha dejado de aceptar certificados SSL autofirmados, considerándolos inseguros. El error NET::ERR_CERT_COMMON_NAME_INVALID se produce porque el certificado generado carece del campo SAN (subjectAltName). Para resolver este problema, proporcione un certificado con atributos extendidos (extensiones X509 v3) que incluyan el campo SAN.

Instalar un certificado raíz en cada cliente de Citrix Director

El shadowing de sesiones utiliza el mismo almacén de certificados basado en el Registro que IIS, por lo que puede instalar certificados raíz mediante IIS o el complemento Certificados de Microsoft Management Console (MMC). Cuando reciba un certificado de una CA, puede reiniciar el Asistente para certificados de servidor web en IIS y el asistente instalará el certificado. Alternativamente, puede ver e importar certificados en el equipo mediante MMC y agregar el certificado como un complemento independiente. Internet Explorer y Google Chrome importan los certificados instalados en su sistema operativo de forma predeterminada. Para Mozilla Firefox, debe importar sus certificados de CA raíz en la ficha Autoridades del Administrador de certificados.

Instalar un certificado de servidor y su clave en cada servidor VDA de Linux

Asigne a los certificados de servidor el nombre “shadowingcert.*” y al archivo de clave “shadowingkey.*” (* indica el formato, por ejemplo, shadowingcert.pem y shadowingkey.key). Coloque los certificados de servidor y los archivos de clave en la ruta /etc/xdl/shadowingssl y protéjalos correctamente con permisos restringidos, permitiendo que solo ctxsrvr tenga acceso de lectura. Un nombre o una ruta incorrectos impiden que el VDA de Linux encuentre un certificado o un archivo de clave específicos y, por lo tanto, provocan un error de conexión con Citrix Director. Los comandos son los siguientes:

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-->

Uso

Desde Citrix Director, busque la sesión de destino y haga clic en Shadow en la vista Session Details para enviar una solicitud de shadowing al VDA de Linux.

Una vez que se inicializa la conexión, aparece una confirmación en el cliente de sesión ICA (no en el cliente Citrix Director) para solicitar al usuario permiso para hacer shadowing de la sesión.

Si el usuario hace clic en Sí, aparece una ventana en el lado Citrix Director, lo que indica que la sesión de ICA se está supervisando.

Para obtener más información sobre el uso, consulte la documentación de Citrix Director.

Limitaciones

• Si sus VDA están unidos a un dominio y están alojados en Microsoft Azure mediante Azure Active Directory (AAD) para la autenticación, la función de supervisión de sesiones no funciona.
• La supervisión de sesiones está diseñada para usarse solo en una intranet. No funciona para redes externas, incluso si se conecta a través de Citrix Gateway. Citrix declina toda responsabilidad por la supervisión de sesiones de Linux VDA en una red externa.
• Con la supervisión de sesiones habilitada, un administrador de dominio solo puede ver las sesiones de ICA, pero no tiene permiso para escribirlas ni controlarlas.
• Después de que un administrador haga clic en Supervisar desde Citrix Director, aparece una confirmación para solicitar al usuario permiso para supervisar la sesión. Una sesión solo se puede supervisar cuando el usuario de la sesión da el permiso.
• La confirmación mencionada anteriormente tiene una limitación de tiempo de espera de 20 segundos. Una solicitud de supervisión falla cuando se agota el tiempo.
• Una sesión solo puede ser supervisada por un administrador. Por ejemplo, si el administrador B envía una solicitud de supervisión para una sesión que el administrador A está supervisando, la confirmación para obtener el permiso del usuario reaparece en el dispositivo del usuario. Si el usuario acepta, la conexión de supervisión del administrador A se detiene y se establece una nueva conexión de supervisión para el administrador B. Si un administrador envía otra solicitud de supervisión para la misma sesión, también se puede establecer una nueva conexión de supervisión.
• Para usar la supervisión de sesiones, instale Citrix Director 7.16 o posterior.
• Un cliente Citrix Director utiliza un FQDN en lugar de una dirección IP para conectarse al servidor Linux VDA de destino. Por lo tanto, el cliente Citrix Director debe poder resolver el FQDN del servidor Linux VDA.

Solución de problemas

Si la supervisión de sesiones falla, depure tanto el cliente Citrix Director como el Linux VDA.

En el cliente de Citrix Director

A través de las herramientas para desarrolladores del explorador, compruebe los registros de salida en la pestaña Consola. O bien, compruebe la respuesta de la API ShadowLinuxSession en la pestaña Red. Si aparece la confirmación para obtener el permiso de usuario, pero falla el establecimiento de la conexión, haga ping manualmente al FQDN del VDA para verificar que Citrix Director puede resolver el FQDN. Si hay un problema con la conexión wss://, compruebe sus certificados.

En el VDA de Linux

1. Compruebe el archivo /var/log/xdl/vda.log en busca de pistas.

2. Edite el archivo /var/xdl/sessionshadowing.sh y cambie la variable ‘logFile’ para especificar un archivo de registro que se pueda rastrear en busca de pistas durante el shadowing de sesiones desde el director.

3. Además, puede verificar manualmente si sus certificados funcionan correctamente con la conexión noVNC:

   1. Ejecute ps aux | grep xorg para encontrar el número de pantalla Xorg de la sesión actual $display-num, por ejemplo, :3.

   2. Ejecute el siguiente comando para iniciar un servidor x11vnc y espere una conexión entrante.

      Nota:

      Antes de ejecutar el siguiente comando, establezca las variables $passwd, $port y $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. Intente conectarse mediante noVNC para verificar el modo SSL de la siguiente manera. Introduzca el FQDN de su VDA y el número de puerto. En este ejemplo, el número de puerto es 6009.

      

   4. Resuelva cualquier error impreso por Websockify en el VDA o notificado por el explorador en el cliente.

      Puntos de control clave durante el establecimiento de la conexión:

      1. Compruebe si hay alguna limitación del firewall que impida que el shadowing de sesiones abra el puerto.
      2. verificar que ha nombrado correctamente los certificados y los archivos de clave y los ha colocado en la ruta correcta si se trata del escenario SSL.
      3. verificar que queden suficientes puertos entre 6001-6099 para nuevas solicitudes de shadowing.
      4. Ejecute openssl x509 -in shadowingcert.pem -text -noout para verificar que los certificados están configurados correctamente, prestando especial atención a los campos CN y SAN.

      5. En RHEL 8, puede haber un problema por el que no se encuentre rebind.so. Para resolver este problema, ejecute el siguiente comando:

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