RDP no Windows 10 e 11: “As credenciais não funcionam” — como descobrir o usuário correto e habilitar o logon remoto

Erro “As credenciais não funcionam” ao ligar-se por RDP no Windows? Este guia prático mostra como descobrir o usuário correto, habilitar permissões e ajustar políticas para que o logon remoto funcione no Windows 10 e 11.

Índice

Visão geral do problema

Ao tentar conectar via Área de Trabalho Remota (RDP) entre dois PCs Windows na mesma rede, o Windows recusa o logon e exibe mensagens como “As credenciais não funcionam” ou “The sign-in method you’re trying to use isn’t allowed”. As causas mais comuns são:

PC de destino sem suporte a host RDP (Windows Home).
RDP desativado ou regra de Firewall ausente.
Conta sem senha (PIN/Hello não serve para RDP).
Uso do nome de usuário incorreto (confusão entre nome exibido, conta local, Microsoft ou domínio).
Usuário sem permissão no grupo Remote Desktop Users ou políticas que negam o logon.

Checklist rápido de pré‑requisitos

Antes de qualquer ajuste, valide estes três pontos no PC de destino:

Edição do Windows: apenas Pro, Enterprise ou Education aceitam conexões RDP como host. O Windows Home não recebe RDP.
RDP e Firewall: em Configurações > Sistema > Área de Trabalho Remota, ative Permitir Área de Trabalho Remota. No Firewall do Windows, confirme ativa a regra Remote Desktop (TCP‑In).
Senha definida: RDP não permite login com senha em branco. Crie/defina uma senha para a conta que fará o logon.

Como descobrir o nome de usuário correto no PC de destino

O passo mais importante é usar o identificador exato de usuário que o Windows espera. No PC de destino, abra o Prompt de Comando e execute:

whoami

A saída do comando indica o formato que você deve digitar no cliente RDP (campo Usuário em mstsc.exe):

Saída do `whoami`	Significado	Como digitar no RDP (campo “Usuário”)
`PCNAME\usuario`	Conta local	`PCNAME\usuario` ou `.\usuario`
`MicrosoftAccount\email@dominio.com`	Conta Microsoft	`email@dominio.com` (se falhar, tente `MicrosoftAccount\email@dominio.com`)
`DOMÍNIO\usuario`	Conta de domínio (AD/Entra)	`DOMÍNIO\usuario`

Dicas úteis

Quando o PC é Azure AD/Entra ID ingressado, algumas versões exibem AzureAD\usuario ou mapeiam para o UPN. Em caso de dúvida, tente o UPN (e‑mail organizacional) no campo Usuário ou use exatamente o que o whoami retornar.
Se o “nome exibido” do Windows parecer diferente (com espaços ou acentos), confie no que o whoami mostra.
Para listar contas locais e seus nomes exatos, pode usar: netplwiz
Para saber o nome do computador (PCNAME), execute: hostname

Dar permissão de RDP à conta

Além de usar o nome correto, a conta precisa ter direito de entrar via RDP. Isso ocorre quando ela pertence ao grupo Remote Desktop Users (ou é Administrador).

Via interface gráfica

No PC de destino, abra Painel de Controle > Sistema e clique em Configurações remotas.
Em Área de Trabalho Remota, clique em Selecionar usuários….
Adicione a conta correta (no formato revelado por whoami).

Via linha de comando

No PC de destino, em um Prompt de Comando (Admin):

:: Conta local
net localgroup "Remote Desktop Users" "PCNAME\usuario" /add

\:: Conta Microsoft
net localgroup "Remote Desktop Users" "MicrosoftAccount\\[email@dominio.com](mailto:email@dominio.com)" /add

\:: Domínio (AD/Entra)
net localgroup "Remote Desktop Users" "DOMÍNIO\usuario" /add </code></pre>

<p>No <strong>PowerShell</strong>, você pode verificar a associação:</p>
<pre><code>Get-LocalGroupMember -Group "Remote Desktop Users"
</code></pre>

<h2>Senha, não PIN: como habilitar a entrada por senha</h2>
<p>O <strong>Windows Hello/PIN</strong> não é aceito em sessões RDP. Certifique-se de que a entrada por senha está habilitada no PC de destino:</p>
<ol>
  <li>Acesse <em>Configurações &gt; Contas &gt; Opções de entrada</em>.</li>
  <li>Desative (se estiver ligado) a opção <em>“Permitir apenas entrar com o Windows Hello…”</em>.</li>
  <li>Defina/atualize a senha da conta Microsoft ou da conta local.</li>
</ol>

