Enimbos.com
Close

Creación de una Granja RDS 2016 con Alta Disponibilidad y Autoescalado

En esta nueva entrada del blog, nuestro compañero Hugo Margallo detallará cómo construir una granja de servidores de Windows Server 2016 empleando los roles de Remote Desktop Services (RDS) y desplegándolos sobre una infraestructura jerárquica en nube de 4 servidores.

Para ello dividirá el proceso en 3 puntos: Construcción de la granja RDS, Funcionalidad y operatividad de una granja RDS, y la creación de una Autoridad Certificadora.

¿Qué es RDS?

El sistema de radiodifusión de datos conocido como RDS (acrónimo del inglés Radio Data System) un protocolo de comunicaciones que permite enviar datos.

¿Cómo se ha llevado a cabo la granja de servidores con RDS? Aspectos fundamentales

Una instalación mínima de RDS con alta disponibilidad podría realizarse con 3 equipos, pero utilizaré 4 para que los roles estén más definidos, de tal forma que mi controlador de dominio no tendrá ningún rol RDS, aunque podrá monitorizar la granja.

Este contenido se dividirá en 3 partes como consecuencia de la gran cantidad de contenido y extensión del tema y que se publicarán progresivamente durante estas tres semanas siguientes. En la primera entrada del blog se explicará la configuración de los primeros aspectos de la granja y la puesta a punto para el despliegue óptimo de la misma, la segunda parte se centrará en su funcionalidad y operatividad; y por último, en la tercera y última entrada del Blog configuraré los certificados necesarios para un funcionamiento seguro y, además, explicaré los scripts que se pueden usar para hacer la granja autoescalable de manera automática.

Una instalación completa de RDS requeriría máquinas con el rol RD License server, que proporcionaría las licencias necesarias a los equipos, pero no entraremos en detalle por resultar menos relevante que los otros roles.

Infraestructura

  • EnimbosDC: Es el controlador del dominio enimbos.local. Se encargará de instalar los roles necesarios en el resto de equipos y realizará el despliegue. Todo podrá gestionarse y monitorizarse desde aquí. También poseerá el rol de ‘Autoridad Certificadora’ del dominio. Todos los certificados estarán autorizados por esta máquina y serán fiables dentro del propio dominio.
  • EnimbosBroker1: Se encargará de gestionar las conexiones de los equipos externos hacia los host RDS. Para ello empleará funciones de balanceo y funcionará en alta disponibilidad con EnimbosBroker2. Todas las conexiones se dirigirán a uno de los dos equipos mediante una DNS común funcionando con Round Robin. Concretamente este equipo también funcionará a modo de servidor de ficheros Samba que compartirá determinadas rutas para facilitar funciones de transferencia de archivos y autoescalado, como veremos más adelante.
  • EnimbosBroker2: Se encargará de las mismas funciones que EnimbosBroker1 con el añadido de que también hará de servidor web para poder ofrecer el archivo RDP a todos los usuarios de dominio mediante una URL en la que hacer login.
  • EnimbosHost1: Será el primero de los Session Host al que los usuarios de dominio podrán conectarse de manera remota. Este equipo siempre se mantendrá activo independientemente del crecimiento o decrecimiento de la granja RDS.

Los demás equipos se irán añadiendo y eliminando mediante scripts que proporcionan autoescalado y todos tendrán el rol de Session Host, al igual que EnimbosHost1.

1.Creación del controlador de dominio

Una vez que accedamos de manera remota al equipo EnimbosDC, debemos acceder al Server Manager e instalar el rol de Active Directory Domain Services como muestra la siguiente captura (no debemos instalar ninguna característica, solo roles):

rds

Pulsamos siguiente en todos los pasos del asistente y marcamos que el servidor pueda reiniciarse en caso de necesitarlo. Acto seguido, debemos fijarnos en el siguiente mensaje:

rds

Si clickeamos sobré él iniciamos el asistente de promoción del equipo a controlador de dominio. Lo primero que el asistente nos preguntará es si debemos unirlo a un dominio ya existente, crear otro dominio o un bosque (dominio principal del que parten el resto de dominios). Como partimos de cero, seleccionaremos la opción bosque y lo llamaremos enimbos.local. Como es lógico, este equipo también hará las funciones de servidor DNS, así que esa casilla la dejamos marcada, preocupándonos solo de elegir el nivel funcional del bosque y el dominio, que será en nuestro caso Windows Server 2016.

