Pocas cosas resultan más frustrantes que sentarte a conectarte de forma remota a tu propio PC, escribir tus credenciales y que te digan, de la forma menos útil posible, que “una restricción de cuenta de usuario (por ejemplo, una restricción de hora del día) te impide iniciar sesión”.

¿Una restricción de hora del día? Yo mismo configuré este equipo.

Ese era yo, sin poder acceder a un servidor Windows una hora después de migrarlo a un nivel funcional de dominio más reciente. Tras revisar la documentación de Microsoft y foros de administradores de sistemas, finalmente averigüé qué había salido mal, y no era en absoluto lo que sugería el mensaje de error.

Esto es lo que nadie te dice de entrada: este error no es un único problema, es una categoría. La causa puede ser cualquier cosa, desde una cuenta sin contraseña hasta que la ruta de autenticación vuelva silenciosamente a NTLM cuando solo se permite Kerberos. Una vez que entiendes eso, ya estás a medio camino de solucionarlo.

Una restricción de la cuenta de usuario está impidiendo iniciar sesión

Tabla de contenidos

Síntoma / Causa	Entorno	Primera acción	Frecuencia
En blanco / sin contraseña en la cuenta local	PC independiente / doméstico	Solución 1 — Establecer una contraseña	Común
La cuenta no está en el derecho Permitir inicio de sesión por RDP	Cualquiera	Solución 2 — Comprobar la asignación de derechos de usuario	Común
La cuenta está en el derecho Denegar inicio de sesión por RDP	Cualquiera	Solución 2 — Quitar de la directiva de denegación	Común
Conexión por IP, NTLM restringido	Dominio	Solución 3 — Usar el nombre de host FQDN	Común
Cuenta bloqueada	Cualquiera	Solución 4 — Desbloquear en ADUC / lusrmgr	Ocasional
Restricción de horario de inicio de sesión	Dominio	Solución 4 — Comprobar las horas de inicio de sesión en ADUC	Ocasional
Cuenta en Usuarios protegidos, Kerberos no funciona	Dominio	Solución 5 — Reparar Kerberos o quitar del grupo	Admin/endurecido
Los registros de eventos muestran fallo de autenticación	Cualquiera	Solución 6 — Leer el registro de Seguridad (Evento 4625)	Diagnóstico

La corrección que necesita depende por completo de su entorno. Repase estas preguntas antes de tocar nada.

¿Puede iniciar sesión localmente con la misma cuenta? Si es así, y solo falla RDP, no se trata de credenciales incorrectas. El problema es una asignación de derechos de RDP, una restricción de directiva o un problema en la ruta de autenticación. Compruebe en el Visor de eventos → Registros de Windows → Seguridad del equipo de destino el Id. de evento 4625. En entornos de dominio, compruebe también los registros de seguridad del controlador de dominio, ya que algunos errores de autenticación solo son visibles allí.

¿Un usuario o todos? Un solo usuario bloqueado apunta a una configuración a nivel de cuenta. Todos bloqueados simultáneamente sugiere un cambio reciente de directiva, una actualización de Directiva de grupo o un cambio de configuración del lado del servidor.

¿Equipo independiente o unido a un dominio? Los entornos de dominio introducen Directivas de grupo de Active Directory, Kerberos, restricciones de NTLM y comportamiento de Usuarios protegidos. Si está en un PC doméstico independiente, probablemente solo sean relevantes las Correcciones 1, 2 y 4. Si está en un dominio, pueden aplicarse todas las correcciones.

¿Se está conectando por dirección IP o por nombre de host? Esto importa más de lo que la mayoría se da cuenta. Conectarse por dirección IP normalmente impide que Windows use Kerberos y obliga a recurrir a NTLM. Si NTLM está restringido en su entorno, esa alternativa falla y obtendrá este error exacto, aunque nada en su cuenta real haya cambiado. Consulte la Corrección 3.

