Erro RDP: autenticação ao nível da rede falhou

Introduz o nome de utilizador e a palavra-passe na Ligação ao Ambiente de Trabalho Remoto, clica em Ligar e, antes de aparecer qualquer ecrã de início de sessão, surge uma mensagem de erro. Sem ambiente de trabalho, sem barra de progresso, nada. É exatamente esta a assinatura de um problema de NLA: a autenticação ao nível da rede decorre antes do estabelecimento da sessão. Se falhar, nunca chega a ver um ecrã de início de sessão onde pudesse corrigir seja o que for.

Este artigo percorre as causas realistas pela ordem em que surgem na prática e mostra, para cada uma, o comando de verificação, a solução e o caminho de regresso quando o RDP está completamente morto.

As mensagens de erro, palavra por palavra

Não existe uma única mensagem, mas antes um punhado delas, e o texto exato já delimita bastante a causa. Estas são as variantes com que mais se depara:

• "O computador remoto requer Autenticação ao Nível da Rede, que o seu computador não suporta." O servidor exige NLA e o cliente não o fornece. Típico em clientes antigos, em clientes de terceiros sob Linux ou macOS e em políticas de cliente mal definidas.
• "Ocorreu um erro de autenticação. Não é possível contactar a Autoridade de Segurança Local." Em inglês: "The Local Security Authority cannot be contacted". É a clássica mensagem de certificado ou de desvio horário.
• "Ocorreu um erro de autenticação. A função pedida não é suportada." Isto é quase sempre CredSSP e não NLA em sentido estrito. Mais sobre o assunto adiante.
• "As credenciais utilizadas para estabelecer a ligação não funcionam." Conta bloqueada, desativada, palavra-passe expirada ou conta em falta no grupo Utilizadores do Ambiente de Trabalho Remoto.
• "Não foi possível estabelecer a relação de confiança entre esta estação de trabalho e o domínio primário." A conta de computador no domínio já não corresponde.

Importante para a distinção: se o cliente indicar ao fim de vinte segundos que o computador remoto não está acessível, isso não é um erro de NLA, mas sim rede, firewall ou um serviço que não está a correr. Os erros de NLA chegam depressa, normalmente em um a três segundos, porque a ligação TCP está de pé e só depois falha a autenticação.

Causa 1: desvio horário entre cliente e servidor

Esta é, de longe, a causa mais frequente e também a mais ignorada, porque "o relógio está um bocadinho errado" soa a problema inofensivo. Não é. Dois mecanismos quebram de imediato com desvio horário:

• O Kerberos tolera, por predefinição, no máximo cinco minutos de desvio. Acima disso, o controlador de domínio rejeita o pedido com KRB_AP_ERR_SKEW. Afeta todos os membros do domínio.
• A verificação TLS do certificado RDP falha quando o relógio do cliente está fora do período de validade do certificado do servidor. Isto atinge também servidores isolados sem domínio, precisamente quando o servidor arranca depois de um reinício com um relógio no passado e um certificado acabado de gerar ainda não é válido do ponto de vista do cliente.

Verificação no servidor, numa PowerShell com direitos de administrador:

w32tm /query /status /verbose
w32tm /query /source
w32tm /stripchart /computer:ptbtime1.ptb.de /samples:5 /dataonly

O stripchart devolve o desvio em segundos. Tudo abaixo de um segundo é bom, tudo acima de 60 segundos é suspeito e tudo acima de 300 segundos explica o erro.

Aqui os sistemas separam-se, e a maioria dos tutoriais mete tudo no mesmo saco:

• Servidor isolado sem domínio: definir uma fonte NTP externa.
• Membro do domínio: nunca definir uma lista de pares própria. Um servidor membro tem de obter a hora a partir da hierarquia do domínio, caso contrário deriva em relação ao controlador de domínio.

w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x9 time.windows.com,0x9" /syncfromflags:manual /update

w32tm /config /syncfromflags:domhier /update

Em ambos os casos, reinicie a seguir o serviço e sincronize:

net stop w32time
net start w32time
w32tm /resync /rediscover

Uma particularidade que apanha quem trabalha com servidores virtualizados: se o relógio estiver exatamente uma ou duas horas errado, não se trata de deriva, mas de um problema de interpretação do relógio de hardware. O Windows espera o RTC em hora local, ao passo que muitas plataformas de virtualização o disponibilizam em UTC. Verifique primeiro o fuso horário e altere depois, se for o caso, a interpretação:

tzutil /g
tzutil /s "W. Europe Standard Time"

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Causa 2: certificado expirado ou mal associado

Sem uma PKI própria, o Windows gera para o RDP um certificado autoassinado com cerca de meio ano de validade, que normalmente se renova sozinho. "Normalmente" é aqui a palavra operativa. Se a renovação falhar por causa de permissões no arquivo de chaves, ou se um certificado associado à mão a partir de uma CA interna expirar, deixa de conseguir iniciar sessão e vê a mensagem sobre a Autoridade de Segurança Local.

Verificar o que existe:

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Select-Object Subject, NotBefore, NotAfter, Thumbprint