A continuación hemos de introducir la contraseña del modo de restauración de los servicios de directorio, que será Enimbosblog2018#, aunque por ahora es irrelevante.

No indicaremos la creación de una delegación DNS, así que procedemos a introducir un nombre de NetBios, que en este caso podemos dejar el que viene por defecto (ENIMBOS), así como las rutas que empleará el controlador de dominio para la gestión de todos los equipos y usuarios de Active Directory.

Por último, solo debemos revisar en el asistente si las opciones que hemos escogido están tal y como las deseamos y lanzar la comprobación de prerrequisitos, que si no nos hemos pasado nada nos dará el visto bueno y podremos proceder a la promoción del equipo.

Nota: El usuario con el que hemos ejecutado este asistente (que debe tener privilegios de administrador), pasará a ser usuario administrador del dominio.

2. Unir equipos al dominio

Necesitamos que el resto de los equipos que formen parte de la granja RDS se encuentren en el mismo dominio. Los pasos a seguir son iguales para todas las máquinas, así que solo lo mostraré para el caso de EnimbosBroker1.

Lo primero será permitir que el dominio enimbos.local pueda ser resuelto por las DNS, por lo que hay que indicar como servidor DNS la ip del controlador de dominio, y eso podremos hacerlo a través del panel de control, en la configuración de IPv4:

rds

La ip configurada como DNS alternativo (8.8.8.8) pertenece a Google, y nos ofrecerá salida a Internet mediante la resolución de todos los dominios de la WWW.

Podemos comprobar que funciona correctamente haciendo ping a enimbos.local.

Ahora que podemos resolver el nombre de dominio, el siguiente paso es especificar que debe unirse a él. Para ello, desde el panel de control/Sistema, clickeamos sobre la opción de cambiar la configuración del equipo y en la pestaña Nombre del equipo, escogemos Cambiar. Por defecto, veremos que el equipo pertenece a un Workgroup. Debemos marcar la casilla de dominio y especificar enimbos.local. Al establecerse la conexión por LDAP, lo siguiente será introducir las credenciales de administrador del dominio y, si todo ha salido bien, veremos un mensaje de bienvenida y tendremos que reiniciar el equipo, que podremos hacerlo ahora o más adelante.

Ahora EnimbosBroker1 está en dominio y debemos hacer lo mismo con las restantes.

3. Despliegue RDS

Para comenzar con el despliegue debemos iniciar sesión en el controlador de dominio y acceder al Server Manager. Una vez allí, debemos añadir a los nuevos equipos del dominio al server pool. Para ello, clickeamos sobre Add Server en la pestaña Manage del Server Manager, y seleccionamos los equipos por su nombre (también se puede hacer por la IP) como se muestra en la siguiente captura:

Si todo ha salido bien, en la opción All Servers del menú izquierdo del Server Manager podremos ver a los equipos seleccionados y con estado Online, indicando que ya pueden ser gestionados desde ahí.

Para comenzar el despliegue, debemos instalar primero los roles correspondientes en cada máquina, aunque puede hacerse de manera más sencilla clickeando sobre Manage y Add roles and Features. Veremos en el asistente que podemos seleccionar directamente hacer una instalación de Remote Desktop Services.

En las siguientes pantallas debemos escoger la opción Despliegue Estándar y Despliegue de escritorio basado en sesión. Una vez escogidas ambas opciones, procedemos a seleccionar qué rol poseerá cada máquina, siendo EnimbosBroker1 el primer Connection Broker , EnimbosBroker2 el RD Web (más adelante también será bróker) y EnimbosHost1 el primer RDSessionHost.

Si todo ha salido bien, podremos ver a la izquierda del Server Manager la opción “Remote Desktop Services” y, al clickear, se nos mostrará un esquema general de la granja indicando los equipos que pertenecen a ella, como se muestra en la siguiente captura:

