En esta sexta nota, y continuando con la serie, veremos la instalación y configuración de la funcionalidad “Remote Dekstop Gateway” (Puerta de Enlace de Escritorio Remoto), describiremos su funcionalidad y por supuesto demostraremos su utilización
Es muy importante tener en claro cuál es su funcionalidad, y qué tipo de acceso permite, y sobre todo las diferencias con “Remote Desktop Web Access” (Acceso Web a Escritorio Remoto) y el uso de cada uno
Además, y no tan conocido, es que “RD-Gateway” permite que se limite qué usuarios se podrán conectar y a qué equipos podrán acceder, entre otras cosas
Así que en este caso veremos primero que nada estas diferencias
Es un error muy común pensar que teniendo configurado “RD-Web Access” que permite el acceso a aplicaciones publicadas (RemoteApp) y Escritorio Remoto y verificando que funciona en la red interna, esto va a permitir el acceso desde otras redes, y esto normalmente no es así
“RD-Web Access” crea un sitio web que funciona bajo HTTPS pero que se limita a presentar las aplicaciones al cliente, pero luego cuando el cliente va a ejecutar una aplicación o conectarse a un Escritorio Remoto, utiliza protocolo RDP, y por supuesto, por motivos de seguridad básicos, este no está permitido en los cortafuegos. Por lo tanto no es accesible desde “afuera”
Para evitar este problema es que existe la funcionalidad “RD-Gateway” que permite encapsular el tráfico de protocolo RDP en HTTPS y por lo tanto pasar a través de los cortafuegos
Y por lo tanto permite que el cliente usando solamente HTTPS pueda hacer conexiones de Escritorio Remoto. Atención con algo, no estoy nombrando RemoteApp, esta es una limitación a tener en cuenta, sólo Escritorio Remoto
Comencemos entonces en DC1, donde hemos centralizado toda la administración de Escritorio Remoto, instalando la funcionalidad “RD-Gateway” en la máquina “rd-wa-cb-gat”
Recordemos que todos los iconos en color verde son los componentes no instalados, así que pulsando sobre el correspondiente comenzará el asistente
Como había propuesto al principio instalaré la funcionalidad en el mismo equipo donde ya está “RD-Web Access” y “RD-Connection Broker”, así que lo selecciono
¿Recuerdan que ya habíamos puesto el certificado con el nombre público que se utilizará para accederlo externamente? Hay que escribir ese justamente
Y cuando finaliza debemos configurar el certificado correspondiente, que servirá para que el cliente pueda autenticarlo
No he capturado todas las pantallas para que no sea tan larga esta nota, pero procederemos análogamente a lo que hemos hecho con los otros roles
Debe quedar así
Y podemos ver que ahora que ya está instalado el componente el icono se ha grisado, igual a los otros ya instalados
Repasemos algunas de las configuraciones que se hicieron anteriormente
Podemos ver que el sistema ha cambiado automáticamente la configuración para que se comience a utilizar “RD-Gateway”
Para comenzar a configurar esta funcionalidad, necesitamos una herramienta que por omisión no se instala en el equipo donde estamos centralizando todo, y tiene su motivo. Para hacer la instalación de esta consola, entre otros componentes se necesita instalar IIS, lo cual no sería una buena idea que esté en cualquier máquina
Si lo deseamos se puede instalar en DC1, yo prefiero ir directamente a la máquina que tiene la funcionalidad (rd-wb-cb-gat) y hacerlo desde allí. Debemos seleccionar “Remote Desktop Gateway Manager”
Vamos a ver qué opciones tenemos para configurar. Comencemos con las propiedades del servidor
En la ficha “General” podemos, como importante, seleccionar cuál es límite máximo de conexiones simultáneas, o deshabilitar nuevas conexiones, por ejemplo si está prevista una parada del servicio por mantenimiento
En “SSL Certificate”, no tenemos nada que hacer ya que tenemos el certificado correcto
En “Transport Settings”, podríamos configurar en cuáles direcciones IP atíende el sistema y que protocolos y puertos se usarán
En “RD CAP Store” (ya veremos qué son las RDCAPs) podemos seleccionar usar un NPS (“Network Policy Server”) separado. NPS tiene funcionalidad RADIUS y más
En “Server Farm” en nuestro caso no lo he implementado, pero se podría usar una granja de servidores para proveer tolerancia a fallas o balance de carga
En “Auditing” podemos seleccionar qué acciones se auditarán
“SSL Bridging” permitiría “puentear” las conexiones SSL para comunicarse con otro servidor, por ejemplo si el “RD-Gateway” estuviera en una DMZ
Y por último en “Messaging” podemos poner dos mensajes para que muestre a los usuarios. El primero por ejemplo avisando que está programada una interrupción del servicio, y el segundo de uso aceptable. Aunque en este caso me he permitido hacer algo de humor, ya lo veremos cuando muestre la conexión desde un usuario ;)
Antes de continuar, aclaro dos abreviaturas muy usadas, y que el propio sistema las utiliza
CAP = “Connection Authorization Policies”: permiten limitar qué usuarios podrán conectarse
RAP = “Resource Authorization Policies”: configuran a qué recursos de la red podrán acceder los usuarios que se conecten a través de “RD-Gateway”
Comencemos viendo la CAP creada por omisión
En “General” sólo cambiar el nombre, y si la habilitamos o no
En “Requirements” vemos que por omisión están autorizados todos los usuarios del Dominio, podríamos limitar a un determinado grupo. Lo mismo se pueden limitar qué máquinas del Dominio, por omisión todas
En “Device Redirection” se explica por sí mismo
Y en “Timeouts” la duración de las sesiones activas y ociosas
Vamos ahora a las propiedades de la RAP por omisión
En “General” es análogo a la CAP
En esta demostración, no he puesto limitaciones, así que en “User Groups” no muestra limitaciones
En “Network Resource” es donde se puede limitar a qué máquinas podrán acceder los usuarios, por supuesto que en este caso no he puesto limitaciones
Y finalmente en “Allowed Ports” que puertos estarán permitidos
Entonces resumiendo: el uso de “RD-Gateway” es para acceso desde una red externa, pero también puede funcionar en la red interna, así que antes de hacer el movimiento de las máquinas clientes a una red externa, lo pruebo desde un cliente y controlo que todo siga funcionando bien por “RD-Web Acces” en ambos clientes (no vaya a suceder que por agregar algo, estropeemos algo que ya funciona :))
Observen que ya utilizo el nuevo URL (https://rd.guillermod.com.ar/RDWeb)
Todo bien
Recuerdo que habíamos dejado desde la primera nota que tanto en RDSH1 como RDSH2 habíamos permitido el acceso a todos los usuarios a Escritorio Remoto, incluyendo a “Domain Users” en el correspondiente grupo local “Remote Desktop Users”
Ahora moveré a los clientes a una red externa, simulando Internet, aunque disculpen que esté usando direccionamiento privado por limitaciones de mi ambiente de laboratorio
Agregué un equipo con Windows Server 2012 R2 que está cumpliendo funciones de NAT y compartir Internet, simulando un Router, interconectando la red del Dominio con esta Internet simulada. Si alguien tiene dudas cómo configurarlo puede consultar la siguiente nota: “Windows Server 2012: Compartir Conexión a Internet”
La única configuración adicional, fue redirigir todo el tráfico HTTPS recibido en la interfaz externa, a la del equipo “rd-wa-cb-gat” en la red interna. Todo lo que llegue a 192.168.0.14-TCP443 enviarlo a 192.168.1.103-TCP443
En cada uno de los clientes (CL1 y CL2) los conecté a la red de tipo externa del NAT (gracias VMware), les asigné dirección IP válida para esta red externa (192.168.0.0/24) eliminando las otras configuraciones como servidor DNS y Puerta de Enlace
Y agregué a mano en el archivo HOSTS de cada máquina los mapeos de nombre a dirección IP, para no tener que poner otra máquina virtual simulando un DNS de Internet. La dirección IP 192.168.0.14 corresponde a la interfaz externa de NAT
Verifico la conectividad con “rd.guillermod.com.ar” para cerciorarme que está todo correcto, antes de probar el Escritorio Remoto
No lo muestro, pero he hecho también la configuración en CL2, por supuesto con otra dirección IP
Comienzo la configuración del cliente de Escritorio Remoto en CL1, ya que debemos indicar que se utilizará “RD-Gateway”
En la ficha “General” no hay nada especial, salvo que tengan en cuenta que hay que ingresar el nombre interno de la máquina a la cual nos conectaremos (rdsh1.ad.guillermod.com.ar)
Pero debemos configurar el uso del “RD-Gateway” como se muestra a continuación
Ingresamos el nombre del “RD-Gateway” acá
Y nos conectamos …
Ahí vemos el mensaje que configuré antes :) Podemos ver que no conviene usar vocales acentuadas :)
En este caso da nuevamente la advertencia de la falta de confiabilidad del certificado. Esto se debe a que como usamos una Autoridad Certificadora propia e interna, no se tiene acceso a la CRL, pero podemos configurar que no se vuelva a mostrar
Y podemos ver que la conexión fue exitosa
Si hacemos una configuración análoga en CL2 veremos que también podemos ingresar exitosamente
Aprovecho para mostrar, por las dudas si alguien no se dio cuenta, que podemos guardar la configuración de la conexión, para evitar tener que escribirla cada vez
Resumiendo lo conseguido en esta nota: hemos configurado y demostrado el acceso externo, a través de una Internet simulada, el acceso de los clientes a Escritorio Remoto, usando exclusivamente protocolo HTTPS
Continuaremos en la próxima nota instalando, configurando y activando el licenciamiento de Escritorio Remoto: “Remote Desktop – Escritorio Remoto: Instalación y Activación de las Licencias (RD-CAL) (Nota 7)”
WindowServer 
Comentarios
Excelente toda la tanda de notas, justo estoy configurando esto en la empresa que laburo, tenia el servidor de licencias parado esperando que compren las rdcal, entre tanto se pasó el periodo de gracia y de un dia para el otro no pude hacer acc remoto ni con la cuenta administrador. Desinstale el rol para reinstalarlo, volvió a conectar y como ahora tengo las licencias quise instalar de nuevo pero me da un error de que no puede instalar el rol Agente de conexión al escritorio remoto. Veré mañana reiniciar el server y volver a intentar. Gracias por el laburo que te tomas para hacer esto. Espero con ansias la 7ma nota. Un abrazo. Jorge
Hola Jorge, me alegro te sirvan :)
Respecto al tema del licenciamiento cuando se vence, a veces no es tan facil. He visto mas de una pregunta en los foros de Technet
En mi empresa tenemos varios servidores que accedemos desde afuera a travez de diferentes puetos RDP. Si utilizara RD-Gateway debo tener los servidores con el puerto por defecto ? o se añadiria a la ruta al escribirlo en el cliente? eso no me queda muy claro.
Y sobre todo que ventaja me ofrece esto?, como para saber si vale la pena convertir lo que ya tengo.
Gracias por tu trabajo y el tiempo que le dedicas.
Hola Crisitian, aunque RDP cifra la información, se obtiene más seguridad si a la vez se lo encapsula en HTTPS
Además con RD-GAT hay más opciones para configurar y restringir a los clientes
Y por último viene a solucionar el problema si se utiliza RD-Web Acccess
tengo un problema con esto no me deja acceder desde afuera me sale un mensaje de error y creo que es por el certificado
«ESTE EQUIPO NO PUEDE COMPROBAR LA IDENTIDAD DE PUERTA DE ENLACE DE ESCRITORIO REMOTO dominio.com. No es seguro conectarse a servidores que no se pueden identificar»
porque me sale ese mensaje alguien sabe???
Justamente, es un problema con RD-Gateway. Revisa los pasos, o pon la pregunta en un foro de soporte, Technet por ejemplo, dando todos los datos que puedas para que te puedan ayudar mejor
Hola Guillermo, buen día!
He seguido toda la configuración y me funciona muy bien, pe he intentando conectarme por Web Access desde la red externa y no he podido, me muestra la página web con las aplicaciones y la pestaña para conexión a los PC pero me da error, me dice que no se puede conectar al RD-Gateway, falta alguna configuración adicional para Web Access? (ya que en la nota no has probado esta opción)
Hola Coldfran, tiempo que no te veía por acá :)
Para acceso desde el exterior con WebAccess se debe conectar directamente, ignorando el RDG. Lo que sí hay que configurar es que en el NAT hay que redirigir la dirección IP externa puerto TCP-443 a la dirección IP interna puerto TCP-443. Revísalo si está bien, tratando de acceder directamente a la interfaz web
Hola, si, estoy retomando el buen camino :)
Lo estaba haciendo directamente como mencionas pero no me conectaba y salia error del RDG, así que lo removí y lo volví a agregar por si me había saltado algún paso, pero igual me seguía dando el error, reinicié todas las virtuales y el error persistía…, pero al día siguiente lo volví a intentar antes de eliminar toda la infraestructura y por fin conecto sin problemas a las aplicaciones mediante Web Access desde una máquina externa.
Creo que estos problemas me surgen porque no tengo suficiente memoria para las VMs :(
No es por falta de memoria, es porque seguramente era tarde y las máquinas estaban fuera de horario de trabajo :D
Ahora en serio, seguramente el problema estaba en la máquina física, no creo que sea por falta de RAM, se pone todo lento pero debería funcionar. No sé como lo haces o con qué aplicación de virtualización usas, pero yo he montado labs donde los servidores tenían 1024, o aún 512 de RAM. En el aprovechamiento de la RAM suele tener mejor resultado VMware que Hyper-V
Hola Guillermo buenas noches! muy bueno el instructivo. Solo tengo una duda, yo hice un mergue entre este procedimiento y el anterior que hiciste con servidores dedicados por rol. Instale cada rol en servidores dedicados hasta el gateway y por lo visto salio todo muy bien. El problema o duda que tengo es la siguiente, un servidor es el rdweb (que tiene el acceso por web a las app) y otro es el servidor gateway, que tiene un nombre publico, esta todo NATEADO como correspondes, pero al publicarlo solo veo la pagina de inicio de IIS, el rdweb no funciona en ese server, entonces estoy en duda a cual apuntar desde afuera… al mismo tiempo publique el server rdweb y puedo acceder al sitio pero al intentar levantar alguna aplicacion me dice que no encuentra el gateway…
Entonces nose donde esta el error,… ¿como hace el gateway para mostrar el rdweb?
gracias.
slds.-
[Guillermo] Unifico los dos comentarios
Me olvide de comentar que tanto mi dns interno como externo apuntan al gateway.
Hola Julio, es difícil desde acá, habría que revisar muchas cosas más. Y el RD-Gateway es bastante «quisquilloso» :)
El RD-Gateway, lo que hace es permitir que el tráfico RDP y HHTPS (al RD-Web) que llega encapsulado en HTTPS sea «desencapsulado» al pasarlo a la red Interna
Por otro lado, no importa el nombre real de RD-Gateway, lo que importa es que el nombre público y el certificado coincidan
También hay que revisar la configuración al RD-Gateway en el cliente RDP para que lo use
Si ves la página de inicio del IIS, revisa si cuando pones el URL no te olvidas de poner al final el «rdweb» :)
Por otro lado, es lógico que si publicas el RD-Web, aunque lo accedas no puedes ejecutar aplicaciones. El motivo es que el RD-Web le dice cuál es el RD al que debe conectarse, y el cliente utiliza RDP (que no está abierto ni nateado)
Y respecto a lo último, que unifiqué desde el otro comentario, no termino de comprender totalmente, pero lo primero a revisar es que todas las máquinas apunten a un DNS que pueda resolver los nombres necesarios, y el RD-Gateway no es DNS
Hola Guillermo tengo un problema, tengo un Server 2016 ya configurado con RemoteApp de manera local logro entrar y las aplicaciones publicadas funcionando. Deseo ingresar desde otra red al remoteapp, pero manda error, si hago ping al dominio obtengo respuesta. Podrias apoyarme ??
Hola Olivia, lamentablemente no puedo ayudarte, tanto porque no hago soporte como que para poder decir algo faltan multitud de datos. Trata de recurrir a algún foro de soporte y proporciona datos «me manda error» no significa nada, siempre debes poner textualmente el mensaje que da porque eso es información que da pistas
Por ejemplo los foros de Technet los tienes en https://social.technet.microsoft.com/Forums/es-ES/home
Y agrego algo más, nunca deberías tener PING al Dominio, es un tema básico de seguridad
Muchas gracias Guillermo
Buenos días Guillermo, Primero que nada quiero felicitarte por tu contribución, está todo paso a paso y bien explicado.
Pero al parecer me salté un paso, algo no hice bien o falta algo. Mientras estoy en la red todo funciona, el problema lo tengo al abrir los remoteapp desde fuera de la red, ya que al parecer el RDP intenta conectarse directo por nombre a uno de los servidores de sesiones: srv1.dominio.cl en vez de usar remoteapp.dominio.cl
Por favor me podrías orientar al respecto, dónde tengo q revisar??
Hola Julio, si intenta conectarse directo por RDP es que no está bien la parte de que use el RD-Gateway. Debe usar HTTPS con el RD-Gateway encapsulando el tráfico RDP. Justamente la función del RD-Gateway es desencapsular RDP y enviarlo a donde corresponda
Consulta, yo tengo problemas para poder conectarme desde afuera a mi servidor privado, pero tengo algunas dudas con respecto el tipo de configuración mi router…
Esas notas son sobre comentarios de la nota, y sólo cuando preguntas sobre algún tema muy puntual si puedo oriento. De ningua forma es para soporte ni capacitación ni consultoría. Tampoco puedo por este medio desarrolar temas teóricos de funcionamiento y aplicación de características de un servidor. No lo tomes a mal pero deberías recurrir a un foro de soporte, consultora de sistemas, o simplemente buscar el tema concreto en la web, ya que hay muchísima información, aunque esto último hay que tener cuidado por que no toda es buena
Hola Guillermo. Tu sitio es una enciclopedia para mi.
Tengo una duda cuando dices «Atención con algo, no estoy nombrando RemoteApp, esta es una limitación a tener en cuenta, sólo Escritorio Remoto». Intentas decir que: ¿Nunca se podrá ingresar a las APPS desde afuera? ó ¿Tu explicación es para ESCRITORIOS desde afuera y hay que hacer otras configuraciones para las APPS?
Necesito tener claro la limitación que indicas, en vista que he seguido todo a pie de la letra pero cuando ingreso desde afuera me indica que el RDGateway no esta disponible.
Gracias por tu gentil respuesta
Hola John, realmente es una nota de hace mucho tiempo y no recuerdo bien todo el pocedimiento porque son 7 notas que se van encadenando con el procedimiento, pero entiendo que es así, en ese caso no se podrán usar de esa forma, sólo por RD-Web
Guillermo, es decir si publico una app con RD Web acces, internamente me va a funcionar, https://servidor/rdweb, pero desde red externa no, desde red externa para acceder a esa app como sera?? desde red externa debo ingresar por rdp?
El RD-Gateway es justamente el que te permite el acceso externo desde el exterior ya que encapsula RDP en HTTPS
Con Web Access, aunque el acceso es HTTPS, luego la conexión al servidor es por RDP
Otra opción, sin RD-Gateway es que ingrese por VPN, y entonces es como si estuviera en la red interna
Saludos Guillerno, excelente trabajo al desarrollar estas notas. gracias a ellas tengo configurado todo y puedo acceder mediante el RD-Gateway desde una red externa, aunque por asuntos con la telefónica llego al puerto 443 por medio del 55555, es decir, para acceder al servidor del puerta de enlace debo escribir https://****:55555 desde una red externa por lo que en mstsc .exe en la sección Opciones avanzadas > Configuración «usar esta configuración de servidor de puerta de enlace de escritorio remoto» > «nombre del servidor: https://***:55555» Y tengo una conexión perfecta. El problema es que en https://xxxxxxxxxx.net:55555/RDWeb/Pages/es-ES/default.aspx puedo llegar bien y hacer login, cuando hago click en una aplicación me muestra el dialogo de con los detalles y me resulta que en el apartado que menciona el nombre del RD-Gateway no incluye los :55555 y al cabo de una segundos luego de darle a conectar recibo el mensaje que no puedo acceder al equipo remoto porque el servidor de puerta de enlace de escritorio remoto no esta disponible en este momento. Claro que no lo estará porque entiendo que la solicitud se está haciendo hacia el puerto https://xxxxx.443, y no al que tengo disponible, el 55555, La pregunta: existe forma de hacer que RemoteApp use el servidor de puerta de enlace utilizando un nombre https://xxxxxxx.55555? Agradeceré cualquier sugerencia que me puedas dar.
Realmente no lo sé si se puede hacer, uno de los elementos de «propaganda» del sistema es justamente que no hay que abrir puertos adicionales ya que el 443 está «normalmente» abierto en el cortafuegos
Igual impresionante tu atención. Aunque publiqué la nota aquí también seguí indagando algo más del asunto. Resultó que sí se puede. Cambiando el puerto predeterminado (443) en Herramientas administrativas > Terminal Services > Administrador de puerta de enlace de escritorio remoto > Propiedades del Servidor. Luego de cambiarlo le advierte que se detendrán las conexiones etc., y que cambiará la regla en el cortafuegos (OK). Entonces por medio de PowerShell agregar una nueva propiedad a la colección publicada (Set-RDSessionCollectionConfiguration –CollectionName «Your Session Collectionnam» -CustomRdpProperty » gatewayhostname:s::» -ConnectionBroker ) tomado de otro foro :-), luego de esto entonces ya puedo acceder por medio del RD-Gateway hacia mi colección de aplicaciones desde una red externa. Claro, todo esto no aplica para condiciones normales donde el puerto 443 estuviera disponible para usar en el RD-Gateway, pero en mi caso tengo otro servicio anterior que ya ocupaba el 443 y que no puedo mover a otro puerto. Por lo que tus notas excelentes. Gracias por tu tiempo.
Me alegro lo solucionaras :)
Y algo importante ¡Gracias por compartir la información!
Buenos días Guillermo, acabo de implementar esta configuración de RD Gateway en un cliente, pero el cliente me comenta que necesita que la conexión se debe hacer por el puerto 443, lo que no logro entender es si una vez configure el RD Gateway este se sigue conectando por 3389 pero este trafico lo encapsula en el 443 bajo el protocolo HHTPS, ya que al decirle en la conexion 192.168.x.xxx:443 no me da acceso al servidor.
Hola, el cliente tiene que hacer la comunicación al Router Externo que le pasará la información al servidor interno, y esta tiene que ser la dirección IP
Trackbacks
[…] Remote Desktop – Escritorio Remoto: Instalación y Configuración de “RD-Gateway” (Nota 6) […]
[…] Continuaremos en la próxima nota “Remote Desktop – Escritorio Remoto: Instalación y Configuración de “RD-Gateway” (Nota 6)” […]
[…] Remote Desktop – Escritorio Remoto: Instalación y Configuración de “RD-Gateway” (Nota 6) […]