Arquitectura de “Remote Desktop Services” (RDS) y sus roles principales
Arquitectura de Remote Desktop Services? (RDS) y sus roles principales
Hola a todos nuevamente!!!! En esta oportunidad les voy a contar un poco acerca de la arquitectura de RDS, sus componentes, y las diferentes funciones de cada rol.
En Windows Server 2008 R2 (WS2008R2), Terminal Services (TS) ha sido más desarollado y renombrado como Remote Desktop Services (RDS). RDS es la columna vertebral de las Soluciones de infraestructura de escritorios virtuales (VDI) de Microsoft. De la misma manera, en Windows Server 2012, RDS se ha desarollado aún más al tener una característica de configuración basado en escenarios? que pueden ser configurados a través de asistentes de configuración (wizards). Aún así, los conceptos y la Arquitectura para RDS permanecen prácticamente idénticos desde WS2008R2. La nueva y mejorada Arquitectura, saca provecho de la virtualización, y hace que el acceso remoto sea una solución más flexible con la implementación de nuevos escenarios. Para tener una idea de la capacidad de RDS, resulta esencial comprender las funciónes de sus componentes principales de la arquitectura, a la vez de como interactúan entre sí para procesar un requerimiento de RDS. Existe una nueva terminología y acrónimos con los cuáles debemos familiarizarnos dentro del contexto de RDS. Para los fines de este post, vale la pena mencionar que RDS implica la Plataforma de Windows 2008 R2 y posteriores, mientras que TS (Terminal services) , implica solamente Windows 2008..
Existen cinco roles primordiales dentro de la Arquitectura de RDS, como se puede observar en la imagen siguiente, y todos requieren de un servidor de licenciamiento RDS. Cada componente incluye un conjunto de características diseñadas para adquirir ciertas funciones específicas dentro de la Arquitectura RDS. Juntos, los cinco roles componen una estructura para el acceso de aplicaciones de "Terminal Services"?, escritorios remotos, y escritorios virtuales. En esencia, WS2008R2 y posteriores, ofrecen un conjunto de características con funciones específicas para el diseño de la infraestructura de acceso remoto de una empresa.
Para comenzar, un usuario final deberá acceder a la URL de RDS, la cuál será la URL que contenga los recursos publicados (Aplicaciónes). La interface, provista por Remote Desktop Web Access (RDWA), y configurada a través de un Internet Information Services (IIS) con SSL, es el punto de acceso Web para RemoteApp y VDI. La URL de acceso, es consistente independientemente de como los recursos son organizados, compuestos, y publicados desde mútiples servidores de sesión RDS por detrás. Por defecto, RDS publica los recursos en el siguiente formato de URL https://FQDN-del-Webaccess-server-RDWA/rdweb y esta URL es la única información que el administrador deberá proveer a los usuarios finales, para acceder a los recursos autorizados a través de RDS. Un usuario final necesitará ser autenticado con sus credenciales de AD cuando acceda a la URL del RDWA, haciendo que las aplicaciones y recursos publicados sean "presentados"? al usuario final en base a los permisos otorgados en la lista de control de accesos. Es decir, el usuario final solo podrá ver y acceder aquellos recursos, los cuáles su cuenta de AD posee el permiso requerido.
Remote Desktop Gateway (RDG) es opcional y funciona de la misma manera que en Terminal Services. Un RDG se ubica en el borde de la red corporative para filtrar los requerimientos externos de RDS, en base al criterio de acceso definido en un servidor llamado Network Policy Server (NPS). Basado en certificados, RDG ofrece acceso remoto seguro hacia la infraestructura de RDS. Para el administrador de sistemas, el RDG es la frontera de una red de RDS. Hay dos políticas de acceso principales definidas en un servidor NPS relacionados con un RDG:
- Una es la política de autorización de conexión o CAP. Prácticamente es una lista de autorización de usuarios finales, que muestra quiénes pueden conectarse al RDG
- La otra es la política de autorización de acceso a los recursos o RAP. En esencia, esta es una lista de acceso a recursos, que especifíca a que dispositivos un usuario final de CAP, podrá conectarse con un RDG asociado.
En RDS, las aplicaciónes son instaladas y publicadas en un Remote Desktop Session Host (RDSH), similar a un TS Session Host, o simplemente un Terminal Server en un escenario de TS. Un RDSH carga las aplicaciónes, las ejecuta, y muestra los resultados. El "Sign-in Digital"? puede ser fácilmente habilitado en un RDSH con un certificado. Multiples RDSH pueden ser configurados con tecnología de "balanceo de carga"?. Esto requiere que cada RDSH en un grupo de balanceo de carga necesite ser configurado idéntico de la misma manera, y con exactamente las mismas aplicaciónes.
Una importante mejora en RDSH (a comparación de TS Session Host), es la habilidad para "mostrar"? las aplicaciónes publicadas a usuarios finales, basándose en la lista de acceso (ACL) de la aplicación. Un usuario final autorizado, podrá solo acceder a aquellas aplicaciónes publicadas para las cuáles fue autorizado dentro de la ACL. Por defecto, el grupo de usuarios "Everyone" ?, se encuentra autorizado a acceder, por ende todo usuario conectado podrá conectarse a dicha aplicación.
Remote Desktop Virtualization Host (RDVH) es una nueva característica, la cuál atiende los requerimientos para escritorios virtuales ejecutándose en máquinas virtuales, o asignación de máquinas virtuales en sí. Un servidor RDVH se encuentra basado en Hyper-V, por ejemplo un servidor Windows con el rol de Hyper-V habilitado. Al momento de atender un requerimiento de usuario con necesidad de asignación de una VM, un servidor RDVH automáticamente iniciará una VM, en el caso que la misma ya no se encuentre ejecutándose. Paso siguiente, el usuario final requerirá colocar sus credenciales al ingresar al escritorio virtual. Sin embargo, un RDVH no acepta de manera directa los requerimientos de conexión, utiliza en cambio un RDSH como "redirector"? para atender los requerimientos basados en VMs. El par de un RDVH junto con su "redirector"?, es definido dentro del Remote Desktop Connection Broker (RDCB) al momento de agregarse un recurso basado en RDVH.
Remote Desktop Connection Broker (RDCB), como una expansión de lo que es Terminal Services Session Broker en TS, Proporciona una experiencia unificada para configurar el acceso de los usuarios a las aplicaciones TS tradicionales y a los escritorios virtuales basados en máquinas virtuales (VM). Aquí, un escritorio virtual puede estar ejecutándose tanto en en una VM designada, o una VM dinámicamente asignada, basándose en la carga de balanceo, desde un "pool"? definido de VMs. Un administrador de sistemas utilizará la consola de RDCB, llamada Remote Desktop Connection Manager, para agregar RDSHs, TS Servers, y RDVHs, como así también aquellas aplicaciónes publicadas por los RDSHs y TS Servers. De la misma manera, aquellas VMs ejecutándose en los RDVHs, podrán ser publicadas luego a través de la URL del RDWA. Una vez autenticados los usuarios finales en esta URL del RDWA, los usuarios podrán acceder a las aplicaciones autorizadas (RemoteApp), y escritorios virtuales.
Un cliente de Remote Desktop (RD) obtiene información de la conexión a realizar desde el servidor RDWA dentro de una estructura de RDS. Si el cliente RD se encuentra por fuera de la red corporativa, el cliente se conectará a través del RDG. En cambio si el cliente RD se encuentra dentro de la red corporativa, el cliente podrá luego conectarse de manera directa tanto hacia un RDSH, como también hacia un RDVH, toda vez que el RDCB provea la información de la conexión. En ambos casos, el RDCB juega un papel primordial a la hora de proveer asegurar al cliente RD, el acceso al recurso apropiado. Mediante el uso de certificados, el administrador de red puede configurar el Single Sign ON (SSO) entre los varios componentes de RDS, para proveer al usuario final una experiencia confortable y segura.
En la imágen de aquí debajo podemos observar la función que desempeña cada uno de los roles explicados, de manera gráfica:
Conceptualmente, el RDCB es el "jefe de operaciones"? dentro de una Arquitectura de RDS, y sabe dónde esta cada recurso, con quién contactarse, y que realizar con cada petición de RDS. Antes de que una conexión lógica pueda establecerse entre un cliente y un RDSH o RDVH de destino, el RDCB actúa como un "enlace"?, enviando la información pertinente "desde y hacia"? los diferentes componentes, al momento de atender una petición de RDS.
EN SINTESIS
Desde una vista más general, el cliente RD utiliza RDWA/RDG para obtener acceso hacia un RDSH o RDVH, mientras RDCB conectará al cliente RD con una sesión hacia el RDSH destino, o hacia una VM configurada en un RDVH de destino.
Espero que luego de haber leído este post, les quede más claro cuál es la función de cada rol dentro de una arquitectura de RDS, y les pueda ser de utilidad.
Hasta el próximo post!!!