Corrigir credenciais da Área de Trabalho Remota que não estão funcionando

O erro Suas credenciais não funcionaram na Área de Trabalho Remota não significa que sua senha esteja errada. Em muitos casos, a máquina que se conecta está enviando credenciais em cache obsoletas que sobreviveram a uma alteração de senha. Em algumas configurações, a máquina de destino está em um estado de entrada baseado em PIN do Windows Hello que pode bloquear a entrada via RDP com Conta da Microsoft. Esses são os gatilhos mais comuns, mas falhas de credenciais têm mais de uma dúzia de causas-raiz distintas em ambas as máquinas.

Este guia abrange as correções mais confiáveis relatadas na documentação e no Q&A da Microsoft, bem como em tópicos recorrentes de solução de problemas na comunidade.

Sumário

Encontre, na tabela abaixo, a sua causa mais provável e vá diretamente para essa correção em vez de testar cada opção.

Causa	Lado	Seção de correção
Credenciais em cache ou desatualizadas	Cliente	Correção 1
Problema de entrada na Conta Microsoft relacionado ao PIN do Windows Hello	Máquina de destino	Correção 2
Formato de nome de usuário incorreto	Cliente	Correção 3
Usuário não está no grupo Usuários da Área de Trabalho Remota	Máquina de destino	Correção 4
Delegação de credenciais bloqueada por GPO	Cliente	Correção 5
Incompatibilidade da camada de segurança do RDP	Máquina de destino	Correção 6
`Always prompt for password` está ativada	Máquina de destino	Correção 7
Perfil de rede definido como `Public`	Máquina de destino	Correção 8
Incompatibilidade do nível de autenticação do LAN Manager	Máquina de destino	Correção 9
`fDenyTSConnections` definido como `1`	Máquina de destino	Correção 10
Restrição de senha em branco	Máquina de destino	Correção 11
Ouvinte do RDP não está ativo	Máquina de destino	Correção 12
Certificado RDP expirado	Máquina de destino	Casos especiais
Porta RDP não padrão	Máquina de destino	Casos especiais

Esta é a correção mais confirmada quando as credenciais da Área de Trabalho Remota não funcionam em máquinas que usam Contas Microsoft com o PIN do Windows Hello ativado. Em relatos de usuários, entrar localmente com a senha da conta restaurou o acesso via RDP após o uso apenas do PIN no dispositivo de destino.

NOTA: O Windows Hello for Business é um recurso empresarial separado que oferece suporte ao início de sessão via RDP por meio de implantação baseada em certificados, via Microsoft Intune ou Active Directory Certificate Services. Isso requer infraestrutura de PKI, implantação de certificados e certificados do controlador de domínio. Não está disponível em configurações padrão para consumidores ou SMB e não tem relação com o cenário de PIN de consumidor descrito aqui.

Na máquina de destino, encerre a sessão atual.
Na tela de entrada, clique em Opções de entrada.
Selecione a opção de senha (o ícone de chave).
Faça login com a senha completa da sua Conta Microsoft.
Tente novamente a conexão RDP a partir da máquina que está se conectando.

Na tela de entrada, clique em Opções de entrada e, em seguida, clique em Esqueci meu PIN.
Autentique-se com as credenciais da sua Conta Microsoft, incluindo qualquer aprovação de dois fatores.
Quando for solicitado a redefinir seu PIN, confirme a redefinição. Você pode inserir novamente o mesmo PIN.
Volte a tentar a ligação RDP após a conclusão do fluxo de início de sessão baseado em palavra-passe.

Vários usuários confirmaram que desativar essa única opção resolveu o problema sem precisar sair e entrar novamente.

Na máquina de destino, vá para Configurações > Contas > Opções de entrada.
Encontre Para maior segurança, permitir apenas o início de sessão com o Windows Hello para contas da Microsoft neste dispositivo.
Desligue-o.
Saia e entre novamente usando a senha da Conta da Microsoft.

O Gerenciador de Credenciais do Windows na máquina que está se conectando armazena em cache entradas TERMSRV/. Após uma alteração de senha, ele envia silenciosamente a senha antiga em todas as tentativas de conexão, sem solicitar.

