Error RDP: fallo de la autenticación a nivel de red

Escribes el nombre de usuario y la contraseña en Conexión a Escritorio remoto, haces clic en Conectar y, antes de que aparezca ninguna pantalla de inicio de sesión, salta un mensaje de error. Ni escritorio, ni barra de progreso, nada. Eso es exactamente lo que caracteriza a un problema de NLA: la autenticación a nivel de red se ejecuta antes de que se cree la sesión. Si falla, nunca llegas a ver una pantalla de inicio de sesión en la que pudieras corregir algo.

Este artículo recorre las causas realistas en el orden en el que aparecen en la práctica y, para cada una, te da el comando de comprobación, la solución y el camino de vuelta cuando RDP está completamente muerto.

Los mensajes de error, palabra por palabra

No hay un solo mensaje, sino un puñado de ellos, y el texto exacto ya acota bastante la causa. Estas son las variantes con las que te encontrarás más a menudo:

• "El equipo remoto requiere autenticación a nivel de red, que su equipo no admite." El servidor exige NLA y el cliente no lo ofrece. Es típico en clientes antiguos, en clientes de terceros bajo Linux o macOS y con directivas de cliente mal configuradas.
• "Se ha producido un error de autenticación. No se puede establecer contacto con la entidad de seguridad local." En inglés: "The Local Security Authority cannot be contacted". Es el mensaje clásico de certificado o de desfase horario.
• "Se ha producido un error de autenticación. No se admite la función solicitada." Esto casi siempre es CredSSP, no NLA en sentido estricto. Más abajo lo vemos en detalle.
• "Las credenciales que se usaron para conectarse no funcionaron." Cuenta bloqueada, deshabilitada, contraseña caducada o la cuenta falta en el grupo de usuarios de escritorio remoto.
• "No se pudo establecer la relación de confianza entre esta estación de trabajo y el dominio principal." La cuenta de equipo en el dominio ya no coincide.

Una distinción importante: si el cliente te avisa al cabo de veinte segundos de que no se puede llegar al equipo remoto, eso no es un error de NLA, sino un problema de red, de firewall o de un servicio parado. Los errores de NLA llegan rápido, normalmente en uno a tres segundos, porque la conexión TCP sí está establecida y lo único que falla es la autenticación.

Causa 1: desfase horario entre cliente y servidor

Es con diferencia la causa más frecuente y también la que más se pasa por alto, porque "el reloj va un poco mal" suena a problema inofensivo. No lo es. Dos mecanismos se rompen en cuanto hay desfase horario:

• Kerberos tolera de forma predeterminada un máximo de cinco minutos de desviación. Por encima de eso, el controlador de dominio rechaza la petición con KRB_AP_ERR_SKEW. Afecta a todos los miembros del dominio.
• La comprobación TLS del certificado RDP falla cuando el reloj del cliente queda fuera del periodo de validez del certificado del servidor. Esto afecta también a servidores individuales sin dominio, y en concreto cuando el servidor arranca tras un reinicio con el reloj en el pasado y un certificado recién generado todavía no es válido desde el punto de vista del cliente.

Comprueba en el servidor, en una sesión de PowerShell con permisos de administrador:

w32tm /query /status /verbose
w32tm /query /source
w32tm /stripchart /computer:ptbtime1.ptb.de /samples:5 /dataonly

El stripchart te indica el desfase en segundos. Todo lo que esté por debajo de un segundo está bien, todo lo que pase de 60 segundos es sospechoso y todo lo que pase de 300 segundos explica el error.

Aquí es donde los sistemas se separan, y la mayoría de las guías lo mete todo en el mismo saco:

• Servidor individual sin dominio: configura una fuente NTP externa.
• Miembro de dominio: no configures en ningún caso una lista de pares propia. Un servidor miembro tiene que tomar la hora de la jerarquía del dominio, porque si no acaba desviándose respecto al controlador de dominio.

w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x9 time.windows.com,0x9" /syncfromflags:manual /update

w32tm /config /syncfromflags:domhier /update

Después, en ambos casos, reinicia el servicio y sincroniza:

net stop w32time
net start w32time
w32tm /resync /rediscover

Una particularidad que te pilla en servidores virtualizados: si el reloj marca exactamente una o dos horas de diferencia, no se trata de deriva, sino de un problema de interpretación del reloj de hardware. Windows espera el RTC en hora local, mientras que muchas plataformas de virtualización lo entregan en UTC. Comprueba primero la zona horaria y cambia después, si procede, la interpretación:

tzutil /g
tzutil /s "W. Europe Standard Time"

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Causa 2: certificado caducado o mal enlazado

Sin una PKI propia, Windows genera para RDP un certificado autofirmado que es válido alrededor de medio año y que normalmente se renueva solo. "Normalmente" es aquí la palabra clave. Si la renovación falla por permisos en el almacén de claves, o si caduca un certificado enlazado a mano procedente de una CA interna, ya no puedes iniciar sesión y ves el mensaje de la entidad de seguridad local.

Comprobar lo que hay:

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Select-Object Subject, NotBefore, NotAfter, Thumbprint

