El controlador de dominio cree que está en una red pública

Tenemos un controlador de dominio primario Server 2008 R2 que parece tener amnesia a la hora de determinar en qué tipo de red se encuentra. La (única) conexión de red se identifica al inicio como una 'Red pública'.

Sin embargo, si desactivo y luego vuelvo a habilitar la conexión, felizmente se da cuenta de que en realidad es parte de una red de dominio.

¿Esto se debe a que los Servicios de dominio de AD no se inician cuando la ubicación de red se resuelve inicialmente?

Este problema causa algunos dolores de cabeza con las Reglas de Firewall de Windows (que estoy más que consciente de que se pueden resolver de otras maneras), por lo que tengo curiosidad por ver si alguien sabe por qué sucede esto.

¿Tiene una puerta de enlace predeterminada en esa conexión? ¿Responde a las solicitudes de ping?

Windows usa puertas de enlace para identificar redes; Si no tiene una puerta de enlace configurada, o si no puede hacer ping con éxito, no podrá identificar la red a la que está conectada y asumirá que es pública.

Si la red de un controlador de dominio se clasifica como red de dominio no depende de la configuración de la puerta de enlace.

El comportamiento de una clasificación de red falsa puede ser causado por el servicio NLA(reconocimiento de ubicación de red) starts before the domain is available. En este caso, la red pública o privada se elige y no se corrige después.

Cómo verificar si se da esta situación de falla
Cuando el controlador de dominio después de reiniciar está en la red pública, reinicie el servicio NLA o desconecte / vuelva a conectar la red. El controlador de dominio debe estar en la red de dominio después.

Cómo resolverlo
Puede ayudar configurar el Servicio NLA en un inicio retrasado . Mejor, verifique por qué el dominio necesita mucho tiempo para estar presente. Parece que el dominio necesita más tiempo para iniciarse cuando hay varias tarjetas de red.

Cuando no ayuda
Cuando no se acelera la carga del dominio ni el retraso de la ayuda de NLA y el error es causado por la carga prolongada del dominio (mira: "cómo verificar ..."), entonces hay algunos Más cosas que se pueden hacer.

• Escriba un script para reiniciarlo y ejecútelo con el planificador (peligroso)

• Cambia la carga del servicio NLA al inicio del servicio, cambiando el orden de carga en el registro (peligroso)

  La siguiente entrada del Registro establece las dependencias en 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
  

• Ejecute "IPCONFIG / RENEW" desde el planificador al inicio con un retraso de 1 o 2 minutos (mejor que iniciar el servicio NLA)

• Reinicie el servicio NLA manualmente después de cada reinicio (pero: "IPCONFIG / RENEW" debería ser preferido).

Una causa más también puede ser cuando el controlador de dominio tiene dos o más IP configuradas (en la misma o en otras tarjetas de red) y las redes adicionales no están configuradas en el DNS.

La reproducción de la conducta
En un controlador de dominio de prueba (solo DC!) Que suprime la entrada puerta de enlace predeterminada y establecer el DNS Servera delayed start. Al hacer esto, el dominio necesitó mucho tiempo para cargarse y la red se clasificó como public. Después de desconectar y volver a conectar el cable de red, la red se clasificó correctamente como domain network.

Editar

Agradecido de los comentarios de Daniel Fisher lennybacony Joshua Hanley:

Cómo agregar una dependencia para NlaSvc a DNS y NTDS

ejecutar sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDSdesde CMD (use sc.exe si lo está ejecutando en PowerShell). Si desea verificar dos veces las dependencias existentes antes de agregar DNS y NTDS, usesc qc nlasvc

He visto un comportamiento similar en un servidor AD R2 2008. Lo que me atrapó fue tener más de una NIC habilitada, aunque no estaba en uso. Una vez que desactivé las NIC no utilizadas y reinicié, el problema desapareció.

La característica exacta de Windows con la que te enfrentas aquí se llama NLA (Network Location Awareness). No sé lo suficiente para afirmar que soy un experto, pero sé que hay información interesante sobre los intertubos sobre cómo funciona todo o se supone que funciona.

En mi caso, el servidor era DMZ y muchas reglas de firewall bloquean el servidor para hablar con los controladores de dominio. En este caso, deberá abrir Firewalls (hardware FW) para permitir que los servidores se comuniquen. También para ejecutar una prueba, conecte el servidor a la red donde las reglas de firewall permiten las comunicaciones entre el cliente y los servidores.

Después de instalar un nuevo controlador de dominio, es posible que "WINDOWS FIREWALL" no esté configurado correctamente en "DOMAIN: ON". Este es el resultado de los valores predeterminados de instalación incorrectos proporcionados por Microsoft. Para solucionar esto, borre la configuración de DNS IP6 en la conexión de red de ":: 0" a automático. Además, borre los reenviadores IP6 del servidor DNS.