Объект групповой политики брандмауэра Windows не применяется должным образом
Итак, у меня есть небольшая лаборатория. с 2 контроллерами домена, оба работают под управлением server 2019 core. Я создал объект групповой политики с некоторыми правилами брандмауэра и связал его в верхней части домена, применив ко всем устройствам, включая оба контроллера домена.
DC1, который в настоящее время все еще выполняет все роли FSMO, получил политику, но правила не активны.
DC2, получил политику и все правила активны.
Я хоть убей не могу понять, почему один 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, находятся в «Неактивном» status и показать статус принудительного применения как "ProfileInactive" - что указывает на отключение профиля домена, но на самом деле это совсем не так - все профили брандмауэра включены на обоих контроллерах домена, и, конечно же, есть некоторые настраиваемые правила (профиль домена), которые получают в любом случае включен DCPromo, так что профиль должен быть включен и работать, но здесь с обоих контроллеров домена
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}
Кто-нибудь знает, в чем может заключаться проблема?
В сетевых настройках на DC1, подключены ли вы к профилю домена? Настройки -> Сеть и Интернет -> Центр управления сетями и общим доступом -> Изменить дополнительные настройки общего доступа -> Убедитесь, что домен является текущим профилем.
Рекомендуется, или, по крайней мере, я лично рекомендую синхронизировать идентификатор группы и идентификатор пользователя. Есть много способов сделать, и поддерживать это последовательно - я перейду к трем вариантам.
Вручную :
Можно вручную добавить пользователя на каждый хост, первый SSH на оба хоста, а затем выполнить useradd -u 1500 testuser , заменив testuser предпочтительным именем пользователя.
Это создаст пользователя с GID/UID 1500 , который можно подтвердить с помощью id testuser , который должен дать вам что-то вроде uid = 1500 (testuser) gid = 1500 (testuser) groups = 1500 (testuser)
Testuser :
Для этого потребуется еще
testuser:
user.present:
- fullname: 'Test User'
- uid: 1500
- gid: 1500
Ссылка: https://docs.saltstack.com/en/3000/ref/modules/all/salt.modules.useradd.html
(Есть и другие варианты управления конфигурацией, такие как Anible, Puppet, Chef)
Централизованная :
Есть несколько вариантов, но популярным является FreeIPA , который является хорошим моноблочным решением для централизованной аутентификации Linux.
Конечно, этот вариант более интересен и потребует от вас некоторых исследований - но есть несколько руководств по установке и настройке, например этот.
-121--480743- По сути, Apache и PHP используют средства управления доступом на уровне операционной системы и файловой системы для защиты целостности файлов, сценариев и кода.
Предполагается, что если эти пользователи проходят мимо несанкционированных пользователей, у вас есть большие проблемы, вы не можете полагаться на то, что система осознает тот факт, что она была подделана и должна считать всю систему скомпрометированной. (И
Попытки защитить целостность ваших файлов, сценариев и кода от доверенных пользователей обычно считаются проигрышным предложением.)
PHP не имеет никакой собственной поддержки для подписи кода , я ожидаю, потому что это та технология, которая не очень хорошо работает в экосистемах Open Source и процветает гораздо больше в закрытых платформах.
IIRC еще в день « Zend Guard » была вещью для подписанного и зашифрованного PHP, которая полагалась на пользовательский «модуль» PHP, чтобы позволить этому зашифрованному PHP работать. Но это никогда не переносилось за пределы PHP 5.6.
В настоящее время существует несколько PHP-кодеров/обфускаторов AFAIK, которые предназначены для того, чтобы сделать обратную инженерию и успешные изменения кода более трудными для достижения, но не эквивалентными подписыванию кода.
-121--478507-
KB162 был верен, так как DC1 считал, что он находится в общедоступной сети, а не в домене.
Что касается причины...
Служба NlaSvc (Network Location Service) отвечает за определение сетевого местоположения устройства. Для этого он полагается (возможно, среди прочего) на DNS.
Сетевая карта контроллера домена имела 2 записи DNS в следующем порядке:
- 127.0.0.1
- DC2
Служба DNS запускается после службы NLA, что заставляет сервер думать, что она находится в открытом расположении. Хотя DC2 также имеет 127.0.0.1 в качестве первого DNS-сервера, он не страдает от этих проблем, что означает, что гонка условия происходит и что DC1 не всегда могут быть затронуты этой проблемой.
Несколько исследований показывают несколько возможных решений:
- Установите для NlaSvc значение Automatic (отложенный запуск)
- Добавьте зависимость DNS к NlaSvc
- Измените порядок DNS-сервера, чтобы сначала перейти к другому контроллеру домена, а затем к самому себе.
Первый вариант не обязательно решает его, поскольку это условие гонки, и мы не знаем, сколько времени займет запуск DNS-сервера. Это, скорее всего, всегда исправит, но я не верю, что мы можем гарантировать с 100% уверенностью, что это никогда не повторится.
Второй вариант - это небольшой взлом, и я бы утверждал, что он не поддерживается, и может даже быть, что Microsoft изменяет эти значения во время обновления, это просто невозможно знать наверняка.
Что касается третьего варианта... пока он решает его в ситуации, когда хотя бы один из контроллеров домена работает, он все равно будет представлять проблему, когда оба контроллера домена не работают: первый, который будет загружен, будет смотреть на другой контроллер домена для DNS, он не отвечает, NlaSvc установит сетевое расположение на общедоступное, служба DNS запускается, NlaSvc больше не меняет его. Второй DC, чтобы начать будет хорошо, хотя.
Я думаю, что я пойду с первым вариантом, поскольку он, возможно, обеспечивает лучшую поддержку и будет следить оттуда.
Спасибо KB162, что помогли мне найти это решение.