Come si trovano i controller di dominio in Windows

Questo articolo descrive il meccanismo usato da Windows per individuare un controller di dominio in un dominio basato su Windows.

Nota

Questo articolo si applica a Windows 2000. Il supporto per Windows 2000 termina il 13 luglio 2010. Windows 2000 End-of-Support Solution Center è un punto di partenza per la pianificazione della strategia di migrazione da Windows 2000. Per altre informazioni, vedere i criteri relativi al ciclo di vita supporto tecnico Microsoft.

Si applica a: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numero KB originale: 247811

Riepilogo

Questo articolo descrive in dettaglio il processo di individuazione di un dominio in base al nome di tipo DNS e al nome NetBIOS (Flat Style). Il nome in stile flat viene usato per la compatibilità con le versioni precedenti. In tutti gli altri casi, i nomi di tipo DNS devono essere usati come una questione di criteri. Questo articolo illustra anche la risoluzione dei problemi relativi al processo di percorso del controller di dominio.

Come il localizzatore trova un controller di dominio

Questa sequenza descrive come il localizzatore trova un controller di dominio:

  • Nel client (il computer che sta individuando il controller di dominio), il localizzatore viene avviato come chiamata di procedura remota (RPC) al servizio Netlogon locale. La chiamata API (Application Programming Interface) DsGetDcName del localizzatore viene implementata dal servizio Netlogon.

  • Il client raccoglie le informazioni necessarie per selezionare un controller di dominio. Passa quindi le informazioni al servizio Netlogon usando la chiamata DsGetDcName.

  • Il servizio Netlogon nel client usa le informazioni raccolte per cercare un controller di dominio per il dominio specificato in uno dei due modi seguenti:

    • Per un nome DNS, Netlogon esegue query su DNS usando il localizzatore compatibile con IP/DNS. Ovvero, DsGetDcName chiama la chiamata DnsQuery per leggere i record SRV (Service Resource) e "A" da DNS dopo aver aggiunto il nome di dominio alla stringa appropriata che specifica i record SRV.

    • Una workstation che esegue l'accesso a un dominio basato su Windows esegue query su DNS per i record SRV nel formato generale:

      _service._protocol.DnsDomainName
      

      I server Active Directory offrono il servizio LDAP (Lightweight Directory Access Protocol) tramite il protocollo TCP. I client trovano quindi un server LDAP eseguendo una query su DNS per ottenere un record del modulo:

      _ldap._tcp. DnsDomainName

  • Per un nome NetBIOS, Netlogon esegue l'individuazione del controller di dominio usando il localizzatore compatibile con Microsoft Windows NT versione 4.0. In altre parole, usando il meccanismo specifico del trasporto, ad esempio WINS.

    In Windows NT 4.0 e versioni precedenti, l'individuazione è un processo per individuare un controller di dominio per l'autenticazione nel dominio primario o in un dominio attendibile.

  • Il servizio Netlogon invia un datagramma ai computer che hanno registrato il nome. Per i nomi di dominio NetBIOS, il datagramma viene implementato come messaggio mailslot. Per i nomi di dominio DNS, il datagramma viene implementato come ricerca UDP (Ldap User Datagram Protocol). UDP è il protocollo di trasporto del datagramma senza connessione che fa parte della suite di protocolli TCP/IP. TCP è un protocollo di trasporto orientato alla connessione.

  • Ogni controller di dominio disponibile risponde al datagramma per indicare che è attualmente operativo e restituisce le informazioni a DsGetDcName.

UDP consente a un programma in un computer di inviare un datagramma a un programma in un altro computer. UDP include un numero di porta del protocollo, che consente al mittente di distinguere tra più destinazioni (programmi) nel computer remoto.

  • Ogni controller di dominio disponibile risponde al datagramma per indicare che è attualmente operativo e restituisce le informazioni a DsGetDcName.
  • Il servizio Netlogon memorizza nella cache le informazioni sul controller di dominio in modo che le richieste successive non debbano ripetere il processo di individuazione. La memorizzazione nella cache di queste informazioni incoraggia l'uso coerente dello stesso controller di dominio e una visualizzazione coerente di Active Directory.

Quando un client accede o si aggiunge alla rete, deve essere in grado di individuare un controller di dominio. Il client invia una query di ricerca DNS a DNS per trovare i controller di dominio, preferibilmente nella subnet del client. I client trovano quindi un controller di dominio eseguendo una query su DNS per ottenere un record del modulo:

_LDAP._TCP.dc._msdcs.domainname

Dopo aver individuato un controller di dominio, il client stabilisce la comunicazione tramite LDAP per ottenere l'accesso ad Active Directory. Come parte di tale negoziazione, il controller di dominio identifica il sito in cui si trova il client in base alla subnet IP del client.

