- 09/08/2020
- 6 minuti per leggere
-
- D
- v
- s
Questo articolo descrive il meccanismo usato da Windows per localizzare un controller di dominio in un dominio basato su Windows-basato su Windows.
Nota
Questo articolo si applica a Windows 2000. Il supporto per Windows 2000 termina il 13 luglio 2010. Il Windows 2000 End-of-Support Solution Center è un punto di partenza per pianificare la tua strategia di migrazione da Windows 2000. Per ulteriori informazioni, consultare la politica del ciclo di vita del supporto Microsoft.
Versione originale del prodotto: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numero originale della KB: 247811
Sommario
Questo articolo descrive in dettaglio il processo di individuazione di un dominio in base al suo nome in stile DNS e al suo nome in stile flat (NetBIOS). Il nome in stile flat è usato per la compatibilità all’indietro. In tutti gli altri casi, i nomi in stile DNS dovrebbero essere usati come una questione di politica. Questo articolo affronta anche la risoluzione dei problemi del processo di localizzazione del controller di dominio.
Più informazioni
Questa sequenza descrive come il Locator trova un controller di dominio:
-
Sul client (il computer che sta localizzando il controller di dominio), il Locator viene avviato come una chiamata di procedura remota (RPC) al servizio Netlogon locale. La chiamata API (application programming interface) DsGetDcName del Locator è implementata dal servizio Netlogon.
-
Il client raccoglie le informazioni necessarie per selezionare un controller di dominio e le passa al servizio Netlogon usando la chiamata DsGetDcName.
-
Il servizio Netlogon sul client usa le informazioni raccolte per cercare un controller di dominio per il dominio specificato in uno dei due modi:
-
Per un nome DNS, Netlogon interroga il DNS usando il localizzatore IP/DNS-compatibile–cioè, DsGetDcName chiama la chiamata DnsQuery per leggere i record SRV (Service Resource) e i record “A” dal DNS dopo aver aggiunto il nome del dominio alla stringa appropriata che specifica i record SRV.
-
Una workstation che si sta collegando a un dominio basato su Windows interroga il DNS per i record SRV nella forma generale:
_service._protocol.DnsDomainName
I server Active Directory offrono il servizio Lightweight Directory Access Protocol (LDAP) sul protocollo TCP. Pertanto, i client trovano un server LDAP interrogando il DNS per un record della forma:
_ldap._tcp.DnsDomainName
-
-
Per un nome NetBIOS, Netlogon esegue la ricerca del controller di dominio utilizzando il Microsoft Windows NT versione 4.0-compatibile Locator (cioè, usando il meccanismo specifico del trasporto (per esempio, WINS).
In Windows NT 4.0 e precedenti, la “scoperta” è un processo per localizzare un controller di dominio per l’autenticazione nel dominio primario o in un dominio fidato.
-
Il servizio Netlogon invia un datagramma ai computer che hanno registrato il nome. Per i nomi di dominio NetBIOS, il datagramma è implementato come un messaggio di mailslot. Per i nomi di dominio DNS, il datagramma è implementato come una ricerca LDAP User Datagram Protocol (UDP). (UDP è il protocollo di trasporto dei datagrammi 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 permette a un programma su un computer di inviare un datagramma a un programma su un altro computer. UDP include un numero di porta del protocollo, che permette al mittente di distinguere tra più destinazioni (programmi) sul 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 del controller di dominio in modo che le richieste successive non debbano ripetere il processo di scoperta. La cache di queste informazioni incoraggia l’uso coerente dello stesso controller di dominio e una visione coerente di Active Directory.
Quando un client si connette o si unisce alla rete, deve essere in grado di localizzare un controller di dominio. Il client invia una query DNS Lookup al DNS per trovare i controller di dominio, preferibilmente nella sottorete del client. Pertanto, i client trovano un controller di dominio interrogando il DNS per un record della forma:
_LDAP._TCP.dc._msdcs.domainname
Dopo che il client trova un controller di dominio, stabilisce la comunicazione utilizzando LDAP per ottenere l’accesso ad Active Directory. Come parte di questa negoziazione, il controller di dominio identifica in quale sito si trova il client in base alla subnet IP di quel client. Se il client sta comunicando 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 controller di dominio in quel sito (per esempio, quando il client invia una query DNS Lookup al DNS per trovare controller di dominio nella sottorete del client), il client usa il controller di dominio che non è ottimale. Altrimenti, il client esegue di nuovo una ricerca DNS specifica per il sito con il nuovo nome del sito ottimale. Il controller di dominio usa alcune delle informazioni del servizio di directory per identificare i siti e le subnet.
Dopo che il client individua un controller di dominio, la voce del controller di dominio è nella cache. Se il controller di dominio non si trova nel sito ottimale, il client lava la cache dopo quindici minuti e scarta la voce della cache. Quindi tenta 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, impostare un canale sicuro. Il client è quindi pronto per eseguire normali interrogazioni e cercare informazioni nella directory.
Il client stabilisce una connessione LDAP a un controller di dominio per accedere. Il processo di logon utilizza Security Accounts Manager. Poiché il percorso di comunicazione usa l’interfaccia LDAP e il client è autenticato da un controller di dominio, l’account del client è verificato e passato attraverso Security Accounts Manager all’agente del servizio di directory, poi al livello del database e infine al database nell’Extensible Storage Engine (ESE).
Risoluzione dei problemi del processo di individuazione del dominio
Per risolvere i problemi del processo di individuazione del dominio:
-
Controlla Event Viewer sia sul client che sul server. I log degli eventi possono contenere messaggi di errore che indicano la presenza di un problema. Per visualizzare Event Viewer, clicca su Start, su Programmi, su Strumenti di amministrazione e poi su Event Viewer. Controlla il registro di sistema sia sul client che sul server. Inoltre, controlla i log di Directory Service sul server e i log DNS sul server DNS.
-
Controlla la configurazione IP usando il comando
ipconfig /all
al prompt dei comandi. -
Usa l’utilità Ping per verificare la connettività di rete e la risoluzione dei nomi. Fai il ping sia dell’indirizzo IP che del nome del server. Potresti anche voler fare il ping del nome del dominio.
-
Utilizzare lo strumento Netdiag per determinare se i componenti di rete funzionano correttamente. Per inviare l’output dettagliato a un file di testo, usate il seguente comando:
netdiag /v >test.txt
Esaminate il file di log, cercando i problemi, e indagate su qualsiasi componente coinvolto. Questo file contiene anche altri dettagli di configurazione della rete. -
Per risolvere problemi minori, usa lo strumento Netdiag con la seguente sintassi:
netdiag /fix
. -
Utilizzare il comando
nltest /dsgetdc:domainname
per verificare che un controller di dominio possa essere localizzato per un dominio specifico. -
Utilizzare lo strumento NSLookup per verificare che le voci DNS siano correttamente registrate nel DNS. Verificate che i record host del server e i record SRV GUID possano essere risolti.
Per esempio, per verificare la registrazione dei record, usate i seguenti comandi:
nslookup servername. childofrootdomain. rootdomain.com
nslookup guid._msdcs. rootdomain.com
-
Se uno di questi comandi non ha successo, usate uno dei seguenti metodi per registrare nuovamente i record nel DNS:
- Per forzare la registrazione dei record dell’host, digitate ipconfig /registerdns.
- Per forzare la registrazione del servizio del controller di dominio, fermate e avviate il servizio Netlogon.
-
Per rilevare i problemi del controller di dominio, eseguite l’utilità DCdiag da un prompt dei comandi. L’utilità esegue una serie di test per verificare che un controller di dominio funzioni correttamente. Usate questo comando per inviare i risultati a un file di testo:
dcdiag /v >dcdiag.txt
-
Utilizzare lo strumento Ldp.exe per connettersi e collegarsi al controller di dominio per verificare la corretta connettività LDAP.
-
Se si sospetta che un particolare controller di dominio abbia dei problemi, può essere utile attivare la registrazione di debug Netlogon. Usa l’utilità NLTest digitando questo comando:
nltest /dbflag:0x2000ffff
. Le informazioni vengono poi registrate nella cartella Debug nel file Netlogon.log. -
Se non hai ancora isolato il problema, usa Network Monitor per monitorare il traffico di rete tra il client e il controller di dominio.