なんていうか、いろいろ面倒くさい時代になってしまいました（笑）
インターネットが普及しだした頃はここまでセキュリティについて考えることはなかったのに…
というわけで今回は Windows Server 2008 から導入されている 【接続セキュリティの規則】 について
改めて設定してみようと思います。
*****************************************
こちらのテスト環境では以下を想定。
Windows Server 2012 R2 = 192.168.1.205
Windows Server 2008 R2 = 192.168.1.210
Windows Server 2003 R2 = 192.168.1.5
Windows 10 = 192.168.1.225
Windows XP = 192.168.1.12
*****************************************
上記5つのPCがドメイン内で稼動していることを前提として設定します。
2003とXPがなければラクなのに…。
≪何をしたいのか≫
・ドメイン内のPCは共有フォルダー含め全てアクセス可能にし、それ以外のPCからのアクセスを禁止（分離）
・Windows XP とWindows 2003 端末からリモートで他のPC（2012,2008,10）へアクセス出来るようにする
１.まずはドメインの直下に【グループ ポリシー（名前は何でも可）】を作成し、画像の場所まで移動します。
（最初から設定されている Default Domain Policy に設定してもかまいませんよ。…設定してもいいのなら）
コンピューターの構成
∟ポリシー
∟Windows の設定
∟セキュリティの設定
∟セキュリティが強化された Windows Firewall
∟接続セキュリティの規則 ←ココですね。
２．[接続セキュリティの規則] を右クリックし、【新しい規則】 をクリック
３．ドメイン分離のための設定を行います。
≪規則の種類≫ で [分離] をクリックし、【次へ】をクリック
４．≪要件≫を選択します。
ここでは [受信接続の認証を必須とし、送信接続に対して認証を要求する] にチェックを入れて【次へ】をクリック
５．≪認証方法≫を選択します。
ここでは [既定] をチェックし、【次へ】をクリック
６．≪プロファイル≫項は任意で設定し、【次へ】をクリック
７．≪名前≫項は任意の名前をつけて【完了】をクリック
まとめるとこんな感じ。（画像クリックで拡大します）
８．グループ ポリシー を適用します。適用順はクライアントから。
すぐにアップデートするならコマンド プロンプトを開き、以下のコマンドを入力・実行します。
Gpupdate /force
-----------------------------------------
こんな要領で、リモート用の設定も作成していきます。
ただし、Windows XP と 2003 に限っては、運用してる人は少ないと思いますが、
Windows Server 2003 R2 以前の環境には 【接続セキュリティの規則】 が作成できないせいか、
2枚目の画像部分で ≪認証の除外≫ 設定と、≪カスタム≫ でリモート用設定の2つを新たに定義しなくちゃいけなかった。
コレが気に入らない…ま、時代が時代なだけにしょうがないかな（笑）
もう1つ大事なことを書き忘れてましたが、こちらも Windows Server 2003 以前のOS に限ってですが、
TCP 445 ポートが SMBv1 でしか通信ができないので、SMBv2 以降を使うサーバーへのアクセスや共有フォルダー、
グループ ポリシーの更新ができなくなってしまいます。でも、Ping や DNS 参照、ドメインにはログオンできる。
XP だけ毎月やらなきゃいけないポリシー更新をどうしようか悩むわ・・・。
そのつどDCサーバー側のSMB1の値のデータを 0 から1 に戻して更新、ポリシー更新後に変更した値を元に戻して
Server, Netlogon, DFS Namespace サービスを再起動する。
コレならポリシー更新できるし、サーバー自体も再起動させなくてすむけどあほくさいな・・・（笑）
これで運用できるようになったけど、十分なテストを行ってから実環境に導入してみてください。
（IPSEC の導入を推奨しますが、IPSEC 設定についてざくっと書けば、ドメイン ネットワーク全体に整合性のみ、
暗号化はしないようにセキュリティのネゴシエートをする。その後、各コンピューター間で暗号化設定等を行う）
テストして最後には、認証モード（3枚目の画像）について
【受信および送信で必須】にできればいいんですけどね。
ただ、そうなれば WMI フィルターを使わないといけないのかな？今度は Windows 10 が問題になりそう…
-----------------------------------------------------------
追記）
ポリシーの適用後にサーバーと通信ができなくなった場合の対処
-----------------------------------------------------------
ただ単にポリシ－設定を戻して更新をかけ直してもポリシーの更新に失敗するだけなので、以下のように設定しなおす。
① DC 側の設定を最初に戻す。ここでは一度、【認証しない】を設定し、適用させる。
② Nslookup コマンドで DNS 参照ができるかを確認しておく。（クライアント、サーバー側ともに）
例）nslookup ＜DNS サーバー名＞
③ ポリシーの適用が失敗したクライアントPCのファイアウォールを一時的に無効化する。
④ ポリシー設定を、サーバー側と同じ、【認証しない】を適用する。ただし、コンピューターに対してのみ適用する。
ターゲットを指定しないと適用に失敗する。
Gpupdate /target:Computer /Force
ポリシーの処理に失敗する場合には、しばらく時間をあけてもう一度実行する。（適用に時間かかった時もあった
⑤ ポリシーの更新が成功したら念のため Nslookup コマンドで DNS 参照ができるかを確認しておく。
⑥ 更新が完了したらファイアウォールを有効化に戻す。
⑦ もう一度、ポリシーを適用させるコマンドを実行する。今度はユーザーも含める。
Gpupdate /Force
⑧ ポリシーが適用できたら念のため Nslookup コマンドで DNS 参照ができるかを確認しておく。
やってて色々謎が多かった。なぜサーバー側ではなく、クライアント側のファイアウォールを無効にしないといけないのか、とか、なぜ強制的に適用させたはずのポリシーの更新が、かなり遅延した状態でないと適用しなかったのか、なぜコンピューターとユーザーポリシーを同時に処理できないのに、コンピューターポリシーだけの処理なら処理が成功するのか、など、謎は深まるばかりで楽しかった（笑）
