Tengo un pequeño laboratorio con 2 DC, ambos con el núcleo del servidor 2019. Creé un GPO con algunas reglas de firewall y lo vinculé en la parte superior del dominio, aplicándolo a todos los dispositivos, incluidos ambos DC.
DC1, que actualmente todavía desempeña todas las funciones de FSMO, recibió la política pero las reglas no están activas.
DC2, ha recibido la póliza y tiene todas las reglas activas.
Por mi vida no puedo entender por qué un DC está aplicando correctamente las reglas mientras que el otro no. Puedo navegar hasta el registro y ver las reglas del firewall en ambos DC, en un RSOP muestra que la computadora definitivamente está recibiendo la política y analizándola e incluso puedo ver las reglas cuando las busco en PowerShell, pero... entonces Hay una diferencia al comparar ambos DC:
DC1 (donde no se aplican reglas):
EnforcementStatus Name Profile PrimaryStatus
----------------- ---- ------- -------------
ProfileInactive ComPlusNetworkAccess-DCOM-In Domain Inactive
{ProfileInactive, Enforced} RemoteDesktop-UserMode-In-UDP Any OK
{ProfileInactive, Enforced} RemoteDesktop-UserMode-In-TCP Any OK
ProfileInactive RemoteEventLogSvc-RPCSS-In-TCP Domain Inactive
ProfileInactive RemoteEventLogSvc-NP-In-TCP Domain Inactive
ProfileInactive RemoteEventLogSvc-In-TCP Domain Inactive
ProfileInactive RVM-RPCSS-In-TCP Domain Inactive
ProfileInactive RVM-VDSLDR-In-TCP Domain Inactive
ProfileInactive RVM-VDS-In-TCP Domain Inactive
ProfileInactive ComPlusRemoteAdministration-DCOM-In Domain Inactive
ProfileInactive WMI-ASYNC-In-TCP Domain Inactive
ProfileInactive WMI-WINMGMT-In-TCP Domain Inactive
ProfileInactive WMI-RPCSS-In-TCP Domain Inactive
ProfileInactive RemoteTask-RPCSS-In-TCP Domain Inactive
ProfileInactive RemoteTask-In-TCP Domain Inactive
Mientras que en DC2 se ven así:
EnforcementStatus Name Profile PrimaryStatus
----------------- ---- ------- -------------
Enforced ComPlusNetworkAccess-DCOM-In Domain OK
{ProfileInactive, Enforced} RemoteDesktop-UserMode-In-UDP Any OK
{ProfileInactive, Enforced} RemoteDesktop-UserMode-In-TCP Any OK
Enforced RemoteEventLogSvc-RPCSS-In-TCP Domain OK
Enforced RemoteEventLogSvc-NP-In-TCP Domain OK
Enforced RemoteEventLogSvc-In-TCP Domain OK
Enforced RVM-RPCSS-In-TCP Domain OK
Enforced RVM-VDSLDR-In-TCP Domain OK
Enforced RVM-VDS-In-TCP Domain OK
Enforced ComPlusRemoteAdministration-DCOM-In Domain OK
Enforced WMI-ASYNC-In-TCP Domain OK
Enforced WMI-WINMGMT-In-TCP Domain OK
Enforced WMI-RPCSS-In-TCP Domain OK
Enforced RemoteTask-RPCSS-In-TCP Domain OK
Enforced RemoteTask-In-TCP Domain OK
En resumen, todas las reglas aplicadas a través de GPO a DC1 están en estado "Inactivo" y muestran el estado de cumplimiento como "Perfil Inactivo", lo que indica que el perfil del Dominio está deshabilitado, pero en realidad ese no es el caso en absoluto: todos los perfiles de firewall están habilitados en ambos DC y, por supuesto, hay algunas reglas personalizadas (perfil de dominio) que DCPromo habilita de todos modos, por lo que el perfil debe estar activo y funcionando, pero aquí de ambos DC
DC1:
Name : Domain
Enabled : True
DefaultInboundAction : NotConfigured
DefaultOutboundAction : NotConfigured
AllowInboundRules : NotConfigured
AllowLocalFirewallRules : NotConfigured
AllowLocalIPsecRules : NotConfigured
AllowUserApps : NotConfigured
AllowUserPorts : NotConfigured
AllowUnicastResponseToMulticast : NotConfigured
NotifyOnListen : False
EnableStealthModeForIPsec : NotConfigured
LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log
LogMaxSizeKilobytes : 4096
LogAllowed : False
LogBlocked : False
LogIgnored : NotConfigured
DisabledInterfaceAliases : {NotConfigured}
DC2:
Name : Domain
Enabled : True
DefaultInboundAction : NotConfigured
DefaultOutboundAction : NotConfigured
AllowInboundRules : NotConfigured
AllowLocalFirewallRules : NotConfigured
AllowLocalIPsecRules : NotConfigured
AllowUserApps : NotConfigured
AllowUserPorts : NotConfigured
AllowUnicastResponseToMulticast : NotConfigured
NotifyOnListen : False
EnableStealthModeForIPsec : NotConfigured
LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall.log
LogMaxSizeKilobytes : 4096
LogAllowed : False
LogBlocked : False
LogIgnored : NotConfigured
DisabledInterfaceAliases : {NotConfigured}
¿Alguien tiene alguna pista de dónde podría estar el problema?
Respuesta1
En la configuración de red en DC1, ¿está conectado al perfil de dominio? Configuración -> Red e Internet -> Centro de redes y recursos compartidos -> Cambiar la configuración de uso compartido avanzado -> Asegúrese de que el dominio sea el perfil actual.
Respuesta2
KB162 tenía razón en que DC1 pensó que estaba en una ubicación de red pública en lugar de en un dominio.
En cuanto al motivo...
Pues el servicio NlaSvc (Network Location Service) se encarga de determinar la ubicación de red de un dispositivo. Para hacer eso, se basa (quizás entre otras cosas) en DNS.
La NIC de este DC tenía 2 entradas DNS de la siguiente manera (en este orden):
- 127.0.0.1
- DC2
El servicio DNS se iniciaba después del servicio NLA, lo que hacía que el servidor pensara que estaba en una ubicación pública. Aunque DC2 también tiene 127.0.0.1 como primer servidor DNS, no sufre estos problemas, lo que significa que se está produciendo una condición de carrera y es posible que DC1 tampoco siempre se vea afectado por este problema.
Un poco de investigación muestra algunas posibles soluciones:
- Configure NlaSvc en Automático (inicio retrasado)
- Agregue una dependencia de DNS a NlaSvc
- Cambie el orden del servidor DNS para ir primero al otro DC y luego a sí mismo.
La primera opción no necesariamente lo resuelve ya que es una condición de carrera y no sabemos cuánto tiempo tarda el servidor DNS en iniciarse. Lo más probable es que siempre se solucione, pero no creo que podamos garantizar con un 100% de certeza que nunca volverá a suceder.
La segunda opción es un poco pirateada y yo diría que no es compatible e incluso puede ser que Microsoft cambie estos valores durante una actualización, es simplemente imposible saberlo con seguridad.
En cuanto a la tercera opción... si bien lo resuelve en una situación en la que al menos uno de los DC está activo, aún presentará un problema cuando ambos DC estén inactivos: el primero que se inicie buscará en el otro DC. DNS, no responde, NlaSvc establecerá la ubicación de la red como pública, se inicia el servicio DNS, NlaSvc ya no lo cambia. Sin embargo, el segundo DC en comenzar estará bien.
Creo que optaré por la primera opción, ya que posiblemente proporcione el mejor soporte y monitorearé desde allí.
Gracias a KB162 por ayudarme a llegar a esta solución.