Tras años funcionando, al conectarse por RDP desde Internet a un Windows Server 2016 Essentials aparece “Logon attempt failed”, mientras que en la LAN inicia sin problema y el RD Gateway autoriza. Aquí tienes un diagnóstico guiado y una solución segura para restaurar el acceso.
Resumen del caso
Escenario típico: servidor Windows Server 2016 (Essentials Experience) con RD Gateway publicado; desde fuera, las conexiones fallan con el mensaje “logon attempt failed”, pero las mismas credenciales funcionan en la red local. Los registros del RD Gateway indican autorización, por lo que el rechazo sucede en el propio servidor al iniciar sesión.
Diagnóstico rápido
- Delegación de credenciales y NLA a través de RD Gateway. Si la cuenta tiene marcada la opción de Active Directory “La cuenta es confidencial y no se puede delegar”, el RD Gateway no puede delegar las credenciales hacia el host destino y la NLA (CredSSP) falla con “logon attempt failed”. En la LAN, donde no hay salto por gateway, sí inicia sesión.
- Derechos de inicio de sesión por RDP controlados por GPO. Un cambio de directiva puede permitir RDP local pero denegar la entrada cuando la autenticación se hace por NLA/RDS.
- Credenciales y formato de usuario. Credenciales guardadas corruptas o el uso de un formato de nombre incorrecto provocan rechazos inmediatos.
- Sincronización de hora y Kerberos. Una desviación superior a cinco minutos rompe la autenticación segura.
- Conectividad y publicación. Cambios en certificados, puertos o reglas de publicación pueden parecer autorización correcta en RDG pero fallar después.
Procedimiento paso a paso
Prueba con NLA deshabilitado de forma temporal
Objetivo: confirmar si el problema está en la combinación NLA + delegación de credenciales.
- En el servidor, abre SystemPropertiesRemote.exe > pestaña Remoto y desmarca “Solo permitir las conexiones desde equipos que ejecuten Escritorio remoto con Autenticación a nivel de red (NLA)”.
- Alternativa por registro/PowerShell (útil si el acceso por consola es limitado):
# Desactivar NLA (temporal)
Set-ItemProperty `
-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
-Name 'UserAuthentication' -Value 0
Activar NLA de nuevo (producción)
Set-ItemProperty ` -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp'`
-Name 'UserAuthentication' -Value 1 Resultado esperado: si desde Internet ahora sí puedes iniciar sesión, la causa más probable es la delegación/NLA. Continúa con la revisión de la cuenta y la configuración del cliente RDP.
Creación de una cuenta de prueba no privilegiada
Para aislar si el problema es de la cuenta de administrador de dominio:
- Crea un usuario de prueba en AD sin pertenecer a Domain Admins.
- Añádelo a Remote Desktop Users en el servidor (o a Administrators temporalmente para la prueba).
- Intenta iniciar sesión a través del RD Gateway.
Si la cuenta de prueba accede y la original no, refuerza el diagnóstico: la cuenta original está afectada por no delegable o por un derecho de inicio de sesión denegado.
Revisión de la cuenta en Active Directory
Comprueba si la cuenta usada para el RDP está marcada como no delegable o pertenece a grupos con restricciones especiales:
- En ADUC: propiedades de la cuenta > pestaña Cuenta > verifica “La cuenta es confidencial y no se puede delegar”.
- Con PowerShell de AD:
Get-ADUser usuario.ejemplo -Properties AccountNotDelegated, MemberOf |
Select-Object SamAccountName, AccountNotDelegated, MemberOf
Qué hacer: usa otra cuenta administrativa dedicada para acceso remoto que no esté marcada como no delegable. Evita usar Domain Admins a través de Internet. Si decides desmarcar la opción por necesidad, asume el riesgo y compénsalo con MFA en el RD Gateway.
Comprobación de derechos de inicio de sesión por RDP mediante GPO
Recuerda que las directivas de derechos se evalúan en el servidor destino:
- Ruta: Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Asignación de derechos de usuario.
| Directiva | Comprobación | Recomendación |
|---|---|---|
| Allow log on through Remote Desktop Services | Incluye a Administrators y/o el grupo que contiene al usuario remoto. | Si falta, agrégalo en la GPO que aplica al servidor RDS/servidor. |
| Deny log on through Remote Desktop Services | No debe incluir a la cuenta ni a sus grupos (p. ej. Domain Admins si lo usas). | Si aparece, retíralo o mueve la cuenta a un grupo permitido. |
Útiles de diagnóstico:
# Ver GPO efectiva en el servidor
gpresult /H C:\gp.html
Comprobar pertenencia a grupos
whoami /groups
Limpieza de credenciales guardadas y formato de usuario
Desde el equipo cliente, elimina entradas antiguas del Administrador de credenciales. Al reconectar, introduce el usuario como DOMINIO\usuario o usuario@dominio.tld. En mstsc.exe > Mostrar opciones > pestaña Avanzadas > Configuración de RD Gateway, desmarca “Usar mis credenciales del servidor de puerta de enlace para el equipo remoto” y permite pedirlas por separado.
Sincronización de hora y Kerberos
Comprueba que cliente, servidor y DC tengan hora sincronizada (desviación máxima recomendada: cinco minutos):
w32tm /query /status
w32tm /query /configuration
Resincronizar (ejecutar como admin)
w32tm /resync
Conectividad, RD Gateway y certificados
Asegura que la publicación permanece intacta:
- Comprobación del puerto 443 hacia el RD Gateway:
Test-NetConnection nombre-o-dns-del-rdg -Port 443
- Valida que el certificado del RDG sea válido y coincida con el FQDN que usa el cliente.
- Para diagnóstico controlado, puedes publicar temporalmente el 3389 directo al servidor (solo durante la prueba) para aislar si el problema está en el gateway o en el host de destino.
Registro de eventos que orientan
El visor de eventos es la brújula para saber dónde y por qué se niega el inicio de sesión.
| Log | Origen | Evento | Interpretación |
|---|---|---|---|
| Seguridad | Microsoft Windows Security Auditing | 4625 | Inicio de sesión erróneo en el servidor. Revisa Estado/Subestado: 0xC000015B (denegado por derechos), 0xC000006A (contraseña incorrecta), 0xC0000234 (cuenta bloqueada), 0xC0000193 (cuenta expirada). |
| Aplicaciones y servicios > Microsoft > Windows > RemoteDesktopServices-RdpCoreTS > Operational | RdpCoreTS | 131, 140 | Errores de transporte o credenciales en la fase de NLA. |
| Aplicaciones y servicios > Microsoft > Windows > TerminalServices-RemoteConnectionManager > Operational | TermServ-RemoteConnectionManager | 1149 | Autenticación de usuario correcta a nivel de red. Si aparece y luego hay 4625, la denegación es por derechos o delegación. |
| Aplicaciones y servicios > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational | TermServ-LocalSessionManager | 21, 40 | Creación y cierre de sesiones; indica si llega a abrirse sesión interactiva. |
Fondo técnico sobre NLA, RD Gateway y delegación
Cuando te conectas desde Internet mediante RD Gateway, el cliente RDP establece un túnel HTTPS con el gateway, que a su vez reenvía las credenciales mediante CredSSP hacia el servidor destino para NLA. Si la cuenta está marcada como no delegable o pertenece a grupos con restricciones de delegación, el salto de credenciales se bloquea y el servidor destino rechaza la autenticación con el genérico “logon attempt failed”. En la red local este salto no existe, por eso la misma cuenta funciona.
Esta es la razón por la que desactivar NLA temporalmente permite entrar desde fuera: se elimina la exigencia de CredSSP, pero no es una solución permanente. La corrección real consiste en usar una cuenta apta para delegación (o ajustar la política de delegación con pleno conocimiento del riesgo) y mantener NLA habilitado.
Buenas prácticas y solución final
- Evita usar Domain Admins a través de Internet. Emplea una cuenta administrativa dedicada para RDP que no esté marcada como no delegable. Activa MFA en el RD Gateway si es posible (por ejemplo, mediante NPS Extension).
- Mantén NLA habilitado en producción. Solo apágala para confirmar la hipótesis y vuelve a encenderla de inmediato.
- Define y documenta en GPO los derechos de inicio de sesión por RDS para los servidores críticos. Evita cambios manuales locales que se pierden con el tiempo.
- Monitorea eventos 4625 y revisa el Substatus para identificar rápidamente si fue contraseña, derechos, expiración o restricciones.
- Revisa hora y DNS de forma programada; una deriva de tiempo o una resolución DNS incorrecta suelen romper la autenticación de manera intermitente.
Comandos y scripts útiles
Recopilación de mandatos prácticos para acelerar el diagnóstico:
# Comprobar que el servidor escucha RDP
qwinsta
Probar conectividad al RD Gateway
Test-NetConnection rdg.midominio.tld -Port 443
Mostrar información de certificado de equipo (Personal)
Get-ChildItem Cert:\LocalMachine\My | Format-Table FriendlyName, Subject, NotAfter
Verificar si NLA está requerido
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' UserAuthentication
Exportar GPO efectiva (abre gp.html en el navegador)
gpresult /H C:\gp.html
Inspeccionar pertenencia a Remote Desktop Users y Administrators
net localgroup "Remote Desktop Users"
net localgroup Administrators
Revisar atributo "no delegable" en usuarios con patrón "admin"
Get-ADUser -Filter 'SamAccountName -like "admin"' -Properties AccountNotDelegated |
Where-Object AccountNotDelegated -EQ \$true |
Select SamAccountName Tabla de decisión rápida
| Síntoma | Causa probable | Cómo verificar | Acción |
|---|---|---|---|
| Desde Internet falla, en LAN funciona | Delegación bloqueada o NLA | Desactivar NLA temporalmente; revisar AccountNotDelegated | Usar cuenta delegable; reactivar NLA |
| Evento 4625 con Substatus 0xC000015B | Derechos RDS denegados | GPO de Allow/Deny log on through RDS | Ajustar GPO; incluir grupo correcto |
| Se piden credenciales varias veces | Formato de usuario o credenciales guardadas | Borrar credenciales; usar DOMINIO\usuario | Reintroducir credenciales correctas |
| Fallas intermitentes o de madrugada | Desfase de hora/NTP | w32tm /query /status en cliente, servidor y DC | Corregir NTP; asegurar jerarquía de tiempo |
| Autorización en RDG pero sin sesión | Certificado o RAP/CAP incongruente | Validar certificado y políticas RDG | Renovar cert; revisar reglas y FQDN |
Guía detallada para cerrar el caso
- Desactiva NLA solo para la prueba. Si ahora inicia desde fuera, confirma que estás ante un problema de delegación.
- Revisa la cuenta de acceso: quita no delegable o mejor usa una cuenta administrativa específica para acceso remoto.
- Asegura que la GPO del servidor incluye a tus grupos en Allow log on through Remote Desktop Services y que no apareces en Deny.
- Borra credenciales guardadas en el cliente y usa formato
DOMINIO\usuarioo UPN. - Sincroniza hora en cliente, servidor y DC. Comprueba DNS y FQDN usados por RDG y servidor.
- Vuelve a activar NLA y valida desde fuera con la cuenta correcta.
Consideraciones específicas para Essentials Experience
En Windows Server 2016 Essentials, Anywhere Access instala y configura un RD Gateway con políticas CAP/RAP y publica el FQDN remoto. Cambios posteriores en certificados, pertenencia a grupos o GPO de seguridad pueden romper el inicio de sesión sin afectar a la autorización del gateway. Por tanto, prioriza revisar:
- Certificado del RD Gateway aún válido y con el nombre público que usa el cliente.
- RAP con el grupo de equipos de destino correcto.
- Cuenta usada sin marca de no delegable y con los derechos RDS apropiados en el servidor objetivo.
Preguntas frecuentes
¿Por qué en la LAN funciona y por Internet falla? Porque al pasar por RD Gateway se requiere delegar credenciales para NLA. Si la cuenta no puede delegarse, el salto falla; en LAN no hay ese salto.
¿Es seguro desactivar NLA? No en producción. NLA mitiga ataques de fuerza bruta y consumo de recursos; úsala siempre. Apágala solo para confirmar hipótesis y regrésala enseguida.
¿Puedo seguir usando Domain Admins? Mejor no. Crea una cuenta administrativa dedicada para acceso remoto, con MFA en el gateway y controles de auditoría. Es más seguro y evita el bloqueo por no delegación.
¿Y si el usuario está en Protected Users? Ese grupo añade restricciones que pueden interferir con delegación o NTLM. Evita usar cuentas de Protected Users para RDP a través de RDG.
Conclusión práctica
Cuando el RD Gateway autoriza pero el servidor rechaza con “logon attempt failed”, la pista más sólida es la combinación de NLA con una cuenta marcada como no delegable o derechos RDS inadecuados. Valida esta hipótesis desactivando NLA de forma temporal; corrige creando/empleando una cuenta administrativa delegable, ajusta GPO de derechos de inicio de sesión y confirma hora y certificados. Con ello recuperarás el acceso remoto manteniendo el nivel de seguridad adecuado.
Plantilla de remediación resumida
- Cuenta de acceso remoto: dedicada, no en Domain Admins, no marcada como no delegable.
- GPO: permitir inicio por RDS al grupo correcto; sin entradas en Deny.
- NLA: activada en el servidor al finalizar.
- Cliente RDP: credenciales para RDG y para el equipo remoto por separado.
- Hora, DNS y certificados: verificados.
- Monitoreo: alertas de 4625 con subestados relevantes.
Resultado esperado: acceso RDP desde Internet estable y seguro a través de RD Gateway, sin volver a ver “logon attempt failed”.