El siguiente paso será configurar los brokers en alta disponibilidad.

4. Configuración de alta disponibilidad

Son imprescindibles dos requisitos para configurar la alta disponibilidad: una dirección DNS compartida por los dos brokers y una base de datos de SQL Server que mantenga los datos. Para lo primero debemos acceder al DNS Manager, que lo encontraremos en Tools (esquina superior derecha del Server Manager) y luego en DNS.

Una vez dentro, debemos desplegar nuestro controlador de dominio (ENIMBOSDC en este caso), luego la carpeta Forward Lookup Zones y finalmente enimbos.local, que es el nombre de nuestro dominio. Una vez dentro, veremos entradas haciendo referencia a los nombres de nuestros equipos. Para añadir una nueva entrada debemos clickear con el botón derecho sobre el fondo blanco de la ventana derecha y seleccionar New Host (A or AAAA). Ahí solo tendremos que poner el nombre de nuestra entrada dns (brokerha en este caso) y la ip del primer bróker. Acto seguido, debemos repetir el mismo paso pero para la ip del segundo bróker (el nombre debe ser el mismo), que en nuestro caso será la IP del equipo EnimbosBroker2, que por ahora es solo RDWeb.

rds

Debemos también asegurarnos que el servidor DNS va a usar el balanceo Round Robin para el correcto funcionamiento de la alta disponibilidad (esto solo se aplica para dos entradas DNS que comparten nombre pero distinta IP). Para ello clicamos con el segundo botón sobre nuestro controlador de dominio en el menú de la izquierda, seleccionamos propiedades y en la pestaña Advanced debemos comprobar que la casilla Enable Round Robin está marcada. Con esto ya tenemos cierto balanceo.

rds

Ahora veamos la base de datos. En este caso he configurado en Amazon Web Services un RDS (es como llama Amazon a los gestores de bases de datos en nube, nada que ver con la granja) con SQL Server Express, pero perfectamente podría ser una base de datos albergada en el controlador de dominio u otra máquina accesible en red.

Lo primero, acceder a ese gestor de base de datos (mediante SQL Management Studio mismamente) y crear una nueva base de datos específica para los brokers, que llamaré bróker a secas y que será perfectamente accesible y modificable por mi usuario de SQL Server por defecto, llamado “Enimbos”.

Ahora debemos volver al Server Manager, concretamente al esquema RDS.

Clicamos con el segundo botón sobre el dibujo del bróker en el esquema y seleccionamos Configure High Availability:

rds

En el asistente debemos especificar “Shared Database”, la dirección dns completa de los dos brokers, es decir, brokerha.enimbos.local y la cadena de conexión, que dependerá del driver ODBC que tengamos instalado en los brokers y del usuario y base de datos que nos hayamos creado, quedando en este caso de la siguiente forma:

Driver={SQL Server};Server=tcp:enimbosblog-rds-db.cvpdkpgzesjl.eu-central-1.rds.amazonaws.com,1433;Database=broker;Uid=Enimbos;Pwd=EnimbosBlog2018#;TrustServerCertificate=yes

Podemos averiguar el driver ODBC que tenemos dándole a Tools y ODBC data Sources (64 bits). En la pestaña Drivers veremos, al menos, uno llamado SQL Server, pero podemos instalar otros descargándolos de la web de Microsoft. Es necesario que el nombre del driver sea especificado con el nombre exacto.

Si todo ha salido bien ya podemos seleccionar con el segundo botón del ratón sobre el bróker la opción Add RD Connection Broker Server e iniciaríamos un asistente similar al del despliegue RDS pero teniendo que seleccionar solo un nuevo bróker.

Nota: debemos permitir el acceso a la base de datos, por lo que tendremos que configurar el firewall en el puerto 1433 (por defecto) y, en caso de utilizar servicios en nube, las reglas de entradas correspondientes en el grupo de seguridad.

Funcionalidad y operatividad de una granja RDS

De cara a ver cómo funciona una granja RDS hay que centrarse qué es y cómo se crea un Servidor de Ficheros y una colección de Escritorios Remotos.

Servidor de Ficheros

