Se, ao iniciar sessão num PC ingressado no AD, você vê “There is no logon server available…” ou “The security database… trust relationship”, este guia prático explica causas, diagnóstico e correção — priorizando reparar o secure channel sem sair do domínio.
Visão geral e sintomas
Após anos funcionando normalmente, um computador membro de domínio passa a exibir, ao tentar autenticar:
There is no logon server available to service the logon requestao usar contas do domínio.The security database on the server does not have a computer account for this workstation trust relationshipao tentar reinserir a máquina no domínio.- Em alguns cenários, até o administrador local falha ao iniciar sessão quando o equipamento está na rede, porque o Windows tenta preferir o domínio. Desconectar a rede permite login local.
Objetivo: voltar a iniciar sessão com contas do domínio, preservando perfis, políticas e associações do Active Directory.
Causa provável em termos práticos
Na grande maioria dos casos, o canal seguro (secure channel) entre o computador e um Controlador de Domínio (DC) foi quebrado. As razões típicas incluem:
- Senha da conta de computador no AD fora de sincronia (por snapshot/reversão de VM, imagem antiga, período offline prolongado, falhas de replicação).
- Desvios de data/hora (Kerberos rejeita tíquetes quando o skew ultrapassa alguns minutos).
- DNS apontando para servidores errados (públicos) ou não resolvendo SRV do AD.
- Conectividade instável com DCs (portas bloqueadas por firewall, VPN mal configurada, rota quebrada).
Antes de começar
- Acesso a uma conta local com privilégios de administrador (
.\AdministradorouCOMPUTADOR\Usuario). - Uma credencial de Administrador do Domínio para reparar o canal seguro.
- Nome do domínio (ex.:
contoso.local) e, preferencialmente, o nome de um DC (ex.:DC01). - Se o login local estiver travado pela rede, desligue o Wi‑Fi ou remova o cabo para forçar o uso da conta local.
Checklist rápida
| O que verificar | Por quê | Comando/ação | Resultado esperado |
|---|---|---|---|
| DNS aponta para DC | Sem DNS do AD, o PC não acha DCs | ipconfig /all | DNS primário = IP do DC |
| SRV do AD resolvendo | Confirma descoberta de DC | nslookup -type=SRV ldap.tcp.dc._msdcs.DOMINIO | Lista de DCs |
| Hora/data corretas | Kerberos exige relógio alinhado | w32tm /query /status | Origem de tempo válida |
| Canal seguro | Valida a confiança | nltest /sc_verify:DOMINIO | Status = 0 (SUCCESS) |
Reparar o secure channel (preferível, sem sair do domínio)
Este é o caminho recomendado, pois preserva a conta de computador no AD e evita criação de perfis duplicados no Windows.
Entrar localmente
- Na tela de login, clique em Outras opções (se aparecer) e selecione Conta local.
- Digite
.\Administrador(ouCOMPUTADOR\Usuario) e a senha. Se a rede atrapalhar, desconecte o PC.
Verificar rede e DNS
- Abra o Prompt ou PowerShell como Administrador.
- Confirme os DNS:
ipconfig /allO DNS primário deve ser o(s) DC(s) do domínio. Evite DNS público. - Teste nome e ping do DC:
ping DC01 nltest /dclist:DOMINIO nltest /dsgetdc:DOMINIO /force - Cheque registros SRV do AD:
nslookup -type=SRV kerberos.tcp.DOMINIO nslookup -type=SRV ldap.tcp.dc._msdcs.DOMINIO
Sincronizar data/hora
- Verifique o status:
w32tm /query /status - Force a sincronização (se possível, na rede do domínio):
w32tm /resync - Se falhar, aponte para um DC como fonte de tempo e sincronize:
w32tm /config /manualpeerlist:DC01 /syncfromflags:manual /update w32tm /resync
Uma diferença de poucos minutos já pode quebrar o Kerberos. Mantenha o desvio < 5 minutos.
Reparar a relação de confiança
Abra o PowerShell como administrador local e informe credenciais de um administrador do domínio quando solicitado.
Test-ComputerSecureChannel -Repair -Credential DOMINIO\AdministradorComandos equivalentes:
Reset-ComputerMachinePassword -Server DC01 -Credential DOMINIO\Administradornetdom resetpwd /server:DC01 /userd:DOMINIO\Administrador /passwordd:*Reiniciar e validar
- Reinicie o computador.
- Faça login com uma conta do domínio.
- Valide o canal seguro e DC preferido:
nltest /sc_verify:DOMINIO nltest /dsgetdc:DOMINIO - Forçe atualização de políticas, se necessário:
gpupdate /force
Dica: com Test-ComputerSecureChannel, o retorno True indica que o canal foi reparado. Em netdom resetpwd, procure por mensagem de êxito e código de retorno zero.
Alternativa clássica: sair do domínio e reingressar
Se a reparação não funcionar ou o objeto de computador estiver corrompido, use esta abordagem.
- Entre como administrador local.
- Altere para grupo de trabalho:
- Propriedades do Sistema → guia Nome do Computador → Alterar… → seleciona Grupo de trabalho (ex.:
WORKGROUP) → OK → reinicie.
- Propriedades do Sistema → guia Nome do Computador → Alterar… → seleciona Grupo de trabalho (ex.:
- Opcional (recomendado no AD): resete a conta de computador no AD em vez de excluí-la, para manter pertenças a grupos.
- Reingresse no domínio:
- Volte em Alterar… → selecione Domínio (ex.:
contoso.local) → informe credenciais de administrador do domínio → OK → reinicie.
- Volte em Alterar… → selecione Domínio (ex.:
- Valide login de usuário do domínio e aplicação de GPO.
Diagnóstico objetivo e comandos úteis
| Comando | Para quê | Interpretação |
|---|---|---|
ipconfig /all | Checar gateways, DNS, DHCP | DNS deve apontar ao DC. Evite 8.8.8.8 ou similares em clientes do AD. |
nltest /dclist:DOMINIO | Listar DCs | Se falhar, há problema de descoberta/LDAP/DNS. |
nltest /sc_query:DOMINIO | Estado do canal seguro | Se STATUSNOTRUSTSAMACCOUNT ou código ≠ 0, o trust está quebrado. |
Test-ComputerSecureChannel | Validação/repair via PowerShell | True = OK; use -Repair para ajustar. |
w32tm /query /status | Origem de tempo | Fonte deve ser o domínio/DC ou NTP confiável alinhado ao domínio. |
Test-NetConnection DC01 -Port 88 | Testar porta Kerberos | Sucesso indica Kerberos acessível; teste também 389 (LDAP), 445 (SMB), 135 (RPC). |
nslookup -type=SRV ldap.tcp.dc._msdcs.DOMINIO | SRV do AD | Retorno vazio = DNS do AD quebrado. |
Erros relacionados e como relacioná-los ao problema
| Mensagem | Tradução/Contexto | Ação sugerida |
|---|---|---|
There are currently no logon servers available | Sem DC acessível | Cheque DNS/portas/VPN. Use nltest /dsgetdc:DOMINIO. |
The security database... does not have a computer account... | Conta de computador não encontrada ou fora de sincronia | Reparar canal seguro ou reingressar. |
Clock Skew too great (eventos Kerberos) | Hora divergente | w32tm /resync e configure NTP adequado. |
Cenários especiais e como lidar
VM revertida a snapshot ou imagem antiga
Reverter um snapshot faz o PC “esquecer” a última senha da conta de computador. O AD, entretanto, já a rotacionou. Resultado: confiança quebrada. Execute o reparo do canal seguro. Em ambientes de clonagem, sempre sysprep antes de ingressar no domínio.
Computador foi renomeado recentemente
O objeto no AD pode ter o nome antigo enquanto o PC já usa o novo. Garanta consistência:
Rename-Computer -NewName NOVONOME -DomainCredential DOMINIO\Administrador -RestartVerifique se o objeto de computador no AD corresponde ao nome atual do equipamento.
Notebook ficou muito tempo fora da rede
Se a rotação de senha de máquina ocorreu enquanto o computador estava offline e depois houve alterações vindas de imagem/snapshot, pode haver desencontro. Conecte-o à rede do domínio, ajuste hora e repare o canal seguro.
Várias interfaces de rede
Placas virtuais de VPN ou múltiplas NICs podem causar resolução invertida (rota errada) ou DNS inconsistente. Desabilite temporariamente interfaces extras e teste novamente.
Verificações no Event Viewer
- System > Netlogon — eventos como 5719 (sem DC) e 5722/5805 (falha de sessão de computador).
- System > Time-Service — eventos de sincronização de tempo/W32Time.
- Security — eventos Kerberos (falhas de tíquete por desvio de hora).
Portas de rede essenciais
| Serviço | Porta/Protocolo | Uso |
|---|---|---|
| Kerberos | 88/TCP, 88/UDP | Autenticação de domínio |
| LDAP | 389/TCP, 389/UDP | Consulta a diretório |
| LDAPS | 636/TCP | LDAP seguro (se configurado) |
| Global Catalog | 3268/TCP, 3269/TCP | Catálogo global |
| SMB | 445/TCP | Comunicação com DC/DFS/SYSVOL |
| RPC Endpoint Mapper | 135/TCP | Negociação de RPC |
| RPC dinâmico | 49152–65535/TCP | Chamadas RPC diversas |
Prevenção e boas práticas
- Hora consistente: configure GPO para que clientes sincronizem com DCs. Mantenha desvio < 5 minutos.
- Imagens e snapshots: evite reverter VMs de membros de domínio. Se inevitável, planeje a troca da senha de máquina (
Reset-ComputerMachinePassword) ao voltar. - Saúde de DC/DNS: não defina DNS público nos clientes. Garanta disponibilidade e replicação dos DCs.
- VPN/Firewall: libere portas do AD; empurre regras por GPO para clientes remotos.
- Monitoramento: alerte para eventos Netlogon 5719/5805 e falhas repetidas de secure channel.
Perguntas frequentes (FAQ)
Preciso estar online para reparar?
Sim, para falar com um DC e reparar o canal seguro. Mas para entrar como local admin, você pode desconectar a rede.
Posso usar um DC específico?
Sim. Prefira um DC local/mais próximo (ex.: -Server DC01 no PowerShell ou /server:DC01 no netdom).
Usuários perderão o perfil?
Se você reparar o canal sem sair do domínio, os perfis permanecem. Reingressar ao domínio normalmente preserva perfis, mas pode criar pastas USUARIO.DOMINIO se houver divergências de SID/permissões.
E se Test-ComputerSecureChannel devolver False mesmo após -Repair?
Verifique DNS e hora; confira se a conta de computador existe e está habilitada no AD; então tente reingressar.
Login local não aparece na tela?
Use .\Usuario ou COMPUTADOR\Usuario. Desconectar a rede muitas vezes faz o Windows exibir a opção local.
Script pronto para diagnosticar e reparar
Execute como Administrador local. Informe as credenciais de Administrador do Domínio quando solicitado.
$Domain = "DOMINIO" # ex.: contoso.local
$DC = "DC01" # opcional, force um DC específico
Write-Host "=== Verificando DNS ==="
ipconfig /all | Out-Null
Write-Host "=== Resolvendo SRV do AD ==="
try { nslookup -type=SRV "\ldap.\tcp.dc.\_msdcs.\$Domain" } catch {}
Write-Host "=== Checando descoberta de DC ==="
nltest /dsgetdc:\$Domain
Write-Host "=== Consultando hora ==="
w32tm /query /status
Write-Host "=== Tentando reparo do canal seguro ==="
\$result = Test-ComputerSecureChannel -Server \$DC -Repair -Credential "\$Domain\Administrador" -ErrorAction SilentlyContinue
if (\$result) {
Write-Host "Canal seguro reparado com sucesso." -ForegroundColor Green
} else {
Write-Host "Falha no reparo via PowerShell; tentando Reset-ComputerMachinePassword..." -ForegroundColor Yellow
try {
Reset-ComputerMachinePassword -Server \$DC -Credential "\$Domain\Administrador"
Write-Host "Senha da conta de computador redefinida." -ForegroundColor Green
} catch {
Write-Host "Falha ao redefinir senha da conta de computador. Considere reingressar no domínio." -ForegroundColor Red
}
}
Write-Host "=== Validando canal seguro ==="
nltest /sc\_verify:\$Domain Checklist pós-correção
- Login de domínio OK: usuário entra e recebe perfil correto.
- Políticas aplicadas:
gpresult /rmostra GPOs de computador/usuário. - Canal seguro válido:
nltest /sc_verify:DOMINIOretorna sucesso. - Hora alinhada:
w32tm /query /statuscom origem confiável. - Eventos limpos: Netlogon sem novos 5719/5805 recorrentes.
Resumo executivo
Confirme rede/DNS/tempo; em seguida, priorize reparar o secure channel com PowerShell (Test-ComputerSecureChannel -Repair) ou netdom resetpwd. Se ainda assim falhar, deixe o grupo de trabalho e reingresse no domínio. Esse fluxo resolve, com segurança, a maioria dos casos sem causar perda de perfil.
Em resumo: verifique DNS, conectividade e hora; tente reparar o canal seguro; como último recurso, saia e reingresse no domínio. Essa abordagem minimiza impacto e devolve o login de domínio rapidamente.