<h2>Como fazer uma tentativa de login “limpa”</h2>
<ol>
  <li>No cliente, abra <strong>mstsc.exe</strong> e clique em <em>Mostrar opções</em>.</li>
  <li>Em <em>Computador</em>, digite o IP ou nome do PC de destino.</li>
  <li>Em <em>Usuário</em>, insira exatamente o identificador mapeado pela tabela acima.</li>
  <li>Clique em <em>Mais escolhas &gt; Usar uma conta diferente</em> e introduza <strong>usuário + senha</strong> corretos.</li>
  <li>Se houver credenciais antigas salvas, remova-as em <em>Gerenciador de Credenciais &gt; Credenciais do Windows</em> apagando as entradas <code>TERMSRV/&lt;PC&gt;</code> ou <code>TERMSRV/&lt;IP&gt;</code>.</li>
</ol>

<h2>Testes e verificações adicionais</h2>

<h3>NLA (Network Level Authentication)</h3>
<p>Para diagnóstico, desmarque temporariamente <em>“Permitir somente conexões de computadores com NLA”</em> nas <em>Configurações remotas</em>. Se funcionar sem NLA, o problema costuma estar em <strong>usuário/senha</strong>, relógio fora de sincronia ou políticas. Reative o NLA após o teste.</p>

<h3>Direitos de logon por RDP</h3>
<p>Abra <strong>Política de Segurança Local</strong> (<code>secpol.msc</code>) &gt; <em>Políticas Locais &gt; Atribuição de direitos de usuário</em> e confirme:</p>
<ul>
  <li><strong>Permitir logon por Serviços de Área de Trabalho Remota</strong> inclui <em>Administrators</em> e <em>Remote Desktop Users</em>.</li>
  <li><strong>Negar logon por Serviços de Área de Trabalho Remota</strong> não contém a sua conta.</li>
</ul>

<h3>Firewall e porta</h3>
<ul>
  <li>Confirme a regra <em>Remote Desktop (TCP‑In)</em> ativa nos perfis <em>Domínio</em>, <em>Privado</em> e (se necessário) <em>Público</em>.</li>
  <li>Teste a porta no cliente:
    <pre><code>Test-NetConnection -ComputerName &lt;PC ou IP&gt; -Port 3389

Verifique se o serviço está a escutar no destino:

netstat -ano | findstr 3389
sc query termservice

Conta desativada ou com restrições

No destino, verifique o estado da conta:

net user &lt;usuario&gt;

Procure por “Conta ativa: Sim”, horário de logon, expiração e se a conta não está bloqueada. Em ambientes de domínio/Entra, as políticas de Logon Hours ou de dispositivo podem impedir o acesso.

Layout de teclado e senha

Senhas com caracteres especiais podem falhar se o layout de teclado no ecrã de logon remoto for diferente. Se necessário, altere temporariamente a senha para testar ou garanta o layout correto.

Relógio e autenticação

Diferenças de tempo (dezenas de segundos) podem quebrar a autenticação em cenários com NLA/Kerberos. Sincronize o relógio dos dois PCs com o mesmo servidor de tempo.

Computador em suspensão

Garanta que o PC de destino não entre em suspensão durante os testes. Ajuste em Configurações > Sistema > Energia & Suspensão.

Porta RDP personalizada

Se alguém alterou a porta padrão (3389), será necessário especificar <PC>:<porta> no cliente RDP. Verifique a chave do Registro no destino (administradores apenas):

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber

Mensagens de erro comuns e causas prováveis

Mensagem	Causa típica	Correção
“As credenciais não funcionam”	Usuário no formato errado; senha incorreta; credenciais antigas em cache; NLA exigindo senha válida	Use o formato do `whoami`; limpe o cache no Gerenciador de Credenciais; confirme a senha
“The sign-in method you’re trying to use isn’t allowed”	Política nega logon por RDP; Windows Hello sem senha; direitos de usuário ausentes	Habilite senha; inclua a conta em Remote Desktop Users; ajuste secpol.msc
“O computador remoto requer NLA”	Credenciais inválidas; relógio fora de sincronia; NLA estrita	Corrija senha/usuário; sincronize o relógio; teste desativando NLA provisoriamente
“O computador remoto não aceita conexões”	RDP desativado; Firewall bloqueando; serviço RDP parado; porta alterada	Ative RDP; habilite regra de Firewall; inicie TermService; use `<PC>:<porta>` se customizado

Exemplos práticos

Conta local

