Si el Escritorio Remoto inicia y, tras unos segundos, muestra “No Response From Server” en un servidor con Windows Server, es muy probable que el problema no sea la red ni el propio RDP. En este caso real, el origen fue un proveedor de credenciales de terceros (SecurEnvoy) mal configurado. Aquí tienes el diagnóstico y la solución.
Resumen del caso práctico
Entorno con un servidor físico con Windows Server y dos máquinas virtuales en Hyper‑V. Las conexiones RDP arrancaban con normalidad y la pantalla de inicio de sesión aparecía, pero a los 10–15 segundos el cliente devolvía el mensaje “No Response From Server”. La conectividad básica estaba OK (ping, recursos compartidos, DNS). RDP estaba habilitado, los usuarios pertenecían a los grupos correctos, se probó con NLA desactivado y con el Firewall apagado, y no había saturación de CPU o memoria.
En el Visor de eventos se registraban advertencias en TerminalServices‑LocalSessionManager del tipo:
RDP_SEC: ... FEventCheckAndCompleteReadsFailed (0x8007139F)Network characteristics detection ... disabled (Reason Code: 2 – Server Configuration)
Tras investigar, la causa raíz fue un Windows Logon Agent de SecurEnvoy instalado en los servidores on‑prem e incompletamente configurado, que interfería en el inicio de sesión interactivo. Al desinstalar el agente, RDP volvió a funcionar de inmediato.
Causa raíz confirmada
Los productos de MFA o SSO que se integran con Windows añaden un Credential Provider para participar en el flujo de autenticación. Si ese proveedor no responde, se bloquea o queda en un estado inconsistente, la sesión RDP puede quedar en un punto muerto: el transporte está vivo, pero la autenticación no progresa. En este caso, el agente de SecurEnvoy era el proveedor que provocaba el bloqueo.
El código 0x8007139F que aparece en los eventos del LSM suele mapear con un estado no válido durante la negociación, lo que encaja con un proveedor de credenciales que no completa su parte del flujo.
Cómo reconocer el patrón
Señales típicas que apuntan a un proveedor de credenciales de terceros:
- El cliente RDP llega a mostrar la interfaz de inicio de sesión, pero retrocede con “No Response From Server” sin cortar la red.
- Los registros de LocalSessionManager, RemoteConnectionManager y RdpCoreTS contienen mensajes sobre lecturas fallidas, detección de características de red deshabilitada por configuración del servidor o retrasos sin errores explícitos de TLS/Certificados.
- Existen agentes de autenticación instalados (MFA, SSO, passwordless) o restos de instalaciones previas.
| Origen | Mensaje orientativo | Interpretación práctica |
|---|---|---|
| TerminalServices‑LocalSessionManager | RDP_SEC ... FEventCheckAndCompleteReadsFailed (0x8007139F) | Fallo al completar el flujo; el servidor aceptó la conexión, pero el inicio de sesión no avanzó a estado válido. |
| TerminalServices‑LocalSessionManager | Network characteristics detection ... disabled (Reason Code: 2 – Server Configuration) | El servidor está configurado para omitir detección de características de red; no es la causa por sí misma, pero refuerza un escenario “todo responde excepto el logon”. |
| RdpCoreTS | Mensajes sin error TLS explícito | Transporte operativo; el bloqueo está en la capa de autenticación interactiva. |
Qué está ocurriendo en el flujo de autenticación
De forma simplificada, el recorrido es:
- El cliente abre el canal al puerto del servicio de escritorio remoto y negocia seguridad de transporte.
- Con NLA activo, se usa CredSSP para autenticar antes de crear la sesión interactiva.
- El subsistema de inicio de sesión carga Credential Providers registrados en el sistema.
- Si un proveedor de terceros toma el control y no finaliza su parte (por ejemplo, esperando un segundo factor o una comunicación con backend que no llega), el servidor no avanza y el cliente termina informando “No Response From Server”.
Como la red, el puerto y el servicio están activos, la traza no muestra un corte clásico de conectividad: el atasco es lógico, no físico.
Guía rápida de actuación
Cuando sospeches de un proveedor de credenciales, sigue este camino de menor a mayor impacto:
- Accede por consola (KVM, iDRAC/iLO, consola del hipervisor, visita física) para evitar depender del mismo flujo RDP que está fallando.
- Desinstala o deshabilita temporalmente el agente problemático. En el caso descrito, retirar el Windows Logon Agent de SecurEnvoy resolvió el problema en el acto.
- Si no puedes retirarlo, excluye su proveedor por directiva usando la política Excluir proveedores de credenciales e indicando el GUID del proveedor del tercero para pruebas controladas.
- Reinicia el servicio o el servidor tras los cambios para limpiar manejadores cargados.
- Restablece NLA al estado deseado (recomendado habilitado) una vez validada la solución.
Comandos de comprobación en PowerShell
Inventariado rápido de proveedores registrados:
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers' |
Select-Object PSChildName
Localiza instalaciones relacionadas con MFA/SSO en el registro de desinstalación:
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object { $_.DisplayName -match 'SecurEnvoy|Duo|Okta|RSA|Ping|Thales|HYPR|Auth|MFA' } |
Select-Object DisplayName, DisplayVersion, Publisher, InstallDate, UninstallString
Estado de servicios y configuración básica de RDP y NLA:
Get-Service TermService, UmRdpService | Select-Object Name, Status, StartType
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections'
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' Eventos relevantes para correlación rápida:
$logs = @(
'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational',
'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational',
'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational'
)
\$pattern = 'RDP\_SEC|0x8007139F|Network characteristics'
\$logs | ForEach-Object {
Get-WinEvent -LogName $\_ -MaxEvents 200 |
Where-Object { $\_.Message -match \$pattern } |
Select-Object TimeCreated, Id, ProviderName, Message
} Cómo deshabilitar temporalmente un proveedor
Para aislar el impacto sin desinstalar, utiliza la directiva de Excluir proveedores de credenciales y añade el GUID del proveedor de terceros. Aplica la GPO solo al equipo afectado y reinicia. Esta técnica es útil para confirmar rápidamente si el bloqueo desaparece al sacar de la ecuación al proveedor sospechoso.
Importante: no dejes la exclusión de forma permanente a menos que la organización haya decidido retirar ese factor de autenticación. Documenta el cambio y revierte una vez terminado el análisis.
Pasos de remediación recomendados
- Retirar el agente defectuoso en el servidor afectado. En el caso tratado, desinstalar el Windows Logon Agent de SecurEnvoy normalizó RDP al instante.
- Actualizar y configurar correctamente el agente si debe permanecer: registro del equipo en el backend, políticas aplicadas, validación de URLs y puertos, servicios en ejecución y versión compatible con el sistema.
- Probar en un entorno de preproducción antes de reintroducirlo en producción para validar el flujo completo de autenticación, incluyendo NLA.
- Reactivar NLA y confirmar que la pila de RDP queda en estado saludable.
Verificaciones después de aplicar los cambios
- NLA en el estado deseado y el servicio
TermServiceen Running. - Los registros ya no muestran referencias a
0x8007139Fni cuelgues durante el logon. - La sesión RDP progresa con normalidad desde distintos orígenes de cliente.
- No hay bloqueos posteriores al cierre de sesión ni problemas de reconexión.
Recomendaciones prácticas para resolver y prevenir
Buscar agentes de inicio de sesión de terceros
Los productos de MFA y SSO (SecurEnvoy, Duo, Okta, y otros) se integran como proveedores de credenciales. Si están mal configurados, pueden bloquear RDP.
- Desde una sesión alternativa (consola física, iDRAC/iLO o herramienta remota de terceros), desinstala, actualiza o deshabilita temporalmente el agente para probar.
- Comprobación rápida de proveedores instalados:
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers' |
Select-Object PSChildName
Identifica GUID no Microsoft y comprueba si pertenecen a soluciones MFA o SSO.
Si necesitas mantener el agente
- Valida que esté plenamente configurado: registro del equipo en la plataforma, políticas correctas, URLs y puertos permitidos, servicio en Running.
- Verifica compatibilidad con el sistema y aplica la versión más reciente.
- Coordina con el proveedor para el mapeo correcto con NLA y realiza pruebas en staging.
Validaciones de RDP y NLA tras el ajuste
- Restablece NLA al estado preferido (recomendado habilitado).
- Confirma que las GPO de RDP no excluyen proveedores necesarios.
- Revisa los registros:
- TerminalServices‑LocalSessionManager / Operational
- RemoteConnectionManager / Operational
- RdpCoreTS / Operational
- Verifica que el evento con
0x8007139Fya no aparece y que el inicio de sesión progresa.
Causas descartadas para no repetir esfuerzo
- Firewall deshabilitado sin efecto.
- RDP habilitado y permisos comprobados.
- NLA desactivado de forma temporal sin cambios.
- Latencia de red y recursos del servidor normales.
Procedimiento de diagnóstico detallado
Inventario de software y servicios de autenticación
Busca paquetes y servicios asociados a MFA/SSO. Examina tanto arquitectura nativa como de 32 bits:
# Software instalados con huella MFA/SSO
$apps = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object { $_.DisplayName -match 'SecurEnvoy|Duo|Okta|RSA|Ping|Thales|HYPR|Auth|MFA' }
\$apps | Select-Object DisplayName, DisplayVersion, Publisher, UninstallString | Format-Table -Auto
Servicios que podrían pertenecer a estos agentes
Get-Service | Where-Object { $\_.DisplayName -match 'SecurEnvoy|Duo|Okta|RSA|Ping|Thales|HYPR|Auth' } |
Select-Object Status, Name, DisplayName Revisión de proveedores de credenciales
Lista básica de GUID instalados para detectar proveedores no Microsoft:
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers' |
Select-Object PSChildName
Con esa lista, identifica el proveedor del agente sospechoso con la documentación del producto o con tu inventario de software.
Prueba temporal sin el proveedor
Si la política de seguridad lo permite, excluye el GUID del proveedor con una GPO de equipo que aplique Excluir proveedores de credenciales solo a ese servidor y reinicia. Si RDP funciona, has aislado el origen.
Validación remota con PowerShell
Si WinRM está habilitado, puedes ejecutar la desinstalación de forma remota mientras RDP falla:
Invoke-Command -ComputerName NOMBRE_SERVIDOR -ScriptBlock {
$apps = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object { $_.DisplayName -match 'SecurEnvoy' }
$apps | Select-Object DisplayName, UninstallString
# Si UninstallString es MSI:
# Start-Process "msiexec.exe" -ArgumentList "/x {PRODUCT-CODE} /qn" -Wait
} -Credential (Get-Credential)
Consejo: usa siempre la cadena de desinstalación oficial del producto. Evita manipular DLL o entradas de registro sin un plan de reversión claro.
Buenas prácticas de prevención
| Control preventivo | Aplicación recomendada |
|---|---|
| Catálogo de autenticación | Mantén un inventario de todos los agentes MFA/SSO por servidor, versión y compatibilidad. |
| Gestión de cambios | Instala y actualiza agentes primero en staging. Define plan de reversión. |
| Monitoreo de eventos | Alerta sobre patrones de LSM, RemoteConnectionManager y RdpCoreTS que impliquen bloqueos. |
| Pruebas de NLA | Incluye casos con NLA activo e inactivo para verificar la integración del proveedor. |
| Documentación de GPO | Registra cualquier exclusión temporal de proveedores para evitar olvidos en producción. |
Preguntas frecuentes
¿Por qué puedo hacer ping o acceder a recursos compartidos, pero RDP falla?
Porque la red funciona, pero el bloqueo está en la autenticación interactiva que ejecuta proveedores de credenciales. El transporte RDP está activo; el logon se queda congelado.
¿Deshabilitar NLA soluciona el problema?
En este caso, no. El proveedor de terceros aún participa en el flujo y puede bloquear la sesión incluso sin NLA. NLA debe quedar habilitado cuando todo esté correcto.
¿Sirve conectar con opción de administración?
A veces permite sortear particularidades de directivas, pero no garantiza saltarse un proveedor de credenciales que esté enganchado al logon.
Checklist de bolsillo
- Confirmar que el transporte responde y que el mensaje exacto es “No Response From Server”.
- Revisar eventos de LSM, RemoteConnectionManager y RdpCoreTS en el periodo del fallo.
- Listar proveedores de credenciales y software MFA/SSO instalado.
- Excluir temporalmente el proveedor sospechoso o desinstalar el agente.
- Reiniciar y validar RDP con NLA habilitado.
- Actualizar y configurar correctamente el agente si debe permanecer.
Conclusión y mensaje clave
Cuando veas “No Response From Server” y la red esté sana, piensa en proveedores de credenciales. En este caso, el agente de SecurEnvoy era el culpable: retirarlo o configurarlo apropiadamente restableció RDP al instante. Evita bucles de pruebas de red y enfoca el esfuerzo en el logon interactivo y los Credential Providers.
Nota: si otro equipo pide una “solución desde el lado de SecurEnvoy”, la respuesta habitual es actualizar a la versión compatible y completar la configuración del agente (o aplicar el fix del proveedor) para que no bloquee el flujo de autenticación con RDP y NLA.
Resumen operativo
- Síntoma: RDP muestra “No Response From Server” tras la pantalla de logon.
- Registro: eventos de LSM con
FEventCheckAndCompleteReadsFailed (0x8007139F)y mensajes de detección de red deshabilitada por configuración. - Causa raíz: proveedor de credenciales de terceros, concretamente el agente de SecurEnvoy sin configurar.
- Solución: desinstalar o configurar correctamente el agente. Restituir NLA y validar.
- Prevención: versionado, pruebas en staging, monitoreo de eventos y control de cambios de agentes MFA/SSO.