E, a seguir, que certificado o listener utiliza realmente:

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'").SSLCertificateSHA1Hash

Compare o hash devolvido com os thumbprints do primeiro comando. Há dois quadros de erro possíveis: o hash aponta para um certificado expirado, ou aponta para um certificado que já nem sequer está no arquivo.

A reparação consiste em desfazer a associação e remover o certificado antigo. O Windows gera depois um novo no arranque do serviço:

Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name SSLCertificateSHA1Hash -ErrorAction SilentlyContinue

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Where-Object { $_.NotAfter -lt (Get-Date) } | Remove-Item

Restart-Service TermService -Force

Duas advertências a este respeito. Primeiro, o reinício do TermService derruba todas as sessões RDP existentes, incluindo a sua, caso ainda esteja lá dentro de alguma forma. Execute isto através da consola. Segundo: se uma política de grupo impuser um modelo de certificado para a autenticação de servidor, o servidor vai buscar o certificado à CA interna. Se a CA não estiver acessível ou o modelo tiver expirado, não chega nenhum certificado novo e o erro mantém-se. Nesse caso, verifique primeiro a CA e não o servidor.

Controlo de êxito: o primeiro comando devolve agora um certificado com uma data NotAfter no futuro, e o SSLCertificateSHA1Hash aponta exatamente para esse.

Causa 3: conta bloqueada, desativada ou palavra-passe expirada

Aqui está a armadilha que distingue o NLA de todos os outros problemas de início de sessão: com o NLA ativo, não é possível alterar uma palavra-passe expirada através do cliente RDP. A caixa de diálogo "A sua palavra-passe expirou e tem de ser alterada" só aparece dentro da sessão, e à sessão não chega sem passar pela autenticação. Em vez disso, o cliente limita-se a dizer que as credenciais não funcionam. A palavra-passe está perfeitamente correta, apenas expirou.

Ver o estado de uma conta local:

net user Administrator

Preste atenção às linhas "Conta ativa", "A conta expira", "A palavra-passe expira" e "Palavra-passe expirável". As contramedidas adequadas:

net user Administrator "NovaPalavraPasseLonga!2026"

Enable-LocalUser -Name "Administrator"

Set-LocalUser -Name "Administrator" -PasswordNeverExpires $true

Uma conta local bloqueada depois de demasiadas tentativas falhadas é um estado próprio, que não é anulado nem por Enable-LocalUser nem por uma alteração de palavra-passe. Desbloqueia-se sozinha no fim do período de bloqueio, que pode consultar assim:

net accounts

Desbloquear de imediato consegue-se sem gestão gráfica, através de ADSI:

$u = [ADSI]"WinNT://./Administrator,user"; $u.IsAccountLocked = $false; $u.SetInfo()

Quando as portas RDP estão acessíveis a partir da Internet, os bloqueios acontecem praticamente todos os dias, porque há bots a experimentar a sua conta de administrador. É um argumento forte para restringir o acesso, em vez de andar sempre a desbloquear a conta. Uma porta diferente ajuda de forma percetível contra os varrimentos em massa, veja Alterar a porta RDP sem reiniciar.

Por fim, a pertença ao grupo. O nome do grupo está localizado, o que costuma desfazer scripts. De forma independente do idioma, a consulta faz-se pelo SID conhecido:

Get-LocalGroupMember -SID "S-1-5-32-555"

Causa 4: NLA desativado ou meio desativado no servidor

Dois interruptores distintos determinam o comportamento, e é precisamente a combinação deles que causa os problemas. UserAuthentication controla o NLA, SecurityLayer a proteção do transporte, com os valores 0 para a antiga camada de segurança do RDP, 1 para negociação e 2 para TLS forçado.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer

O beco sem saída típico: alguém desliga o NLA por suspeitar de um problema de certificado, mas deixa o SecurityLayer em 2. Assim, a negociação TLS com o certificado avariado mantém-se e o erro só muda de redação. Se quiser mesmo baixar ambos para diagnosticar, baixe ambos e reponha tudo a seguir.

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'") | Invoke-CimMethod -MethodName SetUserAuthenticationRequired -Arguments @{UserAuthenticationRequired=0}

O segundo beco sem saída é ainda mais desagradável: define o valor no registo, reinicia, e ele volta a estar em 1. Nesse caso, vem de uma política de grupo. Os valores de política ficam noutro sítio e ganham sempre:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication

gpresult /r /scope:computer

Enquanto lá estiver um valor, qualquer alteração local só é válida até à próxima aplicação da política. A política chama-se "Requerer autenticação do utilizador para ligações remotas através da Autenticação ao Nível da Rede" e tem de ser alterada no controlador de domínio.

E a regra mais importante para fechar esta secção: desligar o NLA de forma permanente não é uma solução, é uma porta aberta. Sem NLA, qualquer pessoa que chegue à porta consegue alcançar o ecrã de início de sessão e, com ele, uma parte desprotegida da stack de sessão. Desligue-o para diagnosticar e volte a ligá-lo a seguir.

Causa 5: relação de confiança de domínio quebrada

