STATUSNOLOGON_SERVERS in Active Directory: diagnosi e correzione dei trust tra domini

Errore STATUSNOLOGONSERVERS / STATUSNOLOGONSERVERS durante l’autenticazione tra domini con trust? In questa guida trovi un flusso di diagnosi pratico, comandi pronti all’uso e best practice per capire se il server contatta prima il proprio DC o quello del dominio fidato e come risolvere definitivamente.

Panoramica dell’errore STATUSNOLOGON_SERVERS

STATUSNOLOGONSERVERS (spesso indicato anche come STATUSNOLOGONSERVERS, codice 0xC000005E) è un errore generato dal servizio Netlogon quando la macchina non riesce a individuare un Domain Controller disponibile per autenticare la sessione. Il messaggio appare tipicamente quando:

• Un server del dominio B deve autenticare utenti o computer del dominio A tramite un trust.
• Il server non riesce a raggiungere un DC valido lungo la catena prevista (prima il DC del proprio dominio, poi eventuale inoltro verso il DC del dominio fidato).

Conoscere l’ordine con cui vengono contattati i DC è essenziale per non inseguire falsi positivi: se l’account da autenticare è del dominio B, il server cerca sempre un DC di B; se l’account è del dominio A, il DC di B funge da intermediario e inoltra la richiesta a un DC di A.

Come funziona l’autenticazione fra domini con trust

In un trust bidirezionale (o unidirezionale) tra A e B, il flusso tipico è il seguente:

• La macchina nel dominio B contatta un DC di B usando il meccanismo di DC Locator (SRV DNS + Siti AD).
• Se l’account appartiene ad A, il DC di B inoltra la richiesta verso un DC di A sfruttando il trust.
• Il risultato (ticket Kerberos o risposta NTLM, a seconda del percorso) torna al server di origine.

In altri termini, il server tenta sempre di raggiungere prima un DC del proprio dominio; solo se l’account appartiene al dominio fidato, sarà il suo DC a inoltrare la richiesta a un DC esterno. L’errore indica che almeno uno di questi passaggi non riesce a trovare un DC disponibile.

Schema sintetico

Fase dell’autenticazione	Controller di dominio contattato per primo	Possibili cause del mancato contatto
Autenticazione di account del proprio dominio	Un DC del proprio dominio (dominio B)	DC offline; record DNS/SRV assenti o errati; firewall o routing che blocca porte AD (TCP 88/135/389/445, UDP 389/464, ecc.).
Autenticazione di account del dominio fidato	Il DC del proprio dominio (dominio B) inoltra la richiesta a un DC del dominio A	Problemi di rete/DNS tra i DC; trust interrotto o password del trust non sincronizzata; filtri firewall tra i siti.

Sintomi e messaggi correlati

• Impossibilità di accedere con utenti del dominio locale o fidato.
• Servizi che usano account di dominio in Log On As che vanno in errore.
• Eventi Netlogon e LSA (es. Event ID 5719, 5723, 5783, 40960/40961) su server e/o DC.
• Timeout o ritardi significativi durante la risoluzione del controller di dominio (DC Locator).

Guida passo‑passo alla risoluzione

Verifica DNS e record SRV

La risoluzione DNS corretta è il primo mattone. Assicurati che i record SRV dei servizi directory puntino a DC effettivamente raggiungibili.

nslookup -type=SRV ldap.tcp.dc._msdcs.<DominioB>
nslookup -type=SRV ldap.tcp.dc._msdcs.<DominioA>

Controlla che:

• Siano restituiti almeno uno o più DC con peso/priorità sensati.
• I nomi FQDN corrispondano ai certificati (se usi LDAPS) e ai record A/AAAA.
• Non vi siano record obsoleti o duplicati (stale), soprattutto in ambienti con DC rimossi o rinominati.

Ulteriori verifiche utili:

nslookup -type=SRV kerberos.tcp.dc._msdcs.<DominioB>
nslookup <FQDN-DC>
ipconfig /all

Verifica anche l’ordine dei suffissi DNS di ricerca sul server e che il DNS Client punti ai DNS interni autorevoli per la zona AD.

Test di raggiungibilità dei DC

Conferma innanzitutto la connettività di base e le porte chiave:

ping <FQDN-DC>
telnet <FQDN-DC> 389
telnet <FQDN-DC> 445

Preferibilmente usa strumenti più moderni:

Test-NetConnection -ComputerName <FQDN-DC> -Port 88
Test-NetConnection -ComputerName <FQDN-DC> -Port 389
Test-NetConnection -ComputerName <FQDN-DC> -Port 445

Per identificare il DC che il server intende usare:

nltest /dsgetdc:<DominioB>
nltest /dsgetdc:<DominioA>
nltest /dclist:<DominioB>
nltest /dclist:<DominioA>

Controllo stato del trust

Verifica che il trust sia integro e la sua password sia sincronizzata:

netdom trust <DominioA> /domain:<DominioB> /verify
netdom trust <DominioA> /domain:<DominioB> /quarantine

Puoi effettuare controlli e gestione anche dallo snap‑in Active Directory Domains and Trusts (valuta transitive vs external, Selective Authentication, Name Suffix Routing in ambienti multiforest).

Sincronizzazione oraria e repliche

Kerberos rifiuta ticket con differenze di orologio superiori a ~5 minuti per impostazione predefinita. Assicurati che il percorso NTP sia corretto, soprattutto per il PDC Emulator di ciascun dominio.

w32tm /query /status
w32tm /query /configuration
w32tm /resync

Controlla anche la salute delle repliche AD, che possono influire sulla visibilità dei DC o dei record DNS:

repadmin /replsummary
repadmin /showrepl *

Event Viewer

Esamina i log su server e su DC (registri System e Directory‑Service). Eventi tipici:

• 5719 (Netlogon): il computer non è in grado di trovare un DC.
• 5723 e 5783: problemi nel canale sicuro del computer.
• 40960/40961 (LSA): errori di autenticazione Kerberos/NTLM verso il DC.

Firewall, ACL o IPSec

La mancata apertura di porte fra subnet/siti/VPN è una delle cause più comuni. Tabella di riferimento:

Servizio	Porte	Note
Kerberos	TCP/UDP 88	Autenticazione principale in AD.
LDAP	TCP/UDP 389	LDAP in chiaro (per DC Locator e bind di servizio).
LDAPS	TCP 636	LDAP su TLS/SSL.
Global Catalog	TCP 3268, 3269	Ricerca universale; 3269 è GC su TLS.
SMB/Netlogon	TCP 445	Accesso a SYSVOL/NETLOGON e RPC su SMB.
RPC Endpoint Mapper	TCP 135	Indirizzamento servizi RPC.
RPC dinamiche	TCP 49152–65535	Intervallo predefinito moderno per chiamate RPC.
NTP	UDP 123	Sincronizzazione oraria.

Se esistono VPN con NAT, verifica che il NAT non alteri i pacchetti Kerberos (frag/MTU) e che i ritorni siano consentiti (stateful).

Riavvio o riparazione del canale sicuro

Il secure channel che lega il computer al dominio può rompersi (snapshot, restore, reset password macchina, ecc.).

nltest /sc_verify:<DominioB>
nltest /sc_reset:<DominioB>

In PowerShell:

Test-ComputerSecureChannel -Verbose
Reset-ComputerMachinePassword -Server <FQDN-DC> -Credential (Get-Credential)

Approfondimenti tecnici utili

DNS e DC Locator

Il meccanismo di DC Locator usa query SRV (es. ldap.tcp.dc.msdcs.<dominio>, kerberos.tcp) combinate con la mappatura Site/Subnet in Active Directory Sites and Services. In assenza di record o con siti non definiti correttamente, il client può scegliere DC remoti o non raggiungibili, sfociando in STATUSNOLOGONSERVERS.

