☰

Windows ファイアウォール GPO が正しく適用されない

tag-icon • tag-icon windows active-directory firewall group-policy
Windows ファイアウォール GPO が正しく適用されない

私には 2 つの DC があり、どちらも Server 2019 Core を実行している小さなラボがあります。ファイアウォール ルールを含む GPO を作成し、それをドメインの最上位にリンクして、両方の DC を含むすべてのデバイスに適用しました。

現在すべてのFSMOロールを保持しているDC1はポリシーを受信しましたが、ルールはアクティブではありません。

DC2 はポリシーを受信し、すべてのルールをアクティブにしています。

一方の DC ではルールが適切に適用されているのに、もう一方の 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 に適用されたすべてのルールは「非アクティブ」ステータスで、適用ステータスは「ProfileInactive」と表示されます。これはドメイン プロファイルが無効になっていることを示していますが、実際にはそうではありません。両方の DC ですべてのファイアウォール プロファイルが有効になっており、もちろん、DCPromo によって有効になるカスタム (ドメイン プロファイル) ルールもいくつかあるため、そのプロファイルは稼働している必要がありますが、ここでは両方の 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}

問題がどこにあるのか、何か手がかりを持っている人はいますか?

答え1

DC1 のネットワーク設定で、ドメイン プロファイルに接続されていますか? [設定] -> [ネットワークとインターネット] -> [ネットワークと共有センター] -> [詳細な共有設定の変更] -> [ドメイン] が現在のプロファイルであることを確認します。

答え2

KB162 は、DC1 がドメインではなくパブリック ネットワークの場所にあると認識していた点で正しいです。

理由は…

さて、NlaSvc (ネットワーク ロケーション サービス) サービスは、デバイスのネットワーク ロケーションを決定する役割を担っています。そのために、このサービスは (おそらく他のものの中でも) DNS に依存しています。

この DC の NIC には、次の 2 つの DNS エントリがありました (この順序で)。

  • 127.0.0.1
  • DC2

DNS サービスは NLA サービスの後に開始されていたため、サーバーはパブリックな場所にあると認識していました。DC2 も最初の DNS サーバーとして 127.0.0.1 を持っていますが、これらの問題は発生していません。これは、競合状態が発生しており、DC1 も常にこの問題の影響を受けるわけではないことを意味します。

少し調べてみると、いくつかの解決策が見つかりました。

  1. NlaSvc を自動 (遅延開始) に設定する
  2. NlaSvc に DNS の依存関係を追加する
  3. DNS サーバーの順序を変更して、最初に他の DC にアクセスし、次に自分自身にアクセスするようにします。

最初のオプションは、競合状態であり、DNS サーバーの起動にどのくらい時間がかかるか分からないため、必ずしも問題を解決するわけではありません。ほとんどの場合、この方法で必ず問題は解決しますが、二度と発生しないと 100% 保証できるとは思いません。

2 番目のオプションはちょっとしたハックであり、サポートされていないと主張します。また、Microsoft が更新中にこれらの値を変更する可能性さえありますが、確実に知ることは不可能です。

3 番目のオプションについては、少なくとも 1 つの DC が起動している状況では問題は解決しますが、両方の DC がダウンしている場合は依然として問題が発生します。最初に起動した DC は DNS について他の DC を参照しますが、応答しません。NlaSvc はネットワークの場所をパブリックに設定し、DNS サービスが開始され、NlaSvc はそれを変更しなくなります。ただし、2 番目に起動する DC は問題ありません。

おそらく最も優れたサポートを提供し、そこから監視する最初のオプションを選択することになると思います。

この解決方法を見つけるのに協力してくれた KB162 に感謝します。

関連情報