Tenga en cuenta que este escenario es diferente de uno similar: ¿Cómo desactivo TLS 1.0 sin romper RDP?
La pregunta vinculada es sobre RDP y la desactivación de TLS 1.0.
Esta pregunta es sobre RemoteApp y la desactivación de TLS 1.0
Ya tengo RDP directo a través del puerto 3389 funcionando con TLS 1.2.
Tenemos un servidor 2012R2 que aloja RemoteApp.
Tenemos las funciones RD Gateway, RD Web Access, RD Connection Broker y RD Session Host instaladas en este servidor.
Las RemoteApp se sirven a través de RD Gateway a través de https. El único puerto público que tenemos abierto es el 443.
Tenemos un certificado SSL comodín proporcionado por una CA pública instalado en todas las funciones de RD e IIS, por lo que todo se remonta a un certificado raíz confiable.
El certificado es compatible con TLS 1.2. Veo esto en un navegador web cuando veo el sitio web de RDWeb.
Estamos intentando desactivar TLS 1.0 en este servidor para reforzar la seguridad. Estamos usando IISCrypto 2.0 para deshabilitar TLS 1.0
Cuando desactivamos TLS 1.0 se observan dos cosas:
1.La RemoteApp deja de funcionar. No se pueden iniciar desde la máquina de un usuario final.
2. Las conexiones RDP directas funcionan bien.
Cuando volvemos a habilitar TLS 1.0, RemoteApp vuelve a funcionar.
El registro de SChannel confirma que RemoteApps está usando TLS 1.2, por lo que esperaría que RemoteApps continúe funcionando cuando TLS 1.0 esté deshabilitado. Sin embargo eso no es lo que estoy observando.
Todos los clientes utilizan versiones completamente actualizadas/parcheadas de Windows 8.1 y 10.
Respuesta1
Después de casi un año, finalmente descubrí una solución funcional para deshabilitar TLS 1.0/1.1 sin interrumpir la conectividad de RDP y Servicios de Escritorio remoto.
Ejecute IISCrypto y desactive TLS 1.0, TLS 1.1 y todos los cifrados incorrectos.
En el servidor de Servicios de Escritorio remoto que ejecuta la función de puerta de enlace, abra la Política de seguridad local y navegue hasta Opciones de seguridad - Criptografía del sistema: utilice algoritmos compatibles con FIPS para cifrado, hash y firma. Cambie la configuración de seguridad a Activada. Reinicie para que los cambios surtan efecto.
Tenga en cuenta que en algunos casos (especialmente si se utilizan certificados autofirmados en Server 2012 R2), es posible que sea necesario configurar la opción de Política de seguridad Seguridad de red: nivel de autenticación de LAN Manager en Enviar respuestas NTLMv2 únicamente.
Déjame saber si esto también funciona para ti.
Respuesta2
Criptografía del sistema: utilice algoritmos compatibles con FIPS para cifrado, hash y firma.
Esto vuelve a habilitar en secreto los protocolos más antiguos. Microsoft ni siquiera recomienda el uso de esta configuración.
Yo también he estado luchando contra esto. Todavía no he encontrado la solución adecuada.
Respuesta3
Publicación anterior, pero acabo de leer un artículo que dice que si está utilizando el servidor SQL interno (WID) para la base de datos del agente de conexión, el agente de conexión necesita TLS 1.0 habilitado para comunicarse con WID. Puede solucionar este problema utilizando una base de datos de SQL Server "real" para el agente de conexión en lugar del WID interno de SQL.