Escribes tus credenciales, el aviso de Seguridad de Windows parpadea y aparece una línea roja: The logon attempt failed. La sesión nunca se abre. Me he topado con esto en laboratorios caseros, equipos cliente y servidores por igual. Y el error se ve idéntico, ya sea que la causa sea un derecho de Directiva de grupo que falta, una entrada obsoleta en el Administrador de credenciales, una actualización de Windows que dañó CredSSP o un controlador de dominio que estuvo brevemente inaccesible.
En este artículo, te guiaré a través de las causas raíz más comunes y confirmadas y de las correcciones probadas para el error de RDP “The logon attempt failed”.
¿Qué significa “RDP Logon Attempt Failed”?
The logon attempt failed es el mensaje genérico de Windows para un rechazo de credenciales en algún punto de la cadena de autenticación de RDP. Se muestra como texto dentro del cuadro de diálogo de credenciales de RDP antes de que se establezca el escritorio remoto. El problema es que Windows devuelve esta misma cadena para fallos en múltiples puntos distintos.
El registro de seguridad de Windows en la máquina de destino lo registra como Event ID 4625, y el código de estado o de subestado dentro de ese evento es lo que realmente identifica el punto de fallo.
¿Cómo solucionar el error “Remote Desktop Logon Attempt Failed”?
Solución 1: Conceder el derecho de inicio de sesión de Servicios de Escritorio remoto
Esto resuelve una gran parte de los casos en los que las credenciales son correctas, pero la conexión falla. Empiezo por aquí antes de tocar nada más.
-
En el equipo de destino, presiona la tecla Windows + R, escribe
secpol.mscy presiona Intro para abrir Directiva de seguridad local. -
Expanda Directivas locales y seleccione Asignación de derechos de usuario.
-
En el panel derecho, haga doble clic en
Permitir iniciar sesión a través de los Servicios de Escritorio remoto.
-
Haga clic en Agregar usuario o grupo y escriba el nombre de usuario exacto de la cuenta que utiliza para conectarse.
-
Haga clic en Aceptar y cierre Directiva de seguridad local.
-
Abra un Símbolo del sistema con privilegios elevados y ejecute
gpupdate /forcepara aplicar el cambio sin reiniciar.
Mientras estás en Administración de equipos, verifica también que la cuenta sea miembro del grupo Usuarios de Escritorio remoto en Usuarios y grupos locales. Esto no sustituye el derecho de la directiva, pero forma parte de la configuración esperada. De forma predeterminada, la pertenencia al grupo Usuarios de Escritorio remoto suele conceder este derecho, a menos que esté anulado por una Directiva de grupo local o de dominio. Sin embargo, si una Directiva de grupo lo anula explícitamente, es posible que debas agregar la cuenta directamente al derecho en la directiva, incluso si la pertenencia al grupo ya está en vigor.
Solución 2: Eliminar credenciales obsoletas en el Administrador de credenciales
Ejecute esta solución inmediatamente después de la Solución 1 si el error persiste, especialmente después de un cambio de contraseña en el equipo de destino.
-
En el equipo que se conecta, abra el menú Inicio y busque Administrador de credenciales.
-
Seleccione Credenciales de Windows.
-
Busque cualquier entrada que comience con
TERMSRV/seguida de la dirección IP o el nombre de host de la máquina de destino. -
Expanda cada entrada coincidente y haga clic en Eliminar.
-
Cierre el Administrador de credenciales.
-
Abra Conexión a Escritorio remoto, introduzca las credenciales manualmente y conéctese.
No permita que Conexión a Escritorio remoto guarde las credenciales nuevamente mientras aún está diagnosticando. Desmarque la casilla de verificación Permitir guardar credenciales antes de conectarse, para que Windows no escriba una nueva entrada obsoleta.
Para el caso de Win11 a Win11 en la compilación 26100.6584 informado en Microsoft Q&A, agregar manualmente las credenciales de la máquina de destino mediante Panel de control > Administrador de credenciales > Credenciales de Windows > Agregar una credencial de Windows también resuelve los casos en los que la directiva de delegación de credenciales está interfiriendo.
Además, prueba con un perfil RDP nuevo ejecutando mstsc, haciendo clic en Mostrar opciones y evitando cualquier perfil de conexión guardado. Los archivos de configuración de RDP (.rdp) corruptos u obsoletos pueden reutilizar parámetros o credenciales no válidos.
Solución 3: Diagnosticar y deshabilitar la autenticación a nivel de red
NLA preautentica la sesión usando sus credenciales antes de que se cargue el escritorio remoto. Cuando el equipo de destino no puede alcanzar el controlador de dominio, cuando hay una incompatibilidad de versiones de CredSSP o cuando el tipo de cuenta es incompatible con el handshake de NLA, NLA puede fallar el handshake de autenticación y mostrar el mismo mensaje logon attempt failed en el lado del cliente. Desactivar NLA temporalmente confirma si es la causa.
-
En el equipo de destino, presione la tecla Windows + Pausa para abrir Propiedades del sistema, luego haga clic en Configuración de Acceso remoto en el panel izquierdo.
-
En la pestaña Remoto, desmarca
Permitir conexiones solo desde equipos que ejecuten Escritorio remoto con Autenticación a nivel de red. -
Haga clic en Aplicar.
-
Intente la conexión desde el equipo cliente.
Si la conexión se establece con NLA deshabilitada, el problema se encuentra dentro de la cadena de autenticación de NLA, y puedes diagnosticar más a fondo sin conjeturas. Para el acceso basado en el Registro, la configuración de NLA se almacena en:
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
El nombre del valor es UserAuthentication. Establécelo en 0 para deshabilitar NLA o en 1 para requerirla. El valor SecurityLayer en la misma ruta controla la capa de seguridad más amplia: 0 para solo seguridad de RDP, 1 para negociar, 2 para SSL.
La etapa de preautenticación de NLA es exactamente lo que falla en los escenarios de soporte con los que los técnicos de TI se topan con mayor frecuencia:
- Equipos remotos fuera de la red corporativa
- Dispositivos en los que el controlador de dominio es inaccesible
- Equipos en los que no se ha realizado ninguna configuración de TI
Si su caso de uso es el soporte remoto en lugar del acceso a sus propios equipos, HelpWire elimina por completo esta capa de la ecuación. El usuario final abre un enlace de sesión y realiza una conexión saliente sin NLA, sin necesidad de que el dominio sea alcanzable y sin ninguna configuración de cuenta por su parte.
Solución 4: Corrige el error de RDP “El intento de inicio de sesión falló” con una cuenta de Microsoft
Las cuentas de Microsoft pueden usarse para RDP, pero la autenticación puede fallar si se usa Windows Hello o un PIN en lugar de la contraseña de la cuenta, si el formato del nombre de usuario es incorrecto (por ejemplo, usar el correo electrónico en lugar de MicrosoftAccount\email en algunas configuraciones), o si se producen conflictos de almacenamiento en caché de credenciales. En estos casos, usar explícitamente la contraseña de la cuenta o una cuenta local puede ser una solución alternativa más confiable:
-
En el equipo de destino, abra Configuración y vaya a Cuentas, luego a Otros usuarios.
-
Haz clic en Agregar cuenta, luego haz clic en No tengo la información de inicio de sesión de esta persona.
-
Seleccione Agregar un usuario sin una cuenta de Microsoft.
-
Crea un nombre de usuario y una contraseña segura para la cuenta local.
-
Después de crear la cuenta, haga clic en ella en Otros usuarios, seleccione Cambiar el tipo de cuenta y configúrela como Administrador.
-
Vuelva a la Solución 1 y conceda a esta cuenta local el derecho de
Permitir iniciar sesión a través de Servicios de Escritorio remotoen la Directiva de seguridad local. -
Use el nombre de usuario y la contraseña de la cuenta local cuando se conecte a través de RDP.
En muchos casos, cambiar a una cuenta de administrador local resuelve el problema de forma más confiable, especialmente cuando la autenticación sin contraseña o basada en PIN está habilitada.
Solución 5: Solucionar “Logon Attempt Failed” de RDP después de una actualización de Windows
Se han reportado dos escenarios relacionados con actualizaciones que pueden causar este error. El primero es la corrección de la vulnerabilidad de “encryption oracle” de CredSSP introducida en la actualización de mayo de 2018 (KB4103727 y relacionadas). El segundo es KB5065426 en Windows 11 24H2 y 25H2, que rompe la autenticación de RDP en equipos con SIDs duplicados provenientes de imágenes preparadas incorrectamente con Sysprep.
Para el error de CredSSP (Se ha producido un error de autenticación. La función solicitada no es compatible), la corrección adecuada es asegurarse de que tanto el cliente como la máquina de destino estén completamente actualizados para que sus versiones de CredSSP sean compatibles. Solo como solución temporal, aplique lo siguiente en la máquina que se conecta:
-
Presiona la tecla Windows + R, escribe
gpedit.msc, y presiona Enter. -
Vaya a Configuración del equipo > Plantillas administrativas > Sistema > Delegación de credenciales.
-
Abra Corrección del oráculo de cifrado y configúrelo en Habilitado.
-
Establece el Nivel de protección en Vulnerable.
-
Ejecute
gpupdate /forceen un Símbolo del sistema con privilegios de administrador.
Esto es solo una solución temporal. La solución definitiva es actualizar la máquina de destino para que ambos lados ejecuten una versión compatible de CredSSP.
Para la regresión de KB5065426 en Windows 11 24H2 y 25H2, la solución alternativa en el Registro reportada por la comunidad intenta deshabilitar el indicador de característica introducido por esa actualización:
-
En el equipo de destino, abra el Editor del Registro presionando la tecla Windows + R y escribiendo
regedit.exe. -
Vaya a
HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides.
-
Cree un nuevo valor DWORD (32 bits) denominado
718619. -
Establece los datos en 0.
-
Reinicie la máquina de destino.
La solución permanente para este entorno es ejecutar sysprep /generalize /oobe /shutdown en la imagen base antes de cualquier despliegue.
NOTA: Esta solución alternativa del registro proviene de la comunidad y no está documentada oficialmente por Microsoft. Verifique que sea aplicable a su compilación específica antes de aplicarla.
Solución 6: Corregir el fallo de RDP al iniciar sesión en el segundo intento en entornos de dominio
En entornos de dominio, algunos usuarios encuentran que el primer intento de RDP falla pero el segundo tiene éxito, o que la cuenta se bloquea en el segundo intento. Configuraciones incorrectas de autenticación NTLM (lmcompatibilitylevel) pueden provocar fallos de autenticación en entornos de dominio o heredados donde se aplican diferentes políticas de NTLM en distintas máquinas.
La solución consiste en alinear el lmcompatibilitylevel en ambas máquinas:
-
En el controlador de dominio y en el host de RDP, presione la tecla Windows + R y escriba
regedit.exe. -
Vaya a
HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
-
Localice o cree un valor DWORD llamado
lmcompatibilitylevel. -
Establezca el valor en 5, lo que impone: Enviar únicamente la respuesta NTLMv2, rechazar LM y NTLM.
-
Reinicia ambas máquinas.
Esto corresponde a la ruta de Directiva de grupo: Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Opciones de seguridad > Seguridad de red: nivel de autenticación de LAN Manager. Establecerlo en Enviar solo respuesta NTLMv2. Rechazar LM y NTLM en ambas máquinas elimina la incompatibilidad que provoca el fallo repetido.
Uso del Visor de eventos para diagnosticar errores de autenticación de RDP
Visor de eventos en el equipo de destino es la forma más rápida de identificar exactamente qué causa raíz se aplica antes de cambiar cualquier configuración. Lo ejecuto primero en cualquier equipo donde la solución no sea inmediatamente obvia.
-
En la máquina de destino, presiona la tecla Windows + R, escribe
eventvwr.mscy presiona Enter. -
En el panel izquierdo, expanda Registros de Windows y seleccione Seguridad.
-
En el panel derecho de Acciones, haga clic en Filtrar registro actual.
-
Escriba
4625en el campo Id. de evento y haga clic en Aceptar. -
Haga clic en la entrada más reciente de Event ID 4625 y lea los detalles en el panel inferior.
Los campos Status y SubStatus dentro del evento realizan la mayor parte del trabajo de diagnóstico:
| Código de estado y subestado | Significado | Solución a aplicar |
|---|---|---|
| 0xC000006A | Nombre de usuario correcto, contraseña incorrecta | Verifica la contraseña, revisa el Administrador de credenciales |
| 0xC0000064 | El nombre de usuario no existe en el destino | Verifica el nombre exacto de la cuenta en los usuarios locales |
| 0xC0000234 | Cuenta bloqueada | Desbloquea en Active Directory o en la administración de usuarios local |
| 0xC0000072 | Cuenta deshabilitada | Habilita la cuenta en la administración de usuarios |
| 0xC000015B | Tipo de inicio de sesión no concedido | Solución 1 arriba (Agregar el derecho Permitir iniciar sesión a través de los Servicios de Escritorio remoto) |
| 0xC000006F | Cuenta restringida por horas de inicio de sesión | Revisa las propiedades de la cuenta |
| 0xC0000070 | Restricción de estación de trabajo | Cuenta limitada a equipos específicos |
Si SubStatus muestra 0x0, confíe en el código de Status en su lugar. Si Status o SubStatus muestra 0xC000015B pero la cuenta ya está en el grupo Remote Desktop Users, compruebe si una GPO a nivel de dominio está invalidando el derecho local antes de aplicar la Solución 1.
También vale la pena comprobar el campo Logon Type. Type 10 es interactivo remoto, que es lo que usa RDP. Logon Type 10 indica RDP (RemoteInteractive). Otros tipos de inicio de sesión pueden indicar rutas de autenticación diferentes o una gestión fallida de sesiones, lo que apunta a un problema de configuración de un relé o puerta de enlace de red en lugar de un problema de directiva local.
En entornos de dominio, ejecute la misma búsqueda del ID de evento 4625 en el registro Security del controlador de dominio, así como en el equipo de destino. El controlador de dominio suele registrar el rechazo de autenticación antes de que el equipo de destino lo registre, y las dos entradas juntas le muestran exactamente dónde se rompió la cadena de autenticación.
No todos los fallos de RDP generan una entrada 4625 limpia en el equipo de destino en entornos de dominio, especialmente cuando la autenticación falla antes en el controlador de dominio.
Si eso no funcionó, después de las correcciones anteriores quedan dos casos límite:
- El equipo de destino está en un estado colgado de sesión de Remote Desktop Services. Tras un corte de energía inesperado o una desconexión forzada, TermService puede entrar en un estado que rechaza nuevas autenticaciones. Un reinicio completo del equipo de destino lo corrige. Si tiene una vía alternativa de acceso al equipo, puede reiniciar solo Remote Desktop Services a través de
services.mscsin un reinicio completo. - Una Directiva de grupo a nivel de dominio o de unidad organizativa aplica un derecho Deny logon through Remote Desktop Services a su cuenta, lo que anula cualquier derecho Allow inferior. Ejecute
rsop.mscen el equipo de destino y navegue aComputer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
Si su cuenta aparece tanto enAllow log on through Remote Desktop Servicescomo enDeny log on through Remote Desktop Services, la opción Deny prevalece independientemente de la pertenencia a grupos. Debe quitar la cuenta de la entrada Deny en el nivel de directiva donde se aplica, lo que requiere acceso a la Group Policy Management Console.
Causas del error de RDP por intento de inicio de sesión fallido
6 causas raíz representan la inmensa mayoría de los casos que he visto y se reportan comúnmente en la documentación de Microsoft, los foros de la comunidad y la solución de problemas en campo.
| Cadena de error | Causa raíz | Entorno |
|---|---|---|
El intento de inicio de sesión falló. |
Falta el derecho de la directiva Permitir iniciar sesión a través de Servicios de Escritorio remotoFormato de nombre de usuario incorrecto (local vs. dominio) |
Grupo de trabajo o dominio |
Sus credenciales no funcionaron. El intento de inicio de sesión falló. |
Credenciales obsoletas o en conflicto en el Administrador de credenciales | Todos los entornos |
Credenciales de inicio de sesión no válidas. |
Problemas con las credenciales de la cuenta de Microsoft en algunos escenarios de RDP (a menudo debido a una discrepancia entre contraseña/PIN o al manejo de credenciales) | Windows 11 |
Se ha producido un error de autenticación. La función solicitada no es compatible. |
Desajuste de seguridad CredSSP/NLA entre el cliente y el destino (a menudo después de actualizaciones o cuando una de las partes no está completamente actualizada) | Tras una actualización, todos |
Se ha producido un error de autenticación. No se puede contactar con la Autoridad de seguridad local. |
Fallo de NLA con el controlador de dominio inaccesible | Redes de dominio |
Error de inicio de sesión: no se ha concedido al usuario el tipo de inicio de sesión solicitado en este equipo. |
A la cuenta se le negó explícitamente el derecho de inicio de sesión de RDS mediante Directiva de grupo | Directiva de dominio o local |
NOTA: En entornos mixtos, el formato incorrecto del nombre de usuario (por ejemplo, un nombre de usuario local en lugar de DOMAIN\username, o viceversa) provoca un fallo de autenticación inmediato incluso cuando la contraseña es correcta.
El error también puede aparecer al conectarse al host equivocado (por ejemplo, si el DNS resuelve a una máquina diferente) o cuando el Escritorio remoto no está habilitado correctamente en el destino.
La mayoría de estas causas se remontan a la forma en que RDP apila sus capas de autenticación antes de que sea visible un solo píxel del escritorio remoto. Ese diseño tiene sentido para un protocolo de red corporativo. Pero para los técnicos de TI que brindan soporte remoto en dispositivos que no controlan por completo, esas capas son una fuente inevitable de fallos de sesión. HelpWire está diseñado para ese caso de uso específico. Solo inicias una sesión enviando un enlace, y el usuario final se conecta sin ninguna configuración de cuenta por su parte. Además, el acceso desatendido te permite realizar trabajo de seguimiento sin obligarte a volver a pasar por la cadena de autenticación.
¿Por qué RDP muestra “Remote Desktop Connection Logon Attempt Failed” incluso con la contraseña correcta?
Las credenciales correctas no anulan la ausencia de un derecho de directiva. El derecho Permitir iniciar sesión a través de Servicios de Escritorio remoto en la Directiva de seguridad local es un control separado de los privilegios de administrador local. Si tu cuenta no está incluida bajo ese derecho en la máquina de destino, Windows rechaza la conexión antes de confirmar si la contraseña es válida. He visto a personas restablecer su contraseña dos veces, agregar su cuenta al grupo de Administradores locales y aun así toparse con el mismo error, porque ninguna de esas acciones afecta esa configuración de directiva.
La segunda causa silenciosa es el Administrador de credenciales en la máquina que se conecta. Windows almacena credenciales de RDP vinculadas al nombre de host o a la dirección IP del destino. Si esas credenciales guardadas están desactualizadas o pertenecen a otra cuenta, Windows puede aplicar automáticamente las credenciales almacenadas para el destino antes de pedírtelas, según cómo esté guardada la entrada. Ves el error, asumes que la contraseña es incorrecta, la cambias y te topas con el mismo muro de nuevo. En algunos casos, las credenciales almacenadas en el Administrador de credenciales prevalecen sobre la entrada manual, especialmente después de cambios de contraseña.
El bloqueo de cuenta es una tercera causa que se pasa por alto en entornos de grupo de trabajo. Si otro dispositivo, una credencial guardada obsoleta en un navegador o una sesión de RDP desconectada está probando credenciales antiguas contra la misma cuenta, la cuenta se bloquea antes de que abras Conexión a Escritorio remoto. Comprobar el panel de administración de usuarios locales de la máquina de destino en Administración de equipos lo confirma en menos de 30 segundos.
Lo que la mayoría de las personas intenta primero tras “Remote Desktop Login Failed” (y por qué no funciona)
Deshabilitar el Firewall de Windows es el primer movimiento instintivo. Las reglas del firewall controlan si la conexión TCP 3389 llega siquiera al destino. Si llegas a la solicitud de credenciales, normalmente el firewall no es la causa.
Agregar la cuenta al grupo local Administradores es el segundo instinto. Los privilegios de administrador no otorgan el derecho de inicio de sesión de Servicios de Escritorio remoto. Son controles independientes. Puedes ser administrador local y aun así quedar bloqueado en RDP si falta ese derecho de directiva.
Probar distintos formatos de nombre de usuario sin leer primero el Visor de eventos es pura conjetura. DOMAIN\user, user@domain.com y el nombre de usuario a secas pueden representar la misma cuenta. Sin Event ID 4625 delante de ti, no tienes base para saber qué está fallando realmente.
Ejecutar el cliente de Conexión a Escritorio remoto como administrador en el equipo que se conecta no tiene efecto. La autenticación se valida frente a la directiva de seguridad del equipo de destino, no la del cliente.
Además, verifica que el Escritorio remoto esté habilitado en el equipo de destino y que la edición de Windows admita conexiones de host de RDP (Windows Home no lo hace).
Preguntas frecuentes
NLA autentica la sesión antes de que se cargue el escritorio remoto. Cuando la máquina de destino no puede comunicarse con el controlador de dominio, o cuando hay una discrepancia de versiones de CredSSP entre el cliente y el destino, NLA puede finalizar el intento de autenticación antes de que se inicie la sesión. Esto a menudo se manifiesta como el mensaje The logon attempt failed en el lado del cliente. Deshabilitar temporalmente NLA en la máquina de destino en la pestaña Propiedades del sistema > Remoto confirma si NLA es la causa.
Ejecute rsop.msc en el equipo de destino y vaya a Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Asignación de derechos de usuario. Si la cuenta afectada aparece en Deny log on through Remote Desktop Services, esa entrada anula todos los derechos de Permitir y debe eliminarse en el nivel de Directiva de grupo donde se está aplicando, mediante la Consola de administración de directivas de grupo.
A partir de la actualización de Windows de abril de 2026 (KB5083769), Microsoft añadió advertencias obligatorias antes de que los archivos .rdp se conecten, solicitando a los usuarios que confirmen qué recursos locales compartir. Es una función de seguridad para prevenir ataques de suplantación de identidad, pero puede parecer repetitiva si el cuadro de diálogo no guarda las preferencias. Establecer RedirectionWarningDialogVersion en 1 revierte el comportamiento del cuadro de diálogo al anterior a abril de 2026 como solución temporal, aunque las mejoras de seguridad subyacentes permanecen activas.
Consejo profesional: Configura una cuenta local de administrador dedicada para el acceso por RDP en cada equipo que administres de forma remota antes de necesitarla. Asígnale una contraseña segura almacenada en un gestor de contraseñas y concédele el derecho Allow log on through Remote Desktop Services en el momento de la configuración. Cuando el controlador de dominio se caiga, NLA falle tras una actualización o la cuenta principal tenga un conflicto de directivas, esa cuenta local será la única vía de acceso al equipo que evita toda la cadena de autenticación descrita en este artículo.
Si administras archivos .rdp para los usuarios, considera firmarlos con PowerShell después de la actualización de abril de 2026 para evitar advertencias de confianza repetidas. Los archivos .rdp sin firmar activarán la nueva advertencia de suplantación en cada ejecución en Windows 11 con KB5083769 o posterior.
Si el error de intento de inicio de sesión fallido está bloqueando tu única vía de acceso a la máquina, y no tienes acceso a la consola, ni una cuenta local alternativa, y no hay nadie en el sitio para cambiar la configuración, la resolución de problemas estándar de RDP se topa con un muro. No puedes abrir secpol.msc, limpiar el Administrador de credenciales o deshabilitar NLA en una máquina en la que no puedes iniciar sesión.
En este escenario, HelpWire ofrece una salida práctica. El usuario final abre un enlace de sesión, sin configuración de cuenta, sin proceso de autenticación NLA y sin necesidad de conectividad al dominio de su lado. Una vez que la sesión está activa, puedes aplicar cualquiera de las soluciones de este artículo desde dentro de la máquina y restaurar RDP para uso futuro.