Cuando Windows muestra que la conexión fue denegada porque la cuenta de usuario no está autorizada para el inicio de sesión remoto, la contraseña no es el problema. Fue aceptada; la sesión fue rechazada un paso después, en la autorización.
Dos comprobaciones determinan ese resultado: la cuenta debe pertenecer al grupo local Usuarios de Escritorio remoto o al grupo de Administradores, y debe aparecer en la directiva Permitir iniciar sesión a través de Servicios de Escritorio remoto en secpol.msc. Si falta cualquiera de ellas, este es el error que obtendrás.
Hay una configuración que prevalece sobre ambas: Denegar iniciar sesión a través de Servicios de Escritorio remoto. Si la cuenta, o cualquier grupo al que pertenezca, está en esa lista, quedará bloqueada sin importar qué más esté configurado.
En equipos unidos a un dominio hay una cuarta capa. La Directiva de Grupo desde el nivel del dominio o de la UO puede restablecer silenciosamente la configuración local en la siguiente actualización, deshaciendo una corrección que parecía concluida hace unos minutos.
Empieza por la pertenencia a grupos; es la causa más común.
Ruta de corrección rápida
Si desea comenzar de inmediato sin leer la explicación completa, siga estos pasos en orden y deténgase cuando el error se resuelva.
-
Agregue la cuenta al grupo local Usuarios de Escritorio remoto en el equipo de destino.
-
Abra secpol.msc y confirme que el grupo de la cuenta aparece en Permitir iniciar sesión a través de Servicios de Escritorio remoto.
-
En la misma ubicación, comprueba Denegar inicio de sesión a través de Servicios de Escritorio remoto y confirma que la cuenta no esté en la lista allí.
-
Si el equipo está unido a un dominio, comprueba la GPO del dominio en GPMC, no solo la directiva local en secpol.msc.
-
Elimine las credenciales guardadas obsoletas del Administrador de credenciales solo después de confirmar que las configuraciones de directiva indicadas arriba son correctas.
Lo que reportan los usuarios reales sobre este error
La queja más común en los foros: todo parece correcto y, aun así, el error persiste. Un administrador de dominio en Microsoft Q&A describió una estación de trabajo con Windows 11 que rechazaba todas las conexiones RDP de usuarios no administradores a pesar de la pertenencia correcta a los grupos y de un secpol.msc local aparentemente correcto. El verdadero bloqueo era una GPO a nivel de dominio que reemplazaba silenciosamente la configuración local. (Microsoft Q&A, septiembre de 2024)
En las máquinas virtuales de Azure, un problema relacionado aparece como un bucle: se agrega manualmente una cuenta, las sesiones funcionan, luego la cuenta desaparece tras un reinicio y el error vuelve. La causa era una GPO de Grupos restringidos que eliminaba la pertenencia en cada actualización de directivas, y ninguna corrección desde la interfaz se mantiene hasta que se actualiza la propia GPO. (Comunidad técnica de Microsoft, junio de 2023)
Las credenciales guardadas son un desencadenante menos obvio. Un grupo de RDS que había funcionado durante años de repente comenzó a rechazar a todos los usuarios con este error. Los permisos no habían cambiado. Eliminar la contraseña guardada y volver a introducirla manualmente lo solucionó de inmediato, confirmado por varios usuarios en el mismo hilo. (Microsoft Q&A, octubre de 2022)
En las VM de Azure unidas al dominio, un administrador que gestionaba 1,000 usuarios agregó cuentas a la directiva Permitir iniciar sesión a través de Servicios de Escritorio remoto, ejecutó gpupdate /force y aún así se topó con el error. El paso que faltaba era agregar usuarios al grupo local Usuarios de escritorio remoto en la propia VM. Se requieren ambas comprobaciones. (Microsoft Q&A, noviembre de 2022)
En entornos administrados con Intune, lusrmgr.msc no muestra el dominio de Azure como una ubicación disponible, por lo que la solución estándar basada en pertenencia a grupos no aplica. Una directiva de configuración de Intune correcta no es suficiente por sí sola. Se requiere una directiva independiente que apunte al derecho Permitir iniciar sesión a través de Servicios de Escritorio remoto para los dispositivos unidos a Entra. (Microsoft Q&A, diciembre de 2024)
Cómo solucionar la conexión fue denegada porque la cuenta de usuario no está autorizada para el inicio de sesión remoto
Solución 1: Agregar al usuario al grupo Usuarios de Escritorio remoto
La falta de pertenencia a un grupo es la causa más común de este error en equipos independientes. Ejecute estos pasos en el PC remoto, no en el equipo desde el que se conecta. Tenga en cuenta que lusrmgr.msc no está disponible en las ediciones Home de Windows, aunque las ediciones Home tampoco pueden actuar como hosts de RDP.
-
Presiona Win + R, escribe lusrmgr.msc, y presiona Enter.
-
Seleccione Grupos en el panel izquierdo, luego haga doble clic en Usuarios de Escritorio remoto.
-
Haga clic en Agregar.
-
Escriba el nombre de usuario, haga clic en Comprobar nombres para confirmar que se resuelve correctamente y luego haga clic en Aceptar.
-
Haga clic en Aceptar para cerrar la ventana de propiedades del grupo.
Para una alternativa más rápida mediante Propiedades del sistema: presiona Win + R, escribe sysdm.cpl, selecciona la pestaña Remoto, haz clic en Seleccionar usuarios y agrega allí la cuenta.
Desde una consola de PowerShell con privilegios elevados en la máquina remota:
Add-LocalGroupMember -Group “Remote Desktop Users” -Member “username”
Reemplaza username con el nombre real de la cuenta. No es necesario reiniciar.
Solución 2: Verifique la directiva Permitir iniciar sesión a través de Servicios de Escritorio remoto
La pertenencia al grupo y la directiva de derechos de usuario se comprueban de forma independiente. Ambas deben cumplirse, y corregir una sin la otra deja el error en su lugar. Ejecute estos pasos en el PC remoto.
-
Presiona Win + R, escribe secpol.msc y presiona Enter.
-
Vaya a Configuración de seguridad > Directivas locales > Asignación de derechos de usuario.
-
Haga doble clic en Permitir iniciar sesión a través de Servicios de Escritorio remoto.
-
Confirme que tanto Usuarios de Escritorio remoto como Administradores estén en la lista. Si falta alguno, haga clic en Agregar usuario o grupo, escriba el nombre del grupo y haga clic en Aceptar.
-
Haga clic en Aceptar y luego ejecute lo siguiente desde un Símbolo del sistema con privilegios de administrador: gpupdate /force
En un equipo unido a un dominio, un GPO de dominio en conflicto puede sobrescribir esta configuración en cuestión de minutos tras guardarla. Si la configuración se revierte, vaya a la Solución 4.
Solución 3: Comprueba si hay una política de denegación que anule la configuración de permitir
La directiva Denegar el inicio de sesión a través de Servicios de Escritorio remoto bloquea el acceso independientemente de la pertenencia a grupos o de la directiva Permitir. Compruebe esto incluso cuando la configuración de Permitir parezca completa.
-
En secpol.msc, navegue a Configuración de seguridad > Directivas locales > Asignación de derechos de usuario.
-
Haga doble clic en Denegar iniciar sesión a través de Servicios de Escritorio remoto.
-
Revise la lista. Si la cuenta que se conecta o cualquier grupo al que pertenece, incluidos Invitados o Invitados del dominio, aparece aquí, selecciónelo y haga clic en Quitar.
-
Haga clic en Aceptar, luego ejecute gpupdate /force.
Si la configuración sigue revirtiéndose después de guardarla y ejecutar gpupdate /force, una GPO de dominio está controlandSi la configuración sigue revirtiéndose después de guardarla y ejecutar gpupdate /force, una GPO de dominio está controland a nivel de dominio. Administra esta directiva únicamente a través de la Directiva de seguridad local o de la Administración de directivas de grupo. Evita intentar editar las asignaciones de derechos de usuario directamente en el Registro, ya que los derechos de inicio de sesión Permitir y Denegar son administrados por Windows como constantes de privilegio con nombre (SeRemoteInteractiveLogonRight y SeDenyRemoteInteractiveLogonRight), no como valores simples del Registro. Para auditoría, usa secpol.msc, gpresult o secedit.
Solución 4: Abordar directamente la GPO del dominio
En un equipo unido a un dominio donde los cambios locales se siguen revirtiendo, una GPO de dominio los está sobrescribiendo. Esta solución requiere acceso a la Consola de administración de directivas de grupo, normalmente disponible en un controlador de dominio o en un equipo con RSAT instalado.
-
Abra GPMC desde Administrador del servidor > Herramientas > Administración de directivas de grupo.
-
Expanda el dominio, haga clic con el botón derecho en el GPO que controla el equipo afectado, y seleccione Editar.
-
Vaya a Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Asignación de derechos de usuario.
-
Abra Permitir el inicio de sesión a través de Servicios de Escritorio remoto y confirme que Usuarios de Escritorio remoto y Administradores están ambos en la lista.
-
Abra Denegar el inicio de sesión a través de los Servicios de Escritorio remoto y confirme que la cuenta afectada y sus grupos no figuran en la lista.
-
Guarde los cambios y luego ejecute lo siguiente en el equipo afectado: gpupdate /force
Si la GPO relevante no es inmediatamente evidente, ejecute esto en el equipo afectado y abra el archivo resultante para identificar qué directiva está controlando la Asignación de derechos de usuario:
gpresult /h gpreport.html
Solución 5: Eliminar las credenciales guardadas obsoletas del Administrador de credenciales
Esta es una causa menos común, pero vale la pena comprobarla después de confirmar que la pertenencia a los grupos y la configuración de las directivas son correctas. Las credenciales de RDP guardadas pueden quedar obsoletas tras un cambio de contraseña, una migración de cuenta o cambios en un grupo de RDS. En algunos casos, esto produce fallos de inicio de sesión que se asemejan a errores de autorización. La solución, documentada en un hilo de Microsoft Q&A en el que un grupo de RDS con años de credenciales guardadas de repente empezó a fallar para todos los usuarios, fue borrar la entrada almacenada y volver a introducir las credenciales manualmente.
-
Abra el Panel de control, vaya a Cuentas de usuario y luego haga clic en Administrador de credenciales.
-
Seleccione las credenciales de Windows.
-
Busque entradas que comiencen con TERMSRV/ seguidas del nombre del equipo o de la dirección IP del equipo remoto.
-
Expanda cada entrada relevante y haga clic en Eliminar.
-
Cierre el Administrador de credenciales y vuelva a intentar la conexión RDP, introduciendo las credenciales manualmente cuando se le solicite.
Solución 6: Usa HelpWire como alternativa gratuita mientras solucionas RDP
Si el error de autorización está bloqueando el acceso a una máquina que necesita ahora mismo, HelpWire le ofrece una conexión remota funcional mientras resuelve la configuración de las directivas. No utiliza el servicio de Escritorio remoto de Windows ni el puerto 3389, por lo que los problemas de pertenencia a grupos y derechos de usuario que provocan el error “cuenta de usuario no autorizada” no lo afectan.
HelpWire funciona en Windows, macOS y Linux y es de uso gratuito. La configuración toma unos minutos: instale el cliente del operador en su equipo, instale el agente de HelpWire en la máquina remota y conéctese. Para el acceso desatendido a una máquina que administra, el agente puede configurarse para ejecutarse como un servicio en segundo plano sin requerir que alguien en el extremo remoto acepte cada conexión.
Preguntas frecuentes
Las cuentas de administrador pertenecen al grupo local Administradores, que Windows siempre incluye en la directiva Permitir iniciar sesión a través de Servicios de Escritorio remoto. Las cuentas de usuario estándar no se agregan de forma predeterminada al grupo Usuarios de Escritorio remoto ni a la directiva Permitir iniciar sesión a través de Servicios de Escritorio remoto, por lo que se les deniega el acceso hasta que ambos se configuren explícitamente.
Sí. Las configuraciones de GPO de dominio aplicadas a nivel de dominio, sitio u OU sobrescriben las configuraciones locales de secpol.msc en cada actualización de Directiva de grupo. Si una corrección local sigue revirtiéndose, hay una GPO en conflicto activa. Utilice GPMC para resolverlo a nivel de dominio y ejecute gpresult /h gpreport.html en el equipo afectado para identificar qué directiva controla la Asignación de derechos de usuario.
Bloquea cualquier cuenta incluida en ella, o cualquier grupo que contenga esa cuenta, para que no se conecte mediante RDP. La directiva de denegación anula tanto la configuración Permitir iniciar sesión mediante Servicios de Escritorio remoto como la pertenencia al grupo Usuarios de Escritorio remoto. Las cuentas pueden acabar en un grupo de denegación por accidente, por ejemplo por pertenecer al grupo Invitados, que muchos entornos reforzados incluyen en la directiva de denegación de forma predeterminada.
“La conexión fue denegada porque la cuenta de usuario no está autorizada para el inicio de sesión remoto” significa que la solicitud de sesión llegó al equipo de destino y fue rechazada en la capa de autorización, normalmente debido a la falta de pertenencia a un grupo, una brecha en la directiva de derechos de usuario o una directiva de denegación activa. “Acceso denegado” es más amplio y también puede indicar restricciones de Credential Guard, limitaciones de acceso al SAM o problemas generales de permisos no relacionados específicamente con los derechos de inicio de sesión remoto. La distinción importa porque apuntan a diferentes rutas de solución de problemas.