Controlli rapidi:

nltest /dsgetsite
nltest /dsgetdc:<Dom> /force
dcdiag /test:DNS /v

Global Catalog, UPN e referral

Per autenticazioni cross‑domain, la presenza di un Global Catalog nel sito o comunque raggiungibile riduce la latenza e gli errori di referral. Assicurati che gli UPN suffix siano noti e instradati correttamente tra le foreste, e che non vi siano omonimie di UPN che inducano a contattare il dominio sbagliato.

RODC e siti remoti

Con Read‑Only Domain Controller nei branch office, alcune credenziali potrebbero non essere memorizzate in cache (password caching policy). Se il collegamento WAN non consente il contatto con un DC scrivibile/GC, l’autenticazione può fallire con STATUSNOLOGON_SERVERS.

Password del trust e rotazione

Le password dei trust si aggiornano periodicamente. Se la replica tra DC è interrotta o gli orologi sono fuori sincronia, la verifica del trust può fallire. In questi casi, oltre al netdom trust /verify, può essere necessario reset della password del trust e/o ripristino della replica.

Kerberos e NTLM

Kerberos è preferito; NTLM può intervenire in scenari particolari (es. vecchi protocolli o mancata risoluzione SPN). Problemi di SPN, di delega o di canale sicuro possono far ricadere su NTLM, e se anche questo non raggiunge un DC si ottiene lo stesso errore.

Quando il problema è intermittente

Se l’errore si presenta a finestre orarie ricorrenti, indaga su:

• Backup, snapshot o patch che riavviano temporaneamente i DC.
• Job che modificano regole firewall o tabelle di routing.
• Saturazione banda nelle ore di picco (repliche o DFS che occupano la WAN).

Strumenti avanzati utili

Comandi che accelerano la diagnosi:

dcdiag /v
dcdiag /test:DNS /DNSALL /e
repadmin /queue
repadmin /showrepl *
repadmin /showconn *
repadmin /kcc *
klist purge
setspn -L <AccountDiServizio>
Get-WinEvent -LogName System -FilterXPath "*[System[(EventID=5719 or EventID=5723 or EventID=5783)]]"

Per catture di rete, usa Wireshark focalizzandoti su Kerberos (tcp.port==88 or udp.port==88), LDAP/GC (389, 636, 3268, 3269) e RPC (135 + range dinamico).

Esempi di scenari e fix

DC remoto raggiungibile via ping ma non via LDAP

Sintomo: ping OK, ma Test-NetConnection -Port 389 fallisce. Causa: ACL firewall inter‑site che consente solo ICMP. Fix: apri le porte AD minime (389/636/88/445/135 + RPC dinamiche) e verifica con nltest /dsgetdc.

SRV obsoleti dopo rimozione di un DC

Sintomo: nslookup -type=SRV ldap.tcp.dc._msdcs restituisce anche un DC inesistente. Causa: record SRV e host non ripuliti. Fix: rimuovi i record residui, forza la registrazione DNS: ipconfig /registerdns sul DC attivo o riavvia il servizio Netlogon.

Trust apparentemente integro ma autenticazione cross‑domain fallisce

Sintomo: netdom trust /verify OK, ma utenti di A non accedono a risorse in B. Causa: Global Catalog non raggiungibile o siti AD non configurati; DC di B inoltra a un DC di A non raggiungibile. Fix: abilita un GC in sito o apri le porte verso un GC raggiungibile; verifica gc.tcp e nltest /dclist.

Checklist rapida