Lo primero que debemos hacer es configurar un servidor de ficheros para compartir carpetas en todo el dominio y que sirvan de ayuda para la granja. Concretamente se compartirán dos carpetas: una para almacenar los userprofiles (lo veremos más adelante) y otra que sirva de almacén temporal para facilitar la transferencia de ficheros entre el Session Host y la máquina anfitriona. También utilizaremos esta última carpeta para facilitar la función de autoescalado (lo veremos más adelante), pues sirve de apoyo a los scripts que usaré.

En primer lugar, es necesario instalar el rol de File Server. Lo haremos en EnimbosBroker1, aunque podríamos hacerlo en cualquiera.rds

Es importante marcar la casilla File Server Resource Manager si queremos utilizar características avanzadas de Samba, como veremos ahora.

El siguiente paso es dirigirse a la opción File and Storage Services del menú de la izquierda y seleccionar Shares. En la esquina superior derecha del marco principal clickeamos sobre Tasks y luego en New Share. Se iniciará un asistente.rds

La opción que debemos seleccionar es SMB Share -Advanced.

Luego debemos seleccionar el servidor EnimbosBroker1 y, muy importante, marcar que vamos a compartir rutas específicas. En este caso he creado una carpeta llamada RDS dentro C: y, a su vez, dos carpetas dentro de esta: UserProfiles y Datos, y ambas las compartiré. Se puede ver que las carpetas pueden ser creadas en el propio asistente.

Ya tenemos las carpetas preparadas para ser usadas en todo el dominio. La forma de acceder es mediante el siguiente formato \(nombredelequipo)(nombredelacarpeta)

El asistente te muestra otras opciones como la de gestionar permisos o aplicar cuotas, pero las obviaremos por ser irrelevantes en el ejemplo que estoy ilustrando.

Colección de Escritorios Remotos

Ahora viene el paso más importante, pues debemos facilitar el acceso al RDHost actual y a los que se irán creando por autoescalado, por lo que debemos crear lo que en RDS se conoce como Colección, que no es más que una forma de agrupar varios Session Hosts a los que se puede acceder remotamente (o a aplicaciones remotas) bajo las mismas políticas de seguridad, de tal forma que el bróker sabe dónde y cómo debe aplicar sus reglas de balanceo así como restringir o permitir el acceso a un determinado grupo de usuarios, además de otras reglas como las relacionadas con la autenticación  y los tiempos y límites máximos de cada sesión. Esta parte está sujeta al criterio del administrador.

Para crear una colección debemos seleccionar Collections en el menú de los RDS y, acto seguido, clicar sobre Task, donde podremos ver la opción Create Session Collection. También completamos más abajo con información sobre qué equipos tienen el rol de RDHost.rds

Una vez dentro disponemos de un asistente donde, entre otras cosas, debemos autorizar a los usuarios que podrán acceder remotamente a los equipos de la colección y, sobretodo, qué RDHosts pertenecerán a la colección. Estos deben tener ese rol instalado.

Otra opción importante es la de los UserProfiles, que consistirá en una carpeta (en este caso compartida), donde se almacenarán imágenes de disco de cada usuario que acceda a la granja desde la primera vez y que se cargarán durante los inicios de sesión del usuario.

Podemos usar un programa llamado Sidder que no requiere instalación y que nos permite gestionar los archivos de imagen de disco, pudiendo comprobar a quién pertenecen y pudiendo borrarlos si no están en uso (se marcan en rojo). En la siguiente foto podemos ver un ejemplo de su función, que es bastante intuitiva y sencilla.rds

Esta imagen muestra únicamente un usuario, que es con el que iniciaré sesión en el ejemplo que mostraré más adelante. La otra imagen es simplemente un template.

La colección la he llamado Escritorios Remotos, y será ese el nombre con el que se muestre en la web que nos proporcionará la máquina de rol RDWeb (EnimbosBroker2).

Podemos editar las características de la colección clickeando en el nombre de la colección en el menú de la izquierda y, posteriormente, en Tasks y Edit Collection en el marco superior del menú. Estas opciones también están sujetas a los criterios del administrador.

