Windows Server: risolvere l’errore “Naming Information Cannot Be Located” in Active Directory

Su un server Windows membro di dominio, l’errore “Naming Information Cannot Be Located” blocca strumenti come ADUC o ADSI Edit. Questa guida pratica spiega cause, controlli e comandi per ripristinare la connessione ad Active Directory in modo sicuro e ripetibile.

Indice

Che cos’è l’errore “Naming Information Cannot Be Located”

Il messaggio appare tipicamente quando apri Active Directory Users and Computers, ADSI Edit, Active Directory Administrative Center o altre MMC che interrogano Active Directory. In sostanza, il server non riesce a individuare o contattare un Domain Controller (DC) per effettuare il bind LDAP/GC e navigare gli spazi dei nomi di directory. All’origine ci sono quasi sempre problemi di DNS, connettività, tempo/Kerberos o appartenenza al dominio.

Sintomi tipici

Apertura di ADUC/ADAC/ADSI Edit con messaggio di errore e impossibilità a sfogliare il dominio.
Risoluzione dei nomi AD assente o incoerente (SRV non risolti, GC non raggiungibile).
Eventi di sistema come Netlogon 5719/5783, DNS Client 1014, Kerberos 4/7/16, GroupPolicy 1054/1129.
Comandi come nltest /dsgetdc:<dominio> o echo %logonserver% che falliscono o restituiscono valori inattesi.

Perché succede

DNS non corretto: la scheda di rete punta a DNS pubblici/esterni (es. 8.8.8.8) anziché al DNS del dominio che pubblica i record SRV (ldap, kerberos, gc, msdcs).
Connettività bloccata: firewall o ACL che impediscono porte critiche (389/636/3268/3269, 88, 445, 135, 53, RPC dinamico).
Drift dell’orario: differenza di orario > 5 minuti fa fallire Kerberos.
Trust del computer danneggiato: il canale sicuro della machine account è rotto, spesso dopo snapshot/restore o ripristini non coerenti.
Topologia dei siti AD errata: subnet non mappate a siti corretti → il client sceglie DC remoti o non raggiungibili.
Policy di sicurezza LDAP o canali firmati richiesti su DC con client non aggiornati.

Percorso di risoluzione rapido

Imposta il DNS primario verso un Domain Controller interno. Flusha e registrati: ipconfig /flushdns e ipconfig /registerdns.
Verifica la connettività verso il DC: ping, test porta 389/3268/88/445/53.
Controlla e riallinea l’orario: w32tm /query /status, quindi w32tm /resync.
Riavvia i servizi DNS Client e Netlogon per rigenerare registrazioni e sessioni.
Ispeziona i log per confermare la causa (DNS/Netlogon/Kerberos) e applica le correzioni.

Tabella azione–risultato

Obiettivo	Azione proposta	Spiegazione pratica
Verificare connettività di rete	Controllare cavi, IP, gateway, eventuali conflitti; provare `ping` verso il controller di dominio.	L’errore nasce spesso quando il server non raggiunge il DC sulle porte 389/LDAP o 445/SMB.
Confermare la configurazione DNS	Impostare come DNS primario l’indirizzo di un Domain Controller. Eseguire `ipconfig /flushdns` e `ipconfig /registerdns`.	Active Directory dipende dai record SRV pubblicati nel DNS del dominio; puntare a DNS esterni provoca mancata risoluzione dei nomi AD.
Verificare la corretta appartenenza al dominio	`nltest /dsgetdc:nomedominio` o `echo %logonserver%`. Se falliscono, rimuovere e ri‑aggiungere il server al dominio (ultima ratio).	Se il trust della machine account è corrotto, la ricerca dei servizi di directory non riesce.
Sincronizzazione dell’ora	`w32tm /resync`. Assicurarsi che l’offset con il DC sia < 5 minuti.	Kerberos rifiuta ticket quando c’è un drift di orario significativo.
Analisi log	Usare Event Viewer → Windows Logs → System. Su DC: log DNS Server e Directory Service. Filtrare Event ID chiave (vedi tabella dedicata).	Gli eventi rivelano se DNS, Netlogon, Kerberos o Replication sono la causa.
Test di risoluzione DNS	`nslookup -type=SRV ldap.tcp.dc._msdcs.nomedominio.tld` o `Resolve-DnsName`.	Conferma la presenza dei record SRV di LDAP/GC indispensabili.
Riavvio servizi chiave	`net stop dnscache && net start dnscache` e `net stop netlogon && net start netlogon`.	Rigenera la registrazione DNS del server e rinegozia la sessione con il DC.
Firewall	Consentire 53/TCP‑UDP, 88/TCP‑UDP, 135, 389, 445, 464 e 49152‑65535 (RPC dinamico).	Blocchi firewall interni o di terze parti impediscono il bind LDAP.
Strumenti avanzati	`dcdiag /v /test:dns` (su DC), `repadmin /replsummary` (replica), `setspn -X -F` (SPN duplicati), `ldp.exe` (test LDAP).	Forniscono diagnosi approfondite quando i controlli base non bastano.

