En esta quinta nota de la serie, vamos a comenzar a quitar las advertencias de seguridad que aún nos muestra cuando ingresamos por “RD Web Access”
Además y previendo que luego vamos a instalar y configurar “RD Gateway”, para permitir el acceso desde otras redes externas, vamos a hacer unos cambios sobre el certificado digital que identifica a la máquina “rd-wa-cb-gat”
Comencemos repasando lo que tenemos hasta ahora, en cuanto a advertencias de seguridad en los clientes
Comienzo en CL1 (W8.1) accediendo a https://rd-wa-cb-gat.guillermod.com.ar
Ya anteriormente habíamos solucionado que no hubiera problema con el certificado del servidor, y no recomendara acceder al sitio
El problema que nos queda por resolver es cuando el usuario inicia una aplicación y recibe el mensaje “A website is trying to run a RemoteApp program. The publisher of this RemoteApp program can’t be identified”. Y observen además que no tenemos opción para marcar de que no lo vuelva a mostrar. Este era un tema que no había podido solucionar en notas anteriores del blog
En cambio en CL2 (W10) usando Edge, el problema es diferente, no muestra la anterior advertencia, pero impide que el RDP descargado se ejecute automáticamente
[Nota] Esto no lo he podido solucionar al día de hoy
Vamos a comenzar con el tema de los certificados, en Escritorio Remoto la autenticación a los diferentes servidores que contactará el cliente es importante. El cliente se conecta al “RD-Web Access”, que lo contacta con el “RD-Connection Broker” que a su vez le informa cuál “RD-Session Host” que debe contactar. Sí, es así de “complejo” :)
Sobre todo son muy importantes los certificados de “RD-Web Access” y “RD-Connection Broker”
Justamente para facilitar esta configuración es que, como he comentado en la primera nota, hice coincidir estos dos roles en el mismo equipo (“rd-wa-cb-gat”). Y donde luego instalaré el rol “RD-Gateway”
Entonces en el administrador del IIS de este servidor, abrimos “Server Certificates”
Y vamos a solicitar un certificado más, asociado al sitio web, y aclaro los motivos por los que haré un cambio
A futuro también en este equipo se instalará la funcionalidad “RD-Gateway” que será accedido desde el exterior de la red de trabajo, y por lo tanto se deberá usar un nombre público del servidor, y no el nombre interno del Dominio Active Directory
El nombre del Dominio Active Directory que estoy usando es “ad.guillermod.com.ar”, y voy a suponer que el nombre público en internet es “guillermod.com.ar”. Por lo tanto necesitaré un certificado a nombre de esta máquina que contenga el nombre de dominio de prescencia en Internet. Usaré “rd.guillermod.com.ar”
Vamos entonces a solicitar el nuevo certificado para el sitio web
Muy importante es que pongan exactamente el nombre con resolución externa
Indicamos a que Autoridad Certificadora se solicitará el certificado
Le pones un “Friendly Name” que nos permita identificarlo fácilmente
Y ya está
Este certificado debemos exportalo para luego poder incluirlo en los procesos de autenticación
Ya lo guardo directamente en DC1 que es donde haré el procedimiento, y le pongo una contraseña, ya que se exportará incluyendo la clave privada (Importante)
Ya lo tenemos en DC1
Y vamos a asignarlo
Observen que hay tres roles para asignar certificados, debemos hacer lo mismo para los tres. Muestro el proceso en el primero, pero hay que repetirlo para todos
Hay que ir haciendo “Apply” por cada certificado
Quedando finalmente así
Como por ahora, estamos probando todo en la misma red (interna) pero estoy previendo que luego se pueda acceder externamente, y por eso el cambio de nombre del certificado, debo hacer que de alguna forma las máquinas internas puedan resolver el nombre externo
Me he tomado una licencia por estar en ambiente de demostración, y en el DNS he creado manualmente un zona similar a la que será externa (guillermod.com.ar) creando el registro correspondiente a “rd.guilermod.com.ar”. Podría haber sido también modificando el archivo HOSTS de las máquinas que necesiten acceder
Vamos a comenzar a probar en los clientes a ver qué cambios hay, si los hubiera. Comienzo en CL1 (W8.1)
Atención, ahora me conecto al nombre “externo” (https://rd.guillermod.com.ar/RDWeb)
Sigue saliendo la advertencia, aunque ahora sí tenemos la opción de que no la vuelva a mostrar. A diferencia de lo resaltado, no la marquen, ni cancelen, sigamos el siguiente procedimiento
Podemos ver en el cuadro quién es el “Publisher”, y si pulsamos sobre el mismo veremos el certificado presentado. Vamos a la ficha “Details” y veamos el “Thumbprint”. Este está presente en todos los certificados emitidos a esta máquina
Vamos a configurar mediante GPO que todos los certificados con este “Thumbprint” sean confiables
Debemos copiarlo, pero con una salvedad, sin espacios, y cuidado si usan “Copy/Paste” porque hay un caracter no visible al principio de la cadena de caracteres. Lo pueden verificar si hacen el “Copy/Paste” al Notepad y cuando lo vayan a salvar dará una advertencia de que se perderán caracteres Unicode
Así que lo mejor es tomarse el trabajo de copiarlo a mano, en un Notepad, y salvarlo en DC1 que es donde lo utilizaremos luego
Como habíamos dicho, debemos crear una GPO para que todos tomen este “Thumbprint” como confiable
Así que en DC1 creé una GPO (“RD-Thumbprint”) enlazada a nivel Dominio donde haré la configuración correspondiente
Debemos editar “Computer Configuration / Policies / Administrative Templates / Windows Components / Remote Desktop Services / Remote Desktop Services Client / Specify SHA1 thumbprints of certificates representing trusted .rdp publishers” (uffffff) y pegar el “thumbprint” correspondiente
En ambos clientes, abro un CMD como administrador y actualizo las GPOs
Pruebo primero en CL1, y sí, por fin, hemos quitado la advertencia :)
No así la de CL2 (W10 con Edge)
Sí, si usamos IE
Ya tenemos solucionado el tema de las advertencia con “RD-Web Access” y preparado el certificado para que se pueda acceder desde redes externas
Continuaremos en la próxima nota “Remote Desktop – Escritorio Remoto: Instalación y Configuración de “RD-Gateway” (Nota 6)”
WindowServer 
Comentarios
Buenas tardes guillermo, me encanta tu trabajo, oye estoy atorado con la renovación del certificado, tienes alguna nota al respecto?
te agradezco mucho por la información que has compartido
Hola Alejandro, me alegro te guste el blog :)
Pulsando en el margen izquierdo en «Buscar» y «autoridad certificadora» me salen 115 resultados :)
Buenas tardes Guillermo, te estopy muy agradecido por estos manuales tan estupendos, soy un iniciado en esto y gracias a ellos estoy poniendo en marcha un servidor para el uso en la empresa.
Mi duda es la siguiente, tras configurar el rd-gateway, puedo acceder sin problemas a la red de forma externa, pero con una condición y es que en los equipos clientes tengo que modificar el archivo drivers/etc/hosts y agregarle la mi ip publica+ nombre servidor; la duda es, ¿Hay que hacerlo así obligatoriamente?, lo digo por que trabajamos con el servicio DYNDNS, y por supuesto este no se puede aplicar al archivo HOSTS para que funcione.
Por otro lado al dia siguiente de la instalación al intentar conectarme con rd o rdweb, al mandar la autenticación de los usuarios me saltaba el siguiente mensaje: la conexion se interrumpio porque se recibe un certificado de autenticacion de servidor inesperado desde el equipo remoto. Finalmente indagando por internet vi que debia cambiar la fecha, asi que le puse la fecha del dia de la instalación y todo funcionó correcto y luego la actualicé, mi duda es si esto volverá a surgir, ya que veo que los certificados generados tienen 1 año de caducidad, ¿habra que estar generando siempre certificados?.
Muchas gracias por tu atención y por tu gran labor para ayudar y formar a expertos y principiantes.
¿¿Que la fuerza te acompañe!!
WordPress no te quiere, te saqué de la carpeta de spam :D
Lo que es obligatorio es que el certificado tiene un nombre, luego la conexión debe hacerse a ese nombre, no puede ser una alias, ni la dirección IP, ni ninguna otra forma. Si conectas con un nombre diferente al del certificado siempre va a decir que no corresponde el certificado presentado con el nombre
Lo segundo que nombras seguramente debe estar relacionado con lo anterior también
Por otra parte, los certificados son así, tienen un período de validez asignado durante la obtención del certificado, esto lo establece la autoridad certificadora, corresponde renovarlos antes de la expiración. Los sistemas «viejos», si verificaba que el certificado era válido pero vencido igual permitía la conexión, los «nuevos» ya no, si está vencido «no sirve»
Hola Guillermo!! Disfrutando al máximo de tu blog y de tus Posts :)
En mi caso tengo una duda referente a los certificados, tengo cada role instalado de forma independiente en servidores distintos, dispongo del certificado con el FQDN público para el RDG, para el RDWA quiero usar un certificado wilcard del tipo *svc.dominio.com y mi duda aparece con el/los certificado/S que debo usar en los otros dos casos para el Connection Broker Enable SSO y Publishing… Puedo usar cualquiera de los dos que dispongo? debo usar otro distinto? qué recomiendas en cada caso?
Espero que puedas aclararme la duda. Muchas gracias por tus aportes a la comunidad.
Hola Xisco, no me hagas leer de nuevo toda la serie de notas, hay muchos pasos que ahora no recuerdo, otra cosa era cuando iba planeando la infraestructura paso a paso :)
A ver si puedo resumir un poco. El uso de certificado es para que el cliente autentique al servidor, y luego crear un canal cifrado con una clave que le transmite el servidor al cliente, para que este ponga usuario/contraseña, y que se pueda validar el cliente
Para que un cliente tome como válido el certificado tiene que sí o sí, coincidir con el nombre que el cliente usa para conectarse, y por supuesto tener el certificado de la CA que emitió el certificado
En el esquema con el RDG, éste se comporta como un «gateway», es decir, recibe el pedido del cliente, que es RDP encapsulado en HTTPS, quita la parte HTTPS y envía el RDP al servidor que corresponda, o si se sa RDWeb a dicho servidor, que redirecciona al cliente para que use RDP hacia el RDSH
Bueno, te dejo pensando :D
Trackbacks
[…] Vamos avanzando de a poco con el tema, para la próxima nota seguiremos con “Remote Desktop – Escritorio Remoto: Quitar Advertencias y Preparación para “RD-Gateway” (…” […]
[…] Remote Desktop – Escritorio Remoto: Quitar Advertencias y Preparación para “RD-Gateway” (… […]
[…] Remote Desktop – Escritorio Remoto: Quitar Advertencias y Preparación para “RD-Gateway” (Nota… […]