O GPO do Firewall do Windows não está sendo aplicado corretamente

O GPO do Firewall do Windows não está sendo aplicado corretamente

Portanto, tenho um pequeno laboratório com 2 DCs, ambos executando o núcleo do servidor 2019. Criei um GPO com algumas regras de firewall e vinculei-o no topo do domínio, aplicando-se a todos os dispositivos, incluindo ambos os DCs.

DC1, que atualmente ainda detém todas as funções do FSMO, recebeu a política, mas as regras não estão ativas

DC2 recebeu a política e tem todas as regras ativas.

Não consigo entender por que um DC está aplicando as regras corretamente enquanto o outro não. Posso navegar até o registro e ver as regras de firewall em ambos os DCs, em um RSOP mostra que o computador está definitivamente recebendo a política e analisando-a e posso até ver as regras ao procurá-las no PowerShell, mas... então há uma diferença ao comparar os dois DCs:

DC1 (onde as regras não são aplicadas):

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

Enquanto no DC2 eles se parecem com isto:

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

Resumindo, todas as regras aplicadas via GPO ao DC1 estão no status "Inativo" e mostram o status de aplicação como "ProfileInactive" - ​​que aponta para o perfil do domínio sendo desabilitado, mas na verdade não é o caso - todos os perfis de firewall estão habilitados em ambos os DCs e, claro, existem algumas regras personalizadas (perfil de domínio) que são habilitadas pelo DCPromo de qualquer maneira, então esse perfil deve estar ativo e funcionando, mas aqui de ambos os DCs

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}

Alguém tem alguma pista de onde pode estar o problema?

Responder1

Nas configurações de rede do DC1, você está conectado ao perfil do domínio? Configurações -> Rede e Internet -> Central de Rede e Compartilhamento -> Alterar configurações avançadas de compartilhamento -> Certifique-se de que o domínio seja o perfil atual.

Responder2

KB162 estava correto porque DC1 pensava que estava em um local de rede pública e não em um domínio.

Quanto ao motivo...

Pois bem, o serviço NlaSvc (Network Location Service) é responsável por determinar a localização de rede de um dispositivo. Para fazer isso, ele depende (talvez entre outras coisas) do DNS.

A NIC deste DC tinha 2 entradas DNS como segue (nesta ordem):

  • 127.0.0.1
  • DC2

O serviço DNS foi iniciado após o serviço NLA, fazendo com que o servidor pensasse que estava em um local público. Embora o DC2 também tenha 127.0.0.1 como o primeiro servidor DNS, ele não sofre desses problemas, o que significa que uma condição de corrida está acontecendo e que o DC1 também pode nem sempre ser afetado por esse problema.

Um pouco de pesquisa mostra algumas soluções possíveis:

  1. Defina NlaSvc como automático (início atrasado)
  2. Adicione uma dependência de DNS ao NlaSvc
  3. Altere a ordem do servidor DNS para ir primeiro para o outro controlador de domínio e depois para ele mesmo.

A primeira opção não resolve necessariamente o problema, pois é uma condição de corrida e não sabemos quanto tempo o servidor DNS leva para inicializar. Provavelmente sempre resolverá o problema, mas não acredito que possamos garantir com 100% de certeza que isso nunca acontecerá novamente.

A segunda opção é um pouco complicada e eu diria que não tem suporte e pode até ser que a Microsoft altere esses valores durante uma atualização, é simplesmente impossível ter certeza.

Quanto à terceira opção... embora resolva numa situação em que pelo menos um dos DCs esteja ativo, ainda apresentará um problema quando ambos os DCs estiverem inativos: o primeiro a ser inicializado irá olhar para o outro DC em busca de DNS, ele não responde, o NlaSvc definirá o local da rede como público, o serviço DNS será iniciado, o NlaSvc não o alterará mais. O segundo DC para iniciar ficará bem.

Acho que optarei pela primeira opção, pois ela provavelmente fornece o melhor suporte e monitorará a partir daí.

Obrigado ao KB162 por me ajudar a chegar a esta solução.

informação relacionada