Se as ferramentas do Active Directory exibem a mensagem “Naming information cannot be located”, quase sempre há um problema de DNS ou de conectividade com os controladores de domínio. Este guia prático mostra como diagnosticar e corrigir rapidamente — do cliente ao DC.
Entenda o que a mensagem realmente significa
O erro aparece ao abrir consoles como Active Directory Users and Computers (ADUC), Active Directory Sites and Services, Group Policy Management ou ao executar tarefas de domínio (ex.: juntar a máquina ao domínio, aplicar GPO, consultar o Catálogo Global). Em termos práticos, o sistema não conseguiu localizar, via DNS e protocolos do AD, os naming contexts e serviços publicados pelos controladores de domínio (DCs).
Em ambientes AD, a descoberta do domínio depende de registros SRV no DNS (por exemplo, ldap.tcp.dc._msdcs), publicados pelo serviço Netlogon dos DCs. Se o cliente usa DNS público, se o DNS interno do AD está incorreto, fora do ar ou se há bloqueio de portas, a resolução falha e o console não consegue se conectar — resultando no erro.
Causa mais comum e solução imediata
Causa principal: DNS mal configurado no cliente/servidor. Em AD, todos os membros do domínio devem usar como DNS somente os servidores DNS internos do AD (normalmente os próprios DCs). Nunca aponte o DNS do cliente para DNS público.
Correção rápida: ajuste o DNS primário do host para o endereço IP de um DC (ou de um servidor DNS do AD), limpe o cache e recadastre:
ipconfig /flushdns
ipconfig /registerdns
Se o DC for autoritativo para o domínio, o cliente conseguirá resolver os registros SRV e localizar os serviços de diretório, eliminando o erro na maioria dos casos.
Checklist rápido
Siga os passos abaixo, em ordem. Substitua dominio.local, DC_FQDN e DOMÍNIO\Administrador pelos valores do seu ambiente.
Rede e DNS
- Valide IP e gateway: sem conflitos, máscara correta e rota para os DCs.
- Confirme o DNS do host com
ipconfig /all:- Servidor(es) DNS: IP(s) do(s) DC(s) ou DNS interno do AD.
- Sufixo DNS primário do computador igual ao do domínio (ex.:
dominio.local).
ipconfig /flushdns ipconfig /registerdnsDica: em PowerShell, você pode definir os DNS do adaptador de rede de forma explícita:# Identifique o adaptador: Get-DnsClientServerAddress Defina os DNS do AD (exemplo): Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.10.10,192.168.10.11 Opcional: ajuste a lista de sufixos de pesquisa Set-DnsClientGlobalSetting -SuffixSearchList @("dominio.local","site.dominio.local")
Testes de resolução e SRV
- Valide a resolução do domínio e dos registros SRV:
nslookup dominio.local nslookup -type=SRV ldap.tcp.dc._msdcs.dominio.localResolve-DnsName dominio.local Resolve-DnsName ldap.tcp.dc._msdcs.dominio.local -Type SRVO retorno deve listar DCs válidos com seus FQDNs e portas. Se falhar, corrija o DNS do cliente e confirme no DC se os SRVs estão sendo publicados (veja a seção de serviços no DC).
Conectividade com o controlador de domínio
- Teste as portas essenciais do cliente para um DC específico (
DC_FQDN):Test-NetConnection DC_FQDN -Port 53 # DNS Test-NetConnection DC_FQDN -Port 88 # Kerberos Test-NetConnection DC_FQDN -Port 135 # RPC Endpoint Mapper Test-NetConnection DC_FQDN -Port 389 # LDAP Test-NetConnection DC_FQDN -Port 445 # SMBFirewalls/ACLs não devem bloquear essas portas e, no caso do RPC, a faixa dinâmica (recentes:49152–65535/TCP) deve estar liberada entre cliente e DC.
Canal seguro com o domínio
- Verifique e repare o canal seguro (comunicação Kerberos/NTLM entre a máquina e o domínio):
nltest /sc_verify:dominio.localTest-ComputerSecureChannel -Verbose Quebrou? Faça o reparo (credenciais do domínio necessárias): Test-ComputerSecureChannel -Repair -Credential DOMÍNIO\AdministradorSe ainda falhar e for uma workstation ou member server, como último recurso desassocie e reingresse no domínio.
Sincronização de hora
- Corrija a hora: diferença > 5 minutos quebra o Kerberos.
w32tm /query /status w32tm /resyncGaranta que o PDC Emulator do domínio seja a origem autoritativa de tempo para os demais DCs e membros.
Serviços e registros no DC
- No controlador de domínio, reinicie serviços e force a publicação de SRVs:
net stop netlogon && net start netlogon nltest /dsregdnsExecute diagnósticos:dcdiag /test:dns /v dcdiag /v repadmin /replsummary repadmin /showreplVerifique as partilhas\\DC\SYSVOLe\\DC\NETLOGON. Se indisponíveis, GPO e scripts de logon não serão aplicados e os consoles do AD podem falhar.
Logs de eventos
- No cliente e no DC, investigue System e DNS Server. Erros típicos:
- Netlogon 5719: DC não encontrado.
- GroupPolicy 1058/1030: falhas de processamento de GPO.
- Erros de DNS e Kerberos (valide hora e SRVs).
Políticas de rede e sites do AD
- Em Active Directory Sites and Services, confira se a sub‑rede onde o cliente está foi mapeada para o site correto (aquele com DCs próximos). Isso afeta quais DCs e GCs serão preferidos. Não desative IPv6. Se houver requisito de desativação, faça de forma suportada e consistente — entradas DNS e rotas precisam permanecer coerentes.
Como interpretar os testes de DNS
Quando você pesquisa ldap.tcp.dc._msdcs.dominio.local, o resultado esperado são vários registros SRV, cada um apontando para um DC com sua porta 389/LDAP (ou 3268 para GC) e o respectivo FQDN. Exemplo de saída válida interpretada:
ldap.tcp.dc._msdcs.dominio.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc01.dominio.local
ldap.tcp.dc._msdcs.dominio.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = dc02.dominio.local
Se não houver resposta, os registros SRV não existem, o DNS usado pelo cliente não é o do AD ou há falha de replicação entre zonas. Confirme no DC:
- O serviço Netlogon está iniciado e registrando SRVs.
- A zona
_msdcs.dominio.localexiste e está íntegra. - A replicação do AD e do DNS está saudável (
repadminedcdiag).
Portas essenciais para o AD
| Serviço | Porta/Protocolo | Uso |
|---|---|---|
| DNS | 53/TCP e UDP | Resolução de nomes e SRVs |
| Kerberos | 88/TCP e UDP | Autenticação |
| LDAP | 389/TCP | Consulta ao diretório |
| SMB | 445/TCP | SYSVOL/NETLOGON, GPO, scripts |
| RPC Endpoint Mapper | 135/TCP | Mapeia serviços RPC |
| Troca de chaves | 464/TCP | Kerberos kpasswd |
| Catálogo Global | 3268/TCP (LDAP) e 3269/TCP (LDAPS) | Consultas GC |
| RPC dinâmico | 49152–65535/TCP | Comunicação RPC pós‑mapeamento |
Bloqueios nessas portas (especialmente entre sites e firewalls de estação) costumam gerar o erro.
Ações rápidas que resolvem a maioria dos casos
- Ajuste o DNS primário do cliente para o DNS interno do AD e rode
ipconfig /flushdns+ipconfig /registerdns. - No DC, reinicie Netlogon e force a republicação com
nltest /dsregdns. - Repare o canal seguro com
Test-ComputerSecureChannel -Repair— útil após snapshots, cliques longos desligados ou restaurações. - Corrija a hora e force
w32tm /resync.
Quando escalar
dcdiag /test:dnsourepadmin /replsummaryretornam falhas persistentes.- Registros SRV do domínio ausentes ou inconsistentes na zona
_msdcs. - Bloqueios de portas entre sites/segmentos que você não controla.
Boas práticas e observações úteis
- Clientes e servidores sempre usam apenas DNS do AD. Para resolver endereços externos, configure reenviadores (forwarders) no DNS do AD — não nos clientes.
- Evite multi‑homing em DCs. Se inevitável, desative registro DNS na interface “errada” e ajuste ordem de vínculos.
- Não desative IPv6 por padrão; o AD e o Windows dependem dele em vários cenários. Se precisar, faça de modo suportado.
- Se o domínio for de rótulo único (ex.:
empresaem vez deempresa.local), aumente os cuidados com sufixos e SRVs; considere plano de migração. - Em ambientes virtualizados, evite reverter snapshots de DCs sem planejamento — isso quebra replicação e pode causar falhas de canal seguro.
Validação pós‑correção
Depois de aplicar as correções, valide com:
nltest /dsgetdc:dominio.local
gpupdate /force
Abra o ADUC e confirme se consegue navegar pelas OUs, localizar usuários e grupos e editar objetos sem erros. Em estações, faça logoff/logon para testar autenticação e GPO.
Exemplos práticos de detecção de causa
DNS do cliente aponta para DNS público
Sintomas: nslookup dominio.local resolve para a internet ou falha; SRVs não retornam.
Correção: aponte o DNS para o DC, limpe e registre DNS; reinicie Netlogon no DC.
Bloqueio de RPC ou SMB por firewall
Sintomas: Test-NetConnection -Port 445 falha; GPO 1058/1030; acesso a \\DC\SYSVOL não funciona.
Correção: libere 445/TCP, 135/TCP e a faixa dinâmica RPC; teste novamente.
Hora fora de sincronia
Sintomas: erros de Kerberos no log, falha em nltest /sc_verify.
Correção: ajuste o serviço de tempo, ressincronize e valide.
SRVs não publicados
Sintomas: ldap.tcp.dc._msdcs vazio.
Correção: no DC, net stop netlogon && net start netlogon, nltest /dsregdns, revisar dcdiag e replicação (repadmin).
Guia de decisão
| Teste | Resultado | Próxima ação |
|---|---|---|
nslookup dominio.local | Resolve para IP externo ou falha | Ajustar DNS do cliente para DNS do AD |
Resolve-DnsName ldap.tcp.dc._msdcs | Sem SRVs | Reiniciar Netlogon no DC e nltest /dsregdns |
Test-NetConnection DC -Port 445/135 | Falha | Corrigir firewall/ACL e faixa RPC |
nltest /sc_verify | Falha | Test-ComputerSecureChannel -Repair |
w32tm /query /status | Divergência de tempo | w32tm /resync e revisar origem NTP |
Dicas de endurecimento
- Defina forwarders no DNS do AD para saída à internet; nunca configure DNS público nos clientes.
- Monitore dcdiag e repadmin periodicamente (integração em scripts ou tarefas agendadas).
- Padronize a ordem de NICs e evite múltiplos DNSs de sites diferentes no mesmo cliente.
- Documente os sites e sub‑redes no AD e revise sempre que houver mudanças de rede.
Perguntas frequentes
Posso manter DNS público como secundário e DNS do AD como primário?
Não. Se o cliente tentar consultar registros do AD no DNS público (mesmo como fallback), a descoberta do domínio falha. Use apenas DNS do AD nos clientes e configure forwarders no DNS do AD. Preciso reiniciar o servidor após ajustar DNS?
Normalmente não. Limpar e recadastrar DNS e reiniciar Netlogon/serviços associados costuma bastar. Reinicie apenas se houver dependências ou drivers de rede com problemas. Desativar IPv6 ajuda?
Não é recomendado. O AD e o Windows oferecem funcionalidades que assumem IPv6. Desative somente com justificativa e procedimento suportado, garantindo consistência em DNS e roteamento. Como diagnosticar problemas de replicação rapidamente?
Use repadmin /replsummary para visão geral e repadmin /showrepl para detalhes por partição. Combine com dcdiag /v. GPO não aplica; isso está relacionado?
Sim. Se o cliente não encontra o DC ou não acessa \\DC\SYSVOL, GPO falha (erros 1058/1030). Corrija DNS, SMB e SRVs. Após restaurar de snapshot, perdi o canal seguro. O que fazer?
Use Test-ComputerSecureChannel -Repair com credenciais do domínio. Em casos graves, reingresse a máquina ao domínio.
Checklist consolidado para execução
- Garantir DNS do cliente apontando para o AD; limpar/registrar cache.
- Testar resolução do domínio e SRVs; corrigir se ausentes.
- Validar portas essenciais e faixa RPC; ajustar firewall/ACL.
- Verificar canal seguro e reparar se necessário.
- Conferir hora e ressincronizar.
- No DC: reiniciar Netlogon, republish SRVs, rodar
dcdiag/repadmin. - Rever sites/sub‑redes no AD e logs de eventos.
- Validar ADUC,
nltest /dsgetdcegpupdate /force.
Conclusão
O erro “Naming information cannot be located” é um sintoma, não a causa. Em mais de 80% dos casos, o problema está no DNS do cliente apontando para o local errado ou em SRVs ausentes por falhas no DC. Seguindo o roteiro acima — começando por DNS, passando por conectividade, canal seguro e tempo — você identifica com rapidez o ponto de falha e aplica a correção adequada, devolvendo estabilidade ao Active Directory.