Entre otras posibilidades, podemos configurar las reglas de balanceo, los criterios de conexión y desconexión de las sesiones de usuario y, muy importante, aquello que va a compartir la máquina anfitriona con los Session Hosts de la colección. En este caso he escogido, por motivos de seguridad, que solo se comparta el audio y el portapapeles.

Por último, debemos revisar la configurar general del despliegue de la granja. Para ello debemos situarnos en el menú Overview de Remote Desktop Services y clicar sobre Tasks en la esquina superior derecha del esquema de la granja, una vez ahí pulsamos sobre Edit Deployment Properties. Este menú nos permite configurar cada uno de los elementos principales de la granja: RDWeb, RDBrokers, RDLicensing, y RDGateway. En nuestro caso solo nos interesan los dos primeros, aunque ya tenemos el RDBroker bien configurado. Sin embargo, necesitamos saber la URL desde la que podremos descargar el archivo rdp personalizado de la colección que hemos creado:

Ahora solo debemos acceder a esa URL y autenticarnos. Esta web es accesible desde todos los equipos del dominio y conviene añadir una entrada DNS concreta al igual que hicimos para los RDBrokers, aunque solo sería para una IP. El acceso a la web lo haremos desde Google Chrome y nos autenticaremos con el usuario administrador, aunque podría ser cualquiera que pertenezca al dominio siempre y cuando los hayamos autorizado.

Como aún no hemos configurado los certificados (se puede hacer desde el menú anterior), la página se muestra como no segura, pero solo tenemos que añadir una excepción y entrar igualmente. Más adelante accederemos a ella por https con certificado seguro.

En la siguiente página disponemos de los archivos RDP (uno por colección de escritorio remoto) con los nombres que hayamos puesto a cada colección. Si hubiésemos creado una colección de Remote Apps, veríamos las aplicaciones remotas que hemos publicado, que también se descargarían como ficheros RDP. Descargamos Escritorios Remotos.

Ahora solo debemos ejecutarlo y nos dirigiremos a uno de los brokers (según Round Robin), y de este al RDHost correspondiente según el criterio de balanceo.

Al ejecutar el fichero RDP podemos ver un mensaje de advertencia. Esto es debido a que el Publisher del fichero es desconocido. Más adelante lo solucionaremos cuando configuremos los distintos certificados que usará la granja. Le damos a conectar.Podemos ver en la imagen que nos encontramos conectados al equipo EnimbosHost1, pero sin embargo la aplicación de Escritorio Remoto nos indica que estamos en EnimbosBroker1, pues la función del bróker es precisamente hacer de puente entre la máquina anfitriona y los Session Host, aplicando el balanceo que corresponda.

Ya tenemos la granja RDS en pleno funcionamiento. De hecho, podemos visualizar desde el Server Manager en EnimbosDC los usuarios que han iniciado sesión en la colección.

Autoridad certificadora

En este tercer y último paso atenderemos a la configuración de los certificados y la función de autoescalado mediante scripts de Powershell y Tareas Programadas.

¿Cómo configurar la autoridad certificadora?

Ya tenemos la granja RDS funcional al 100%. Todos los usuarios de dominio pueden acceder sin problemas a cualquiera de los equipos de la colección “Escritorios Remotos” de forma balanceada y con alta disponibilidad (gracias al uso de los brokers). Sin embargo, Windows nos estará advirtiendo en todo momento de que tal vez no estemos accediendo al lugar que deseamos, ya sea porque el equipo no se identifica de manera correcta o porque de cara al equipo origen (desde el cual accedemos a la granja) resulta un completo desconocido.

Es ahí donde entran en juego los certificados, de la misma forma que ocurre con las páginas webs, y su funcionamiento no es muy diferente.

Partimos de la base de que tanto los equipos como los usuarios que interactuarán en la granja RDS formarán parte del mismo dominio, por lo que simplemente es necesario poseer certificados que, de algún modo, estén autorizados única y exclusivamente dentro del propio dominio, careciendo de toda validez más allá de ese contexto.

Como era de esperar en Windows Server, esto se consigue empleando un rol, y este rol deberá ser instalado en una de las máquinas del dominio, no necesitando más requisito que el de estar encendida y con el servicio corriendo en el momento en el que se creen los certificados de equipo o usuario (este último es realmente útil para el “Code Signing”). Es importante que todas las máquinas que formen parte de la granja RDS tengan acceso a esta máquina, aunque no necesariamente tienen por qué tener acceso todos los usuarios.