¿Cambió algo recientemente? Las actualizaciones de Directiva de grupo, los parches del sistema operativo, las actualizaciones del nivel funcional del dominio y el endurecimiento de la seguridad pueden romper RDP de la noche a la mañana sin advertencia visible. Plantee siempre esta pregunta antes de suponer que el problema es su cuenta.

Las correcciones 1–4 son las más relevantes aquí. Estas no requieren Active Directory ni conocimientos sobre dominios.

Empiece aquí, especialmente en un PC doméstico o una máquina independiente.

De forma predeterminada, Windows bloquea los inicios de sesión remotos para las cuentas locales que no tienen contraseña. Esto es intencional y es una directiva de seguridad documentada: la configuración “Cuentas: Limitar el uso de contraseñas en blanco de las cuentas locales solo al inicio de sesión en la consola” está habilitada de forma predeterminada, lo que significa que las cuentas sin contraseña están restringidas a inicios de sesión interactivos en la consola. RDP es un inicio de sesión interactivo remoto y, por lo tanto, está bloqueado.

Por qué sucede esto: Microsoft documenta este comportamiento en la configuración de la directiva de seguridad local “Cuentas: limitar el uso de contraseñas en blanco de las cuentas locales solo para iniciar sesión en la consola.” (Microsoft Learn)

Establece una contraseña: abre Administración de equipos → Usuarios y grupos locales → Usuarios → haz clic con el botón derecho en la cuenta → Establecer contraseña. Si con eso se soluciona, habrás terminado.

Hay una solución alternativa: puedes deshabilitar la restricción de contraseñas en blanco mediante secpol.msc o la clave del registro LimitBlankPasswordUse. Trátalo como último recurso en cualquier equipo accesible desde la red.

Advertencia: Desactivar las restricciones para contraseñas en blanco debilita significativamente su postura de seguridad. Establecer una contraseña segura siempre es la solución correcta.

Esta es una de las causas más comunes y una de las más fáciles de pasar por alto.

Windows utiliza dos configuraciones de Directiva de grupo complementarias para controlar el acceso a RDP:

Permitir iniciar sesión a través de Servicios de Escritorio remoto — otorga el derecho a conectarse.
Denegar iniciar sesión a través de Servicios de Escritorio remoto — bloquea el derecho a conectarse.

La directiva Denegar siempre tiene prioridad sobre Permitir, independientemente de la pertenencia a grupos. Este es un comportamiento documentado por Microsoft.

Dónde encontrarlo: Abra gpedit.msc → Configuración del equipo → Configuración de Windows → Configuración de seguridad → Directivas locales → Asignación de derechos de usuario.

Comprueba ambas directivas. Confirma que tu cuenta, o un grupo al que pertenece, como Usuarios de Escritorio remoto o Administradores, aparece en Permitir. Confirma que no aparece en Denegar. Si tu cuenta falta por completo en Permitir, el acceso RDP está bloqueado independientemente de tu contraseña o credenciales.

En equipos de dominio: Estos derechos pueden establecerse a nivel de dominio mediante Directiva de Grupo y pueden anular la configuración local. Si la configuración local parece correcta pero el problema persiste, verifica si hay GPO en conflicto usando gpresult /h report.html en el equipo de destino.

Este único cambio resuelve más problemas de los que debería.

Cuando te conectas usando una dirección IP (por ejemplo, 192.168.1.100), Windows normalmente no puede usar la autenticación Kerberos y recurre a NTLM. En equipos domésticos independientes esto suele estar bien. En equipos unidos a un dominio donde NTLM está restringido o deshabilitado, esta conmutación por error falla silenciosamente, y obtienes el error de restricción de cuenta, aunque nada en tu cuenta haya cambiado.

Usa el nombre de host de la máquina en su lugar:

server.yourdomain.com ✔ Recomendado

192.168.1.100 ✘ Fuerza el recurso a NTLM