Y después, qué certificado usa realmente el listener:

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'").SSLCertificateSHA1Hash

Compara el hash devuelto con las huellas digitales del primer comando. Hay dos escenarios posibles: el hash apunta a un certificado caducado, o apunta a un certificado que ya no está en el almacén.

La reparación consiste en deshacer el enlace y eliminar el certificado antiguo. Windows genera después uno nuevo al arrancar el servicio:

Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name SSLCertificateSHA1Hash -ErrorAction SilentlyContinue

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Where-Object { $_.NotAfter -lt (Get-Date) } | Remove-Item

Restart-Service TermService -Force

Dos advertencias al respecto. La primera: reiniciar TermService tira todas las sesiones RDP existentes, también la tuya si de algún modo todavía sigues dentro. Ejecútalo desde la consola. La segunda: si una directiva de grupo define una plantilla de certificado para la autenticación de servidor, el servidor obtiene su certificado de la CA interna. Si la CA no está accesible o la plantilla ha caducado, no llega ningún certificado nuevo y el error se mantiene. En ese caso comprueba primero la CA, no el servidor.

Control de éxito: el primer comando devuelve ahora un certificado con una fecha NotAfter en el futuro, y SSLCertificateSHA1Hash apunta exactamente a ese certificado.

Causa 3: cuenta bloqueada, deshabilitada o contraseña caducada

Aquí está la trampa que diferencia a NLA de cualquier otro problema de inicio de sesión: con NLA activo no puedes cambiar una contraseña caducada desde el cliente RDP. El diálogo "La contraseña ha expirado y se debe cambiar" solo aparece dentro de la sesión, y a la sesión no llegas sin superar la autenticación. En su lugar, el cliente se limita a decir que las credenciales no funcionan. La contraseña es totalmente correcta, lo único que pasa es que ha caducado.

Consultar el estado de una cuenta local:

net user Administrator

Fíjate en las líneas "Cuenta activa", "La cuenta expira", "La contraseña expira" y "Se puede cambiar la contraseña". Las contramedidas correspondientes:

net user Administrator "NuevaClaveLarga!2026"

Enable-LocalUser -Name "Administrator"

Set-LocalUser -Name "Administrator" -PasswordNeverExpires $true

Una cuenta local bloqueada tras demasiados intentos fallidos es un estado aparte, que no se resuelve ni con Enable-LocalUser ni cambiando la contraseña. Se desbloquea sola cuando pasa la duración del bloqueo, que consultas así:

net accounts

Para desbloquear al momento sin ninguna herramienta gráfica de administración, ve por ADSI:

$u = [ADSI]"WinNT://./Administrator,user"; $u.IsAccountLocked = $false; $u.SetInfo()

Si los puertos RDP son accesibles desde internet, los bloqueos ocurren prácticamente a diario, porque los bots van probando combinaciones contra tu cuenta de administrador. Es un argumento de peso para restringir el acceso en lugar de desbloquear la cuenta una y otra vez. Cambiar de puerto ayuda de forma notable contra los escaneos masivos, mira cambiar el puerto RDP sin reiniciar.

Por último, la pertenencia al grupo. El nombre del grupo está localizado, algo con lo que los scripts suelen tropezar. Para consultarlo con independencia del idioma, usa el SID conocido:

Get-LocalGroupMember -SID "S-1-5-32-555"

Causa 4: NLA desactivado o desactivado a medias en el servidor

Dos interruptores independientes determinan el comportamiento, y es justo su combinación la que causa problemas. UserAuthentication controla NLA y SecurityLayer la protección del transporte, con los valores 0 para la antigua capa de seguridad de RDP, 1 para negociar y 2 para TLS forzado.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer

El callejón sin salida típico: alguien desactiva NLA porque sospecha de un problema de certificado, pero deja SecurityLayer en 2. Con eso se mantiene la negociación TLS con el certificado roto, y lo único que cambia es el texto del error. Si de verdad quieres bajar los dos valores para diagnosticar, bájalos los dos y restáuralos después.

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'") | Invoke-CimMethod -MethodName SetUserAuthenticationRequired -Arguments @{UserAuthenticationRequired=0}

El segundo callejón sin salida es aún más molesto: pones el valor en el registro, reinicias y vuelve a estar en 1. Entonces viene de una directiva de grupo. Los valores de directiva están en otro sitio y ganan siempre:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication

gpresult /r /scope:computer

Mientras haya un valor ahí, cualquier cambio local solo vale hasta la siguiente aplicación de la directiva. La directiva se llama "Requerir autenticación de usuario para conexiones remotas mediante Autenticación a nivel de red" y hay que tocarla en el controlador de dominio.

Y la regla más importante para cerrar este apartado: desactivar NLA de forma permanente no es una solución, es una puerta abierta. Sin NLA, cualquiera que alcance el puerto puede dirigirse a la pantalla de inicio de sesión y, con ella, a una parte no protegida del stack de sesión. Desactívalo para diagnosticar y vuelve a activarlo después.

Causa 5: relación de confianza del dominio rota