Na máquina que está se conectando, abra o Gerenciador de Credenciais. Pesquise por ele no Iniciar, ou execute control /name Microsoft.CredentialManager.
Clique em Credenciais do Windows.
Encontre todas as entradas que comecem com TERMSRV/ seguidas do nome ou do endereço IP da máquina remota.
Clique em cada entrada e, em seguida, clique em Remover.
Reconecte-se. O Windows solicitará novas credenciais.

Abra a Conexão de Área de Trabalho Remota (mstsc.exe).
Introduza o nome da máquina remota ou o endereço IP.
Clique em Mostrar opções.
Em Configurações de logon, clique no link editar ao lado do nome de usuário salvo.
Digite a senha atual e salve.

Algumas configurações se recusam a reter as credenciais de RDP entre sessões. Adicionar uma entrada de credencial genérica diretamente no Gerenciador de Credenciais obriga o Windows a usá-la.

Abra Gerenciador de Credenciais > Credenciais do Windows.
Clique em Adicionar uma credencial genérica.
No Endereço da Internet ou de rede, digite TERMSRV/ seguido pelo nome do host ou endereço IP da máquina remota. Por exemplo: TERMSRV/103.27.76.117 ou TERMSRV/COMPUTERNAME.
Insira o nome de usuário e a senha.
Clique em OK, feche o Gerenciador de Credenciais e reconecte-se.

O formato do nome de usuário que você digita determina para qual provedor de autenticação o Windows direciona. Usar o formato incorreto encaminha a solicitação para a fonte de identidade errada e falha mesmo com a senha correta.

A Microsoft documenta que, para um dispositivo ingressado no Microsoft Entra acessado remotamente, você pode entrar com user@domain.com ou AzureAD\user@domain.com, dependendo do caminho de entrada utilizado. Se um formato falhar, tente o outro.

Tipo de conta	Formato correto	Observações
Conta local	`COMPUTERNAME\username</code`	Exemplo: `DESKTOP-AB12\john`
Conta de domínio (NetBIOS)	`DOMAIN\username`	Exemplo: `CORP\johndoe`
Conta de domínio (UPN)	`username@domain.com`	Exemplo: `johndoe@corp.local`
Conta Microsoft	Endereço de e-mail completo	Exemplo: `john@outlook.com`
Ingressado no Microsoft Entra	`AzureAD\user@domain.com` ou `user@domain.com`	A Microsoft documenta ambos os formatos para diferentes caminhos de entrada. Tente o alternativo se o primeiro falhar.

Uma conta deve pertencer ao grupo Usuários da Área de Trabalho Remota ou ao grupo Administradores na máquina de destino. Event ID 4625 com substatus 0xC000015B confirma que não foi concedido ao usuário o tipo de logon necessário. A associação ao grupo, por si só, ainda pode ser bloqueada por um Negar explícito em Atribuição de Direitos de Usuário.

Na máquina de destino, execute este comando como Administrador:
net localgroup "Remote Desktop Users" /add "DOMAIN\username" ou no PowerShell:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\username"
Abra o Executar e digite secpol.msc.
Navegue até 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.
Clique em Adicionar usuário ou grupo.
Digite o nome da conta e clique em OK.
Verifique a mesma lista se há alguma entrada de Negar o logon por Serviços de Área de Trabalho Remota que contenha o usuário ou seu grupo. Remova quaisquer entradas de negação explícitas.

Quando as políticas de delegação de credenciais na máquina que estabelece a conexão restringem como as credenciais são encaminhadas, o cliente RDP não consegue concluir a autenticação mesmo com a senha correta. Isso se aplica a todos os tipos de conta e é uma das causas mais negligenciadas de as credenciais não funcionarem no Remote Desktop. A correção é executada na máquina cliente, não na remota.

