PCの不具合について連絡を受けたとき、最初に確認したいのは「そのPCまで通信できるか」と「遠隔から状態を確認できるか」です。
ところが、Pingに応答せず、リモートデスクトップ(RDP)にも接続できない状態では、現地の方に画面を見てもらうか、管理者が直接PCの前まで行かなければならないことがあります。障害が起きてからRDPを有効にしようとしても、そのPCへ入る手段がない……ということもあります。
そこでこの記事では、Active Directory環境のクライアントPCへ、Ping応答とRDP接続をGPO(グループポリシー)でまとめて許可する方法を解説します。
ただし、遠隔操作できればよいからといって、すべてのネットワークから接続できる状態にするのは避けたいところです。今回は、ドメインネットワーク内の管理端末から保守することを前提に、許可範囲をできるだけ絞って設定します。
忙しい人のための結論
| 設定項目 | 今回の設定 |
|---|---|
| GPO | 遠隔保守用のGPOを新しく作成し、まず検証用OUへリンク |
| Ping | ICMPv4のエコー要求(受信)を許可 |
| 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を作成する
- ドメインコントローラーで「グループ ポリシーの管理」を開く
- 「グループ ポリシー オブジェクト」を右クリックする
- 「新規」を選択する
- GPO名に「クライアント遠隔保守(Ping・RDP許可)」と入力する
- 作成したGPOを、まず検証用PCが入っているOUへリンクする

手順2:GPOでPing応答を許可する
作成したGPOを右クリックして「編集」を開き、次の場所まで移動します。
コンピューターの構成
└ ポリシー
└ Windows の設定
└ セキュリティの設定
└ セキュリティが強化された Windows Defender ファイアウォール
└ 受信の規則

「受信の規則」を右クリックして「新しい規則」を選び、次のように設定します。
| 画面 | 設定内容 |
|---|---|
| 規則の種類 | カスタム |
| プログラム | すべてのプログラム |
| プロトコルの種類 | ICMPv4 |
| ICMP設定 | 「カスタマイズ」から「特定のICMPの種類」→「エコー要求」 |
| スコープ | 可能なら接続元を管理用PC・管理用サブネットに限定 |
| 操作 | 接続を許可する |
| プロファイル | ドメインだけにチェック |
| 名前 | 遠隔保守用 Ping許可(ICMPv4) |
IPv6でもPingを使う環境では、同じ要領でICMPv6の規則も作成します。まずIPv4だけを確認したい場合は、クライアント側でping -4 PC名と実行すると切り分けやすくなります。
手順3:GPOでRDP接続を有効にする
次に、対象PCがリモートデスクトップ接続を受け付けるようにします。GPOエディターで次の場所を開きます。
コンピューターの構成
└ ポリシー
└ 管理用テンプレート
└ Windows コンポーネント
└ リモート デスクトップ サービス
└ リモート デスクトップ セッション ホスト
└ 接続
「リモート デスクトップ サービスを使ってリモート接続することをユーザーに許可する」を開き、「有効」にします。

この設定はRDP本体の接続許可です。これだけではWindowsファイアウォールの受信規則が開いていない場合があるため、次の手順も続けて設定します。
ネットワークレベル認証(NLA)も有効にする
同じ「リモート デスクトップ セッション ホスト」の下にある「セキュリティ」を開き、「リモート接続にネットワーク レベル認証を使用したユーザー認証を必要とする」を有効にします。

NLAを有効にすると、RDPセッションを作成する前にユーザー認証が行われます。古いOSや特殊なRDPクライアントとの互換性確認が必要な場合を除き、有効のまま運用するのがおすすめです。
手順4:RDPのファイアウォール規則を有効にする
Ping規則を作成した「受信の規則」で、もう一度「新しい規則」を開きます。
- 規則の種類で「事前定義」を選択する
- 一覧から「リモート デスクトップ」を選択する
- リモートデスクトップのユーザーモード(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へ追加すると管理しやすくなります。
コンピューターの構成
└ 基本設定
└ コントロール パネルの設定
└ ローカル ユーザーとグループ

「新規」→「ローカル グループ」を選び、アクションを「更新」にします。グループ名は右側の検索ボタンからAD内を検索するのではなく、プルダウンから「Remote Desktop Users(ビルトイン)」を選択します。
続いて「メンバー」の「追加」をクリックし、ドメイングループの「wanwano\G_RDP-Support」を指定します。これで、保守担当者用のドメイングループが、各クライアントPCのローカルRemote Desktop Usersへ追加されます。

ここでアクションを「置換」にすると、既存メンバーまで入れ替わる可能性があります。既存環境へ追加する場合は「更新」を使う方が扱いやすいです。また、Domain Usersなどの大きなグループをそのまま追加せず、必要な担当者だけに絞ります。
クライアントPCへ適用して確認する
設定後は、検証用クライアントPCを再起動するか、管理者権限のPowerShellまたはコマンドプロンプトで次を実行します。
gpupdate /force
GPOが適用されたかは、次のコマンドで確認できます。
gpresult /r /scope:computer
「適用されたグループ ポリシー オブジェクト」に、作成したGPO名が表示されていれば、コンピューターポリシーとして認識されています。

管理端末から接続テストする
ping PC名
Test-NetConnection PC名 -Port 3389
mstsc /v:PC名
ping:ICMPの応答を確認Test-NetConnection:TCP 3389へ接続できるか確認mstsc:実際にリモートデスクトップ接続を開始

Test-NetConnectionのTcpTestSucceededがTrueなら、少なくとも管理端末から対象PCのTCP 3389までは到達しています。それでもログオンできない場合は、ユーザー権限やNLA、入力した資格情報を確認します。
接続できないときの確認順
設定したのに接続できない場合は、何度もGPOを作り直すより、次の順番で確認すると原因を絞りやすくなります。
| 順番 | 確認内容 | 確認方法 |
|---|---|---|
| 1 | 対象PCの電源・ネットワーク | 利用者への確認、DHCPやスイッチの情報 |
| 2 | DNSの名前解決 | Resolve-DnsName PC名 |
| 3 | GPOの適用 | gpresult /r /scope:computer |
| 4 | ドメインプロファイル | Get-NetConnectionProfile |
| 5 | RDPサービス | Get-Service TermService |
| 6 | TCP 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のリンク解除だけでは残る場合があります。今回追加したユーザーまたはグループだけを削除し、既存メンバーやローカルグループ本体は削除しません。戻した後は、接続元から到達・ログオンできる範囲が意図した状態か確認します。

