本文へ移動

GPOでPingとRDPを許可する方法——遠隔で障害対応するためのWindowsファイアウォール設定

GPOでPingとRDPを許可する方法——遠隔で障害対応するためのWindowsファイアウォール設定 Active Directory・GPO

PCの不具合について連絡を受けたとき、最初に確認したいのは「そのPCまで通信できるか」と「遠隔から状態を確認できるか」です。

ところが、Pingに応答せず、リモートデスクトップ(RDP)にも接続できない状態では、現地の方に画面を見てもらうか、管理者が直接PCの前まで行かなければならないことがあります。障害が起きてからRDPを有効にしようとしても、そのPCへ入る手段がない……ということもあります。

そこでこの記事では、Active Directory環境のクライアントPCへ、Ping応答とRDP接続をGPO(グループポリシー)でまとめて許可する方法を解説します。

ただし、遠隔操作できればよいからといって、すべてのネットワークから接続できる状態にするのは避けたいところです。今回は、ドメインネットワーク内の管理端末から保守することを前提に、許可範囲をできるだけ絞って設定します。

忙しい人のための結論

設定項目今回の設定
GPO遠隔保守用のGPOを新しく作成し、まず検証用OUへリンク
PingICMPv4のエコー要求(受信)を許可
RDP本体「リモート デスクトップ サービスを使ってリモート接続することをユーザーに許可する」を有効化
RDPの通信定義済みの「リモート デスクトップ」受信規則を有効化
適用プロファイルドメインのみ
接続元可能なら管理用PCまたは管理用ネットワークに限定
接続ユーザー管理者またはRemote Desktop Usersへ追加した保守担当者だけ

GPO名は、たとえば「クライアント遠隔保守(Ping・RDP許可)」としておくと、何のための設定か後から見ても分かりやすくなります。

PingとRDPは別の確認です

PingとRDPは、どちらも遠隔保守で役立ちますが、確認しているものは違います。

  • Ping:対象PCまでIP通信が届き、ICMPの応答が返るか
  • RDP:対象PCがTCP 3389で接続を受け付け、ログオンできるか

そのため、Pingに成功してもRDPへ接続できるとは限りません。反対に、ICMPだけがファイアウォールで拒否されている場合は、Pingに失敗してもRDPへ接続できることがあります。

確認結果考えられる状態
Ping成功・RDP成功基本的な接続準備は完了
Ping成功・RDP失敗RDP設定、ファイアウォール、サービス、接続権限を確認
Ping失敗・RDP成功ICMPの受信規則だけが適用されていない可能性
両方失敗電源、DNS、ネットワーク、GPOの適用先から確認

設定前に確認しておくこと

接続先はWindows Pro以上か

Windows 10・11のHomeエディションは、別のPCへRDP接続するクライアントにはなれますが、RDPの接続先にはなれません。接続される側のPCには、Pro、Enterprise、Educationなどの対応エディションが必要です。

名前解決とネットワークプロファイル

AD環境では、対象PCの名前をDNSで正しく引けることも大切です。また、今回のファイアウォール規則は「ドメイン」プロファイルだけに適用します。対象PCがドメインコントローラーを認識できず、ネットワークが「パブリック」になっている場合は規則が有効になりません。

Resolve-DnsName PC名
Get-NetConnectionProfile

Get-NetConnectionProfileのNetworkCategoryがDomainAuthenticatedになっているか確認します。

手順1:遠隔保守用のGPOを作成する

  1. ドメインコントローラーで「グループ ポリシーの管理」を開く
  2. 「グループ ポリシー オブジェクト」を右クリックする
  3. 「新規」を選択する
  4. GPO名に「クライアント遠隔保守(Ping・RDP許可)」と入力する
  5. 作成したGPOを、まず検証用PCが入っているOUへリンクする
グループポリシーの管理でクライアント遠隔保守(Ping・RDP許可)GPOをコンピューターOUにリンクした画面
遠隔保守用GPOを、検証するクライアントPCのOUへリンクした状態

手順2:GPOでPing応答を許可する

作成したGPOを右クリックして「編集」を開き、次の場所まで移動します。

コンピューターの構成
└ ポリシー
  └ Windows の設定
    └ セキュリティの設定
      └ セキュリティが強化された Windows Defender ファイアウォール
        └ 受信の規則
GPOのWindows Defenderファイアウォール受信規則で新しい規則を作成する画面
GPOの受信規則から、Pingを許可する新しい規則を作成する

「受信の規則」を右クリックして「新しい規則」を選び、次のように設定します。

画面設定内容
規則の種類カスタム
プログラムすべてのプログラム
プロトコルの種類ICMPv4
ICMP設定「カスタマイズ」から「特定のICMPの種類」→「エコー要求」
スコープ可能なら接続元を管理用PC・管理用サブネットに限定
操作接続を許可する
プロファイルドメインだけにチェック
名前遠隔保守用 Ping許可(ICMPv4)

