Conseguir RDP na LAN mas falhar via Internet com “logon attempt failed” quase sempre indica problema de autenticação ao atravessar o RD Gateway (ou no salto com NLA). Este guia mostra como diagnosticar e corrigir de forma objetiva no Windows Server 2016 Essentials.
Visão geral do cenário
Ao tentar se conectar por Área de Trabalho Remota (RDP) ao Windows Server 2016 Essentials a partir de uma rede externa, a sessão é negada com a mensagem “logon attempt failed”. Internamente (LAN), o mesmo usuário — tipicamente um Administrador de Domínio — conecta sem dificuldades. Os logs indicam que o RD Gateway autoriza a sessão, o que sugere que a recusa acontece no servidor de destino, durante a fase de NLA (Network Level Authentication) ou na validação final de políticas/direitos de logon.
No Essentials 2016, o acesso remoto normalmente passa pelo Anywhere Access/RD Gateway (porta 443/TLS). O Gateway aceita a conexão e cria o túnel, mas a autenticação contra o host de destino ainda precisa ser concluída com as credenciais corretas, obedecendo NLA e políticas de segurança do Windows.
Sinais que apontam a causa
| Comportamento observado | Interpretação provável |
|---|---|
| Funciona na LAN, falha via Internet, RDG “Authorized” | Credenciais erradas no salto, NLA/cliente desatualizado ou política de direitos de logon no host |
| Falha só quando “Usar minhas credenciais do RD Gateway” está marcado | O servidor tenta autenticar com UPN externo em vez do domínio interno |
| Falha para contas com senha expirada/“deve alterar” | Troca de senha bloqueada via NLA/RDG; precisa renovar senha antes |
| Evento 4625 com SubStatus 0xC000015B | Usuário não possui direito “Permitir logon por Serviços de Área de Trabalho Remota” |
| Conectividade 443 OK no Gateway, 3389 não exposto | Cenário correto de RDG; se mesmo assim falha, foque em credenciais/NLA/política |
Plano de resolução, passo a passo
Verificações rápidas de caminho de rede
Antes de mexer em políticas, garanta que o caminho até o servidor de destino está realmente chegando da forma esperada.
Como a conexão chega de fora
- Com RD Gateway (recomendado) — Porta TCP 443 exposta externamente: confirme FQDN público do Gateway e certificado TLS válido no cliente. Em Essentials, costuma ser o modo padrão.
- Sem Gateway (redirecionamento 3389) — Porta TCP 3389 encaminhada direto ao host: evite em produção; se estiver usando, verifique NAT/port‑forward e firewall perimetral.
Testes de conectividade úteis
No cliente remoto:
# Teste moderno (PowerShell)
Test-NetConnection gateway.seudominio.tld -Port 443
Se for acesso direto (não recomendado):
Test-NetConnection IP_PUBLICO -Port 3389
Alternativa clássica, se Telnet estiver instalado:
telnet gateway.seudominio.tld 443
telnet IP\_PUBLICO 3389 Sem conectividade, ajuste firewall/NAT antes de seguir. Se o RD Gateway responde em 443, avance para credenciais/NLA.
Diferencie credenciais do RD Gateway e do host de destino
O erro “logon attempt failed” costuma ocorrer quando o cliente envia ao host as credenciais do Gateway (geralmente UPN público) em vez do formato esperado pelo domínio interno.
- Abra mstsc.exe › Mostrar opções › Avançado › Configurações… (Gateway).
- Desmarque “Usar minhas credenciais do RD Gateway para o computador de destino”.
- Em Geral, no campo Usuário, force DOMÍNIO\usuário ou usuario@dominio.interno.
- No campo Computador, aponte para o FQDN interno do servidor (ex.:
srv01.corp.local), não para o FQDN do Gateway.
Para eliminar credenciais equivocadas:
Painel de Controle > Gerenciador de Credenciais > Credenciais do Windows
- Remova itens TERMSRV/* e do RD Gateway
- Tente conectar novamente
Diagnóstico com NLA
A NLA é a causa mais comum de falhas quando há salto via RDG, especialmente com clientes antigos ou com políticas de criptografia desatualizadas.
- No servidor de destino, execute
sysdm.cpl› guia Remoto. - Desmarque temporariamente “Permitir conexões somente de computadores com Área de Trabalho Remota com NLA”.
- Tente a conexão externa via RDG novamente.
Se a conexão passar a funcionar, o problema está no cliente (RDP desatualizado, TLS/Schannel incompatível) ou no encadeamento de credenciais pelo Gateway. Atualize o cliente RDP do PC remoto, reforce TLS modernos e reative a NLA após o teste — manter NLA desabilitada não é recomendável.
Dica: se você desabilitar a NLA para testar, documente e agende a reversão. Deixe claro para a operação quando NLA for reativada.
Senha expirada ou “deve alterar no próximo logon”
Contas com senha expirada ou marcadas para troca podem falhar via NLA/RDG com “logon attempt failed”, embora funcionem em cenários onde a troca de senha é possível (por exemplo, logon local/console).
- Verifique a conta no AD (Active Directory Users and Computers).
- Renove a senha e remova temporariamente a marca “O usuário deve alterar a senha no próximo logon”, se aplicável.
Comandos úteis de domínio (executar em host com RSAT)
# Ver se a senha expirou e quando foi alterada
Get-ADUser "Administrador" -Properties PasswordLastSet, PasswordExpired, msDS-UserPasswordExpiryTimeComputed |
Select-Object SamAccountName, PasswordExpired, PasswordLastSet,
@{Name="Expiry";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}}
Resetar senha de forma imediata
Set-ADAccountPassword -Identity "Administrador" -Reset -NewPassword (Read-Host -AsSecureString "Nova senha") Direitos de logon e grupos
Mesmo com credenciais corretas, o logon RDP pode falhar se o usuário não possuir o direito adequado ou se houver política de negação.
- Permitir logon por Serviços de Área de Trabalho Remota deve incluir Administrators e/ou Remote Desktop Users.
- Negar logon por Serviços de Área de Trabalho Remota não deve conter sua conta/grupo.
Onde verificar:
Configuração do Computador
> Configurações do Windows
> Configurações de Segurança
> Políticas Locais
> Atribuição de Direitos de Usuário
Em ambientes Essentials, valide também no RD Gateway Manager se as políticas CAP (Connection Authorization Policy) e RAP (Resource Authorization Policy) ainda permitem seu grupo de usuários e o servidor de destino.
Logs que explicam a recusa
O SubStatus dos eventos de segurança é a sua pista de ouro.
- No servidor de destino: Log de Segurança › evento 4625 (Falha de logon). Observe Status e SubStatus.
- Nos logs do RDP: Applications and Services Logs › Microsoft › Windows › TerminalServices-RemoteConnectionManager e RemoteDesktopServices-RdpCoreTS.
- No RD Gateway: Microsoft › Windows › TerminalServices-Gateway (confirma CAP/RAP e mapeia o alvo).
Consulta rápida por PowerShell
# Últimos 50 eventos 4625 com foco nos códigos
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-2)} -MaxEvents 50 |
Select-Object TimeCreated,
@{N='Status';E={$_.Properties[7].Value}},
@{N='SubStatus';E={$_.Properties[9].Value}},
@{N='IpOrigem';E={$_.Properties[19].Value}},
@{N='Conta';E={$_.Properties[5].Value}} |
Format-Table -Auto
Tabela de SubStatus comuns e como agir
| SubStatus | Significado | Correção típica |
|---|---|---|
0xC000006A | Senha incorreta | Limpar credenciais salvas; confirmar senha; verificar políticas de conta |
0xC0000064 | Usuário inexistente | Conferir domínio e grafia; usar DOMÍNIO\usuário ou UPN interno |
0xC0000234 | Conta bloqueada | Desbloquear a conta; investigar repetição de tentativas com credenciais antigas |
0xC0000072 | Conta desabilitada | Habilitar a conta ou usar conta apropriada |
0xC0000193 | Conta expirada | Estender validade ou recriar a conta |
0xC0000224 | Senha deve ser alterada | Trocar a senha fora do túnel RDP (ADUC, portal, help desk) e tentar novamente |
0xC0000071 | Senha expirada | Redefinir senha; verificar políticas de expiração |
0xC000015B | Tipo de logon não concedido | Garantir direito Permitir logon por Serviços de Área de Trabalho Remota |
0xC000018D | Falha de relacionamento de confiança | Reassociar máquina ao domínio se necessário; checar canal seguro |
0xC000006E | Restrição de conta (ex.: horário) | Ajustar horários permitidos ou política de estação de trabalho |
Outros pontos que costumam resolver
- DNS/Nomes: no campo Computador do mstsc, use o nome interno (
srv01.dominio.local) ou o IP interno do servidor, não o FQDN público do Gateway. - Certificados: o certificado do RDG deve corresponder ao nome público e a cadeia precisa ser confiável no cliente. Se houver alerta de certificado, corrija antes de culpar credenciais.
- Cliente alternativo: se tiver VPN, conecte e teste RDP direto ao IP interno. Se via VPN funciona, mas via RDG não, o gargalo está no Gateway/credenciais/NLA.
- TLS/Schannel: clientes legados com TLS antigos podem falhar NLA. Atualize o cliente RDP e a pilha TLS do sistema.
- Sinc. de horário: diferenças de tempo grandes entre cliente/servidor podem quebrar Kerberos. Verifique com
w32tm /query /status. - Porta RDP alterada: se o host usa porta diferente de 3389, ajuste no cliente (
srv01:3390) e na RAP do Gateway. - Firewall do servidor: confirme regra Remote Desktop (TCP‑In) ativa no perfil aplicável.
Fluxo de autenticação explicado
[Cliente RDP]
| 1. Autentica no RD Gateway (TLS 443) com credenciais A
v
[RD Gateway]
| 2. CAP verifica usuário/grupo
| 3. RAP autoriza alvo (host/porta)
v
[Túnel RDG->Host]
| 4. NLA no host solicita credenciais B (podem ser diferentes das de A)
v
[Servidor de Destino]
| 5. Valida B (AD/políticas/direitos) → se falhar, evento 4625
v
[Conexão RDP estabelecida]
Se o passo 5 falhar com “logon attempt failed”, foque em formato de credenciais, NLA, senha expirada e direitos de logon.
Playbook de correção rápida
- No cliente, desmarque “Usar minhas credenciais do RDG para o computador de destino”.
- Informe usuário como DOMÍNIO\usuário ou usuario@dominio.interno.
- Limpe credenciais salvas do RDP/Gateway e tente novamente.
- Teste temporariamente sem NLA; se passar, atualize o cliente e reative NLA.
- Verifique se a conta não está expirada/bloqueada/obrigada a trocar senha.
- Revise CAP/RAP do RDG e os direitos de logon RDP no host.
- Leia o evento 4625 e anote o SubStatus — ele diz exatamente o que arrumar.
Procedimentos detalhados no RD Gateway
No servidor Essentials (com RD Gateway instalado automaticamente):
- Abra Server Manager › Tools › Remote Desktop Gateway Manager.
- Em Policies:
- CAP: confirme que o grupo do seu usuário (ex.: Domain Users ou um grupo específico) está incluído; autenticação deve ser por senha (ou MFA, se configurado).
- RAP: inclua o servidor de destino (Computer Group ou host específico) e a porta correta.
- Em Monitoring, veja sessões recentes para confirmar “Connection authorized” e o Target Name correto.
Diagnóstico de ponta com comandos
Checar porta RDP configurada no host
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
-Name PortNumber | Select-Object PortNumber
Exportar direitos de usuário locais (para auditar “Allow log on through RDS”)
secedit /export /cfg C:\Temp\secpol.cfg
notepad C:\Temp\secpol.cfg # Procure por SeRemoteInteractiveLogonRight / SeDenyRemoteInteractiveLogonRight
Relatório de GPO efetiva
gpresult /h C:\Temp\gp.html
start C:\Temp\gp.html
Capturar eventos 4625 e logs RDP para enviar ao suporte
# Exportar eventos de Segurança e RDP
wevtutil epl Security C:\Temp\Security.evtx /q:"Event[System[(EventID=4625) and TimeCreated[timediff(@SystemTime) <= 86400000]]]"
wevtutil epl "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" C:\Temp\Rcm.evtx
wevtutil epl "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational" C:\Temp\RdpCore.evtx
Causas frequentes e soluções objetivas
| Causa provável | Sinais | Como corrigir |
|---|---|---|
| UPN externo usado no host | Funciona só quando usa DOMÍNIO\usuário | Desmarcar uso de credenciais do RDG; usar UPN interno ou DOMÍNIO\usuário |
| NLA com cliente antigo | Sem NLA funciona; com NLA falha | Atualizar cliente RDP; reforçar TLS; reativar NLA |
| Senha expirada/“deve alterar” | 4625 com 0xC0000224/0xC0000071 | Resetar senha no AD; remover “deve alterar” temporariamente |
| Direito de logon ausente | 4625 com 0xC000015B | Incluir grupo do usuário em “Permitir logon por RDS” e remover de “Negar” |
| CAP/RAP restritivas | RDG autoriza usuário, mas RAP não mapeia o host | Ajustar RAP para incluir o servidor de destino e porta correta |
| Porta RDP customizada | RAP/Cliente apontando 3389, host escuta outra | Atualizar RAP e cliente para host:porta |
| Skew de horário/Kerberos | Erros intermitentes após reinícios | Corrigir NTP; manter desvios < 5 minutos |
Boas práticas de segurança para produção
- Evite expor a porta 3389 diretamente à Internet. Prefira RD Gateway na porta 443 ou VPN com MFA.
- Restringa CAP/RAP por grupos específicos e recursos necessários. Menos é mais.
- Habilite MFA no Gateway sempre que possível.
- Monitore eventos 4625 e alarmes de bloqueio de conta; salve trilhas para auditoria.
- Padronize formato de credenciais no seu how‑to corporativo: “Sempre usar DOMÍNIO\usuário no RDP”.
- Mantenha clientes RDP e SOs atualizados para suportar NLA e TLS modernos.
Perguntas frequentes
Por que o RD Gateway “autoriza” e ainda assim o logon falha?
Porque a autorização do Gateway valida acesso ao túnel (CAP/RAP). A autenticação final ocorre no host de destino. Se falhar (NLA, senha expirada, direitos), o RDG já terá feito sua parte, mas o servidor recusará a sessão.
Posso usar a mesma credencial para Gateway e host?
Sim, mas isso não significa que o formato seja o mesmo. O Gateway aceita UPN público, enquanto o host pode requerer DOMÍNIO\usuário ou UPN do domínio interno. Desmarcar o uso automático de credenciais do RDG evita confusões.
Desabilitar a NLA resolve definitivamente?
Não é recomendado. A NLA protege o servidor antes de abrir a sessão RDP. Use a desativação apenas para teste, corrija o cliente e volte a ativar.
O problema ocorre só com um usuário específico. O que verificar?
Senha expirada, bloqueio por tentativas anteriores (cache do cliente), direitos de logon e membership em grupos que podem estar na lista “Negar logon por RDS”.
Exemplo de roteiro para o help desk
- Confirmar que o usuário está usando DOMÍNIO\usuário e que “Usar minhas credenciais do RDG…” está desmarcado.
- Pedir para limpar credenciais salvas (TERMSRV/* e Gateway) e refazer o teste.
- Executar
Test-NetConnection gateway.seudominio.tld -Port 443no cliente; registrar resultado. - Solicitar ao time de servidores a leitura do evento 4625 mais recente no host, com SubStatus.
- Se o SubStatus for 0xC0000224/0xC0000071, resetar senha e liberar logon; se 0xC000015B, ajustar direitos de logon; se 0xC000006A, limpar credenciais e testar novamente.
- Caso a conexão funcione com NLA desabilitada, atualizar cliente RDP e reativar NLA.
Resumo prático
- Cliente: desmarcar uso de credenciais do RDG para o host e informar DOMÍNIO\usuário.
- Limpeza: remover credenciais salvas do RDP/Gateway.
- NLA: testar temporariamente sem NLA; se funcionar, atualizar cliente e reativar.
- Conta: checar expiração/bloqueio/“deve alterar”.
- Políticas: CAP/RAP no RDG e direitos de logon RDP no host.
- Logs: ler 4625 e agir pelo SubStatus.
Checklist copiável
[ ] Conectividade 443 (Gateway) ou 3389 (sem Gateway) confirmada
[ ] "Usar minhas credenciais do RDG..." desmarcado no mstsc
[ ] Usuário no formato DOMÍNIO\usuário ou usuario@dominio.interno
[ ] Credenciais TERMSRV/* removidas do Gerenciador de Credenciais
[ ] Teste sem NLA (temporário) → cliente RDP atualizado → NLA reativada
[ ] Senha verificada (sem expiração/obrigação de troca)
[ ] CAP/RAP conferidas (usuário/host/porta corretos)
[ ] Direitos de logon RDS conferidos (Allow/Deny)
[ ] Evento 4625 analisado (SubStatus mapeado e tratado)
Boa prática: evite expor a 3389 na Internet; padronize RD Gateway (443) ou VPN com MFA, e limite CAP/RAP por grupos e recursos mínimos necessários.