Accedemos al equipo del dominio donde deseamos instalar el rol, y luego al Server Manager. Una vez dentro, le damos a “Administrar” y a “Agregar roles y características”, a partir de aquí los pasos son los mismos de siempre, no necesitando otra acción que darle a “Siguiente”. Cuando lleguemos a la lista de roles, marcamos la que dice “Servicios de certificados de Active Directory”, como muestra la captura:

Al darle a “Siguiente”, en la ventana que se abre le damos a “Agregar Características”. Volvemos a darle a “Siguiente” sin marcar nada en el menú de selección de características. Una vez llegados al menú de selección de “Servicios de rol”, seleccionamos únicamente “Entidad de certificación” (nos basta para este ejemplo). Le damos a “Siguiente” y luego a “Instalar”, una barra de progreso nos indicará la situación.

Una vez finalizado (no requiere reinicio), podemos ver que en el menú de la izquierda del Server Manager se ha añadido el apartado “AD CS”, al que si accedemos nos mostrará un mensaje de advertencia de que tenemos pendiente configuraciones:

Por ahora, no es necesario que accedamos al menú específico de “Certification Authority”. Simplemente cliqueamos sobre el icono de la bandera en la esquina superior derecha del Server Manager, que mostrará una señal de “Warning” y cliqueamos luego sobre “Configurar servicios de certificados de Active Directory”, lo que nos abrirá un nuevo asistente.

Lo primero será seleccionar el usuario con el que vamos a realizar los pasos, que podrá ser cualquiera que sea “Admin. Del Dominio”, y le damos a “Siguiente”. En el siguiente menú marcamos “Entidad de Certificación” solamente, por ahora no hace falta más. Luego seleccionamos “CA Independiente” (Standalone en inglés). También nos valdría el empresarial, pero en este caso nos es necesario.

Además, los Standalone CA nos sirven también para WORKGROUPS. Posteriormente seleccionamos “CA Raíz”, puesto que es el primer certificado que estamos creando y no necesitamos certificados intermediarios. Luego seleccionamos “Crear una clave privada nueva”, ya que, en teoría, partiendo de este ejemplo, no poseemos aún ninguna más.

El menú referente al cifrado del certificado se puede dejar tal y como está, aunque puede requerir otra configuración acorde a las necesidades de seguridad del dominio. Le damos a “Siguiente” y especificamos el nombre para la entidad de certificación, en este caso “EnimbosCA”.

Podemos ver como su sufijo CN se ajusta en AD al nombre que hemos puesto:

Le damos a “Siguiente”. El periodo de validez es personalizable, aunque en este caso lo dejaremos como está, en 5 años. Cliqueamos sobre “Siguiente” y luego de nuevo sobre “Siguiente”. Se nos mostrará un resumen de todo lo que hemos seleccionado. Si nos parece todo correcto, le daremos a “Configurar”. Si todo ha salido bien, ya podremos acceder al menú específico del Certification Authority. Cliqueamos sobre “AD CS” en el menú de la izquierda del Server Manager y luego clic al segundo botón sobre el nombre de nuestro servidor. En el menú contextual seleccionamos “Certification Authority” y nos aparecerá un nuevo menú con nuestro certificado CA disponible, llamado EnimbosCA.

Si desplegamos el CA y le damos a “Certificados emitidos”, vemos que no hay ninguno.

El siguiente paso consistirá en crear certificados de equipo que estén autorizados por este CA. Ese certificado deberá configurarse para ser mostrado en el acceso por RDP, de tal forma que al equipo origen le resultará confiable el equipo destino y no mostrará mensaje de advertencia. Conviene añadirlo también en los brokers y en el Publish Profile, ya que vimos en la anterior entrada que se mostraba un “warning” porque el “editor” del fichero RDP era desconocido o no era fiable. También ocurre al acceder a la DNS de los brókers.