Guida passo‑passo dettagliata

Verifica della connettività

Conferma che il server raggiunga un DC e viceversa. Esegui:

ping dc01.nomedominio.tld
Test-NetConnection dc01.nomedominio.tld -Port 389
Test-NetConnection dc01.nomedominio.tld -Port 3268
Test-NetConnection dc01.nomedominio.tld -Port 88
Test-NetConnection dc01.nomedominio.tld -Port 445
Test-NetConnection dc01.nomedominio.tld -Port 53

Se il ping è bloccato per policy, basa la verifica su TCP. In ambienti segmentati/DMZ, pianifica regole firewall bidirezionali precise (vedi tabella porte).

Configurazione DNS corretta

Regola d’oro: su server membri di dominio, il DNS primario deve essere un Domain Controller che esegue il servizio DNS del dominio. Evita DNS pubblici sulla NIC.

Apri le proprietà IPv4 della scheda di rete e imposta come DNS primario l’IP del DC locale al sito.
Se serve un secondario, usa l’IP di un altro DC del tuo dominio.
Flusha e registra di nuovo i record:

ipconfig /flushdns
ipconfig /registerdns

Controlla la suffissa primaria DNS del computer (deve combaciare col dominio AD): Sistema → Impostazioni di sistema avanzate → Nome computer → Altre…

Test dei record SRV

I record SRV guidano i client verso i servizi AD. Verificali così:

nslookup -type=SRV ldap.tcp.dc._msdcs.nomedominio.tld
nslookup -type=SRV kerberos.tcp.nomedominio.tld
PowerShell
Resolve-DnsName -Type SRV ldap.tcp.dc._msdcs.nomedominio.tld
Resolve-DnsName -Type SRV gc.tcp.nomedominio.tld

Se non ottieni risposte, il problema è DNS (server puntato male, zona non risolta, DC che non registra i record perché Netlogon sul DC è fermo).

Controllo dell’appartenenza al dominio e del canale sicuro

Verifica la visibilità del dominio e il canale sicuro della machine account:

nltest /dsgetdc:nomedominio.tld
nltest /dclist:nomedominio.tld
nltest /sc_verify:nomedominio.tld
echo %logonserver%
PowerShell (da amministratore)
Test-ComputerSecureChannel -Verbose

Se Test-ComputerSecureChannel fallisce, prova a ripararlo:

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

Nota: rimuovere e riaggiungere il server al dominio è l’ultima ratio. Prima tenta la riparazione del canale sicuro. Se devi uscire dal dominio, assicurati di avere una credenziale locale di emergenza e valuta l’impatto su profili/GPO/servizi dipendenti.

Allineamento dell’orario

Active Directory usa Kerberos, che tollera un offset di orario limitato. Verifica e riallinea:

w32tm /query /status
w32tm /query /peers
w32tm /resync

In un dominio, i membri si sincronizzano gerarchicamente dai DC. Evita di configurare NTP esterni direttamente sui membri del dominio a meno di esigenze specifiche e condivise dal team AD.

Riavvio dei servizi chiave

Forza una nuova registrazione DNS del client e una nuova negoziazione Netlogon:

net stop dnscache &amp;&amp; net start dnscache
net stop netlogon &amp;&amp; net start netlogon
oppure PowerShell
Restart-Service Dnscache -Force
Restart-Service Netlogon -Force

Analisi dei log eventi

Sul server membro, usa Registri di Windows → Sistema e i log Applicazioni e servizi → Microsoft → Windows → DNS‑Client. Se hai accesso al DC, consulta anche DNS Server e Directory Service. Eventi utili:

Origine	Event ID	Significato	Azione
Netlogon (membro)	5719 / 5783	Nessun controller di dominio disponibile / trust non stabilito	DNS/porte/route; ripara canale sicuro
GroupPolicy (membro)	1054 / 1129	Mancata applicazione GPO per DNS/AD non raggiungibile	Correggi DNS e latenza verso DC
DNS Client (membro)	1014	Timeout di risoluzione nome	Verifica server DNS, SRV e connettività
Kerberos (membro)	4 / 7 / 16	Problemi di KDC/clock/SPN	Allinea orario, verifica SPN duplicati
DNS Server (DC)	4000–4017	Errori di servizio DNS su DC	Ripara DNS, verifica zona _msdcs
Netlogon (DC)	1355 / 5781	Dominio non individuabile / registrazione DNS fallita	Riavvia Netlogon sul DC, verifica permessi zona

Firewall e porte richieste

Assicurati che le seguenti porte siano consentite in uscita dal server membro verso i DC e, dove indicato, anche in ingresso se devi ospitare ruoli o consentire gestione remota.

Protocollo/Porta	Servizio	Direzione tipica	Note
53 TCP/UDP	DNS	Uscita → DC DNS	Risoluzione nomi e query SRV
88 TCP/UDP	Kerberos	Uscita → KDC	Autenticazione
135 TCP	RPC Endpoint Mapper	Uscita → DC	Necessario per RPC dinamico
389 TCP/UDP	LDAP	Uscita → DC	Bind e query directory
636 TCP	LDAPS	Uscita → DC	LDAP su TLS
3268/3269 TCP	Global Catalog	Uscita → GC	Query su intera foresta
445 TCP	SMB	Uscita ↔ Ingresso	Condivisioni SYSVOL/NETLOGON, GPO
464 TCP/UDP	Kerberos change/set password	Uscita → DC	Reset credenziali
49152–65535 TCP	RPC dinamico	Uscita → DC	Intervallo predefinito su Windows moderni
123 UDP	NTP	Uscita → DC/Time Source	Sincronizzazione oraria

Se l’intervallo RPC deve essere ristretto per policy, coordina con il team AD e applica le stesse impostazioni sui DC.

Diagnostica avanzata

DCDIAG (su DC): dcdiag /v /test:dns per validare registrazioni SRV, deleghe e salute del DNS del dominio.
REPADMIN (su DC): repadmin /replsummary per capire se il DC che i client contattano è coerente con il resto della foresta.
LDP.exe (sul membro o DC): testa il bind LDAP/LDAPS su 389/636; verifica che la base DN (DC=nomedominio,DC=tld) sia sfogliabile.
SETSPN (su DC): setspn -X -F per rilevare SPN duplicati che causano errori Kerberos (KRBAPERR_MODIFIED).
Topologia dei siti: conferma in Active Directory Sites and Services che le subnet IP siano mappate al sito corretto; in caso contrario, i client potrebbero consultare DC remoti non raggiungibili.

Best practice e note operative

IPv6: non disabilitarlo a meno di motivi documentati. Se usato, assicurati che la risoluzione AAAA verso i DC sia corretta.
Hosts file: evita di inserire voci che “forzano” la risoluzione dei DC; i record SRV non vengono risolti via hosts e potresti introdurre inconsistenze.
Profili e servizi: prima di uscire/rientrare nel dominio, valuta l’impatto su servizi che eseguono con account di dominio e su profili utente in cache.
Account locali: conserva un account locale amministrativo per emergenze in cui l’accesso al dominio non è disponibile.
Change management: annota indirizzi IP dei DC, modifiche a DNS, orari dei test; servirà per audit e rollback.

Esempi di comandi pronti all’uso

Sequenza rapida per un controllo “end‑to‑end” (sostituisci nomedominio.tld e dc01):

ipconfig /all
ipconfig /flushdns
ipconfig /registerdns

nslookup -type=SRV ldap.tcp.dc._msdcs.nomedominio.tld
Resolve-DnsName -Type SRV ldap.tcp.dc._msdcs.nomedominio.tld

Test-NetConnection dc01.nomedominio.tld -Port 389
Test-NetConnection dc01.nomedominio.tld -Port 3268
Test-NetConnection dc01.nomedominio.tld -Port 88
Test-NetConnection dc01.nomedominio.tld -Port 445
Test-NetConnection dc01.nomedominio.tld -Port 53

w32tm /query /status
w32tm /resync

