¡Lo prometido es deuda! Por ello esta nueva entrada de blog es una continuación de las dos entradas anteriores realizadas por nuestro compañero Hugo Margallo, donde ha ido explicando detalladamente cómo construir una granja de servidores Windows Server 2016 empleando los roles de Remote Desktop Services y desplegándose sobre una infraestructura jerárquica en nube de 4 servidores, en este nuevo post completaremos la información explicando qué es y cómo se crea una Autoridad certificadora paso a paso y de manera completamente detallada para que no te quede ninguna duda ¿vamos a por ello?

1. 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 clickeamos sobre el icono de la bandera en la esquina superior derecha del Server Manager, que mostrará una señal de “Warning” y clickeamos 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. Clickeamos 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. Clickeamos sobre “AD CS” en el menú de la izquierda del Server Manager y luego click 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 click y entramos. En el nuevo menú debemos darle a “Archivo” y a “Agregar o quitar complementos”. En el siguiente menú seleccionaremos “Certificados” y le daremos a “Agregar”. 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:

Clickeamos 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 click sobre nuestro certificado. En la nueva ventana, seleccionamos la pestaña “Detalles” y bajamos hasta el campo “Huella Digital”, donde al clickearlo veremos una serie de caracteres hexadecimales en el recuadro de abajo.

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 y/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, clickeamos sobre él. En el menú que se muestra a la derecha podremos ver la opción “Server Certificates”, a la que accedemos con doble click. Veremos un menú similar a este, donde debemos escoger la opción del menú de la derecha que dice “Crear certificado de dominio”:

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 clickearemos 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 clickeamos sobre “Servicios de Escritorio Remoto” y luego, a la derecha, en “Información general”. Podremos ver un esquema gráfico de la granja RDS, clickeamos 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, clickeamos 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.

En la siguiente entrada explicaremos la función de autoescalado mediante scripts de Powershell y Tareas Programadas.

About Hugo Margallo

Hugo Margallo Gracia / Cloud Consultant. Hugo is Technical Engineer in Computer Systems by Extremadura University and he has a masters in Information and Communication Technology Management. He started his professional career in 2005 managing and setting up networks, joining Enimbos in 2018 as Cloud Consultant.