Cada cuenta de equipo de un dominio tiene su propia contraseña, que de forma predeterminada se cambia automáticamente cada 30 días. Si el estado del servidor y el del controlador de dominio dejan de coincidir, el servidor ya no puede autenticar cuentas de dominio, y NLA falla para todos los usuarios del dominio mientras las cuentas locales siguen funcionando. Justo ese patrón es la prueba de esta causa.

El desencadenante clásico en la operación de servidores es una vuelta atrás a un estado anterior, por ejemplo desde un backup o un snapshot más antiguo que el último cambio de contraseña. Comprobarlo:

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:midominio.local

Repararlo, con la sesión iniciada como administrador local desde la consola:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Reset-ComputerMachinePassword -Credential (Get-Credential)

Sacar el equipo del dominio y volver a unirlo no hace falta para esto y a menudo empeora las cosas, porque en el proceso se pueden perder pertenencias a grupos y permisos de la cuenta de equipo antigua. Tras la reparación basta con reiniciar el servicio Netlogon:

Restart-Service Netlogon

Cuando RDP ya no funciona en absoluto: el camino por la consola

Todos los comandos anteriores dan por hecho que de alguna forma puedes llegar al servidor. En una emergencia real eso es justo lo que no ocurre. Por eso, en los servidores root KVM de KernelHost tienes en el área de cliente una consola VNC que funciona con independencia de RDP, del firewall de Windows e incluso del stack de red del sistema invitado. Es el acceso de emergencia con el que sales por tu cuenta de cualquiera de las situaciones descritas arriba. En los servidores dedicados, el acceso de emergencia va a través del soporte.

Tres cosas funcionan en la consola VNC de forma distinta a una sesión RDP y cuestan tiempo con regularidad:

• Distribución del teclado. La consola suele ofrecer una distribución US mientras Windows está en español, o al revés. Los caracteres especiales de las contraseñas acaban entonces donde no toca y das por incorrecta una contraseña que en realidad es correcta. Ante la duda, usa el teclado en pantalla con osk.exe desde la propia pantalla de inicio de sesión.
• Portapapeles. Copiar desde tu propio equipo a la consola casi nunca funciona. Cuenta con teclearlo todo a mano y elige las contraseñas temporales en consecuencia.
• Inicio de sesión como cuenta local. Con problemas de dominio, inicia sesión con .\Administrator, ya que el punto y la barra invertida fuerzan la cuenta local en lugar de la cuenta de dominio.

En la consola compruebas entonces lo básico antes de ponerte a tocar NLA:

sc query TermService

netstat -ano | findstr :3389

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

Si fDenyTSConnections está en 1, las conexiones remotas están completamente desactivadas, con independencia de NLA:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Las reglas del firewall las activas de forma independiente del idioma a través del identificador interno del grupo, porque el nombre de grupo que se muestra cambia según el idioma del sistema:

Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"

El caso especial de CredSSP, que se confunde a menudo

Si el mensaje dice literalmente "No se admite la función solicitada" y menciona la corrección del oráculo de cifrado de CredSSP, entonces no tiene la culpa ninguna de las cinco causas anteriores. Aquí no coinciden los niveles de parches de cliente y servidor: un lado exige la variante reforzada de CredSSP y el otro todavía no la conoce.

La única solución limpia es actualizar los dos lados. El cambio en el registro con AllowEncryptionOracle en el cliente que circula por la red desactiva justo el refuerzo que provoca el error y, con ello, vuelve a abrir una vía de ataque conocida. Si lo necesitas de forma puntual para poder instalar las actualizaciones, revierte el valor en cuanto el servidor esté al día.

Cómo saber que está realmente resuelto

Una conexión correcta es la prueba más débil, porque también funciona cuando has desactivado NLA para diagnosticar. Comprueba en su lugar, uno por uno:

1. NLA vuelve a estar activo. UserAuthentication está en 1 y SecurityLayer en 2.
2. El reloj es correcto. El desfase del stripchart está por debajo de un segundo y w32tm /query /source indica una fuente real, no "Local CMOS Clock" ni "Free-running System Clock".
3. El certificado es válido. NotAfter está en el futuro y el hash enlazado apunta exactamente a ese certificado.
4. El registro de eventos confirma que la autenticación de red se ha superado. El evento 1149 solo aparece cuando NLA se ha completado, así que es la prueba de verdad.

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 20 | Where-Object Id -eq 1149

Para la contraprueba en los intentos fallidos, los códigos de estado del evento 4625 dicen más que cualquier mensaje del cliente: 0xC0000071 significa contraseña caducada, 0xC0000072 cuenta deshabilitada, 0xC0000234 cuenta bloqueada y 0xC000006A contraseña realmente incorrecta.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

Y para terminar, las sesiones en sí, preferiblemente desde la consola:

qwinsta

Referencia rápida para el diagnóstico

Cuando montas un servidor Windows nuevo, merece la pena dejar bien puestas desde el principio la fuente de hora, las directivas de cuenta y la vía de acceso, en lugar de repararlas más tarde bajo presión. Como orientación sirve la lista de comprobación para un servidor root nuevo, y quien quiera asegurar además el acceso RDP encontrará en cambiar el puerto RDP sin reiniciar el primer paso menos costoso contra los intentos de inicio de sesión automatizados.