nltest /dsgetdc:nomedominio.tld
nltest /sc_verify:nomedominio.tld
Test-ComputerSecureChannel -Verbose

Restart-Service Dnscache -Force
Restart-Service Netlogon -Force

Scenari comuni e come uscirne

DNS impostato su server pubblico

Segnale: nslookup -type=SRV fallisce; ADUC mostra “Naming Information…”.
Soluzione: imposta come DNS primario un DC interno, flusha cache e riprova. In molti casi l’errore scompare immediatamente.

Server in DMZ senza regole AD

Segnale: test porte falliscono; solo ping (se abilitato) risponde.
Soluzione: apri le porte minime necessarie (tabella sopra) o utilizza un jump server nella LAN per la gestione AD; se il membro deve restare in workgroup, gestisci attività AD da remoto.

Drift orario dopo snapshot/restore

Segnale: eventi Kerberos e accessi negati, offset tempo elevato.
Soluzione: w32tm /resync, verifica origine oraria; se il canale sicuro è rotto, riparalo (Test-ComputerSecureChannel -Repair).

Trust del computer corrotto

Segnale: nltest /sc_verify fallisce, eventi Netlogon 5722/5805 sul DC.
Soluzione: ripara il canale sicuro. Solo se fallisce, esci e rientra nel dominio (pianificando impatti).

Topologia dei siti errata

Segnale: il client contatta DC di un altro sito o non raggiungibili, latenza alta, GPO lente.
Soluzione: mappa correttamente le subnet in Active Directory Sites and Services così che i client selezionino DC locali.

Checklist rapida prima dell’escalation

DNS primario punta a un DC del dominio.
nslookup -type=SRV restituisce i record attesi.
Porte verso DC aperte: 53, 88, 135, 389, 445, 464, 3268/3269, 49152–65535.
w32tm allineato, offset < 5 minuti.
nltest /dsgetdc e Test-ComputerSecureChannel OK.
Eventi critici assenti o spiegati, servizi Dnscache/Netlogon riavviati.

Domande frequenti

Posso usare DNS pubblico come secondario?
Sconsigliato. I client potrebbero deviare verso DNS esterni che non conoscono i record SRV del dominio, causando l’errore. Usa solo DNS dei DC del tuo dominio.

Serve LDAPS per far funzionare ADUC?
No, ADUC funziona con LDAP standard. Tuttavia, se la tua organizzazione impone LDAP signing o channel binding, assicurati che i client siano aggiornati e che le policy corrispondano ai DC.

Posso limitare l’intervallo RPC dinamico?
Sì, ma allinealo su membri e DC e coordina col team di rete. In caso contrario, avrai errori intermittenti.

Conviene disabilitare IPv6?
No, non è una best practice. Mantienilo attivo e correttamente configurato; molti componenti Windows lo presuppongono.

Sintesi operativa

Imposta correttamente il DNS (DC interno) e verifica con nslookup che i record SRV rispondano.
Verifica la connettività (ping/port query) tra server e domain controller.
Controlla l’orario e ri‑sincronizza (w32tm).
Esegui ipconfig /flushdns e riavvia i servizi DNS Client e Netlogon.
Analizza i log per errori DNS/Netlogon/Kerberos e agisci di conseguenza; in caso di trust rotto, ripara con Test-ComputerSecureChannel -Repair.

Seguendo questi passaggi, nella maggior parte dei casi l’errore scompare e gli strumenti di gestione Active Directory tornano a funzionare senza interruzioni.

Appendice: script PowerShell di verifica rapida

# Parametri
$Domain = "nomedominio.tld"
$DC     = "dc01.nomedominio.tld"

Write-Host "Verifica DNS SRV..."
Resolve-DnsName -Type SRV "ldap.tcp.dc._msdcs.$Domain" -ErrorAction SilentlyContinue

Write-Host "Test porte essenziali verso $DC..."
389,3268,88,445,53 | ForEach-Object {
$r = Test-NetConnection $DC -Port $_
"{0}: {1}" -f $_, ($r.TcpTestSucceeded)
}

Write-Host "Stato orologio"
w32tm /query /status

Write-Host "Canale sicuro"
Test-ComputerSecureChannel -Verbose

Nota di sicurezza: quando operi su sistemi di produzione, esegui sempre le modifiche in finestra di manutenzione approvata, conserva un account locale amministrativo e, se possibile, prevedi un piano di rollback.