Cenário: o whoami mostra DESKTOP‑PC\maria. No cliente RDP, preencha Usuário como DESKTOP-PC\maria (ou .\maria) e use a senha local. Adicione DESKTOP-PC\maria ao grupo Remote Desktop Users.

Conta Microsoft

Cenário: o whoami mostra MicrosoftAccount\maria.silva@outlook.com. No cliente, use maria.silva@outlook.com como usuário (se não der, tente MicrosoftAccount\maria.silva@outlook.com). A senha é a da conta Microsoft, não o PIN.

Conta de domínio

Cenário: o whoami retorna CONTOSO\maria. No cliente, use CONTOSO\maria e a senha de domínio. Se houver falhas, confirme o relógio, conectividade ao controlador e políticas de logon por RDP.

Roteiro de diagnóstico em dez minutos

1 min: No destino, confirme edição Pro/Enterprise/Education e ative RDP.
1 min: Verifique regra Remote Desktop (TCP‑In) no Firewall.
2 min: Rode whoami e anote o identificador; defina/valide a senha.
2 min: Adicione a conta a Remote Desktop Users (GUI ou net localgroup).
1 min: No cliente, limpe TERMSRV no Gerenciador de Credenciais e preencha usuário no formato correto.
1 min: Se persistir, teste Test-NetConnection -Port 3389 e sc query termservice no destino.
2 min: Desative NLA temporariamente para isolar problema de credenciais; reative depois.

Boas práticas de segurança ao usar RDP

Use RDP apenas em redes confiáveis ou através de VPN.
Mantenha NLA habilitada em produção e use senhas fortes; se possível, habilite autenticação multifator para acesso à VPN.
Expor a porta 3389 diretamente na internet é arriscado; portas “escondidas” não substituem controles reais.
Monitore eventos de segurança e bloqueios de conta no Visualizador de Eventos.

Apêndice: comandos úteis

Listar membros do grupo de RDP

Get-LocalGroupMember -Group "Remote Desktop Users"

Adicionar usuário ao grupo de RDP

net localgroup "Remote Desktop Users" "PCNAME\usuario" /add

Verificar serviço RDP

sc query termservice

Testar conectividade da porta 3389 a partir do cliente

Test-NetConnection -ComputerName &lt;PC ou IP&gt; -Port 3389

Ver se a porta está a escutar no destino

netstat -ano | findstr 3389

Verificar estado da conta

net user &lt;usuario&gt;

Consultar sessões e usuários conectados

quser
qwinsta

Checar logs de falhas de logon RDP

eventvwr.msc

Navegue até Logs do Windows > Segurança e Aplicativos e Serviços > Microsoft > Windows > TerminalServices‑LocalSessionManager para detalhes de falhas e motivos.

Perguntas frequentes

Posso usar o e‑mail como usuário?
Sim, quando a sessão mostra MicrosoftAccount\email@dominio.com no whoami, digite o e‑mail no campo Usuário. Se falhar, experimente o formato completo MicrosoftAccount\email@dominio.com.

O “nome exibido” do Windows é diferente do nome de logon. Qual usar?
Sempre use o identificador de logon revelado por whoami. O nome exibido é apenas um rótulo amigável.

Windows Home recebe RDP?
Não. A edição Home pode iniciar clientes RDP, mas não aceita conexões como host.

PIN/Windows Hello funcionam por RDP?
Não. Você precisa da senha da conta (Microsoft, local ou domínio).

Como limpar credenciais salvas que continuam erradas?
Abra Gerenciador de Credenciais > Credenciais do Windows e remova entradas TERMSRV/<PC> e TERMSRV/<IP>. Depois, em mstsc.exe, use Mais escolhas > Usar uma conta diferente.

Ambiente corporativo com domínio/Entra ID tem algo a mais?
Sim. Políticas podem negar o logon por RDP, exigir NLA estrito, impor horários de logon e restringir dispositivos. Confirme com TI os direitos em Permitir logon por Serviços de Área de Trabalho Remota e se o seu usuário não está no conjunto de negação.

Resumo prático

Garanta que o PC de destino é Windows Pro/Enterprise/Education e que RDP está ativo com a regra de Firewall habilitada.
No destino, execute whoami e use exatamente o formato mostrado (por exemplo, PCNAME\usuario ou email@dominio.com).
Adicione a conta ao grupo Remote Desktop Users e confirme políticas de logon.
Faça o login com senha (não PIN) e, se necessário, limpe credenciais salvas antes de tentar novamente.

Seguindo este roteiro, a grande maioria dos erros de “usuário/senha não aceitos” em RDP no Windows 10 e 11 é resolvida de forma rápida, reproduzível e segura.