Usa también credenciales en formato UPN al conectarte a equipos del dominio: user@domain.com en lugar de DOMAIN\user. Esto ayuda a Windows a seleccionar la ruta de autenticación correcta y evita un número sorprendente de casos límite.

Excepción: Microsoft ha documentado una funcionalidad más reciente de Kerberos sobre IP para entornos de Windows Server, pero requiere una configuración explícita y no está habilitada de forma predeterminada. (Microsoft Learn: Configuración de Kerberos para la dirección IP).

Windows devuelve el mismo mensaje genérico para varios tipos de restricción distintos, lo cual es parte de lo que hace que este error sea tan frustrante. Los bloqueos de cuenta y las restricciones de horario de inicio de sesión son dos de los pocos casos en los que el mensaje de error es literalmente exacto.

Para cuentas locales (independientes o de dominio) Abra lusrmgr.msc → seleccione el usuario → compruebe si La cuenta está bloqueada está marcada. Desbloquéela si es así.

Para cuentas de dominio Abra Usuarios y equipos de Active Directory → busque al usuario → haga doble clic → pestaña Cuenta. Seleccione Desbloquear cuenta y revise las Horas de inicio de sesión.

Un administrador de Windows Server 2016 describió toparse exactamente con este obstáculo: la conexión al servidor fallaba con el mensaje de restricción de cuenta, pero no se habían configurado deliberadamente restricciones de horario. La causa fue una Directiva de grupo que había aplicado silenciosamente una restricción de inicio de sesión tras una actualización de la directiva de dominio. El Id. de evento 4625 en el registro de Seguridad habría mostrado el subcódigo específico.

Evento 4625: La entrada del registro de seguridad para un inicio de sesión fallido incluye un código de subestado que identifica el motivo exacto. Valores comunes: 0xC0000234 (cuenta bloqueada), 0xC000006F (inicio de sesión fuera del horario permitido), 0xC0000022 (acceso denegado). Comprueba esto antes de suponer la causa.

Las soluciones 5 y 6 requieren acceso a Active Directory y familiaridad con Kerberos y NTLM. Si utiliza un PC doméstico independiente, puede omitir esta sección.

Este es el modo de fallo que toma por sorpresa a administradores experimentados, a menudo después de una actualización de dominio.

El grupo de seguridad Usuarios protegidos de Active Directory impone reglas de autenticación más estrictas a sus miembros:

La autenticación NTLM está completamente bloqueada.
Solo se permite Kerberos, y únicamente con cifrado AES.
Los tipos de cifrado de Kerberos RC4 y DES no están permitidos.
Las credenciales no se almacenan en caché en el equipo.

Sobre el papel, esto es una excelente práctica de seguridad. En la práctica, esto rompe el acceso por RDP en entornos que dependían silenciosamente de NTL, que es exactamente lo que sucede cuando se conecta por dirección IP, cuando DNS está mal configurado o cuando Kerberos no se ha validado completamente después de una actualización de dominio. El usuario recibe el mensaje genérico de restricción de cuenta sin ninguna indicación de que Usuarios protegidos esté involucrado.

Por qué aparece después de las actualizaciones de dominio: Elevar el nivel funcional del dominio a menudo permite una aplicación más estricta de las políticas existentes. Las cuentas que ya estaban en Usuarios protegidos pero que antes toleraban reversiones a NTLM pueden fallar repentinamente. (Microsoft Learn: Grupo de seguridad Usuarios protegidos)

Antes de quitar a alguien de Protected Users, prueba estos pasos en este orden:

Usa el FQDN de la máquina (server.domain.com), no una dirección IP.
Usa credenciales UPN (user@domain.com).
Verifica que la resolución DNS funcione correctamente desde la máquina que se conecta.
Confirma la conectividad con el controlador de dominio y que el servicio de Kerberos esté en ejecución.

Si Kerberos está funcionando correctamente, el problema suele desaparecer sin realizar ningún cambio en la cuenta. Si no, puedes quitar la cuenta de Protected Users como medida temporal:

powershell
$Cred = Get-Credential Remove-ADGroupMember -Identity "Protected Users" -Members YourAccountName -Credential $Cred

Acerca de PowerShell Remoting: Este enfoque funciona cuando PowerShell Remoting está disponible. Tenga en cuenta que PowerShell Remoting también usa Kerberos cuando está disponible y NTLM como respaldo, por lo que puede enfrentar las mismas restricciones de autenticación en entornos totalmente endurecidos. (Microsoft Learn: Seguridad de WinRM)

Advertencia: Quitar una cuenta de Usuarios protegidos debilita su postura de seguridad. Considere esto como un paso de diagnóstico, no una solución permanente. La solución correcta es garantizar que Kerberos funcione correctamente en su entorno.

Cierra la sesión y permite que la autenticación se actualice antes de volver a intentar RDP tras cualquier cambio en la pertenencia a grupos.

En este punto, deje de adivinar y empiece a leer.

En la máquina de destino Visor de eventos → Registros de Windows → Seguridad. Filtre por ID de evento 4625. Cada entrada incluye un Motivo del error y un código de Subestado que identifica la causa exacta, con mucha más precisión que el propio mensaje de error de RDP.

Para un rastreo de autenticación más profundo, habilite también: Registros de aplicaciones y servicios → Microsoft → Windows → Autenticación.

En los controladores de dominio Algunas fallas de autenticación, especialmente las relacionadas con Kerberos, solo se registran en el controlador de dominio que procesó la solicitud, no en la máquina de destino. Revise los registros de Seguridad en sus DC cuando los registros locales del destino no le ofrecen el panorama completo.

Una vez que encuentre el código de Subestado en el evento 4625, el error deja de ser vago y se convierte en un problema específico y diagnosticable. Los códigos comunes están enumerados en la nota de la Solución 4 anterior.

Si ves el código de error 0xC07, particularmente en macOS usando Microsoft Remote Desktop, normalmente aparece junto con la misma clase de problemas de autenticación y restricciones descritos en este artículo. Los informes de la comunidad sugieren que conectarse por nombre de host en lugar de dirección IP lo resuelve en muchos casos, lo cual es coherente con el patrón de conmutación a NTLM descrito en la Solución 3.

No existe documentación definitiva de Microsoft que relacione claramente 0xC07 con una única causa raíz. Trátalo como una señal de que estás en la categoría correcta de problema más que como un diagnóstico preciso. Se aplican las soluciones anteriores.

Cuando se deniega el acceso RDP con el mensaje de “restricción de cuenta de usuario”, Windows está haciendo exactamente lo que se supone que debe hacer, solo que sin decirte qué regla has infringido.

La vía más rápida para resolverlo es:

Usa la matriz de diagnóstico al principio de este artículo para identificar la causa más probable.
Aplica la solución correspondiente a tu entorno (hogar/independiente o dominio).
Comprueba el Id. de evento 4625 en el equipo de destino si la causa sigue sin estar clara.
En entornos de dominio, verifica también los registros del controlador de dominio y confirma que Kerberos funciona correctamente antes de cambiar la configuración de la cuenta.

La mayoría de las veces es algo sencillo. Incluso cuando no lo es, suele ser algo lógico, simplemente oculto detrás de un mensaje muy poco útil.

Cómo solucionar la restricción de la cuenta de usuario que impide iniciar sesión

Diagnóstico rápido

Parte 1: PC doméstico & máquinas independientes

Solución 1: La cuenta no tiene contraseña

Solución 2: Verifique quién tiene permiso para conectarse mediante RDP

Solución 3: Deja de conectarte por dirección IP

Solución 4: Compruebe si hay bloqueos de cuenta y restricciones de horario de inicio de sesión

Parte 2: Entornos de dominio & empresariales

Solución 5: El grupo de usuarios protegidos

Solución 6: Lee los registros cuando nada más tenga sentido

¿Qué hay del código de error 0xC07?

Resumen