En el equipo destino en el que queramos configurar el certificado, pulsamos sobre la lupa de la barra de tareas y escribimos “mmc”, le damos clic y entramos. Una vez estemos en el nuevo menú debemos darle a “Archivo” y a “Agregar o quitar complementos”. A continuación, en el siguiente menú seleccionaremos “Certificados” y le daremos a “Agregar”. Finalmente, en la ventana que se nos abre, es importante que seleccionemos “Cuenta de Equipo” y “Equipo local”, ya que va a ser el certificado que identificará a nuestro equipo. Veremos un menú similar a este:

Cliqueamos con el segundo botón sobre “Personal/Certificados” y seleccionaremos “Todas las tareas/Solicitar un nuevo certificado”. Le damos a “Siguiente” hasta que aparezca una ventana donde se nos da elegir el tipo de certificado que queremos. En este caso “Equipo”. Podremos configurar varios parámetros dándole a “Detalles”, pero en este caso no es necesario. Le damos a “Inscribir” y comenzará el proceso. Si todo ha salido correctamente, podremos ver el certificado en la lista y también podremos ver que ha sido autorizado por la CA que hemos creado antes, en lugar de ser autofirmado.

El siguiente paso será configurar ese certificado para ser mostrado en el acceso por RDP.

En la máquina en la que hemos creado el certificado, abrimos una ventana de CMD como Administrador y copiamos y pegamos el siguiente comando:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=»THUMBPRINT»

Aún no lo lanzamos, pues tenemos que conocer el thumprint o huella digital de nuestro certificado. Para ello volvemos al menú anterior, a “Personal/Certificados” y hacemos doble clic sobre nuestro certificado. En la nueva ventana, seleccionamos la pestaña “Detalles” y bajamos hasta el campo “Huella Digital”, donde al cliquearlo veremos una serie de caracteres hexadecimales en el recuadro de abajo.

rds

Todos esos caracteres debemos seleccionarlos y copiarlos con CTRL+C. Conviene pegarlos en un bloc de notas previamente, pues debemos eliminar todos los espacios. Una vez hecho, cambiamos la palabra THUMBPRINT del comando anterior por los caracteres que hemos obtenido. Al lanzarlo, debería mostrarse algo similar a esto:

Ahora ya no tendremos mensajes de advertencia en el acceso a ese equipo por RDP.

Ahora solo tenemos que configurar los certificados propios de los servidores especiales de la granja, como los brokers y el rdweb. El proceso de creación del certificado en el rdweb es similar a los equipos RDHost de la granja, a menos que quiera usarse un nombre DNS distinto para acceder a la web que publica los ficheros RDP.

Por ejemplo, si nuestra máquina que tiene el rol de servidor web en la granja se llama “enimbosweb” (nombre que aparecería en Active Directory como enimbosweb.enimbos.local, por ejemplo), podemos crear un certificado siguiendo el método anterior, y valdría para aquellos casos en los que quisiésemos acceder a esa web introduciendo en el navegador https://enimbosweb.enimbos.local (los sufijos DNS configurados podrían autocompletar la dirección completa a partir de “enimbosweb”); pero tal vez nos interese que la URL sea del tipo “granjards.enimbos.local”, ya que de esa forma se gana transparencia y los usuarios o los administradores no conocerán el nombre de la máquina y la URL describe única y exclusivamente el servicio que les interesa, sin necesidad de saber más.

En ese caso es necesario crear certificados siguiendo otro método, uno que sea sencillo y nos permita introducir un valor de “CN” personalizado, por lo que conseguiríamos que le FQDN y el CN del certificado coincidieran independientemente de que se llamara así la máquina que ofrece el servicio. Además, este método es obligatorio en brokers con HA, ya que es necesario referenciar una DNS compartida por ambos servidores y no una que referencie a uno solo, pues, aunque estuviéramos conservando la alta disponibilidad igualmente, los equipos que acceden a la granja estarían “confiando” en un bróker y no en el otro, por tanto, es necesario un certificado cuyo CN completo sea esa DNS común.

Una forma sencilla de hacerlo es mediante IIS (Internet Information Services), lo cual no nos supone un problema porque la máquina que tiene el rol de RDWEB tiene ese servicio instalado. Accedemos a esa máquina y abrimos el IIS Manager, que podemos hacerlo por la búsqueda en la barra de tareas o accediendo a “Panel de Control/Herramientas Administrativas”.

