Los entornos basados en Windows thin client se han convertido en la forma más habitual de desplegar escritorios virtuales en empresas que necesitan centralizar datos, simplificar la administración y reforzar la seguridad. Sin embargo, cuando empezamos a profundizar en políticas de sesión, opciones de redirección de recursos y requisitos de seguridad, la cosa deja de ser tan sencilla.
Un proyecto de thin clients no consiste solo en enchufar terminales y publicar escritorios. Implica gestionar cómo se comportan las sesiones, qué se redirige desde el dispositivo local y qué condiciones de seguridad se exigen antes de que un usuario pueda entrar en un escritorio remoto o aplicación publicada. A lo largo de este artículo vamos a explicarlo todo detenidamente.
Qué es realmente un Windows thin client y qué papel juega en VDI
Cuando hablamos de un cliente ligero solemos pensar en un pequeño terminal sin disco duro. Sin embargo, la definición moderna va un poco más allá. Un thin client es un dispositivo con el hardware justo para arrancar un sistema operativo mínimo y establecer una conexión remota hacia servidores donde se aloja todo lo importante: aplicaciones, perfiles, datos sensibles y potencia de cómputo.
En entornos Windows, estos dispositivos se apoyan en protocolos como RDP, Citrix ICA u otros canales de comunicación orientados a escritorio remoto. El terminal se encarga básicamente de la entrada de teclado y ratón, la salida de vídeo y el transporte de ciertos periféricos o recursos locales hacia la sesión remota, según lo permitan las políticas.
Fabricantes como HP o Dell ofrecen una amplia variedad de modelos de thin client y zero client. En esencia todos persiguen lo mismo: ser la “ventana” hacia un escritorio virtual (VDI) o una sesión de escritorio remoto alojada en el centro de datos o en la nube.
Este enfoque se considera parte del concepto de escritorio virtual (VDI). El dispositivo del usuario pasa a ser secundario, lo que trae consigo beneficios muy concretos a nivel de TI y de negocio.
Ventajas clave de los clientes ligeros en la empresa
Un despliegue bien planteado de thin clients aporta ventajas muy claras frente al PC tradicional, especialmente cuando se combinan con escritorios virtuales o servicios como Windows 365 o Azure Virtual Desktop.
- Seguridad de los datos corporativos. Al residir los ficheros y aplicaciones en servidores centralizados, se reduce de forma drástica el riesgo de fuga de información por robo de portátiles, pérdida de discos o copias locales incontroladas. El terminal ligero suele almacenar poco o nada de información sensible.
- Centralización de la administración. Los equipos de TI pueden desplegar, parchear y retirar aplicaciones desde una única consola, gestionar plantillas de escritorio y controlar versiones de forma homogénea, sin tener que ir máquina por máquina.
- Reducción de costes. Tanto en infraestructura de puesto de trabajo (terminales más baratos y duraderos) como en fases de actualización y renovación. Al necesitar menos hardware local, la obsolescencia es más lenta y se pueden reutilizar incluso equipos antiguos como thin clients.
- Menor consumo energético y climatización. Estos dispositivos emplean menos energía que un PC completo. Esto se nota en la factura eléctrica y en el calor que generan las salas de trabajo, especialmente en despliegues masivos.
Por último, la copia de seguridad se vuelve un proceso mucho más controlable. Al tener los datos en el centro de datos o en la nube, la protección de la información se concentra en el lado servidor, con sistemas de backup centralizados y políticas de retención mucho más sencillas de gobernar.
Desafíos típicos con thin clients: redirección USB y periféricos
El gran talón de Aquiles de muchos proyectos con thin clients aparece cuando se trata de integrar dispositivos dependientes de USB: memorias, cámaras, lectores de tarjeta inteligente, impresoras especiales, escáneres biométricos, etc. No todo lo que conectamos al puerto del terminal se comporta bien en la sesión remota.
En entornos donde no existe un buen mecanismo de paso de USB desde el thin client a la sesión (ya sea RDP o VDI), los periféricos conectados al dispositivo local solo están disponibles para una sesión “local” del propio cliente ligero, pero no aparecen dentro del escritorio virtual. Esto obliga a muchos usuarios a alternar entre sistemas, lo que rompe el flujo de trabajo.
Este problema genera una clara pérdida de productividad. Si un empleado tiene que saltar continuamente entre aplicaciones locales y remotas, o incluso entre distintos terminales, el tiempo que pierde y la frustración aumentan. En algunos zero clients, directamente no es viable exponer el dispositivo USB a una sesión remota.
Otra consecuencia es el incremento de la complejidad operativa. No todos los tipos de dispositivos son aptos para ser redirigidos mediante mecanismos nativos de los protocolos de escritorio remoto, y aunque el hardware figure como compatible, en la práctica puede comportarse de forma errática, con cortes, desconexiones o funcionalidades limitadas.
En determinados escenarios, cuando un dispositivo USB conectado a un thin client se redirige hasta el servidor mediante RDP, el recurso puede quedar visible para más de un usuario. Si la configuración no se hace con cuidado, otro thin client podría ver e incluso usar ese dispositivo compartido de manera no deseada, con los problemas de seguridad y privacidad que esto conlleva.
Todo esto desemboca en costes adicionales. Las empresas se ven obligadas a invertir en hardware especializado o software de terceros para hacer posible la redirección USB de forma segura y estable, o bien en rediseñar flujos de trabajo para evitar depender de dispositivos que no se redirigen bien.
Redirección de carpetas en Windows mediante Directiva de Grupo
Más allá de la redirección de dispositivos USB, la gestión de datos de usuario en un entorno de escritorios remotos se apoya muchísimo en la redirección de carpetas del perfil. Esta funcionalidad permite enviar carpetas como Documentos o Escritorio a una ubicación diferente, normalmente en un recurso compartido de red.
En Windows, la redirección de carpetas se configura con Objetos de Directiva de Grupo (GPO) desde la Consola de administración de directivas de grupo (GPMC). La ruta para llegar a esta configuración es: <Nombre del GPO>\User Configuration\Policies\Windows Settings\Folder Redirection, donde se controla el destino de cada carpeta de usuario.
Mediante esta técnica, los administradores pueden separar los datos del usuario de la máquina concreta en la que inicia sesión, de modo que un empleado mantenga su información y estructura de carpetas independientemente del thin client o PC que utilice para acceder a la sesión remota.
Carpetas que se pueden redirigir y tipos de redirección
El asistente de redirección de carpetas (desde GPMC) permite actuar sobre un conjunto amplio de ubicaciones del perfil de usuario, incluyendo AppData\Roaming, Contactos, Escritorio, Documentos, Descargas, Favoritos, Enlaces, Música, Imágenes, Juegos guardados, Búsquedas, Menú Inicio y Vídeos. Es decir, prácticamente todos los puntos sensibles del perfil.
La redirección puede configurarse en modo básico o avanzado. En el modo básico, la carpeta de todos los usuarios apunta a una misma ruta raíz, aplicándose a todas las cuentas afectadas por ese GPO. La opción más típica consiste en crear una subcarpeta por usuario en la ruta compartida, con un patrón similar a \\servidor\recurso\NombreDeCuenta\NombreCarpeta.
También existe la posibilidad de usar una ruta explícita compartida entre varios usuarios, algo útil en escenarios colaborativos, combinando si se desea variables de entorno para generar rutas personalizadas. Cuando se opta por “redirigir a la ubicación del perfil de usuario local”, se traslada la carpeta al perfil local de la máquina, manteniéndola dentro de Usuarios en el sistema remoto.
En modo avanzado, el comportamiento cambia según la pertenencia a grupos de seguridad. Esto permite definir destinos distintos para, por ejemplo, personal de administración, departamento técnico o usuarios externos, todo ello dentro del mismo GPO pero con reglas específicas por grupo.
La opción “No configurado” indica que no se aplica redirección de carpetas mediante ese GPO. Si se desactiva la configuración, las carpetas pueden volver a su ubicación de perfil local o seguir donde estaban, en función de las opciones elegidas previamente para el tratamiento al quitar la directiva.
Requisitos previos y pasos para configurar la redirección de carpetas
Antes de empezar a tocar GPOs es fundamental tener preparado el entorno. Se necesita un dominio de Active Directory Domain Services con equipos cliente unidos a dicho dominio, aunque no haya requisitos especiales de nivel funcional de bosque o de esquema.
La cuenta que configure las políticas debe disponer de permisos suficientes para crear y vincular GPOs en el dominio o en las unidades organizativas (OU) donde residen los usuarios afectados. Además, es necesario que los equipos clientes ejecuten Windows o Windows Server. Y que haya al menos un equipo con la GPMC instalada.
Para configurar la redirección, el flujo habitual es abrir la consola de Administración de directivas de grupo, expandir el dominio o la OU adecuada y decidir si se crea un GPO nuevo o se edita uno existente. En muchos entornos compensa crear un GPO específico para gestionar solo la redirección de carpetas.
Una vez dentro del Editor de administración de directivas de grupo, hay que seguir esta ruta:
- Abrir el menú de Configuración de usuario.
- Acceder a Directivas.
- Seleccionar Configuración de Windows.
- Allí, elegir Redirección de carpetas.
Desde ahí se selecciona la carpeta a redirigir, se accede a sus propiedades y en la pestaña “Destino” se elige el tipo de redirección que se desea aplicar.
En esta parte es donde se especifica la ruta final del recurso compartido, siguiendo el formato estándar de UNC \\servidor\recurso\NombreCarpeta. Tras aceptar la configuración, conviene repetir el proceso para todas las carpetas relevantes y forzar la actualización de políticas con un gpupdate /force en los equipos cliente o esperar a que se aplique en el próximo ciclo.
Opciones avanzadas: permisos, movimiento de datos y eliminación de directivas
Dentro de las propiedades de cada carpeta redirigida, la pestaña Configuración permite ajustar detalles finos que marcan la diferencia en el día a día. Uno de los más importantes es el ajuste “Conceder al usuario derechos exclusivos sobre la carpeta”, que suele aparecer activado por defecto.
Esta opción garantiza que solo el usuario tenga permisos sobre su carpeta. De modo que se bloquea el acceso a administradores y otros usuarios, lo que resulta recomendable desde el punto de vista de privacidad.
Otro ajuste práctico es “Mover el contenido de <NombreCarpeta> a la nueva ubicación”. Esto sirve para transferir automáticamente los ficheros ya existentes en la carpeta local hacia la ruta compartida de red. Así se evita que queden datos repartidos entre distintos puntos.
En cuanto a la eliminación de directivas, se puede escoger entre redireccionar de nuevo la carpeta a la ruta de perfil de usuario cuando se quite la política o dejar la carpeta en la ubicación redirigida. En el primer caso, el contenido se copia de vuelta pero no se borra de la ubicación de red, lo que puede implicar un tiempo considerable en conexiones lentas o cuando el volumen de datos es muy grande.
Si se mantiene la carpeta en la ruta redirigida, los datos permanecerán donde estaban. El usuario seguirá accediendo a ellos a través de la carpeta compartida. Esta metodología suele ser la más cómoda cuando no se quiere provocar grandes movimientos de información o cuando las ubicaciones remotas están muy alejadas físicamente.
Redirección de contenido del navegador en entornos Citrix
Cuando las sesiones remotas se sirven mediante Citrix, una de las funcionalidades que más impacto tiene en el rendimiento es la redirección de contenido del navegador al cliente local. En lugar de renderizar ciertas páginas en el servidor, el contenido se envía al navegador del dispositivo del usuario. Eso supone un gran ahorro de recursos del lado servidor.
En una infraestructura VDI publicada, el proceso para activar esta redirección en Google Chrome pasa por instalar la extensión de redirección del navegador de Citrix desde Chrome Web Store. El administrador o el propio usuario accede a la tienda, busca la extensión específica y la añade al navegador.
Si se utiliza Microsoft Edge (versión 83.0.478.37 o posterior), hay que habilitar primero la instalación de extensiones de otras tiendas, acceder a Chrome Web Store desde Edge, buscar “Redireccionamiento de contenido del navegador” y obtener la extensión ofrecida por Citrix, que quedará integrada en el navegador de Microsoft.
La parte de administración central se realiza en Citrix Studio. Desde el panel de Políticas, se edita o crea una política nueva y se busca la opción “Redireccionamiento de contenido del navegador”, que debe establecerse como Permitida, marcando así que el entorno soporta esta característica.
Posteriormente se configuran parámetros más detallados como la ACL de redireccionamiento de contenido, donde se indican las URL cuyo contenido se quiere enviar al cliente. Por defecto suele incluirse algo como https://www.youtube.com/*, que se puede modificar o eliminar si no interesa redirigir ese sitio.
También se contemplan los llamados sitios de autenticación de redireccionamiento. Estos son especialmente útiles cuando una página requiere iniciar sesión a través de un dominio diferente. Se incluyen tanto las URL que muestran contenido como aquellas que gestionan la autenticación. A esto se suma la lista de bloqueo, que define qué direcciones deben seguir representándose en el servidor sin redirigir..
Seguridad, Intune y acceso condicional en entornos Windows remotos
Cuando los escritorios remotos se consumen desde dispositivos personales o móviles, no basta con tener un buen VDI. Es crítico garantizar que el dispositivo de origen cumple ciertos requisitos de seguridad. Aquí entran en juego Microsoft Intune y el acceso condicional de Microsoft Entra.
La idea es aprovechar directivas de protección de aplicaciones de Intune junto con políticas de acceso condicional para que solo se pueda acceder a Azure Virtual Desktop, Windows 365 o Microsoft Dev Box si el dispositivo (o al menos la app desde la que se conecta) cumple lo que se ha definido a nivel de seguridad.
Este modelo cubre varios tipos de plataformas: iOS/iPadOS y Android, tanto administrados como no administrados, y navegadores Microsoft Edge en Windows en modo no administrado. En estos escenarios se pueden exigir elementos como PIN, niveles mínimos de sistema operativo o restricciones en copiar/pegar.
Entre las configuraciones avanzadas destacan opciones como bloquear teclados de terceros, forzar versiones mínimas de la app cliente o establecer un nivel máximo de amenazas permitido para el dispositivo. Si cualquiera de estos requisitos no se cumple, se corta el acceso al escritorio remoto.
Una vez asegurado que el dispositivo local es confiable, se puede pasar a la fase de control. Por ejemplo, la redirección de cámara, micrófono, almacenamiento o portapapeles hacia la sesión remota. Esto es algo muy relevante en escenarios de thin clients “híbridos” o BYOD.
Configurar políticas de acceso condicional para escritorios remotos
Las políticas de acceso condicional permiten controlar el acceso a Azure Virtual Desktop, Windows 365 y Microsoft Dev Box basándose en la identidad del usuario, el tipo de dispositivo, el cliente de acceso y otros factores como la ubicación.
Un escenario típico consiste en permitir el acceso solo si se está aplicando una directiva de protección de aplicaciones a la aplicación de Windows. En este caso, la política de acceso condicional se asigna a un grupo de usuarios concreto y se configura para que apunte como recursos a Azure Virtual Desktop, Windows 365 y el inicio de sesión en la nube de Windows, identificados por sus correspondientes IDs de aplicación.
En el bloque de condiciones se definen las plataformas de dispositivos permitidas. También se especifica qué tipos de clientes son válidos. De esta forma, solo se validarán intentos de acceso desde esos entornos concretos.
En los controles de acceso se marca la opción de requerir que haya una directiva de protección de aplicaciones aplicada como condición para conceder el acceso. Si el dispositivo o la app no cumplen, el usuario verá denegada su conexión al escritorio remoto, aunque sus credenciales sean correctas.
La clave está en combinar estas políticas para conseguir un equilibrio entre seguridad y usabilidad. Es decir, adaptar los controles a la criticidad de los recursos que se exponen mediante thin clients y escritorios virtuales.
Verificación de la configuración en sesiones remotas
Tras definir GPOs de redirección, políticas de Citrix, configuraciones de Intune y acceso condicional, toca validar que el comportamiento real coincide con lo esperado. Esto implica conectarse desde distintos dispositivos y con diferentes apps cliente.
Es recomendable revisar qué acciones puede hacer el usuario con los datos: si puede o no copiar/pegar contenido hacia otras apps, de qué forma se redirigen cámaras o micrófonos, si los dispositivos USB aparecen correctamente en la sesión remota y cómo se comportan las carpetas redirigidas cuando cambian las políticas.
Si se detecta cualquier discrepancia, la solución suele pasar por ajustar filtros, revisar asignaciones de grupos o refinar listas de URLs y dispositivos autorizados. Siempre con pruebas controladas antes de extender los cambios a todos los usuarios.
Cuando todas estas piezas encajan, los entornos basados en Windows thin client proporcionan una combinación muy potente de seguridad, flexibilidad y centralización. El usuario puede acceder a su escritorio desde casi cualquier sitio, los datos se mantienen bajo control en el centro de datos o la nube, y los equipos de TI tienen una visión unificada de políticas de sesión, redirecciones y cumplimiento de seguridad.