☰

GPO брандмауэра Windows не применяется должным образом

tag-icon • tag-icon windows active-directory firewall group-policy
GPO брандмауэра Windows не применяется должным образом

Итак, у меня есть небольшая лаборатория с двумя контроллерами домена, оба с ядром Server 2019. Я создал объект групповой политики с некоторыми правилами брандмауэра и связал его в верхней части домена, применив ко всем устройствам, включая оба контроллера домена.

DC1, который в настоящее время по-прежнему занимает все роли FSMO, получил политику, но правила не активны.

DC2 получил политику и активировал все правила.

Я не могу понять, почему один DC правильно применяет правила, а другой — нет. Я могу перейти в реестр и увидеть правила брандмауэра на обоих DC, в RSOP он показывает, что компьютер определенно получает политику и анализирует ее, и я даже могу увидеть правила при поиске их в PowerShell, но... затем есть разница при сравнении обоих DC:

DC1 (где правила не применяются):

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

Тогда как на DC2 они выглядят так:

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

Короче говоря, все правила, примененные через GPO к DC1, находятся в состоянии «Неактивно» и показывают статус принудительного применения как «ПрофильНеактивно», что указывает на то, что профиль домена отключен, но на самом деле это совсем не так — все профили брандмауэра включены на обоих контроллерах домена, и, конечно, есть некоторые пользовательские правила (профиля домена), которые в любом случае включаются DCPromo, поэтому этот профиль должен быть включен и работать, но здесь с обоих контроллеров домена

ДК1:

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}

ДК2:

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}

Есть ли у кого-нибудь подсказки, в чем может быть проблема?

решение1

В сетевых настройках на DC1 подключены ли вы к профилю домена? Настройки -> Сеть и Интернет -> Центр управления сетями и общим доступом -> Изменить дополнительные параметры общего доступа -> Убедитесь, что домен является текущим профилем.

решение2

KB162 был прав в том, что DC1 считал, что он находится в общедоступной сетевой локации, а не в домене.

Что касается причины...

Ну, служба NlaSvc (Network Location Service) отвечает за определение сетевого местоположения устройства. Для этого она опирается (возможно, среди прочего) на DNS.

Сетевая карта этого контроллера домена имела 2 записи DNS следующим образом (в таком порядке):

  • 127.0.0.1
  • ДК2

Служба DNS запускалась после службы NLA, из-за чего сервер думал, что он находится в публичном месте. Хотя DC2 также имеет 127.0.0.1 в качестве первого DNS-сервера, он не страдает от этих проблем, что означает, что происходит состояние гонки, и что DC1 также не всегда может быть затронут этой проблемой.

Небольшое исследование показывает несколько возможных решений:

  1. Установите NlaSvc в автоматический режим (отложенный запуск)
  2. Добавить зависимость DNS от NlaSvc
  3. Измените порядок DNS-серверов так, чтобы сначала они обращались к другому контроллеру домена, а затем к себе.

Первый вариант не обязательно решает проблему, поскольку это состояние гонки, и мы не знаем, сколько времени требуется DNS-серверу для запуска. Скорее всего, он всегда исправит ее, но я не верю, что мы можем гарантировать со 100% уверенностью, что это никогда не повторится.

Второй вариант — это своего рода хак, и я бы сказал, что он не поддерживается, и вполне возможно, что Microsoft меняет эти значения во время обновления, просто невозможно знать наверняка.

Что касается третьего варианта... хотя он и решает проблему в ситуации, когда хотя бы один из DC включен, он все равно будет представлять проблему, когда оба DC выключены: первый загруженный будет искать DNS на другом DC, он не отвечает, NlaSvc установит сетевое расположение как публичное, запустится служба DNS, NlaSvc больше ее не изменяет. Однако второй запущенный DC будет в порядке.

Думаю, я выберу первый вариант, так как он, пожалуй, обеспечит наилучшую поддержку, и оттуда можно будет вести мониторинг.

Спасибо KB162 за помощь в поиске решения.

Связанный контент