IPv6でもPingを使う環境では、同じ要領でICMPv6の規則も作成します。まずIPv4だけを確認したい場合は、クライアント側でping -4 PC名と実行すると切り分けやすくなります。

手順3:GPOでRDP接続を有効にする

次に、対象PCがリモートデスクトップ接続を受け付けるようにします。GPOエディターで次の場所を開きます。

コンピューターの構成
└ ポリシー
  └ 管理用テンプレート
    └ Windows コンポーネント
      └ リモート デスクトップ サービス
        └ リモート デスクトップ セッション ホスト
          └ 接続

「リモート デスクトップ サービスを使ってリモート接続することをユーザーに許可する」を開き、「有効」にします。

GPOでリモートデスクトップ接続を許可するポリシーを有効にした画面
リモートデスクトップ接続を許可するポリシーを「有効」に設定

この設定はRDP本体の接続許可です。これだけではWindowsファイアウォールの受信規則が開いていない場合があるため、次の手順も続けて設定します。

ネットワークレベル認証(NLA)も有効にする

同じ「リモート デスクトップ セッション ホスト」の下にある「セキュリティ」を開き、「リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする」を有効にします。

GPOでリモートデスクトップのネットワークレベル認証を有効にした画面
リモートデスクトップ接続でネットワークレベル認証(NLA)を必須にする

NLAを有効にすると、RDPセッションを作成する前にユーザー認証が行われます。古いOSや特殊なRDPクライアントとの互換性確認が必要な場合を除き、有効のまま運用するのがおすすめです。

手順4:RDPのファイアウォール規則を有効にする

Ping規則を作成した「受信の規則」で、もう一度「新しい規則」を開きます。

  1. 規則の種類で「事前定義」を選択する
  2. 一覧から「リモート デスクトップ」を選択する
  3. リモートデスクトップのユーザーモード(TCP受信・UDP受信)を有効にする
  4. 「接続を許可する」を選択して完了する
GPOの受信規則でPingとRDPのTCP・UDPをドメインプロファイルだけに許可した画面
PingとRDPのTCP・UDP受信規則をドメインプロファイルだけに限定した状態

上の画像では、PingとRDPのユーザーモード(TCP受信・UDP受信)を、すべて「ドメイン」プロファイルに限定しています。定義済み規則を追加した直後に「すべて」と表示される場合は、そのままにせず各規則のプロパティから変更してください。

環境によっては「リモート デスクトップ – シャドウ(TCP受信)」も作成されます。これは別のRDPセッションを監視・操作するセッションシャドウ用の規則で、通常のクライアントPCへのRDP接続だけなら必須ではありません。今回は使用しないため無効にしています。

RDPでは主にTCP 3389が使われ、UDP 3389は通信品質の改善に利用されます。TCPだけでも接続できる場合はありますが、Windowsが用意している定義済み規則を使えば、必要な規則をまとめて管理しやすくなります。

リモートデスクトップのユーザーモード(TCP受信・UDP受信)をそれぞれダブルクリックし、「詳細設定」タブでプロファイルを「ドメイン」だけに限定します。さらに「スコープ」タブで、リモートIPアドレスを管理用PCや管理用サブネットへ絞れる場合は、ここも設定しておきます。

手順5:RDPを許可するユーザーを決める

RDPを有効にしても、誰でもログオンできるわけではありません。基本的には、対象PCのAdministratorsか、ローカルのRemote Desktop Usersグループに含まれるユーザーが接続できます。

ここでいうRemote Desktop Usersは、AD上のドメイングループではなく、各クライアントPCに用意されているローカルの組み込みグループです。

複数の保守担当者がいる場合は、ADに「G_RDP-Support」などのセキュリティグループを作り、そのドメイングループを各PCのRemote Desktop Usersへ追加すると管理しやすくなります。

コンピューターの構成
└ 基本設定
  └ コントロール パネルの設定
    └ ローカル ユーザーとグループ
GPO基本設定のローカルユーザーとグループで新しいローカルグループを作成する画面
GPOの基本設定から「ローカル グループ」を新規作成する

「新規」→「ローカル グループ」を選び、アクションを「更新」にします。グループ名は右側の検索ボタンからAD内を検索するのではなく、プルダウンから「Remote Desktop Users(ビルトイン)」を選択します。

続いて「メンバー」の「追加」をクリックし、ドメイングループの「wanwano\G_RDP-Support」を指定します。これで、保守担当者用のドメイングループが、各クライアントPCのローカルRemote Desktop Usersへ追加されます。

Remote Desktop UsersローカルグループにドメインのG_RDP-Supportグループを追加した画面
各クライアントPCのRemote Desktop Usersへ、ドメインのG_RDP-Supportグループを追加する

ここでアクションを「置換」にすると、既存メンバーまで入れ替わる可能性があります。既存環境へ追加する場合は「更新」を使う方が扱いやすいです。また、Domain Usersなどの大きなグループをそのまま追加せず、必要な担当者だけに絞ります。

クライアントPCへ適用して確認する

設定後は、検証用クライアントPCを再起動するか、管理者権限のPowerShellまたはコマンドプロンプトで次を実行します。