Na máquina que se conecta, abra o Executar e digite gpedit.msc.
Navegue até Configuração do Computador > Modelos Administrativos > Sistema > Delegação de Credenciais.
Defina Negar a delegação de credenciais salvas como Não Configurado.
Defina Negar a delegação de credenciais recentes como Não Configurado.
Abra Permitir a delegação de credenciais armazenadas com autenticação de servidor somente NTLM. Defina-o como Ativado.
Clique em Mostrar ao lado de Adicionar servidores à lista e digite TERMSRV/*. Clique em OK.
Repita a etapa 5 para: Permitir delegação de credenciais salvas, Permitir delegação de novas credenciais com autenticação de servidor somente NTLM, e Permitir delegação de novas credenciais.
Navegue até Configuração do Computador > Modelos Administrativos > Componentes do Windows > Serviços de Área de Trabalho Remota > Cliente de Conexão da Área de Trabalho Remota.
Defina Não permitir que as senhas sejam salvas como Não Configurado.
Defina Solicitar credenciais no computador cliente como Não configurado.
Feche o Editor de Diretiva de Grupo e execute gpupdate /force em um prompt de comando com privilégios elevados.

Vários usuários confirmaram esta correção depois que todas as outras soluções falharam. Quando cliente e destino não conseguem chegar a um acordo sobre a camada de segurança negociada, a autenticação é recusada antes que as credenciais sejam totalmente avaliadas.

Na máquina de destino, abra Executar e digite gpedit.msc.
Navegue até Configuração do Computador > Modelos Administrativos > Componentes do Windows > Serviços de Área de Trabalho Remota > Host da Sessão da Área de Trabalho Remota > Segurança.
Abra Exigir o uso de camada de segurança específica para conexões remotas (RDP).
Defina como Enabled. No menu suspenso, selecione RDP como a Camada de Segurança.
Clique em OK e, em seguida, execute gpupdate /force em um prompt de comando com privilégios elevados.

Quando essa política está habilitada na máquina remota, ela substitui as credenciais salvas no cliente e força um prompt de reautenticação. Esse prompt falha silenciosamente, gerando o erro de credenciais em vez de uma caixa de diálogo de senha visível.

Na máquina de destino, abra Executar e digite gpedit.msc.
Navegue até Configuração do Computador > Modelos Administrativos > Componentes do Windows > Serviços de Área de Trabalho Remota > Host da Sessão da Área de Trabalho Remota > Segurança.
Abra Sempre solicitar a senha ao conectar.
Defina-o como Desativado ou Não Configurado.
Saia e entre novamente, ou execute gpupdate /force.

Quando o perfil de rede da máquina de destino está definido como Public, o Windows bloqueia conexões RDP recebidas. As orientações de solução de problemas de RDP da Microsoft tratam o perfil de rede e a configuração do firewall como causas válidas de falha de conexão. Esta é uma constatação comum quando todo o restante da configuração parece correto.

Na máquina de destino, abra Configurações > Rede e Internet > Status.
Clique em Alterar as propriedades de conexão.
Defina o Perfil de Rede como Privado.

Uma incompatibilidade de nível de autenticação entre a máquina que se conecta e a máquina remota causa a rejeição das credenciais na camada de negociação do NTLM, independentemente de a senha estar correta ou não.

Na máquina de destino, abra Executar e digite gpedit.msc.
Navegue até Configuração do Computador > Configurações do Windows > Configurações de Segurança > Políticas Locais > Opções de Segurança.
Abra Segurança de rede: nível de autenticação do LAN Manager.
Defina-o para um destes três valores confirmados como funcionais: Send NTLMv2 response only, Send NTLMv2 response only. Refuse LM, ou Send NTLMv2 response only. Refuse LM and NTLM. Qualquer um dos três resolve a incompatibilidade. A opção mais permissiva para tentar primeiro é Send NTLMv2 response only.
Clique em OK.

Quando o RDP aparece habilitado em Configurações, mas as conexões ainda falham, dois valores do Registro podem estar substituindo a configuração da interface do usuário. A Microsoft documenta fDenyTSConnections como a configuração que controla se os usuários podem se conectar remotamente usando os Serviços de Área de Trabalho Remota.

Abra o Editor do Registro como Administrador (regedit.exe).
Navegue até: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
Confirme que fDenyTSConnections está definido como 0.
Verifique também:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services. Se fDenyTSConnections aparecer aqui definido como 1, uma Política de Grupo está aplicando o bloqueio. Alterar o valor local não surtirá efeito. A GPO deve ser corrigida na origem.
Para verificar se a porta RDP não foi alterada do padrão, navegue até: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp
Encontre PortNumber. Altere a base de exibição para Decimal.
O valor deve ser 3389. Se não for, seu cliente RDP deve se conectar a essa porta personalizada, usando o formato hostname:PORT.

Após qualquer alteração no registro, reinicie os Serviços de Área de Trabalho Remota: abra services.msc, localize Serviços de Área de Trabalho Remota, clique com o botão direito e selecione Reiniciar.

O Windows bloqueia o RDP por padrão para contas sem senha definida. Isso é uma restrição da política de segurança local, não uma configuração do RDP.

Abra o Executar e digite gpedit.msc.
Navegue até Configuração do Computador > Configurações do Windows > Configurações de Segurança > Políticas Locais > Opções de Segurança.
Abra Contas: Limitar o uso de senhas em branco de contas locais apenas para o logon no console.
Defina como Disabled.

Antes de presumir que o problema está relacionado a credenciais, confirme que o protocolo RDP está realmente escutando conexões na máquina de destino. Se o ouvinte RDP não estiver ativo, o servidor rejeita conexões no nível de protocolo antes que as credenciais de Área de Trabalho Remota sejam avaliadas. Isso gera erros que parecem falhas de autenticação.

Execute este comando com acesso administrativo na máquina de destino, via PowerShell Remoting ou acesso físico ao console:

qwinsta

Procure uma entrada chamada rdp-tcp com STATE definido como Listen. Se ela estiver ausente ou mostrar um estado diferente, o serviço RDP tem uma falha de protocolo. Verifique as chaves de registro em Fix 10 acima e o certificado RDP na seção de casos-limite abaixo, depois reinicie Remote Desktop Services.

Dica profissional: Em cada máquina que você gerencia remotamente, mantenha uma conta local de administrador dedicada que não use um login de Conta da Microsoft. Quando problemas com MSA, PIN ou certificados bloquearem o RDP, uma conta local contorna completamente o fluxo de credenciais da MSA e fornece um caminho de acesso funcional.

Para equipes de suporte de TI que fazem trabalho remoto em várias máquinas, HelpWire é algo que vale a pena manter ao lado do RDP. As sessões começam com um link, em vez de exigir que o usuário remoto altere quaisquer configurações do sistema. Isso significa que falhas de autenticação do RDP na máquina remota não impedem que uma sessão de suporte seja iniciada. Mantenha as credenciais de administrador local em um gerenciador de senhas, e não em cache no Gerenciador de Credenciais da sua própria máquina.

Abra o Visualizador de Eventos na máquina de destino e verifique Logs do Windows > Sistema em busca de ID de Evento 1057 ou 1058 de Microsoft-Windows-TerminalServices-RemoteConnectionManager. Esses eventos indicam que o certificado autoassinado não pôde ser renovado.

Abra mmc.exe > Arquivo > Adicionar/Remover Snap-in > Certificados > Conta do Computador.
Navegue até Certificados > Área de Trabalho Remota.
Remova o certificado autoassinado expirado.
Reinicie os Serviços de Área de Trabalho Remota no services.msc. O Windows regenera o certificado automaticamente.

Navegue até C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.
Assuma a propriedade do arquivo de chave relacionado ao RDP.
Exclua o arquivo.
Reinicie os Serviços de Área de Trabalho Remota.

Ao conectar-se pelo nome do host, confirme se o DNS está resolvendo para a máquina correta, especialmente após uma reconstrução da máquina ou alteração de IP.

Na máquina de destino, execute IPCONFIG /All em um prompt de comando elevado e anote o endereço IP real.
Na máquina que está se conectando, execute nslookup MACHINENAME e confirme que o IP retornado corresponde.
Também execute Test-NetConnection -ComputerName SERVER-IP -Port 3389 no PowerShell. Se TcpTestSucceeded retornar False, o problema é de rede ou de firewall, não de credenciais.
Se o DNS estiver desatualizado, conecte-se diretamente pelo endereço IP ou atualize o registro DNS.

Tentativas repetidas de RDP com falha acionam a política de bloqueio em máquinas associadas ao domínio. Verifique o Visualizador de Eventos no controlador de domínio em busca do ID de Evento 4625 com Substatus 0xC0000234. Para uma conta local na máquina de destino, execute:

net user USERNAME

Procure por Account active: No na saída. Para reativar:

net user USERNAME /active:yes

A Microsoft documenta que, para um dispositivo remoto ingressado no Microsoft Entra, é possível entrar com user@domain.com ou AzureAD\user@domain.com, dependendo do método de entrada. Se um formato falhar, tente o outro. Em qualquer dos casos, confirme que o usuário foi adicionado ao grupo Remote Desktop Users na máquina de destino. Além disso, verifique o dispositivo no Entra admin center em Devices > the specific device > Local administrators.

ID do Evento 4625 nos Logs de Segurança do Windows registra cada tentativa de logon com falha. O campo Sub Status identifica o motivo exato da falha de autenticação, o que elimina completamente a necessidade de suposições no diagnóstico.

Código de Substatus	Motivo da falha	Correção a aplicar
`0xC000006A`	Nome de usuário correto, senha incorreta	Limpe o Gerenciador de Credenciais, verifique a senha atual
`0xC0000234`	Conta bloqueada	Desbloqueie via conta de administrador ou aguarde a política de bloqueio
`0xC0000072`	Conta desabilitada	Habilite a conta em Gerenciamento do Computador
`0xC0000071`	Senha expirada	Altere a senha na conta de destino
`0xC000015B`	Usuário não possui direito de logon via RDP	Adicione ao grupo Usuários da Área de Trabalho Remota e verifique a Atribuição de Direitos de Usuário

Para acessar esses logs: abra o Visualizador de Eventos > Logs do Windows > Segurança > filtre por ID do Evento 4625. Nos detalhes do evento, expanda Informações de falha e leia o valor hexadecimal de Substatus.

A primeira coisa que a maioria das pessoas faz quando as credenciais da Área de Trabalho Remota do Windows não funcionam é redefinir a senha da Conta Microsoft. Isso não ajuda nos cenários de PIN e credenciais em cache descritos acima. O problema muitas vezes não é a própria senha da conta, mas sim credenciais em cache ou um estado de autenticação incompatível entre dispositivos. Redefinir a senha não resolve o problema porque o cliente continua enviando a credencial antiga em cache até que a entrada TERMSRV/ salva seja limpa ou substituída.

A segunda tentativa comum é alternar o NLA entre ativado e desativado. Para o problema do PIN do Windows Hello e as credenciais em cache obsoletas, o estado do NLA não é o fator determinante. O problema do PIN ocorre porque a autenticação padrão do Windows Hello por PIN é vinculada ao dispositivo e não é encaminhada pelos fluxos padrão de autenticação do RDP. Desabilitar o NLA também enfraquece a segurança da conexão sem abordar a causa raiz.

Uma terceira abordagem que circula em alguns tópicos de fórum envolve excluir a chave de registro WinStations. No entanto, isso pode tornar a máquina inoperante e exigir uma reinstalação completa do sistema operacional.

Quando a própria configuração do RDP é o problema, e não uma questão de formatação de credenciais, vale a pena manter na caixa de ferramentas uma ferramenta criada para trabalhos de suporte. Por exemplo, o HelpWire inicia sessões enviando um link ao usuário remoto, que executa um cliente leve. Em seguida, você se conecta sem precisar se autenticar nas contas locais da máquina remota. Quando você precisa acessar uma máquina cuja pilha de credenciais do RDP está quebrada, isso remove a dependência de o RDP estar configurado corretamente.

Quando você vê que as credenciais da Área de Trabalho Remota não funcionam, o motivo mais comum é uma senha antiga em cache no Gerenciador de Credenciais do Windows na máquina que está se conectando, enviada automaticamente após uma alteração de senha, sem solicitar. Outra razão comum é que a máquina de destino tenha sido autenticada localmente pela última vez com um PIN do Windows Hello, o que pode bloquear o início de sessão RDP com uma Conta Microsoft em algumas configurações.

Um PIN do Windows Hello padrão é vinculado ao dispositivo e não é encaminhado pelos fluxos padrão de autenticação RDP. O RDP requer uma credencial baseada em senha nas configurações padrão de consumidor e SMB.

Windows Hello for Business é um recurso empresarial separado que oferece suporte a RDP por meio de autenticação baseada em certificado, mas requer infraestrutura de PKI, implantação de certificados via Intune ou AD CS e certificados do controlador de domínio. Ele não está disponível em configurações padrão de consumidor ou SMB.

Abra o Gerenciador de Credenciais pelo menu Iniciar, clique em Credenciais do Windows e remova todas as entradas que comecem com TERMSRV/ e correspondam à máquina remota. Se as credenciais não persistirem entre sessões, use Adicionar uma credencial genérica no Gerenciador de Credenciais e insira manualmente o TERMSRV/[hostname] address junto com o nome de usuário e a senha.

Sim. As configurações de Delegação de credenciais em Configuração do Computador > Modelos Administrativos > Sistema na Política de Grupo no computador que está se conectando controlam se as credenciais são encaminhadas. Negar a delegação de credenciais salvas ou Negar a delegação de credenciais novas definidas como Habilitado bloqueiam a autenticação silenciosamente. Definir ambas como Não Configurado e habilitar TERMSRV/* em Permitir a delegação de credenciais salvas com autenticação de servidor somente NTLM resolve isso.

Limpe as entradas do Gerenciador de Credenciais na máquina de origem e tente novamente. Se a conexão ainda falhar, execute Test-NetConnection -ComputerName SERVER-IP -Port 3389 no PowerShell. Se TcpTestSucceeded retornar True mas as credenciais ainda falharem, o problema está na máquina de destino. Se retornar False, o problema está na rede ou no firewall. Uma vez na máquina de destino, leia o ID do Evento 4625 no Log de Segurança para identificar o motivo exato da falha.

Como corrigir as credenciais da Área de Trabalho Remota que não funcionam

12 maneiras de corrigir as credenciais da Área de Trabalho Remota que não funcionam

Correção 1: Entre uma vez com sua senha na máquina de destino (problema com o PIN do Windows Hello)

Método A: Sair e entrar novamente com a senha

Método B: Se a opção de senha não aparecer ou estiver acinzentada

Método C: Desativar a alternância de logon somente com o Windows Hello (correção independente)

Correção 2: Limpar credenciais antigas do Gerenciador de Credenciais no computador que está se conectando

Método A: Remover entradas via Gerenciador de Credenciais

Método B: Atualize a senha diretamente no cliente RDP

Método C: Adicionar manualmente uma credencial genérica quando as credenciais salvas não persistirem

Solução 3: Use o formato correto do nome de usuário

Correção 4: Adicione o usuário ao grupo Usuários da Área de Trabalho Remota e verifique os direitos de logon

Correção 5: Corrigir a Diretiva de Grupo de Delegação de Credenciais na máquina que está se conectando

Correção 6: Alterar a Camada de Segurança do RDP via Política de Grupo no Computador de Destino

Solução 7: Desativar “Sempre solicitar senha” na máquina de destino

Correção 8: Alterar o perfil de rede de Pública para Privada na máquina de destino

Correção 9: Defina o nível de autenticação do LAN Manager na máquina de destino

Correção 10: Verifique a chave do Registro fDenyTSConnections e a porta RDP

Correção 11: Tratar uma senha em branco na conta de destino

Correção 12: Verifique o status do ouvinte RDP

Correções para casos-limite em que as credenciais não funcionam na Área de Trabalho Remota

Falha do Certificado Autoassinado do RDP (ID do Evento 1057 ou 1058)

Verifique o DNS e a segmentação por máquina

Bloqueio de conta

Máquinas ingressadas no Azure AD / Entra ID

Como ler o Visualizador de Eventos para falhas de logon no RDP

Erros comuns cometidos quando as credenciais da Área de Trabalho Remota do Windows não funcionaram

Perguntas frequentes