Una vez dentro, en el menú de la izquierda (“Conexiones”) podemos ver el nombre de nuestro servidor web, cliqueamos sobre él. En el menú que se muestra a la derecha podremos ver la opción “Server Certificates”, a la que accedemos con doble clic. Veremos un menú similar a este, donde debemos escoger la opción del menú de la derecha que dice “Crear certificado de dominio”:

 

rds

Se iniciará un asistente donde deberemos introducir los datos del certificado, como su nombre común, la unidad organizativa, etc. Esos datos dependerán de cada caso particular, pero es importante que el nombre común coincida con el nombre DNS entero.

Tras rellenar esos campos, le damos a “Siguiente” y tendremos que seleccionar el CA, el cual no tendremos que meter manualmente, sino que daremos a “Seleccionar” y lo escogeremos.

Acto seguido, debemos añadir un friendly name, que será, por regla general, el nombre común que va antes del primer punto (enimbosweb, por ejemplo, en vez de enimbosweb.enimbos.local). Le damos a “Finalizar” y el certificado se creará. Podremos ver que ahora aparece en la lista. Ahora solo necesitamos exportarlo, por lo que cliquearemos con el segundo botón sobre él y seleccionaremos “Exportar” en el menú contextual.

Lo siguiente será indicar el nombre y ruta del fichero y especificar una contraseña para la clave privada. Lo ideal es guardarla en una ruta compartida, como la que creamos en la entrada anterior con SMB. Se guardará, a menos que indiquemos lo contrario, en formato “pfx”.

Una vez exportado, debemos ir al Controlador de Dominio o al servidor del dominio donde, de forma centralizada, gestionemos la granja RDS. En nuestro caso estamos usando el primer controlador de dominio.

Accedemos a esa máquina y luego al Server Manager. En el menú de la izquierda cliqueamos sobre “Servicios de Escritorio Remoto” y luego, a la derecha, en “Información general”. Podremos ver un esquema gráfico de la granja RDS, cliqueamos en la esquina superior derecha de ese recuadro en “Tareas” y luego en “Editar propiedades de implementación”. En el nuevo menú, deberemos acceder al apartado “Certificados”.

Tenemos que ir seleccionando los servicios uno a uno. El primero hace referencia al certificado que identificará al equipo en cada uno de los brokers. Una vez seleccionado, cliqueamos en “Seleccionar certificado existente” y, en la nueva ventana, marcaremos “Escoger un certificado distinto”, donde indicaremos la ruta donde está el fichero “.pfx” e introduciremos la contraseña especificada antes.

Es importante marcar la casilla de abajo para que se pueda hacer la importación. Una vez le hemos dado a “Aceptar”, solo tenemos que darle a “Aplicar” en la ventana anterior. Deberíamos ver ahora cómo al lado del servicio se indica “De confianza” como nivel. Además, también podemos ver información sobre el certificado abajo e incluso darle a “ver detalles” para ver más.

Luego repetimos el mismo proceso para el servicio de abajo, que hace referencia al Publisher o editor de los ficheros RDP que descargamos del RDWEB. Este certificado puede ser el mismo que el anterior o puede crearse uno nuevo para este caso. Con estos dos pasos evitamos que mensajes como este puedan aparecer al ejecutar los ficheros RDP:

 

En el caso de no poner un certificado correcto en el Publisher, el mensaje sería similar a cuando ejecutamos aplicaciones de desconocidos en Windows.

El último paso sería hacerlo para el servicio de rdweb y, como ya hemos dicho, podemos hacerlo creando un certificado para el nombre de la máquina o para el nombre DNS que hemos escogido personalmente. Sea como sea será una conexión https segura.

Estos certificados también están sujetos a caducidad y tendremos que tenerlos en cuenta para hacer una renovación cuando sea necesario.

En la siguiente entrada abordaremos el tema del autoescalado de máquinas RDHost en AWS, donde será necesario combinar scripts de Powershell con Tareas programadas.

Related Posts