Sesiones en la sombra
La función de sesiones en la sombra permite a los administradores de dominio ver las sesiones ICA de los usuarios en una intranet. Esta función usa noVNC para conectarse a las sesiones ICA y solo es compatible con RHEL 7.x y Ubuntu 16.04.
Nota:
Para usar la función de sesiones en la sombra, la versión de Citrix Director debe ser 7.16 o posterior.
Instalación y configuración
Dependencias
Se requieren dos nuevas dependencias, python-websockify y x11vnc, para las sesiones en la sombra. Las dependencias python-websockify y x11vnc se instalan automáticamente cuando instalas el VDA de Linux en Ubuntu 16.04. En RHEL 7.x, debes instalar manualmente python-websockify y x11vnc después de instalar el VDA de Linux.
Ejecuta el siguiente comando en RHEL 7.x para instalar python-websockify y x11vnc (versión 0.9.13 o posterior de x11vnc).
sudo yum install -y python-websockify x11vnc
<!--NeedCopy-->
Para resolver python-websockify y x11vnc, habilita los siguientes repositorios en RHEL 7.x:
-
Extra Packages for Enterprise Linux (EPEL)
El repositorio EPEL es necesario tanto para
python-websockifycomo parax11vnc. Ejecuta el siguiente comando para habilitar el repositorio EPEL:sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E '%{rhel}').noarch.rpm <!--NeedCopy--> -
RPM opcionales
Ejecuta cualquiera de los siguientes comandos para habilitar el repositorio de RPM opcionales para instalar algunos paquetes de dependencia de x11vnc:
Para estaciones de trabajo:
subscription-manager repos --enable=rhel-7-workstation-optional-rpms <!--NeedCopy-->Para servidores:
subscription-manager repos --enable=rhel-7-server-optional-rpms <!--NeedCopy--> -
Puerto
La función de sesiones en la sombra selecciona automáticamente los puertos disponibles entre 6001 y 6099 para establecer conexiones desde el VDA de Linux a Citrix Director. Por lo tanto, el número de sesiones ICA® que puedes sombrear simultáneamente está limitado a 99. Asegúrate de que haya suficientes puertos disponibles para satisfacer tus requisitos, especialmente para sesiones en la sombra múltiples.
Registro
La siguiente tabla enumera los registros relacionados:
| Registro | Descripción | Valor predeterminado |
|---|---|---|
| EnableSessionShadowing | Habilita o deshabilita la función de sesiones en la sombra | 1 (Habilitado) |
| ShadowingUseSSL | Determina si se debe cifrar la conexión entre el VDA de Linux y Citrix Director | 0 (Deshabilitado) |
-
Ejecuta el comando
ctxregen el VDA de Linux para cambiar los valores del registro. Por ejemplo, para deshabilitar las sesiones en la sombra, ejecuta el siguiente comando: -
/opt/Citrix/VDA/bin/ctxreg update -k “HKLM\Software\Citrix\VirtualDesktopAgent” -v “EnableSessionShadowing” -d 0x00000000
-
SSL
- La conexión noVNC entre el VDA de Linux y Citrix Director usa el protocolo WebSocket. Para las sesiones en la sombra, la elección de
ws://owss://se determina por el registro “ShadowingUseSSL” mencionado anteriormente. Por defecto, se eligews://. Sin embargo, por razones de seguridad, Citrix recomienda que useswss://e instales certificados en cada cliente de Citrix Director y en cada servidor VDA de Linux. Citrix declina cualquier responsabilidad de seguridad por las sesiones en la sombra del VDA de Linux al usarws://.
Obtener certificados SSL de servidor y raíz
Los certificados deben estar firmados por una Autoridad 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 quieras configurar SSL. Un certificado de servidor identifica un equipo específico, por lo que debes conocer el nombre de dominio completo (FQDN) de cada servidor. Para mayor comodidad, puedes usar un certificado comodín para todo el dominio. En este caso, debes conocer al menos el nombre de dominio.
Además de instalar un certificado de servidor en cada servidor, debes instalar un certificado raíz de la misma CA en cada cliente de Citrix Director que se comunique con el servidor VDA de Linux. Los certificados raíz están disponibles en las mismas CA que emiten los certificados de servidor. Puedes instalar certificados de servidor y cliente de una CA que venga incluida con tu sistema operativo, de una CA empresarial (una CA que tu organización pone a tu disposición) o de una CA no incluida con tu sistema operativo. Consulta al equipo de seguridad de tu organización para saber qué método requieren para obtener certificados.
Importante:
- El nombre común de un certificado de servidor debe ser el FQDN exacto del servidor 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 navegadores los admitan. Por lo tanto, SHA-256 se especifica como el estándar mínimo.
Instalar un certificado raíz en cada cliente de Citrix Director
Las sesiones en la sombra usan el mismo almacén de certificados basado en el registro que IIS, por lo que puedes instalar certificados raíz usando IIS o el complemento de certificados de Microsoft Management Console (MMC). Cuando recibas un certificado de una CA, puedes reiniciar el Asistente para certificados de servidor web en IIS y el asistente instalará el certificado. Alternativamente, puedes ver e importar certificados en el equipo usando la MMC y agregar el certificado como un complemento independiente. Internet Explorer y Google Chrome importan los certificados instalados en tu sistema operativo por defecto. Para Mozilla Firefox, debes importar tus certificados SSL raíz en la ficha Autoridades del Administrador de certificados.
Instalar un certificado de servidor y su clave en cada servidor VDA de Linux
Nombra los certificados de servidor como “shadowingcert.*” y el archivo de clave como “shadowingkey.*” (* puede indicar el formato, por ejemplo, shadowingcert.csr y shadowingkey.key). Coloca los certificados de servidor y los archivos de clave en la ruta /etc/xdl/shadowingssl y protégelos adecuadamente con permisos restringidos. Un nombre o ruta incorrectos hacen que el VDA de Linux no pueda encontrar un certificado o archivo de clave específico y, por lo tanto, provoca un fallo de conexión con Citrix Director.
Uso
Desde Citrix Director, busca la sesión de destino y haz clic en Sombra en la vista Detalles de la sesión para enviar una solicitud de sesión en la sombra al VDA de Linux.
Después de que se inicialice la conexión, aparece una confirmación en el cliente de la sesión ICA (no en el cliente de Citrix Director) para pedir permiso al usuario para sombrear la sesión.
Si el usuario hace clic en Sí, aparece una ventana en el lado de Citrix Director, indicando que la sesión ICA se está sombreando.
Para obtener más información sobre el uso, consulta la Documentación de Citrix Director.
Limitaciones
- Las sesiones en la sombra están diseñadas para usarse solo en una intranet. No funciona para redes externas, incluso conectándose a través de Citrix Gateway. Citrix declina cualquier responsabilidad por las sesiones en la sombra del VDA de Linux en una red externa.
- Con las sesiones en la sombra habilitadas, un administrador de dominio solo puede ver las sesiones ICA, pero no tiene permiso para escribirlas o controlarlas.
- Después de que un administrador haga clic en Sombra desde Citrix Director, aparece una confirmación para pedir permiso al usuario para sombrear la sesión. Una sesión solo se puede sombrear cuando el usuario de la sesión da el permiso.
- La confirmación mencionada anteriormente tiene una limitación de tiempo de espera, que es de 20 segundos. Una solicitud de sesión en la sombra falla cuando se agota el tiempo.
-
Una sesión ICA solo puede ser sombreada por un administrador en una ventana de Citrix Director. Si una sesión ICA ha sido sombreada por el administrador A y, mientras tanto, el administrador B envía una solicitud de sesión en la sombra, la confirmación para obtener el permiso del usuario reaparece en el dispositivo del usuario. Si el usuario acepta, la conexión de sesión en la sombra para el administrador A se detiene y se establece una nueva conexión de sesión en la sombra para el administrador B. Es lo mismo si el mismo administrador envía otra solicitud de sesión en la sombra para la misma sesión ICA.
- Para usar el shadowing de sesión, instale Citrix Director 7.16 o posterior.
- Un cliente de 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 de Citrix Director debe poder resolver el FQDN del servidor Linux VDA.
Solución de problemas
Si el shadowing de sesión falla, realice la depuración tanto en el cliente de Citrix Director como en el Linux VDA.
En el cliente de Citrix Director
A través de las herramientas de desarrollador del navegador, compruebe los registros de salida en la ficha Consola. O bien, compruebe la respuesta de la API ShadowLinuxSession en la ficha Red. Si aparece la confirmación para obtener el permiso del usuario pero la conexión no se establece, haga ping manualmente al FQDN del Linux VDA para verificar que Citrix Director puede resolver el FQDN. Si hay un problema con la conexión wss://, compruebe sus certificados.
En el Linux VDA
Verifique que la confirmación para obtener el permiso del usuario aparece en respuesta a una solicitud de shadowing. Si no es así, compruebe los archivos vda.log y hdx.log en busca de pistas. Para obtener el archivo vda.log, haga lo siguiente:
-
Busque el archivo /etc/xdl/ctx-vda.conf. Quite el comentario de la siguiente línea para habilitar la configuración de vda.log:
Log4jConfig=”/etc/xdl/log4j.xml” -
Abra /etc/xdl/log4j.xml, localice la parte com.citrix.dmc y cambie “info” a “trace” de la siguiente manera:
<!-- Broker Agent Plugin - Director VDA plugin Logger --> <logger name="com.citrix.dmc"> <level value="trace"/> </logger> <!--NeedCopy--> -
Ejecute el comando
service ctxvda restartpara reiniciar el servicioctxvda.
Si hay un error durante el establecimiento de la conexión:
- Compruebe si hay alguna limitación del firewall que impida que el shadowing de sesión abra el puerto.
- Verifique que los certificados y los archivos de clave estén nombrados correctamente y se encuentren en la ruta correcta si se trata del escenario SSL.
- Verifique que queden suficientes puertos entre 6001 y 6099 para nuevas solicitudes de shadowing.