El problema parece ser causado por una actualización de mayo de 2019 y afecta a la conectividad con los sistemas virtuales Windows.
Microsoft Server 2019 y Server versión 1709: ¿Cuál es la diferencia? He aquí algunas características contrastantes que destacan.
Trabajando en un sitio cliente el otro día, descubrí que la conectividad de escritorio remoto desde un conjunto de servidores Windows 2008 R2 a varios sistemas virtuales Windows 7 había dejado de funcionar abruptamente. El error que se produjo al intentar iniciar sesión fue simple: «El nombre de usuario o contraseña es incorrecto.»
Más información sobre Windows
Excepto que estaba seguro de que no era verdad. La búsqueda en Google del tema dio lugar a una plétora de arenques rojos y callejones sin salida que no permitían comprender el problema. Así que, tuve que arremangarme y sacar mi juego de herramientas de detective del administrador del sistema, por así decirlo.
Triangulación del problema
La primera y más obvia suposición fue que la contraseña fue cambiada de alguna manera por alguien, pero esto parecía muy improbable ya que la contraseña en cuestión había existido durante varios años y era compartida por muchas personas. Sin embargo, han sucedido cosas más extrañas.
Descarté esta posibilidad de inmediato iniciando sesión en estas máquinas virtuales directamente a través de la consola VMWare. El ID y la contraseña funcionaban perfectamente, así que supe que algo tenía que estar mal con la comunicación del escritorio remoto en sí.
Mi siguiente paso fue intentar conectarme a estas máquinas desde un sistema diferente; otra máquina Windows 7 en la red a la que podía acceder a través de un escritorio remoto desde este servidor. Eso funcionó bien, así que supe que el problema tenía que ser con los servidores de origen mismos desde los que estaba tratando de acceder al problema de los sistemas Windows 7.
Afortunadamente, había cuatro servidores implicados, así que probé sistemáticamente la conectividad del escritorio remoto de todos ellos, y descubrí que este acceso funcionaba en uno de los cuatro.
Entonces busqué determinar qué era diferente en ese sistema que funcionaba y qué cambiaba en los tres servidores que no funcionaban.
VER: Trabajar en TI: Por qué nos gusta, por qué nos gusta (PDF gratuito) (ConsejoTecnologico.com)
Determinación de los cambios
Lo primero que comprobé fueron las recientes actualizaciones de Windows en los servidores con problemas. Vi que varias actualizaciones se habían instalado unos días antes:
El servidor en funcionamiento NO había recibido las actualizaciones de mayo listadas arriba, así que esa fue una fuerte sugerencia en mi mente de que una de estas actualizaciones rompió la conectividad del escritorio remoto.
Luego hice una lista de las actualizaciones recientemente instaladas e investigué su propósito:
Actualización TitleDescriptionUpdate for Microsoft.NET Framework 4.7.1 (KB4096418.NET updateSecurity Update for Microsoft.NET Framework 4.7.1 (KB4096237.NET updateSecurity Update for Microsoft Windows (KB4103718)Actualización mensual de parchesActualización de seguridad para Microsoft Windows (KB4103768)Actualización acumulativa de IEActualización de seguridad para Microsoft Windows (KB4103712)Soluciona un problema que puede causar un error al conectarse a un servidor de Escritorio remotoActualización para Microsoft Windows (KB4095874)Actualización para Microsoft Windows (KB4095874.NET Framework 3.5.1 Actualización de seguridad para Microsoft Windows (KB4095514)Actualización de seguridad sólo para.NET Framework 3.5.1 para Windows 7 SP1 y Server 2008 R2 SP1Update para Microsoft Windows (KB4099950)Corrección de la configuración de red y problemas de dirección IPActualización para Microsoft Windows (KB4093753)Cambios de zona horaria y DST en Windows para Brasil, Marruecos y Santo Tomé y PríncipeAislamiento
del arreglo paso a paso
Aunque podría haber desinstalado todas las actualizaciones para ver si el problema estaba resuelto, quería tomarme el tiempo extra para tratar de averiguar cuál fue la causa específica del problema; de lo contrario, es probable que el problema volviera a aparecer en la siguiente ronda de parches. Opté por desinstalar las actualizaciones una por una y luego reiniciar y probar la conexión del escritorio remoto cada vez.
Pero, ¿cómo proceder? Después de revisar la lista anterior, quedó claro que algunas de estas actualizaciones no tenían nada que ver con el problema: el…
NET y los parches de zona horaria no eran dignos de mi interés. Sentí que la fuente probable del problema era KB4103712, ya que se refería específicamente a un problema de conectividad de escritorio remoto. Irónicamente, su intención era arreglar los problemas, no causarlos, pero el mundo al revés de los parches a menudo puede llevar a resultados invertidos.
Desinstalé KB4103712, reinicié el servidor, luego intenté una conexión de escritorio remoto y ¡funcionó!
VER: Cómo administrar las TI durante las fusiones y adquisiciones (PDF gratuito) (ConsejoTecnologico.com)
Aplicando una solución a largo plazo
El trabajo no estaba terminado todavía; todo lo contrario. Ahora que sabía qué actualización producía el problema, tenía que averiguar cómo aplicarla y mantener la conectividad de escritorio remoto a estos sistemas Windows 7.
Hablé con un amigo mío, Mike Catalano, Ingeniero Superior de Tecnología de Worldpay, quien me proporcionó más información sobre lo que sucedió aquí. Me señaló un artículo de soporte de Microsoft que explica que este problema implica una actualización de marzo del Protocolo de Proveedor de Soporte de Seguridad de Credenciales (CredSSP) que maneja las solicitudes de autenticación. Otro síntoma de este problema es el error: «Se ha producido un error de autenticación. La función solicitada no está soportada.»
Específicamente, los problemas de conectividad ocurren cuando un cliente parcheado intenta conectarse a un sistema no parcheado, lo cual es exactamente el caso aquí. La conexión funcionaba desde un cliente no parcheado que se conectaba a los sistemas no parcheados, por lo que está claro que el parche de escritorio remoto KB4103712 tenía que estar presente en ambos sistemas. La solución a corto plazo para cada servidor es aplicar esta configuración de registro:
Ruta del registro: HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters
Valor: AllowEncryptionOracle (DWORD): 2
El artículo de soporte de Microsoft al que se hace referencia anteriormente explica todos los ajustes disponibles y afirma que un ajuste de «2» representa el ajuste de política «vulnerable» en el que se permite una conectividad insegura:
Este artículo explica cómo lograr el mismo resultado en la directiva de grupo.
Es importante tener en cuenta que esta configuración se considera una mala idea ya que evita un control de seguridad. Aplique esta configuración como una solución a corto plazo, pero asegúrese de que todos los sistemas implicados reciban todas las actualizaciones disponibles (obviamente lo siguiente que hice fue determinar por qué los sistemas de destino no estaban parcheados últimamente y remediarlo) y deshaga esta configuración – o cambie el valor a «0» a «Forzar clientes actualizados» después de la siguiente ronda de parches y compruebe la funcionalidad del escritorio remoto. Esperemos que todos estén trabajando como se esperaba en ese momento.
Boletín semanal de Microsoft
Conviértase en un experto en Microsoft de su empresa con la ayuda de estos tutoriales de Windows y Office y de los análisis de nuestros expertos sobre los productos empresariales de Microsoft. Entregado Lunes y Miércoles
Inscríbase hoy