gpupdate /force

GPOが適用されたかは、次のコマンドで確認できます。

gpresult /r /scope:computer

「適用されたグループ ポリシー オブジェクト」に、作成したGPO名が表示されていれば、コンピューターポリシーとして認識されています。

gpresultコマンドでクライアント遠隔保守GPOが適用されたことを確認した画面
gpresult /r /scope:computerで、遠隔保守用GPOが適用されていることを確認

管理端末から接続テストする

ping PC名
Test-NetConnection PC名 -Port 3389
mstsc /v:PC名
  • ping:ICMPの応答を確認
  • Test-NetConnection:TCP 3389へ接続できるか確認
  • mstsc:実際にリモートデスクトップ接続を開始
DCからクライアントPCへのPingとTCP 3389接続に成功したPowerShell画面
DCからクライアントPCへのPingとTCP 3389の接続確認に成功した状態

Test-NetConnectionのTcpTestSucceededがTrueなら、少なくとも管理端末から対象PCのTCP 3389までは到達しています。それでもログオンできない場合は、ユーザー権限やNLA、入力した資格情報を確認します。

接続できないときの確認順

設定したのに接続できない場合は、何度もGPOを作り直すより、次の順番で確認すると原因を絞りやすくなります。

順番確認内容確認方法
1対象PCの電源・ネットワーク利用者への確認、DHCPやスイッチの情報
2DNSの名前解決Resolve-DnsName PC名
3GPOの適用gpresult /r /scope:computer
4ドメインプロファイルGet-NetConnectionProfile
5RDPサービスGet-Service TermService
6TCP 3389の待ち受けGet-NetTCPConnection -LocalPort 3389 -State Listen
7接続ユーザーの権限Remote Desktop Usersのメンバーを確認

Pingだけが失敗し、TcpTestSucceededがTrueになる場合は、RDPではなくICMP規則の適用条件を確認します。反対にPingは成功するのにTCP 3389が失敗する場合は、RDP本体の許可、受信規則、ネットワークプロファイル、サービスの順で確認します。

保守内容によって追加で必要になる通信

PingとRDPが使えれば、基本的な疎通確認と画面操作はできます。ただし、遠隔から何を行うかによっては、別の通信も必要です。

行いたいこと追加で必要になるもの
PowerShellによる遠隔操作WinRM(TCP 5985/5986)
\\PC名\C$からログを回収SMB(TCP 445)と管理共有
イベントビューアーを遠隔確認「リモート イベント ログ管理」規則
サービスを遠隔操作「リモート サービス管理」規則
WMIや「コンピューターの管理」を使用WMI・RPC関連規則

これらを最初からすべて許可する必要はありません。特にSMB、WMI、RPCは管理に便利な一方、許可範囲を広げると攻撃時の横展開にも使われやすくなります。必要な保守方法が決まってから、用途ごとにGPOを分けて追加する方が管理しやすくなります。

セキュリティ上の注意点

  • RDPのTCP 3389をインターネットへ直接公開しない
  • ファイアウォールのプロファイルはドメインだけにする
  • 可能なら接続元IPを管理端末・管理用ネットワークへ限定する
  • RDPを許可するユーザーを保守担当者だけに絞る
  • NLAを有効にし、推測されにくいパスワードを使う
  • 社外から接続する場合はVPNやRD Gatewayなどを利用する

切り分けでもファイアウォール全体は無効化せず、対象の受信規則・プロファイル・接続元の範囲を確認します。到達できない場合は、GPOの適用結果とログを確認して、必要な規則だけを調整します。

RDPとクイックアシストの使い分け

RDPは、管理者が対象PCへ入り、設定やログを確認する用途に向いています。一方、WindowsクライアントへRDP接続すると対象PCのローカル画面はロックされるため、利用者と同じ画面を見ながら案内したい場合には向きません。

利用者と画面を共有しながら対応するならクイックアシスト、管理者だけで調査・設定するならRDP、コマンドで複数台を管理するならWinRM……というように使い分けると、無理に一つの方法へ寄せずに済みます。

規則を作ったのにPingやRDPが通らない場合は、ファイアウォールだけを見続けず、gpresultでGPOの適用結果を確認する手順へ戻ると切り分けやすくなります。

TCP接続の TcpTestSucceeded : True は3389番ポートへの到達確認です。RDPの認証成功とは別なので、許可したユーザーで mstsc を開き、サインインできるところまで確認します。ローカルグループへの追加だけでなく、リモートデスクトップのログオン権利や拒否ポリシーも影響します。

保守用の許可を戻すとき

現地操作など別の接続手段を確保してから、今回変更したRDP設定とファイアウォール規則を元へ戻します。GPPでRemote Desktop Usersへ追加したメンバーは、GPOのリンク解除だけでは残る場合があります。今回追加したユーザーまたはグループだけを削除し、既存メンバーやローカルグループ本体は削除しません。戻した後は、接続元から到達・ログオンできる範囲が意図した状態か確認します。