Cada conta de computador num domínio tem uma palavra-passe própria, trocada automaticamente a cada 30 dias por predefinição. Se os estados do servidor e do controlador de domínio deixarem de coincidir, o servidor já não consegue autenticar contas de domínio, e o NLA falha para todos os utilizadores de domínio, enquanto as contas locais continuam a funcionar. É exatamente este padrão que prova esta causa.

O desencadeador clássico na operação de servidores é uma reposição para um estado mais antigo, por exemplo a partir de um backup ou snapshot anterior à última troca de palavra-passe. Verificar:

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:omeudominio.local

Reparar, com sessão iniciada como administrador local através da consola:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Reset-ComputerMachinePassword -Credential (Get-Credential)

Retirar o servidor do domínio e voltar a juntá-lo não é preciso para isto e piora muitas vezes a situação, porque nesse processo se podem perder pertenças a grupos e permissões da conta de computador antiga. Depois da reparação, basta reiniciar o serviço Netlogon:

Restart-Service Netlogon

Quando o RDP deixa mesmo de funcionar: o caminho pela consola

Todos os comandos anteriores pressupõem que consegue chegar de alguma forma ao servidor. É precisamente isso que não acontece no pior cenário. Nos servidores root KVM da KernelHost tem por isso, na área de cliente, uma consola VNC que funciona independentemente do RDP, da firewall do Windows e até da stack de rede do sistema convidado. É o acesso de emergência com que se liberta sozinho de qualquer das situações descritas acima. Nos Servidores Dedicados, o acesso de emergência passa pelo suporte.

Três coisas que na consola VNC são diferentes de uma sessão RDP e que custam tempo com regularidade:

• Esquema de teclado. A consola apresenta muitas vezes um esquema US, enquanto o Windows está em português, ou ao contrário. Os caracteres especiais das palavras-passe saem então errados e toma por incorreta uma palavra-passe que está certa. Na dúvida, use o teclado no ecrã com osk.exe a partir do ecrã de início de sessão.
• Área de transferência. Copiar do computador próprio para a consola normalmente não funciona. Conte com escrever tudo à mão e escolha as palavras-passe temporárias em conformidade.
• Início de sessão como conta local. Em caso de problemas de domínio, inicie sessão com .\Administrator, porque o ponto e a barra invertida forçam a conta local em vez da conta de domínio.

Na consola, verifique então os fundamentos antes de mexer no NLA:

sc query TermService

netstat -ano | findstr :3389

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

Se fDenyTSConnections estiver em 1, as ligações remotas estão completamente desligadas, independentemente do NLA:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

As regras de firewall ativam-se de forma independente do idioma através do identificador interno do grupo, porque o nome de grupo apresentado varia consoante o idioma do sistema:

Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"

O caso especial do CredSSP, que tantas vezes se confunde

Se a mensagem disser literalmente "A função pedida não é suportada" e referir a correção do oráculo de encriptação do CredSSP, então nenhuma das cinco causas acima é a culpada. Aqui, os níveis de atualização do cliente e do servidor não coincidem: um dos lados exige a variante reforçada do CredSSP, o outro ainda não a conhece.

A única solução limpa passa por atualizar os dois lados. A alteração de registo que circula pela Internet com AllowEncryptionOracle no cliente anula precisamente o reforço que provoca o erro e volta assim a abrir um vetor de ataque conhecido. Se precisar dela por pouco tempo para instalar as atualizações, reponha-a assim que o servidor estiver atualizado.

Como perceber que o problema está mesmo resolvido

Uma ligação bem-sucedida é a prova mais fraca, porque também funciona quando desligou o NLA para diagnosticar. Verifique antes, pela ordem:

1. O NLA está novamente ativo. UserAuthentication está em 1 e SecurityLayer em 2.
2. O relógio está certo. O desvio do stripchart fica abaixo de um segundo, e w32tm /query /source indica uma fonte real, não "Local CMOS Clock" nem "Free-running System Clock".
3. O certificado é válido. A data NotAfter está no futuro, e o hash associado aponta exatamente para esse certificado.
4. O registo de eventos confirma que a autenticação de rede foi ultrapassada. O evento 1149 só aparece depois de o NLA ter sido percorrido, sendo por isso a verdadeira prova.

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 20 | Where-Object Id -eq 1149

Para a contraprova em tentativas falhadas, os códigos de estado no evento 4625 são mais elucidativos do que qualquer mensagem do cliente: 0xC0000071 corresponde a uma palavra-passe expirada, 0xC0000072 a uma conta desativada, 0xC0000234 a uma conta bloqueada e 0xC000006A a uma palavra-passe realmente errada.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

Para terminar, as próprias sessões, de preferência a partir da consola:

qwinsta

Comparação rápida para a resolução de problemas

Quando instala um servidor Windows de raiz, vale a pena acertar logo de início a fonte de tempo, as políticas de conta e a via de acesso, em vez de as reparar mais tarde sob pressão. Como orientação serve a lista de verificação para o novo servidor root, e quem quiser proteger adicionalmente o acesso RDP encontra em Alterar a porta RDP sem reiniciar o primeiro passo menos trabalhoso contra as tentativas automatizadas de início de sessão.