Diagnóstico de anomalias de conectividade RDP em servidor Windows
RDP · Windows Server · Troubleshooting · Helpdesk · GPO · NLA
Resumo rápido (TL;DR): No diagnóstico RDP Windows, valide por ordem: serviço TermService, porta 3389 TCP, firewall, NLA, permissões de utilizador, políticas GPO e logs do Event Viewer. Este guia cobre cada passo com comandos PowerShell prontos a usar.
Índice
- Triagem inicial — identificar o tipo de erro
- Serviço TermService e porta 3389 TCP/UDP
- Firewall Windows e regras de rede
- NLA — Network Level Authentication
- Permissões de utilizador e grupo Remote Desktop Users
- Políticas de Grupo (GPO)
- Certificados RDP e erros de confiança
- Event Viewer — canais e IDs críticos
- Comandos de diagnóstico — netstat, telnet, PowerShell
- Erros comuns e resolução
- Checklist pós-correção
- FAQ
Quando uma ligação RDP falha, o erro pode estar no cliente, no servidor ou no caminho de rede entre ambos. O método mais eficaz é seguir uma sequência técnica rigorosa e eliminar hipóteses até encontrar a causa raiz. Este guia cobre o processo completo — desde a mensagem de erro inicial até ao Event Viewer — com os comandos exatos para cada passo.
1. Triagem inicial — identificar o tipo de erro
O primeiro passo é analisar a mensagem de erro exata apresentada pelo cliente RDP. Cada mensagem aponta para uma camada diferente do problema e poupa tempo significativo no diagnóstico.
| Mensagem de erro RDP | Causa provável | Secção a consultar |
|---|---|---|
| “Não é possível ligar ao computador remoto” | Rede, firewall, porta 3389 fechada ou serviço parado | Secções 2, 3 |
| “O computador remoto requer NLA” | Cliente não suporta NLA ou credenciais inválidas antes da sessão | Secção 4 |
| “Acesso negado” / “As credenciais não funcionaram” | Conta sem permissão RDP, conta bloqueada ou expirada | Secção 5 |
| “Política de segurança não permite este pedido” | GPO a bloquear acesso RDP ou utilizador fora do grupo correto | Secção 6 |
| “O certificado não é de confiança” | Certificado RDP auto-assinado ou expirado | Secção 7 |
| “Ocorreu um erro interno” / sem mensagem específica | Problema no servidor — verificar Event Viewer | Secção 8 |
Antes de avançar, confirme também:
- O erro afeta todos os utilizadores ou apenas um utilizador específico?
- O erro ocorre a partir de todas as redes ou apenas de uma localização?
- Ligar por IP direto vs. nome DNS produz resultado diferente?
- O problema é recente (após update, mudança de GPO, etc.) ou sempre existiu?
2. Serviço TermService e porta 3389 TCP/UDP
O Remote Desktop Services assenta no serviço TermService. Se este serviço estiver parado ou em erro, a porta 3389 não estará em escuta e qualquer tentativa de ligação falha imediatamente. É o primeiro ponto a verificar.
Verificar e iniciar o serviço TermService
# Verificar estado do serviço
Get-Service TermService
# Iniciar o serviço se estiver parado
Start-Service TermService
# Configurar para iniciar automaticamente
Set-Service TermService -StartupType Automatic
# Verificar se RDP está ativo nas definições do sistema
Get-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Control\Terminal Server’ -Name fDenyTSConnections
O valor fDenyTSConnections = 0 significa que o RDP está ativo. Se o valor for 1, o RDP está desativado — corrija com:
# Ativar RDP no servidor (requer permissão de administrador)
Set-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Control\Terminal Server’ -Name fDenyTSConnections -Value 0
# Alternativa via Enable-NetFirewallRule para garantir regras ativas
Enable-NetFirewallRule -DisplayGroup “Remote Desktop”
Porta 3389 — TCP e UDP
O RDP usa porta 3389 TCP como protocolo principal — é obrigatório. Desde o Windows Server 2012 R2, o RDP também usa a porta 3389 UDP para otimização de desempenho (transmissão de ecrã com menor latência via UDP Datagram Transport Layer Security — DTLS). Se o UDP estiver bloqueado, a ligação RDP funciona mas com qualidade de imagem inferior e maior latência.
# Verificar se a porta 3389 TCP está em escuta no servidor
Get-NetTCPConnection -LocalPort 3389 -State Listen
# Verificar conectividade TCP 3389 a partir de outro sistema
Test-NetConnection -ComputerName 192.168.1.10 -Port 3389
# Verificar com netstat (útil em Windows Server sem PowerShell 5+)
netstat -an | findstr :3389
# Verificar também UDP 3389
Get-NetUDPEndpoint -LocalPort 3389
Nota sobre mudança de porta: Mudar o RDP da porta 3389 para outra porta reduz o ruído de scans automatizados, mas não é uma medida de segurança. Não substitui MFA, NLA, segmentação de rede e controlo de acesso. Se mudar a porta, atualize também as regras de firewall e documente a mudança.
3. Firewall Windows e regras de rede
Mesmo com o serviço ativo e a porta em escuta, o Windows Firewall pode bloquear as ligações. Verifique o estado das regras de Remote Desktop em todos os perfis (Domain, Private, Public).
# Listar regras de Remote Desktop e o seu estado
Get-NetFirewallRule -DisplayGroup “Remote Desktop” | Select-Object DisplayName, Enabled, Profile, Action
# Ativar as regras de Remote Desktop em todos os perfis
Enable-NetFirewallRule -DisplayGroup “Remote Desktop”
# Verificar se existe alguma regra de bloqueio explícito para a porta 3389
Get-NetFirewallRule | Where-Object {$_.Action -eq “Block”} | Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq “3389”}
# Testar conectividade TCP com mensagem detalhada
Test-NetConnection -ComputerName servidor.dominio.local -Port 3389 -InformationLevel Detailed
Para ambientes com firewall de rede externo (hardware firewall, NSG Azure, Security Group AWS), confirme que as regras permitem TCP 3389 (e UDP 3389 se quiser qualidade otimizada) da origem para o servidor. Use telnet ou Test-NetConnection a partir de uma máquina cliente para confirmar conectividade de rede antes de aprofundar o diagnóstico no servidor.
# Teste de conectividade com telnet (se instalado)
telnet 192.168.1.10 3389
# Se telnet não estiver instalado, usar Test-NetConnection
Test-NetConnection -ComputerName 192.168.1.10 -Port 3389
# Traceroute para identificar onde a ligação é bloqueada
tracert 192.168.1.10
4. NLA — Network Level Authentication
O Network Level Authentication (NLA) é um mecanismo de segurança que exige autenticação do utilizador antes de ser estabelecida a sessão RDP completa. Isto significa que o servidor não carrega o ecrã de login — autentica via Kerberos ou NTLM antes de consumir recursos. O NLA é altamente recomendado e ativo por defeito no Windows Server 2008 R2 e posteriores.
Problemas comuns com NLA
- Cliente desatualizado: clientes RDP antigos (Windows XP SP2 ou anterior) não suportam NLA — atualizar o cliente ou usar CredSSP.
- Conta expirada ou bloqueada: o NLA falha antes de mostrar qualquer ecrã — o utilizador vê “acesso negado” sem perceber o motivo.
- Problemas de Kerberos: se o servidor não consegue contactar o controlador de domínio para autenticação Kerberos, o NLA falha mesmo com credenciais corretas.
- Desajuste de fuso horário: diferença superior a 5 minutos entre cliente, servidor e DC invalida tickets Kerberos.
# Verificar se NLA está ativo no servidor
Get-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -Name UserAuthentication
# UserAuthentication = 1 → NLA ativo (recomendado)
# UserAuthentication = 0 → NLA inativo
# Desativar NLA temporariamente para diagnóstico (NUNCA em produção sem controlo de acesso)
Set-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -Name UserAuthentication -Value 0
# Reativar NLA após diagnóstico
Set-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -Name UserAuthentication -Value 1
Atenção: Desativar o NLA expõe o servidor a ataques de força bruta no ecrã de login e a exploits que aproveitam a fase pré-autenticação. Use esta opção apenas temporariamente para diagnóstico e reative imediatamente após confirmar a causa do problema.
5. Permissões de utilizador e grupo Remote Desktop Users
Para ligar via RDP, o utilizador precisa de pertencer ao grupo local Remote Desktop Users no servidor, ou ser membro do grupo Administrators (que tem acesso RDP por defeito). Sem esta associação, a ligação é recusada mesmo com credenciais corretas.
# Verificar membros do grupo Remote Desktop Users no servidor
Get-LocalGroupMember -Group “Remote Desktop Users”
# Adicionar utilizador ao grupo Remote Desktop Users
Add-LocalGroupMember -Group “Remote Desktop Users” -Member “DOMINIO\utilizador”
# Verificar se a conta está ativa e não expirada
Get-ADUser -Identity “utilizador” -Properties Enabled, LockedOut, PasswordExpired, AccountExpirationDate
# Desbloquear conta se necessário
Unlock-ADAccount -Identity “utilizador”
# Verificar grupos a que o utilizador pertence no AD
Get-ADPrincipalGroupMembership -Identity “utilizador” | Select-Object Name
Em ambientes de domínio, também pode adicionar grupos de segurança do AD ao grupo local Remote Desktop Users — desta forma gere o acesso RDP centralmente no Active Directory sem tocar em cada servidor individualmente.
# Adicionar grupo AD ao grupo local Remote Desktop Users
Add-LocalGroupMember -Group “Remote Desktop Users” -Member “DOMINIO\GrupoHelpdeskRDP”
# Verificar número de sessões RDP simultâneas ativas (limite pode ser atingido)
query session /server:servidor
# Ver sessões e desligar sessões obsoletas se o limite estiver atingido
logoff [ID_SESSÃO] /server:servidor
6. Políticas de Grupo (GPO)
As GPO podem tanto ativar como bloquear o acesso RDP, independentemente do que estiver configurado localmente no servidor. Uma política mal configurada ou aplicada incorretamente é uma causa frequente de falhas RDP em ambientes de domínio — especialmente após reorganizações de OUs ou mudanças de GPO.
Políticas GPO críticas para RDP
| Política GPO | Caminho | Valor correto |
|---|---|---|
| Allow log on through Remote Desktop Services | Computer Config → Windows Settings → Security Settings → Local Policies → User Rights Assignment | Incluir “Remote Desktop Users” e “Administrators” |
| Deny log on through Remote Desktop Services | Computer Config → Windows Settings → Security Settings → Local Policies → User Rights Assignment | Garantir que o utilizador NÃO está aqui |
| Allow users to connect remotely using RDS | Computer Config → Admin Templates → Windows Components → Remote Desktop Services → RD Session Host → Connections | Enabled (ou Not Configured para herdar) |
| Network Level Authentication required | Computer Config → Admin Templates → Windows Components → Remote Desktop Services → RD Session Host → Security | Enabled (recomendado) |
# Forçar atualização de GPO no servidor
gpupdate /force
# Ver GPOs aplicadas e resultante no servidor
gpresult /r /scope computer
# Relatório HTML detalhado de todas as GPOs aplicadas
gpresult /h C:\Temp\gporesult.html
Start-Process C:\Temp\gporesult.html
# Verificar User Rights Assignment localmente
secedit /export /cfg C:\Temp\secpol.cfg /areas USER_RIGHTS
Get-Content C:\Temp\secpol.cfg | Select-String -Pattern “SeRemoteInteractiveLogonRight|SeDenyRemoteInteractiveLogonRight”
7. Certificados RDP e erros de confiança
O RDP usa certificados TLS para encriptar a sessão. Por defeito, o Windows Server gera um certificado auto-assinado que não é de confiança para clientes externos ao domínio. Em ambientes de domínio, é possível (e recomendado) configurar um certificado emitido pela CA interna para eliminar os avisos.
Verificar certificado RDP atual
# Ver thumbprint do certificado RDP atual
Get-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp’ -Name SSLCertificateSHA1Hash
# Listar certificados no store Personal do computador
Get-ChildItem -Path Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, NotAfter
# Verificar se o certificado RDP está expirado
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.NotAfter -lt (Get-Date)} | Select-Object Subject, Thumbprint, NotAfter
Para configurar um certificado emitido pela CA interna, use a GPO Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Automatic Certificate Request Settings com um template de tipo “Computer”, ou atribua manualmente o thumbprint do certificado correto via PowerShell.
8. Event Viewer — canais e IDs críticos
O Event Viewer é a fonte mais fiável de informação sobre falhas RDP. Os eventos relevantes estão distribuídos por vários canais — não apenas no canal “System”. Saber onde procurar poupa tempo considerável.
Canais do Event Viewer para diagnóstico RDP
| Canal | Caminho no Event Viewer | O que encontra aqui |
|---|---|---|
| TerminalServices-RemoteConnectionManager | Applications and Services Logs → Microsoft → Windows → TerminalServices-RemoteConnectionManager → Operational | Ligações aceites/recusadas, erros de autenticação NLA, falhas de serviço |
| TerminalServices-LocalSessionManager | Applications and Services Logs → Microsoft → Windows → TerminalServices-LocalSessionManager → Operational | Criação e fecho de sessões, reconexões, logoffs |
| Security | Windows Logs → Security | Falhas de logon (Event 4625), logons bem-sucedidos (4624), bloqueios de conta (4740) |
| System | Windows Logs → System | Erros do serviço TermService, problemas de driver de rede |
IDs de evento mais importantes para RDP
| Event ID | Canal | Significado |
|---|---|---|
| 1149 | RemoteConnectionManager | Autenticação de utilizador bem-sucedida (ligação aceite) |
| 261 | RemoteConnectionManager | Ligação RDP recebida mas rejeitada |
| 21 | LocalSessionManager | Logon de sessão RDP bem-sucedido |
| 23 | LocalSessionManager | Logoff de sessão RDP |
| 4625 | Security | Falha de logon — ver Failure Reason e Logon Type (tipo 10 = Remote Interactive) |
| 4740 | Security | Conta de utilizador bloqueada |
| 4624 | Security | Logon bem-sucedido — Logon Type 10 confirma sessão RDP |
# Consultar eventos RDP críticos via PowerShell (últimas 2 horas)
$inicio = (Get-Date).AddHours(-2)
# Falhas de logon RDP (Event 4625, Logon Type 10)
Get-WinEvent -FilterHashtable @{LogName=’Security’; Id=4625; StartTime=$inicio} | Where-Object {$_.Message -like “*Logon Type:*10*”} | Select-Object TimeCreated, Message | Format-List
# Ligações aceites
Get-WinEvent -FilterHashtable @{LogName=’Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational’; Id=1149; StartTime=$inicio} | Select-Object TimeCreated, Message
# Eventos de bloqueio de conta
Get-WinEvent -FilterHashtable @{LogName=’Security’; Id=4740; StartTime=$inicio} | Select-Object TimeCreated, Message
9. Comandos de diagnóstico — netstat, telnet, PowerShell
Esta secção reúne os comandos mais úteis para diagnóstico RDP, organizados por fase de investigação.
Diagnóstico de rede e porta
# No servidor — verificar que está a escutar na porta 3389
netstat -an | findstr :3389
# Deve mostrar: TCP 0.0.0.0:3389 LISTENING
# No cliente — testar conectividade TCP antes de tentar RDP
Test-NetConnection -ComputerName servidor -Port 3389
# Teste rápido com telnet (ativar se necessário)
# Install-WindowsFeature Telnet-Client
telnet servidor 3389
# Verificar rota de rede até ao servidor
tracert servidor
# Verificar resolução DNS do nome do servidor
Resolve-DnsName servidor
nslookup servidor
Diagnóstico de sessões ativas e limites
# Ver todas as sessões RDP ativas no servidor
query session /server:servidor
# Ver utilizadores ligados
query user /server:servidor
# Verificar limite de sessões (Windows Server sem RDS CALs: 2 sessões simultâneas)
Get-ItemProperty -Path ‘HKLM:\System\CurrentControlSet\Control\Terminal Server’ -Name MaxConnectionAllowed
# Desligar sessão específica (substituir ID pelo número de sessão)
logoff 3 /server:servidor
Diagnóstico de Active Directory e Kerberos
# Verificar sincronização de tempo com o DC (crítico para Kerberos)
w32tm /query /status
w32tm /stripchart /computer:dc01.dominio.local /samples:5 /dataonly
# Testar conectividade com o controlador de domínio
Test-NetConnection -ComputerName dc01.dominio.local -Port 88 # Kerberos
Test-NetConnection -ComputerName dc01.dominio.local -Port 389 # LDAP
# Verificar estado do Active Directory
nltest /dsgetdc:dominio.local
nltest /sc_verify:dominio.local
10. Erros comuns e resolução
| Sintoma | Causa mais provável | Resolução |
|---|---|---|
| Porta 3389 não responde (TcpTestSucceeded: False) | Serviço parado, firewall bloqueado, porta mudada | Verificar TermService, Enable-NetFirewallRule, confirmar porta no registo |
| Porta responde mas logon falha | Conta bloqueada, sem permissão RDP, GPO Deny | Verificar AD (conta ativa, grupo RDP Users), revisar gpresult |
| Funciona por IP mas não por nome DNS | Resolução DNS incorreta ou registo DNS desatualizado | Correr nslookup, limpar cache DNS no cliente, verificar registo A/PTR no DNS |
| NLA falha mas logon sem NLA funciona | Kerberos degradado, cliente desatualizado, conta expirada | Verificar sincronização de tempo, estado da conta no AD, atualizar cliente RDP |
| Sessão desliga após X minutos sem atividade | Timeout de sessão configurado em GPO ou no servidor | Rever Computer Config → RDS → Session Time Limits |
| Máximo de sessões atingido (Remote Desktop Service) | Sem licenças RDS CAL ou limite de 2 sessões de administrador atingido | Terminar sessões obsoletas com logoff, avaliar licenciamento RDS |
11. Checklist pós-correção
Após resolver a causa raiz, valide os seguintes pontos antes de fechar o incidente:
- Ligação testada com sucesso a partir de pelo menos duas redes diferentes (interna e externa se aplicável).
- Ligação testada com a conta do utilizador afetado — não apenas com conta de administrador.
- Event Viewer sem erros críticos nos canais RemoteConnectionManager e Security.
- Conta de utilizador ativa, sem bloqueio e com palavra-passe válida.
- NLA ativo e a funcionar corretamente após a correção.
- Serviço TermService configurado para inicio automático.
- GPO atualizada em todos os servidores afetados (
gpupdate /force). - Documentação do incidente atualizada: causa raiz, ações tomadas, data de resolução.
- Se foi mudada alguma configuração de segurança (NLA, firewall), confirmação de que foi revertida para o estado seguro.
Artigos Relacionados
- Event Viewer: diagnóstico de ligações e erros em Windows
- Diagnóstico de Active Directory em ambientes Windows
- VPN de acesso remoto: desenho e troubleshooting
- DNS: validações críticas em incidentes de conectividade
FAQ
Qual é a principal causa de falha RDP em PMEs?
As causas mais frequentes em suporte técnico são: serviço TermService parado (muitas vezes após update do Windows), regras de firewall bloqueadas, e conta de utilizador bloqueada por tentativas falhadas de login. Em ambientes de domínio, GPO mal configurada ou aplicada a OUs incorretas também é comum.
O RDP usa TCP e UDP na porta 3389 — qual é a diferença?
O TCP 3389 é obrigatório e é o canal principal de controlo e dados RDP. O UDP 3389 (disponível desde Windows Server 2012 R2) é usado para otimização de desempenho — transmissão de gráficos e ecrã com menor latência via DTLS. Se o UDP estiver bloqueado pelo firewall, a ligação RDP funciona via TCP mas com pior qualidade de imagem e maior latência percetível.
Vale a pena mudar a porta RDP de 3389 para outra?
Mudar a porta reduz o ruído de scans automatizados (bots que procuram 3389 aberto), mas não é uma medida de segurança real — scanners avançados testam todas as portas. Não substitui NLA, MFA, segmentação de rede e controlo de acesso por IP. Se mudar a porta, atualize as regras de firewall correspondentes e documente a mudança.
Como confirmar se o problema é de rede ou de credenciais?
Execute Test-NetConnection -ComputerName servidor -Port 3389 a partir do cliente. Se TcpTestSucceeded for False, o problema é de rede ou firewall — a porta não está acessível. Se for True, a porta responde e o problema está na autenticação, permissões ou NLA. Esta distinção direciona o diagnóstico de imediato.
O que é o NLA e por que é importante no RDP?
O Network Level Authentication (NLA) autentica o utilizador antes de o servidor carregar a sessão RDP completa. Sem NLA, qualquer pessoa que chegue à porta 3389 vê o ecrã de login do Windows — um vetor de ataque. Com NLA ativo, a autenticação ocorre via Kerberos ou NTLM antes de qualquer ecrã ser apresentado, reduzindo significativamente a superfície de ataque e o consumo de recursos do servidor.
Qual o número máximo de sessões RDP simultâneas num Windows Server normal?
Um Windows Server sem o papel Remote Desktop Session Host (RDSH) e sem licenças RDS CAL permite apenas 2 sessões simultâneas de administrador. Para suportar mais utilizadores em simultâneo é necessário instalar o papel RDSH e adquirir licenças RDS CAL (por utilizador ou por dispositivo). Atingir o limite de sessões é uma causa frequente de “não consigo ligar” em PMEs.
