Quando o Windows exibe que a conexão foi negada porque a conta de usuário não está autorizada para logon remoto, a senha não é o problema. Ela foi aceita; a sessão foi rejeitada uma etapa depois, na autorização.
Duas verificações determinam esse resultado: a conta precisa pertencer ao grupo local Usuários da Área de Trabalho Remota ou ao grupo Administradores, e precisa constar na política Permitir logon por Serviços de Área de Trabalho Remota em secpol.msc. Se faltar qualquer uma delas, este é o erro que você verá.
Uma configuração se sobrepõe a ambas: Negar logon por Serviços de Área de Trabalho Remota. Se a conta, ou qualquer grupo ao qual ela pertença, estiver nessa lista, ela será bloqueada independentemente do que mais estiver configurado.
Em máquinas ingressadas no domínio, há uma quarta camada. A Diretiva de Grupo no nível do domínio ou da OU pode, silenciosamente, redefinir as configurações locais na próxima atualização, desfazendo uma correção que parecia concluída minutos atrás.
Comece pela associação ao grupo; é a causa mais comum.
Caminho Rápido de Correção
Se você quiser começar imediatamente sem ler a explicação completa, siga-os em ordem e pare quando o erro for resolvido.
-
Adicione a conta ao grupo local Usuários da Área de Trabalho Remota no computador de destino.
-
Abra o secpol.msc e confirme que o grupo da conta aparece em Permitir fazer logon por meio dos Serviços de Área de Trabalho Remota.
-
No mesmo local, verifique Negar logon por meio dos Serviços de Área de Trabalho Remota e confirme que a conta não está listada lá.
-
Se a máquina estiver ingressada no domínio, verifique a GPO do domínio no GPMC, não apenas a política local no secpol.msc.
-
Limpe as credenciais salvas desatualizadas do Gerenciador de Credenciais somente após confirmar que as configurações de política acima estão corretas.
O que usuários reais relatam sobre este erro
A reclamação mais comum nos fóruns: tudo parece correto, e o erro persiste mesmo assim. Um administrador de domínio no Microsoft Q&A descreveu uma estação de trabalho Windows 11 que recusava todas as conexões RDP de não administradores apesar de a associação ao grupo estar correta e o secpol.msc local parecer limpo. O bloqueador real era uma GPO em nível de domínio substituindo silenciosamente as configurações locais. (Microsoft Q&A, setembro de 2024)
Em VMs do Azure, um problema relacionado aparece como um loop: uma conta é adicionada manualmente, as sessões funcionam, então a conta desaparece após uma reinicialização e o erro retorna. Uma GPO de Grupos Restritos removendo a associação a cada atualização de política foi a causa, e nenhuma correção pela interface do usuário se mantém até que a própria GPO seja atualizada. (Microsoft Tech Community, junho de 2023)
Credenciais salvas são um gatilho menos óbvio. Um pool de RDS que funcionou por anos de repente começou a rejeitar todos os usuários com esse erro. As permissões não haviam mudado. Excluir a senha salva e inseri-la novamente manualmente resolveu imediatamente, confirmado por vários usuários no mesmo tópico. (Microsoft Q&A, outubro de 2022)
Em VMs do Azure ingressadas no domínio, um administrador que gerenciava 1.000 usuários adicionou contas à política Permitir efetuar logon por meio dos Serviços de Área de Trabalho Remota, executou gpupdate /force e ainda assim encontrou o erro. A etapa que faltava era adicionar os usuários ao grupo local Usuários da Área de Trabalho Remota na própria VM. Ambas as verificações são necessárias. (Microsoft Q&A, novembro de 2022)
Em ambientes gerenciados pelo Intune, o lusrmgr.msc não mostra o domínio do Azure como um local disponível, portanto a correção padrão de associação ao grupo não se aplica. Uma política de configuração do Intune bem-sucedida não é suficiente por si só. É necessária uma política separada direcionando o direito Permitir efetuar logon por meio dos Serviços de Área de Trabalho Remota para dispositivos ingressados no Entra. (Microsoft Q&A, dezembro de 2024)
Como corrigir a conexão foi negada porque a conta de usuário não está autorizada para login remoto
Solução 1: Adicionar o usuário ao grupo Usuários da Área de Trabalho Remota
A falta de associação a grupos é a causa mais comum desse erro em máquinas independentes. Execute estas etapas no PC remoto, não no computador a partir do qual você está se conectando. Observe que o lusrmgr.msc não está disponível nas edições Home do Windows, embora as edições Home também não possam atuar como hosts RDP.
-
Pressione Win + R, digite lusrmgr.msc e pressione Enter.
-
Selecione Grupos no painel à esquerda, em seguida, clique duas vezes em Usuários da Área de Trabalho Remota.
-
Clique em Adicionar.
-
Digite o nome de usuário, clique em Verificar Nomes para confirmar a resolução e, em seguida, clique em OK.
-
Clique em OK para fechar a janela de propriedades do grupo.
Para uma alternativa mais rápida via Propriedades do Sistema: pressione Win + R, digite sysdm.cpl, selecione a guia Remoto, clique em Selecionar Usuários e adicione a conta lá.
Em um prompt do PowerShell elevado na máquina remota:
Add-LocalGroupMember -Group “Remote Desktop Users” -Member “username”
Substitua username pelo nome real da conta. Não é necessário reiniciar.
Correção 2: Verifique a política Permitir o logon por meio dos Serviços de Área de Trabalho Remota
A associação ao grupo e a política de direitos do usuário são verificadas independentemente. Ambas devem ser aprovadas e corrigir uma sem a outra faz com que o erro permaneça. Execute estas etapas no PC remoto.
-
Pressione Win + R, digite secpol.msc e pressione Enter.
-
Navegue até Configurações de Segurança > Políticas Locais > Atribuição de Direitos de Usuário.
-
Clique duas vezes em Permitir o logon por meio dos Serviços de Área de Trabalho Remota.
-
Confirme que tanto Usuários da Área de Trabalho Remota quanto Administradores estão listados. Se algum deles estiver ausente, clique em Adicionar Usuário ou Grupo, digite o nome do grupo e clique em OK.
-
Clique em OK e, em seguida, execute o seguinte a partir de um Prompt de Comando elevado: gpupdate /force
Em um computador ingressado no domínio, uma GPO de domínio em conflito pode sobrescrever essa configuração em poucos minutos após salvá-la. Se a configuração reverter, vá para a Correção 4.
Correção 3: Verifique se há uma política de negação sobrepondo a configuração de permissão
A política Negar logon por meio dos Serviços de Área de Trabalho Remota bloqueia o acesso independentemente da associação ao grupo ou da política Permitir. Verifique isso mesmo quando as configurações de Permitir parecerem completas.
-
No secpol.msc, navegue até Configurações de Segurança > Políticas Locais > Atribuição de Direitos de Usuário.
-
Clique duas vezes em Negar logon por Serviços de Área de Trabalho Remota.
-
Reveja a lista. Se a conta que está a ligar-se, ou qualquer grupo a que ela pertença, incluindo Convidados ou Convidados do Domínio, aparecer aqui, selecione e clique em Remover.
-
Clique em OK e, em seguida, execute gpupdate /force.
Se a configuração continuar a reverter após você salvá-la e executar gpupdate /force, uma GPO de domínio está controlandoSe a configuração continuar a reverter após você salvá-la e executar gpupdate /force, uma GPO de domínio está controlando no nível do domínio. Gerencie essa política apenas por meio da Política de Segurança Local ou do Gerenciamento de Política de Grupo. Evite tentar editar as atribuições de direitos do usuário diretamente no Registro, pois os direitos de logon Permitir e Negar são gerenciados pelo Windows como constantes de privilégio nomeadas (SeRemoteInteractiveLogonRight e SeDenyRemoteInteractiveLogonRight), não como valores simples do Registro. Para auditoria, use secpol.msc, gpresult ou secedit.
Correção 4: Aborde diretamente o GPO do domínio
Em uma máquina ingressada no domínio em que as alterações locais continuam sendo revertidas, uma GPO do domínio está substituindo-as. Esta correção requer acesso ao Console de Gerenciamento de Política de Grupo, normalmente disponível em um controlador de domínio ou em uma máquina com o RSAT instalado.
-
Abra o GPMC via Gerenciador do Servidor > Ferramentas > Gerenciamento de Política de Grupo.
-
Expanda o domínio, clique com o botão direito no GPO que controla a máquina afetada e selecione Editar.
-
Navegue até Configuração do Computador > Políticas > Configurações do Windows > Configurações de Segurança > Políticas Locais > Atribuição de direitos de usuário.
-
Abra Permitir o logon por meio dos Serviços de Área de Trabalho Remota e confirme que os Usuários da Área de Trabalho Remota e os Administradores estão ambos listados.
-
Abra Negar logon através dos Serviços de Área de Trabalho Remota e confirme que a conta afetada e seus grupos não estão listados.
-
Salve as alterações e, em seguida, execute o seguinte na máquina afetada: gpupdate /force
Se a GPO relevante não for imediatamente óbvia, execute isto na máquina afetada e abra o arquivo resultante para identificar qual política está controlando a atribuição de direitos de usuário:
gpresult /h gpreport.html
Correção 5: Limpar credenciais salvas desatualizadas do Gerenciador de Credenciais
Esta é uma causa menos comum, mas vale a pena verificar após confirmar que a associação ao grupo e as configurações de política estão corretas. Credenciais RDP salvas podem ficar desatualizadas após uma alteração de senha, uma migração de conta ou mudanças em um pool de RDS. Em alguns casos, isso produz falhas de logon que se assemelham a erros de autorização. A correção, documentada em um tópico do Microsoft Q&A em que um pool de RDS com anos de credenciais salvas de repente começou a falhar para todos os usuários, foi limpar a entrada armazenada e inserir novamente as credenciais manualmente.
-
Abra o Painel de Controle, vá para Contas de Usuário e, em seguida, clique em Gerenciador de Credenciais.
-
Selecione as Credenciais do Windows.
-
Procure por entradas que comecem com TERMSRV/ seguidas pelo nome da máquina ou pelo endereço IP do PC remoto.
-
Expanda cada entrada relevante e clique em Remover.
-
Feche o Gerenciador de Credenciais e tente a conexão RDP novamente, inserindo as credenciais manualmente quando solicitado.
Correção 6: Use o HelpWire como uma alternativa gratuita enquanto corrige o RDP
Se o erro de autorização estiver bloqueando o acesso a uma máquina de que você precisa agora, HelpWire fornece uma conexão remota funcional enquanto você resolve a configuração de políticas. Ele não usa o serviço de Área de Trabalho Remota do Windows nem a porta 3389, portanto, os problemas de associação a grupos e direitos de usuário que produzem o erro “conta de usuário não autorizada” não o afetam.
O HelpWire funciona no Windows, macOS e Linux e é gratuito. A configuração leva alguns minutos: instale o cliente do operador na sua máquina, instale o agente do HelpWire na máquina remota e conecte-se. Para acesso não supervisionado a uma máquina que você gerencia, o agente pode ser configurado para ser executado como um serviço em segundo plano, sem exigir que alguém no lado remoto aceite cada conexão.
Perguntas frequentes
As contas de administrador pertencem ao grupo local Administradores, que o Windows sempre inclui na política Permitir logon por meio dos Serviços de Área de Trabalho Remota. As contas de usuário padrão não são adicionadas ao grupo Usuários da Área de Trabalho Remota nem à política Permitir logon por meio dos Serviços de Área de Trabalho Remota por padrão, portanto o acesso é negado até que ambos sejam configurados explicitamente.
Sim. As configurações de GPO de domínio aplicadas nos níveis de domínio, site ou UO substituem as configurações locais do secpol.msc a cada atualização da Política de Grupo. Se uma correção local continuar sendo revertida, há uma GPO conflitante ativa. Use o GPMC para corrigir isso no nível do domínio e execute gpresult /h gpreport.html no computador afetado para identificar qual política está controlando Atribuição de Direitos de Usuário.
Isso bloqueia qualquer conta listada nela, ou qualquer grupo que contenha essa conta, de se conectar via RDP. A política de negação sobrepõe-se tanto à configuração Permitir fazer logon por meio dos Serviços de Área de Trabalho Remota quanto à associação ao grupo Usuários da Área de Trabalho Remota. As contas podem acabar em um grupo de negação por engano, por exemplo, por pertencerem ao grupo Convidados, que muitos ambientes reforçados incluem na política de negação por padrão.
“A conexão foi negada porque a conta de usuário não está autorizada para login remoto” significa que a solicitação de sessão alcançou a máquina de destino e foi recusada na camada de autorização, normalmente devido à falta de associação a um grupo, a uma lacuna na política de direitos do usuário ou a uma política de negação ativa. “Acesso negado” é mais amplo e também pode indicar restrições do Credential Guard, limitações de acesso ao SAM ou problemas gerais de permissões não relacionados especificamente aos direitos de login remoto. A distinção é importante porque elas apontam para diferentes caminhos de solução de problemas.
