Il controller di dominio pensa che sia su una rete pubblica

Abbiamo un controller di dominio primario Server 2008 R2 che sembra avere amnesia quando si tratta di capire su che tipo di rete si trova. La (unica) connessione di rete viene identificata all'avvio come "Rete pubblica".

Tuttavia, se disabilito e quindi riattivo la connessione, capisce felicemente che fa effettivamente parte di una rete di dominio.

Questo perché AD Domain Services non viene avviato quando inizialmente viene individuato il percorso di rete?

Questo problema provoca alcuni mal di testa con le regole di Windows Firewall (che sono più che consapevole possono essere risolti in altri modi), quindi sono per lo più solo curioso di vedere se qualcuno sa perché questo accade.

Hai un gateway predefinito su quella connessione? Risponde alle richieste di ping?

Windows utilizza i gateway per identificare le reti; se non ha un gateway configurato o se non riesce a eseguire il ping con successo, non sarà in grado di identificare la rete a cui è connesso e supporrà che sia pubblico.

Il fatto che la rete di un controller di dominio sia classificata come rete di dominio non dipende dalla configurazione del gateway.

Il comportamento di una classificazione della rete falsa può essere causato dal servizio NLA(consapevolezza della posizione della rete) starts before the domain is available. In questo caso viene scelta la rete pubblica o privata e non corretta in seguito.

Come verificare se viene fornita questa situazione di errore
Quando il controller di dominio dopo il riavvio si trova nella rete pubblica, riavviare il servizio NLA o disconnettere / riconnettere la rete. Il controller di dominio dovrebbe essere successivamente nella rete del dominio.

Come risolverlo
Potrebbe essere utile impostare il servizio NLA su un avvio posticipato . Meglio, controlla perché il dominio ha bisogno di molto tempo per essere presente. Sembra che il dominio abbia bisogno di più tempo per avviarsi quando ci sono più schede di rete.

Quando non aiuta
Quando non si accelera il caricamento del dominio né il ritardo dell'aiuto di NLA e l'errore è causato dal lungo caricamento del dominio (vedere: "come controllare ..."), allora ci sono alcuni più cose che si possono fare.

• Scrivi uno script per riavviarlo ed eseguilo con lo scheduler (pericoloso)

• Spostare il caricamento del servizio NLA alla fine del servizio inizia, modificando l'ordine di caricamento nel registro (pericoloso)

  La seguente voce di registro imposta le dipendenze su NSI RpcSs TcpIp Dhcp Eventlog NTDS DNS:

  REGEDIT4
  
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc]
  "DependOnService"=hex(7):4e,53,49,00,52,70,63,53,73,00,54,63,70,49,70,00,44,68,\
  63,70,00,45,76,65,6e,74,6c,6f,67,00,4e,54,44,53,00,44,4e,53,00,00
  

• Eseguire "IPCONFIG / RENEW" dallo scheduler all'avvio con un ritardo di 1 o 2 minuti (meglio dell'avvio del servizio NLA)

• Riavvia il servizio NLA manualmente dopo ogni riavvio (ma dovrebbe essere preferito "IPCONFIG / RENEW")!

Un'altra causa può essere anche quando il controller di dominio ha due o più IP configurati (sulla stessa o su altre schede di rete) e le reti aggiuntive non sono configurate nel DNS.

Riproduzione del comportamento
Su un controller di dominio di prova (singolo controller di dominio!) Ho eliminato la voce gateway predefinita e impostato DNS Serversu delayed start. In questo modo il dominio ha richiesto molto tempo per essere caricato e la rete è stata classificata come public. Dopo aver disconnesso e ricollegato il cavo di rete, la rete è stata classificata correttamente come domain network.

modificare

con gratitudine dai commenti di Daniel Fisher lennybacone Joshua Hanley:

Come aggiungere una dipendenza per NlaSvc a DNS e NTDS

eseguire sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDSda CMD (utilizzare sc.exe se lo si esegue in PowerShell). Se si desidera ricontrollare le dipendenze esistenti prima di aggiungere DNS e NTDS, utilizzaresc qc nlasvc

Ho visto un comportamento simile in piedi su un server AD R2 del 2008. La cosa che mi ha fatto era avere più di una scheda di rete abilitata, anche se non era in uso. Dopo aver disabilitato le schede di rete non utilizzate e riavviato, il problema è scomparso.

La funzione esatta di Windows in cui ti trovi qui si chiama NLA (Network Location Awareness). Non ne so abbastanza per affermare di essere un esperto, ma so che ci sono alcune informazioni interessanti là fuori negli intertubes su come tutto funzioni o dovrebbe funzionare.

Nel mio caso, il server era DMZ e molte regole del firewall bloccavano il server per parlare con i controller di dominio. In questo caso, sarà necessario aprire i firewall (hardware FW) per consentire ai server di comunicare. Inoltre, per eseguire un test, connettere il server alla rete in cui le regole del firewall consentono comunicazioni tra client e server.

Dopo aver installato un nuovo controller di dominio, è possibile che "WINDOWS FIREWALL" non sia impostato correttamente su "DOMAIN: ON". Questo è il risultato di impostazioni predefinite di installazione errate fornite da Microsoft. Per risolvere questo problema, cancellare le impostazioni DNS IP6 sulla connessione di rete da ":: 0" a automatico. Inoltre, cancellare i server d'inoltro IP6 dal server DNS.