Se il client comunica con un controller di dominio che non si trova nel sito più vicino (ottimale), il controller di dominio restituisce il nome del sito del client. Se il client ha già provato a trovare i controller di dominio in tale sito, il client usa il controller di dominio non ottimale. Ad esempio, il client invia una query di ricerca DNS a DNS per trovare i controller di dominio nella subnet del client.

In caso contrario, il client esegue di nuovo una ricerca DNS specifica del sito con il nuovo nome di sito ottimale. Il controller di dominio usa alcune delle informazioni del servizio directory per identificare siti e subnet.

Dopo che il client ha individuato un controller di dominio, la voce del controller di dominio viene memorizzata nella cache. Se il controller di dominio non è nel sito ottimale, il client scarica la cache dopo 15 minuti e rimuove la voce della cache. Tenta quindi di trovare un controller di dominio ottimale nello stesso sito del client.

Dopo che il client ha stabilito un percorso di comunicazione con il controller di dominio, può stabilire le credenziali di accesso e autenticazione. E se necessario per i computer basati su Windows, può configurare un canale sicuro. Il client è quindi pronto per eseguire query normali e cercare informazioni sulla directory.

Il client stabilisce una connessione LDAP a un controller di dominio per l'accesso. Il processo di accesso usa Gestione account di sicurezza. Il percorso di comunicazione usa l'interfaccia LDAP e il client viene autenticato da un controller di dominio. L'account client viene quindi verificato e passato tramite Gestione account di sicurezza all'agente del servizio directory, quindi al livello del database e infine al database nel motore di archiviazione estendibile (ESE).

Risoluzione dei problemi relativi al processo di localizzatore di dominio

Per risolvere i problemi relativi al processo di localizzatore di dominio:

  1. Controllare Visualizzatore eventi sia nel client che nel server. I log eventi possono contenere messaggi di errore che indicano che si è verificato un problema. Per visualizzare Visualizzatore eventi, selezionare Start, scegliere Programmi>strumenti di amministrazione e quindi selezionare Visualizzatore eventi. Controllare il log di sistema sia sul client che sul server. Controllare anche i log del servizio directory nel server e i log DNS nel server DNS.

  2. Controllare la configurazione IP usando il ipconfig /all comando al prompt dei comandi.

  3. Usare l'utilità Ping per verificare la connettività di rete e la risoluzione dei nomi. Eseguire il ping sia dell'indirizzo IP che del nome del server. È anche possibile effettuare il ping del nome di dominio.

  4. Usare lo strumento Netdiag per determinare se i componenti di rete funzionano correttamente. Per inviare un output dettagliato a un file di testo, usare il comando seguente:

    netdiag /v >test.txt
    Esaminare il file di log, cercare i problemi e analizzare eventuali componenti implicati. Questo file contiene anche altri dettagli di configurazione di rete.

  5. Per risolvere i problemi secondari, usare lo strumento Netdiag con la sintassi seguente:

    netdiag /fix.

  6. Usare il nltest /dsgetdc:domainname comando per verificare che sia possibile individuare un controller di dominio per un dominio specifico.

  7. Usare lo NSLookup strumento per verificare che le voci DNS siano registrate correttamente in DNS. Verificare che i record host del server e i record SRV GUID possano essere risolti.

    Ad esempio, per verificare la registrazione dei record, usare i comandi seguenti:
    nslookup servername. childofrootdomain. rootdomain.com
    nslookup guid._msdcs. rootdomain.com

  8. Se uno di questi comandi non riesce, usare uno dei metodi seguenti per registrare nuovamente i record con DNS:

    • Per forzare la registrazione del record host, digitare ipconfig /registerdns.
    • Per forzare la registrazione del servizio controller di dominio, arrestare e avviare il servizio Netlogon.
  9. Per rilevare i problemi del controller di dominio, eseguire l'utilità DCdiag da un prompt dei comandi. L'utilità esegue molti test per verificare che un controller di dominio sia in esecuzione correttamente. Usare questo comando per inviare i risultati a un file di testo: dcdiag /v >dcdiag.txt

  10. Usare lo strumento Ldp.exe per connettersi e associare al controller di dominio per verificare la connettività LDAP appropriata.

  11. Se si sospetta che un particolare controller di dominio abbia problemi, può essere utile attivare la registrazione di debug di Netlogon. Usare l'utilità NLTest digitando questo comando: nltest /dbflag:0x2000ffff. Le informazioni vengono quindi registrate nella cartella Debug nel file Netlogon.log.

  12. Se il problema non è ancora stato isolato, usare Monitoraggio di rete per monitorare il traffico di rete tra il client e il controller di dominio.

Riferimenti

Per altre informazioni, vedere Windows Resource Kit, Capitolo 10, "Diagnostica, risoluzione dei problemi e ripristino di Active Directory".