• DNS interni autorevoli configurati sul server? SRV completi e aggiornati?
• Porte AD aperte fra i segmenti coinvolti (incluso intervallo RPC)?
• Tempo sincronizzato (PDC Emulator allineato a fonte NTP affidabile)?
• Replica AD sana (repadmin /replsummary pulito)?
• Trust verificato e password allineata (netdom trust /verify)?
• Secure channel della macchina integro (Test-ComputerSecureChannel)?
• Eventi 5719/5723/5783/40960/40961 analizzati su server e DC?
• Selezione del DC corretta in base ai Siti AD (nltest /dsgetsite)?

Domande frequenti

Il server contatta prima il DC del dominio locale o quello del dominio fidato?
Sempre il DC del dominio locale. Solo se l’account appartiene al dominio fidato, il DC locale inoltra la richiesta verso il DC esterno.

Posso risolvere con un semplice riavvio?
Talvolta un riavvio di Netlogon o del server “sblocca” il DC Locator, ma se la causa è DNS, firewall, orologio o trust danneggiato, il problema si ripresenterà. Segui la checklist.

Perché l’errore compare solo in alcune fasce orarie?
Tipicamente per attività pianificate che spengono o isolano temporaneamente i DC, o per finestre di manutenzione/backup che saturano i link WAN.

Serve un Global Catalog?
Non è obbligatorio in tutti i casi, ma riduce i problemi in ambienti multiforest/multidominio e accelera la risoluzione di UPN e gruppi universali.

Passaggi consigliati per la risoluzione

1. Verifica con DNS e SRV record nslookup -type=SRV ldap.tcp.dc._msdcs.<DominioB> nslookup -type=SRV ldap.tcp.dc._msdcs.<DominioA> Assicurati che restituiscano almeno un DC raggiungibile.
2. Test di raggiungibilità dei DC ping <FQDNDC> telnet <FQDNDC> 389 nltest /dsgetdc:<DominioB> nltest /dsgetdc:<DominioA>
3. Controllo stato del trust netdom trust <DominioA> /domain:<DominioB> /verify Oppure usa “Active Directory Domains and Trusts”.
4. Sincronizzazione oraria e repliche Differenze superiori a 5 minuti (Kerberos) o repliche AD interrotte generano l’errore.
5. Event Viewer Controlla System e Directory‑Service per Event ID 5719, 5723, 5783 o 40960/40961 (LSA).
6. Firewall, ACL o IPSec Verifica che non vi siano blocchi sulle porte AD o filtri tra subnet/VPN.
7. Riavvio o riparazione del canale sicuro nltest /sc_verify:<DominioB> nltest /sc_reset:<DominioB> In casi estremi, rejoin al dominio.

Buone pratiche per prevenire ricadute

• Implementa DNS forwarding reciproco tra foreste e monitora la salute dei record SRV.
• Distribuisci Global Catalog in ogni sito principale e verifica la reachability inter‑site.
• Allinea il PDC Emulator a una fonte NTP affidabile e disabilita la sincronizzazione tempo degli hypervisor dove non appropriata.
• Documenta e automatizza le regole firewall critiche per AD; evita modifiche estemporanee.
• Monitora eventi Netlogon/LSA e la replica AD con report giornalieri (repadmin, dcdiag).

Conclusioni

L’errore STATUSNOLOGON_SERVERS non è “misterioso”: indica che la catena di contatto dei DC si è interrotta in uno dei suoi anelli. Ricostruendo il flusso — DC locale prima, DC del dominio fidato poi — e seguendo la checklist proposta (DNS, connettività, trust, tempo, repliche, secure channel), puoi identificare rapidamente il punto di rottura e ripristinare un’autenticazione stabile tra domini con trust.

---

Informazioni aggiuntive utili

• STATUSNOLOGON_SERVERS (0xC000005E) è restituito da Netlogon quando non trova alcun DC per autenticare la sessione.
• In ambienti multiforest/multidominio è buona prassi avere DNS forwarding reciproco e DC Global Catalog in siti raggiungibili.
• Se il problema si verifica solo per determinati intervalli orari, controlla job di backup, snapshot o patch che spengono temporaneamente i DC.