Escritorio remoto 'error interno' al intentar conectarse después de instalar parches 'NSA'

Acabo de instalar la última actualización de Windows (parche de vulnerabilidad de la NSA el martes) y ahora no puedo conectarme al escritorio remoto.

• El servidor está alojado de forma remota. No tengo acceso fisico. Servidor 2012 R1.
• Afortunadamente, todos los sitios web funcionan bien después del reinicio.
• Todavía no he intentado un segundo reinicio porque tengo un poco de miedo.
• Cuando intento conectarme, inmediatamente recibo este mensaje:
• " Conexión a escritorio remoto : se ha producido un error interno"

• He intentado desde múltiples clientes. Todos fallan, incluida una aplicación de iOS que además me da un error 0x00000904.
• Si ejecuto, telnet servername 3389entonces inicia una conexión, así que sé que el puerto está abierto.
• Puedo conectarme bien a otros servidores desde mi máquina Win 10 (sin parchear).
• Tampoco puedo conectarme desde mi segundo portátil, que es la edición Win 10 Creators.
• No se puede encontrar nada útil en el Visor de eventos.
• Incluso probé wireshark que no me mostró nada útil.
• Lo mejor que tengo que diagnosticar es la capacidad de cargar una página ASPX y ejecutarla.

Entiendo que el resumen de parches reciente de 'NSA edition' tuvo algunas correcciones de RDP, pero no puedo encontrar a nadie más que repentinamente haya tenido problemas durante la semana.

Quiero tener una idea de cuál es el problema antes de contactar a la empresa de hosting, por eso publico aquí.

Actualizar:

Si bien todavía no tengo acceso al servidor físico, recordé que tengo una VM con Windows 7 alojada en el servidor. Pude entrar en esto y abrir el complemento de certificados del servidor al conectarme a la IP local 10.0.0.1.

Esto muestra que el certificado RDP realmente ha expirado, aunque no obtengo errores al conectar esa sugerencia como tal. Ciertamente me he estado conectando a diario y desde que expiró hace 2 meses, supongo que algún tipo de actualización de seguridad eliminó cualquier otro certificado que estuviera en la tienda de Escritorio remoto y no se renovó.

Intentando encontrar una manera de instalar un certificado diferente aquí ahora.

Actualización 2

Finalmente encontré esto en el registro de eventos en 'Eventos administrativos' (conectándose remotamente a través de la VM):

"El Terminal Server no ha podido crear un nuevo certificado autofirmado para ser utilizado para la autenticación del Terminal Server en las conexiones SSL. El código de estado relevante era Objeto ya existe".

Esto parece útil, aunque es un error ligeramente diferente. No se puede reiniciar esta noche, así que tendré que volver a verificar mañana

https://blogs.technet.microsoft.com/the_9z_by_chris_davis/2014/02/20/event-id-1057-the-terminal-server-has-failed-to-create-a-new-self-signed-certificate/

La solución es básicamente aquí.

https://blogs.technet.microsoft.com/askpfeplat/2017/02/01/removing-self-signed-rdp-certificates/

Esto también ayudó:

https://social.technet.microsoft.com/Forums/ie/en-US/a9c734c1-4e68-4f45-be46-8cae44c95257/unable-to-remote-desktop-to-windows-server-2012-due-to- error al crear certificado autofirmado? forum = winserverTS

Suponiendo que ya haya verificado que el certificado enumerado en Certificados> Escritorio remoto> Certificados no es válido ...

Nota: Tomé esta captura de pantalla después de arreglarlo todo, por lo que esta fecha de vencimiento es el certificado recientemente creado de que lo hizo todo por sí mismo.

Básicamente, debe cambiar el nombre o eliminar este archivo, y luego lo volverá a crear:

"C: \ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeys \ f686aace6942fb7f7ceb231212eef4a4_a54b3870-f13c-44bb-98c7-d0511f3e1757"

Este es un nombre de archivo conocido que comienza en f686aace. Luego reinicie el Remote Desktop Configurationservicio y debería recrearlo. (Nota: es posible que no sea necesario reiniciar el servicio; solo espere para ver si se vuelve a crear con el mismo nombre de archivo durante un minuto).

Puede tomar un poco de tiempo con los permisos y es posible que deba tomar posesión del archivo y luego, además, aplicar los permisos. Nota: la propiedad no implica permisos. Debe agregar permisos después de tomar posesión.

Como dije, no tengo acceso físico al servidor; si lo tiene, lo anterior debería ser suficiente.

Tuve la suerte de poder conectarme de forma remota a través de otra máquina en la misma red local y cambiar el registro.

Quería DESACTIVAR la autenticación para poder conectarme y obtener acceso de forma remota. Las entradas de registro para hacer esto sonHKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Establecer las claves existentes SecurityLayery UserAuthenticationpara0

Cree un archivo RDP (abra mstsc y haga clic en Guardar después de ingresar el nombre del servidor) y en el bloc de notas agregue la línea en enablecredsspsupport:i:0alguna parte. Esto desactiva la expectativa de seguridad.

Cuando ejecute el archivo RDP, debería permitirle conectarse INSEGURAMENTE y obtener acceso a su servidor.

Tan pronto como se conecte, cambie estas dos entradas de registro y luego continúe y elimine el f686...archivo ...

Esta configuración solucionó mi problema:

1.En el Panel de control, haga clic en Herramientas administrativas y luego haga doble clic en Política de seguridad local.

2.En Configuración de seguridad local, expanda Políticas locales y luego haga clic en Opciones de seguridad.

3. De acuerdo con la Política en el panel derecho, haga doble clic en Criptografía del sistema: use algoritmos compatibles con FIPS para el cifrado, el hash y la firma, y ​​luego haga clic en Habilitado. En mi caso fue deshabilitado. Así que solo lo habilité y emití el comando que aparece debajo.

4. Ejecute gpupdate / force

Otra opción que resolverá este problema:

Los protocolos no estaban habilitados en el servidor. Usé IIScrypto y habilité TLS1.2 y todo comenzó a funcionar

Hola a todos en mi entorno, esto fue causado cuando se generó un nuevo certificado autofirmado TLS 1.0 está deshabilitado en el registro o no existe en el registro y el nuevo certificado autofirmado no estaba en el almacén de las autoridades de certificación raíz de confianza.

Puede probar esto de dos maneras antes de editar el registro. descargue IIS Crypto y vea qué está habilitado y deshabilitado en Protocolos, Cifrados, Hashes e Intercambios de claves.

A veces, aunque IIS Crypto mostrará que TLS está habilitado aunque no esté habilitado en el registro solo para su información.

Su siguiente opción es activar FIPS en la política de grupo local, esto obliga a TLS 1.0, 1.1 y 1.2 a activarse y utilizarse. Encienda FIPS y luego intente RDP en su máquina, funcionará esta vez incluso si TLS está deshabilitado en el registro. No desea utilizar FIPS de forma permanente, aunque esto es solo para solucionar problemas, desactívelo en el servidor y diríjase al registro.

La cabeza a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNELy bajo protocolos añadir tres nuevas claves título ellas TLS 1.0, TLS 1.1y TLS 1.2luego crear dos subclaves bajo cada entrada TLS ellas Título Clienty Server.

Dentro de las teclas Clienty Servercrea dos entradas DWORD de 32 bits, una titulada DisabledByDefaultcon el Valueconjunto en 0 y Enabledcon el valor establecido en 1.

Una vez que haga esto y su certificado autofirmado no haya caducado y en las tiendas correctas podrá volver a RDP en su servidor.