Cómo utilizar la puerta de enlace HTML5 como puerta de enlace de Escritorio remoto
Desde la versión 12.60.2.11 de TSplus con la versión interna HTML5 v6.84, el servidor HTML5 incluye compatibilidad con la puerta de enlace HTTPS de Escritorio remoto.
Requisitos previos: el módulo HTML5 replica el comportamiento del servidor web SSL de IIS con compatibilidad con la puerta de enlace de Escritorio remoto, lo que conlleva algunas limitaciones en el uso con mstsc.exe o cualquier otro cliente RDP nativo basado en el núcleo del cliente RDP de Microsoft.
El requisito mínimo también es un certificado SSL firmado y válido para el dominio utilizado.
Recuerde que esta limitación está relacionada con el lado del cliente, también con mstsc.exe y no puede verse afectada por la implementación del lado del servidor.
Si utiliza clientes RDP de terceros como FreeRDP, esta limitación se puede gestionar de forma diferente, pero no es nuestro ámbito de interés proporcionar asistencia a clientes RDP de terceros. ¡Consulte la asistencia de software relacionada!
No podrá establecer una conexión con RD-Gateway con mstsc.exe ni con ningún otro cliente basado en el núcleo RDP de Microsoft en los siguientes casos:
1. Accede a RD-Gateway por IP en lugar de por dominio
2. Su certificado SSL CN=***DOMAIN*** es originalmente para un dominio diferente al de la dirección a la que se accede.
3. Su certificado SSL está autofirmado.
4. Su certificado SSL está desactualizado.
5. Su certificado SSL está falsificado.
Puede comprobar fácilmente si mstsc.exe aceptará su servidor web HTML5 de TSPlus como RD-Gateway. Solo tiene que abrir en Internet Explorer https://rdp_gateway_domain y si ve un "mensaje de error rojo" que indica que hay un error de certificado, entonces mstsc.exe no aceptará este servidor como RD-Gateway válido y rechazará la conexión futura. A diferencia del navegador con mstsc.exe, no puede aceptar un certificado SSL de RD Gateway no válido.
Si no desea comprar un certificado SSL, puede reutilizar la herramienta SSL de TSplus para firmar su dominio con Let's Encrypt, ya que mstsc.exe acepta los certificados de Let's Encrypt sin problemas.
Recuerde que Let's Encrypt no se puede utilizar para firmar dominios dinámicos como *.dyndns.com, etc., necesita un dominio de primer nivel.
Si no tiene su propio dominio de primer nivel, puede comprobar los siguientes pasos; a veces, pero no siempre, si tiene una dirección IP de Internet fija, los proveedores le asignan un nombre de dominio resoluble. Puede comprobarlo fácilmente con el siguiente ejemplo:
cmd.exe > nslookup.exe 44.55.66.77
Si ve algo útil en el resultado de nslookup.exe en Nombre: *** y este nombre de dominio se resuelve con la misma IP que en el ejemplo 44.55.66.77 con el siguiente comando:
cmd.exe > ping your_resolved_domain
Enhorabuena, tiene todo lo que necesita, un dominio gratuito y un certificado Let's Encrypt gratuito para trabajar con mstsc.exe a través de RD-Gateway, así que firme este dominio resuelto con Let's Encrypt primero y luego continúe. En caso contrario, si no puede realizar el paso anterior, no tendrá otra opción que comprar un dominio de primer nivel para futuras firmas.
Aviso: el antiguo protocolo RDG-RPC a través de solicitudes de proxy RPC "/rpc/rpcproxy.dll?localhost:**" no es compatible, solo se admite el protocolo RDG-HTTP moderno, ya sea a través de dos conexiones TCP HTTPS SSL o a través de una conexión TCP Websockets SSL.
Si utiliza un proxy de tercera parte (inverso) con una instancia de descifrado SSL antes del servidor TSplus en la cadena de conexión, asegúrese de configurar este proxy de tercera parte (inverso) en el lado del servidor para permitir RDG_OUT_DATA y RDG_IN_DATA como métodos HTTP válidos, ya que de esta manera podría pasar tráfico RDP incluso a través de diferentes servidores proxy de tercera parte.
Solo RD-Gateway debe estar validado y firmado por el dominio, pero los servidores RDP remotos de destino no se ven afectados por esta regla.
Continúe con los siguientes pasos de las preguntas frecuentes solo si está seguro de cumplir con los requisitos previos anteriores con un certificado SSL de dominio válido y firmado.
Cómo usar mstsc.exe con RD-Gateway
0. En primer lugar, verifique *\Clients\webserver\settings.bin para ver si existe la siguiente variable > rdg_allow_proxy=false
Si encuentra esta variable, ¡ELIMINÉMOSLA y reinicie el servidor HTML5! Si no está presente, continúe con el siguiente paso.
De forma predeterminada, HTML5 acepta conexiones proxy de RD-Gateway si no se deshabilitan de forma forzada con settings.bin > rdg_allow_proxy=false
1. Inserte el servidor RDP de intranet de destino deseado como IP o como dominio
Si utiliza un servidor RDP de destino que se encuentra en INTERNET y no en INTERNET (10.*.*.*, 192.168.*.*,172.16.*.*-172.31.*.* y local 127.*.*.*), de forma predeterminada, se rechazarán dichas conexiones de dirección de INTERNET (o se reemplazarán por el puerto localhost:RDP predeterminado) para evitar un alto riesgo de seguridad de que su servidor HTML5 se use indebidamente para conectarse a servidores RDP no verificados en la "red salvaje" de Internet. Estas reglas se aplican tanto a las conexiones HTML5 como a las conexiones de RD-Gateway. Conexiones de cookies RDP proporcionadas por *\Clients\webserver\balance.bin > /~~***=rdp_server:3389 RDPPORT; las cadenas no se ven afectadas por esta regla. Más adelante, después de estas preguntas frecuentes, se explicará cómo permitir servidores RDP de Internet.
2. Vaya a Avanzado > Usar estas configuraciones de servidor de puerta de enlace de Escritorio remoto
> Nombre del servidor: your_html5_server.com (inserte solo el DOMINIO con certificado SSL válido)
(cuando no se especifica ningún puerto, el puerto predeterminado es 443)
¡Todas las demás opciones pueden permanecer sin marcar!
3. Presione Conectar
4. Cuando se le soliciten las credenciales del "Servidor de Puerta de Enlace de Escritorio Remoto", ingrese el siguiente nombre de usuario:
Inicio de sesión: a\a
Contraseña: a
De manera predeterminada, puede ingresar cualquier nombre de usuario y contraseña para el servidor de Puerta de Enlace de Escritorio Remoto, no solo a\a. El único requisito es ingresar el nombre de usuario como cadena de inicio de sesión de dominio, ya que originalmente Microsoft requiere que se configure ActiveDirectory para instalar Puerta de Enlace de Escritorio Remoto, pero para Puerta de Enlace de Escritorio Remoto basada en HTML5, esta limitación no se considera ya que AD no es compatible de todos modos, pero mstsc.exe aún requiere este tipo de ingreso de datos de inicio de sesión. Más adelante, después de esta sección de preguntas frecuentes, puede consultar los pasos para aplicar el inicio de sesión de Puerta de Enlace de Escritorio Remoto verificado.
5. Ingrese el inicio de sesión del servidor RDP
Si marcó la configuración de Puerta de Enlace de Escritorio Remoto para reutilizar el inicio de sesión de Puerta de Enlace de Escritorio Remoto además del inicio de sesión de RDP, recuerde que si no usa la parte de dominio en su inicio de sesión, puede usar la cadena MicrosoftAccount como nombre de dominio predeterminado. Supongamos que su inicio de sesión predeterminado es Administrador, entonces use como inicio de sesión MicrosoftAccount\Administrator, etc.
Pero es mejor evitar reutilizar el mismo inicio de sesión para el servidor RDP y para el servidor de puerta de enlace de Escritorio remoto, recuerde siempre que son dos entidades de inicio de sesión diferentes. Debe pasar con éxito ambas comprobaciones de inicio de sesión, primero la puerta de enlace de Escritorio remoto y segundo el servidor RDP mismo.
Puede verificar *\Clients\webserver\web_log.txt para detectar posibles fallas.
Si usa el mismo dominio como servidor RDP y puerta de enlace de Escritorio remoto, el puerto RDP se configurará automáticamente al puerto de servidor RDP reenviado local predeterminado definido en el servidor HTML5, este comportamiento replica el comportamiento del cliente HTML5.
Este enfoque es necesario cuando se utiliza una red corporativa con un proxy saliente en el que se desea conectar al servidor RDP remoto y la única forma de hacerlo es reutilizando la puerta de enlace de Escritorio remoto con el servidor local, ya que normalmente mstsc.exe no permite ninguna otra forma de conectarse a través del proxy corporativo local que no sea a través de la conexión de la puerta de enlace de Escritorio remoto y el uso de 127.0.0.1 como nombre de servidor RDP de destino podría crear problemas no deseados si falla la verificación de los servidores RDP de destino permitidos. O bien, el servidor RDP ha configurado la misma clave privada SSL que HTML5 + Puerta de enlace de Escritorio remoto, y se desea evitar el mensaje de error de validez de seguridad en mstsc.exe para la conexión RDP que se produciría al utilizar 127.*.*.* como nombre de servidor RDP local. Recuerde que la conexión de la puerta de enlace de Escritorio remoto consta principalmente de 2 (1 Websockets + 1 RDP) o 3 (2 HTTP + 1 RDP) conexiones SSL encapsuladas que consumen más tiempo de CPU para el cifrado/descifrado, por lo que siempre debe tener en cuenta que la verificación de validez de SSL se procesa en dos instancias diferentes, por la puerta de enlace de Escritorio remoto como primera instancia y por el servidor RDP como segunda instancia.
Recuerde: si deshabilitó el reenvío de la conexión RDP local mediante *\Clients\webserver\settings.bin > deshabilitar_rdp=true, las conexiones de la puerta de enlace de Escritorio remoto en el servidor RDP local como 127.0.0.1:3389 también se rechazarán.
Cómo permitir solo servidores RDP de INTERNET específicos como destino a través de la puerta de enlace de Escritorio remoto.
Como ya se describió debido a limitaciones de seguridad, los servidores RDP de Internet no están permitidos de forma predeterminada, solo los de tipo intranet, por lo que lea estas preguntas frecuentes si aún desea permitir que solo los servidores de Internet específicos se conecten a través de la puerta de enlace de Escritorio remoto.
1. Busque o, si no está presente, cree un nuevo archivo *\Clients\webserver\rdplist.bin
2. Agregue como última línea separada como ejemplo
127.0.0.1:3389
192.168.2.1
your-server.com:3390
second-server.net
Tenga en cuenta que si no se proporciona el puerto, se permitirá cualquier puerto. Los dominios no se resuelven a direcciones IP, por lo que el servidor RDP para conectarse debe coincidir por igualdad de cadenas. El dominio se puede resolver a una dirección IP de intranet, pero por lógica de seguridad, dichas direcciones aún se consideran como posibles servidores de Internet de manera predeterminada, por lo que necesitan el mismo manejo adicional en seguridad que las direcciones IP de Internet.
3. Reinicie el servidor HTML5 en la GUI de AdminTool para que los cambios surtan efecto.
Cómo permitir solo servidores con cookie de conexión RDP predefinida /~~** a través de RD Gateway
La principal diferencia entre permitir servidores específicos mediante rdplist.bin como se describió anteriormente o mediante cookie RDP es que cuando se utiliza la cookie, se puede acceder al servidor al que se va a conectar mediante un enfoque que admita el cliente RDP nativo. No todos los clientes RDP nativos admiten el protocolo RD-Gateway, sin embargo, muchos clientes RDP nativos de terceros admiten el paso de cookies RDP. Por lo tanto, al reutilizar el enfoque de cookies, delega la elección al cliente RDP, que aún puede reutilizar el protocolo RD-Gateway si lo admite. Sin embargo, es preferible que el cliente RDP nativo admita el protocolo RD-Gateway, ya que así el cliente RDP nativo podría conectarse a través de un proxy corporativo local.
De forma predeterminada, la cookie de conexión RDP /~~** se puede reutilizar para conectarse al servidor RDP de destino sin necesidad de RD Gateway, como se muestra en el siguiente ejemplo
Servidor > *\Clients\webserver\balance.bin > /~~srvTS1=demo.tsplus.net:3389 RDPPORT;
Lado del cliente > *file*.rdp > loadbalanceinfo:s:/~~srvTS1
En tal caso, el servidor RDP de destino no se verifica para determinar si es de tipo intranet y omite muchas otras comprobaciones de seguridad, pero en el caso de un proxy corporativo local para uso con mstsc.exe, es posible que desee combinar la conexión de la puerta de enlace de Escritorio remoto y la cookie de RDP. Tan pronto como se detecte la cookie, puede establecer como servidor RDP de destino el mismo servidor que para la puerta de enlace de Escritorio remoto y, si la cookie encuentra el servidor RDP de destino en balance.bin, como por ejemplo /~~srvTS1 > demo.tsplus.net:3389, entonces la cadena de servidor proporcionada se cambiará automáticamente al servidor RDP asignado deseado para la cookie, como en el ejemplo anterior demo.tsplus.net:3389.
Pero es posible que desee limitar las conexiones de la puerta de enlace de Escritorio remoto solo a estas conexiones definidas por la cookie de RDP como mejora de seguridad adicional.
1. Localice *\Clients\webserver\settings.bin
2. Agregue como última línea
accept_rdg_forwarded_only_rdp=true
3. Reinicie el servidor HTML5 para que los cambios surtan efecto
A partir de ahora, tan pronto como alguien se conecte a su puerta de enlace de Escritorio remoto sin una cookie RDP aceptada, se rechazará dicha conexión. El efecto secundario agradable de usar esta cookie RDP en el escenario balance.bin es que el contenido del campo del servidor RDP remoto ya no desempeña ningún papel; si se encuentra una cookie en el lado del servidor, el servidor se reemplazará automáticamente por la cookie correspondiente en balance.bin. Recuerde que intentar conectarse sin una cookie RDP con esta opción habilitada accept_rdg_forwarded_only_rdp=true provocará un error en su cliente RDP.
Cómo permitir cualquier servidor RDP de INTERNET como destino a través de la puerta de enlace de Escritorio remoto.
Como se describió anteriormente, debido a limitaciones de seguridad, los servidores RDP de Internet no están permitidos de forma predeterminada, solo los de tipo intranet, así que lea estas preguntas frecuentes si aún desea permitir que cualquier servidor de Internet se conecte a través de la puerta de enlace de Escritorio remoto.
1. Localice *\Clients\webserver\settings.bin
2. Agregue como última línea
disable_internet_servers=false
3. Reinicie el servidor HTML5 en la GUI de AdminTool para que los cambios surtan efecto
Recuerde que permitir cualquier servidor RDP es un riesgo de seguridad alto, ya que su Puerta de enlace de Escritorio remoto podría reutilizarse para hacer cosas maliciosas en nombre de su servidor. Use esta opción bajo su propio riesgo o prefiera en su lugar rdplist.bin o el enfoque de cookies de RDP descrito anteriormente. Recuerde que, en circunstancias normales, es muy poco común que los servidores RDP de destino se encuentren en INTERNET, ya que no tendría sentido conectarse al servidor RDP de INTERNET a través de la Puerta de enlace de Escritorio remoto de INTERNET cuando podría conectarse directamente con el mismo éxito. En la mayoría de los casos, con el escenario de Puerta de enlace de Escritorio remoto, los servidores RDP remotos se encuentran detrás de FireWall en la INTERNET corporativa, por lo que este escenario es el único permitido por seguridad de manera predeterminada.
Cómo limitar la puerta de enlace de Escritorio remoto solo a inicios de sesión de Escritorio remoto específicos
De manera predeterminada, puede usar cualquier inicio de sesión/contraseña de Puerta de enlace de Escritorio remoto en el estilo dominio\inicio de sesión, ya que la implementación de Puerta de enlace de Escritorio remoto HTML5 no admite la verificación de ActiveDirectory. Pero es posible que aún desee limitar el acceso a una constelación de dominio\usuario o dominio\usuario + contraseña específica como algún tipo de autenticación de doble factor. Para hacerlo, siga los siguientes pasos
1. Cree el archivo
*\UserDesktop\files\rdgcredentials.ini
2. Coloque como ejemplo el siguiente contenido
[your_domain\your_login]
NTLMv2Base64=
[MicrosoftAccount\xyz_logon]
NTLMv2Base64=
En tal ejemplo, los inicios de sesión válidos de Puerta de enlace de Escritorio remoto se aceptarán como inicios de sesión de usuario
your_domain\your_login
y
MicrosoftAccount\xyz_logon
y se rechazará cualquier otro inicio de sesión de Puerta de enlace de Escritorio remoto; en el ejemplo anterior, se acepta cualquier contraseña.
Pero a veces puede que desee aceptar contraseñas específicas, las contraseñas pueden almacenarse allí como hashes NTLMv2, como por ejemplo password> your_password se vería como hash NTLMv2
[your_domain\your_login]
NTLMv2Base64=/Rc3R4saIFKzzJExvZak8Q==
Para crear este tipo de contraseña, inicie cualquier navegador directamente en el servidor donde se instaló el servidor HTML5 de TSPlus y use el siguiente formato de enlace http(s)
http://localhost/w0j7?logon=your_domain\your_login&pwd=your_password
Recuerde, no se permite iniciar este enlace por IP de Internet, solo se aceptan http://localhost/ o http://127.*.*.*/ como direcciones.
Después de eso, copie y pegue la salida del navegador en *\UserDesktop\files\rdgcredentials.ini
Tenga en cuenta que la presencia del archivo *\UserDesktop\files\rdgcredentials.ini no vacío impedirá que la puerta de enlace de RD acepte cualquier inicio de sesión, por lo que debe tener cuidado con este archivo para agregar el inicio de sesión correcto o el inicio de sesión/contraseña que no debe olvidar. Las contraseñas reales no se pueden restaurar a partir de hashes NTLMv2 sin fuerza bruta. Como ya se mencionó, la verificación contra ActiveDirectory no es compatible.
AVISO IMPORTANTE: desde HTML5 v7.39, cuando no se utiliza rdgcredentials.ini, de manera predeterminada no se permite el acceso a los servidores de INTRANET, sino solo a localhost/127.*.*.* solo para evitar un posible problema de seguridad que los piratas informáticos puedan usar la puerta de enlace de RDG para escanear su INTRANET en busca de servidores activos. Esta limitación no es efectiva en los casos en que el cliente RDP envía la cookie RDP aprobada /~~* o cuando se encuentran servidores dentro de rdplist.bin. Para deshabilitar esa verificación adicional y permitir servidores INTRANET sin el archivo rdgcredentials.ini, agregue a *\Clients\webserver\settings.bin >no_rdg_intranet_no_credential_file=false y reinicie el servidor para que los cambios tengan efecto.