Skip to content

MS_RDGateway

nishi_74322014 edited this page Aug 19, 2026 · 1 revision

リモート デスクトップ ゲートウェイ

概要

インターネット経由で、イントラ内部の「RDセッション ホスト」に「RD 接続」しなければならない場合、
VPN などのセキュアなネットワーク インフラを構築する必要があったが、「RD ゲートウェイ」によって、
VPN などのセキュアなネットワーク インフラを構築せずに「RD 接続」可能になった。

  • RD クライアント 6.0 以降が必要。
  • RDP over HTTPS を使用して、VPN を構築せず、インターネットからアクセス可能になった。

補足(「RDP over HTTPS」が解決した問題): この一行が
RD ゲートウェイの存在理由のすべてである。

【RD ゲートウェイ無し】
  インターネット ──[3389/TCP]──✕ ファイアウォール
    ↑ 3389 を開けるのは危険。VPN を張るしかない

【RD ゲートウェイ】
  インターネット ──[443/TCP HTTPS]──→ RD ゲートウェイ
                                         ↓ 3389(イントラ内)
                                      RD セッション ホスト

得られる利点は次のとおり。

利点 内容
443 番だけで済む ほとんどの環境で既に開いている。外出先の制限が厳しい NW でも通る
VPN クライアントが不要 端末に何も入れなくてよい
暗号化される TLS
接続先を限定できる RD RAP で「この人はこのサーバだけ」(後述)

特に 4 つ目が VPN との決定的な違いである。
VPN は繋がった時点で「社内ネットワークの住人」になるため、
端末が侵害されていれば内部に自由に到達できてしまう。
RD ゲートウェイはRDP に限定された経路
であり、
かつ接続先サーバまで制限できる。

3389 番をインターネットに直接公開してはならないという点は
現在も変わっておらず、Azure では
Azure Bastionが同種の役割を担う。

詳細

+ NPS

  • また、「RD ゲートウェイ」では、
    RD CAP・RD RAP を組み合わせ、制限するセキュリティ機能を搭載している。
  • これらの機能はネットワーク ポリシー サーバ(以下、NPS と略す)から提供される。

RDゲートウェイ

RD CAP

RD 接続承認ポリシー(RD CAP : RD Connection Authorization Policy)

RD RAP

RD リソース認証ポリシー(RD RAP : RD Resource Authorization Policy)

  • 接続ユーザ
  • 接続先サーバ
  • 接続先ポート

補足(CAP と RAP は「二段階の関門」): 名前が似ていて混同しやすいが、
判定するタイミングと対象が違う

クライアント
   ↓ ① そもそもゲートウェイを通ってよい人か?
【RD CAP】… 誰が(ユーザ/PC)、どうやって(認証方式)通れるか
   ↓ ② その人はどこへ行ってよいか?
【RD RAP】… どのサーバの、どのポートへ繋いでよいか
   ↓
RD セッション ホスト
RD CAP RD RAP
問い 「通してよいか」 「どこへ行かせるか」
主語 接続元(ユーザ、クライアント PC) 接続先(サーバ、ポート)
「社員グループのみ、スマート カード必須」 「経理部は経理サーバのみ」

両方を満たさないと接続できない(AND 条件)。
「認証は通るのに繋がらない」という場合は
RAP 側で接続先が許可されていないことが多い。

実装が NPS(ネットワーク ポリシー サーバ、旧 IAS)である点も要点で、
RADIUS サーバとして中央集約できる
複数の RD ゲートウェイがある場合、
ポリシーを 1 か所の NPS に集約して管理できる。

管理

できること。

RD接続」一覧から以下のオペレーションが可能である。

  • 接続の監視
  • この接続を切断
  • このユーザとの接続を切断

管理方法

[リモート デスクトップ ゲートウェイ マネージャー]管理ツールを起動し、
左部分ウィンドウから対象のサーバを展開し、その直下の[監視]から接続を管理する。

インストールと設定

インストール

  • 以下から、「RD ゲートウェイ」をインストールする。
    • [サーバ マネージャ]管理ツールの[役割]→[役割の追加]→「リモート デスクトップ サービス」
    • または、[役割]→「リモート デスクトップ サービス」→[役割サービスの追加]
  • なお、「RD ゲートウェイ」のサイトを立ち上げるために、IIS、NPS をインストールしておく必要があるが、
    これは「RD ゲートウェイ」のインストールの際に、合わせて自動的にインストールされる。

補足: RD ゲートウェイが IIS を必要とするのは、
RDP over HTTPS の HTTPS 部分を IIS が受けるためである
/rpc 仮想ディレクトリ)。
つまり RD ゲートウェイは
IIS の上に載った RPC over HTTP のプロキシという構造になっている。

このため、IIS の設定変更が RD ゲートウェイに影響することがある
(URL 書き換え、要求フィルタリング、SSL 設定など)。
同一サーバで他の Web サイトを運用する場合は注意が要る
ホストヘッダー)。

設定

SSL用のサーバ証明書の設定

(記載なし)

承認ポリシーの設定

  • クライアントのユーザ、コンピュータ グループの設定を作成
    • ワーク グループ環境
      • ローカル グループ
      • グループにメンバを追加
    • AD 環境
      • グループのスコープ:グローバル
      • グループの種類:セキュリティ
      • グループにメンバを追加
  • 接続承認ポリシー(RD CAP)の設定
    [リモート デスクトップ ゲートウェイ マネージャ]管理ツールを起動し、
    左部分ウィンドウから対象のサーバの[ポリシー]→[接続承認ポリシー]を右クリック、
    [新規ポリシーの作成]→[カスタム]を選択することで、表示される
    [新規 RD CAP]ダイアログから設定を行う。設定手順は以下のとおり。
    • [全般]タブで[ポリシー名]テキスト ボックスにポリシー名を入力する。
    • 次いで、[このポリシーを有効にする]チェック ボックスをオンに設定する。
    • [要件]タブで、Windows 認証方法と、ユーザ グループ メンバシップを設定する。
      • クライアント グループ メンバシップ(必須)
      • クライアント コンピュータ グループ メンバシップ(オプション)
        HTTPS 経由での Web 接続の場合、クライアント環境がサーバ環境と同じフォレストの
        AD 環境に含まれないことが多いので、この設定はオプションの扱いとなっている。
    • [デバイス リダイレクト]タブにて、リソースのリダイレクトを設定する。
  • リソース承認ポリシー(RD RAP)の設定
    [リモート デスクトップ ゲートウェイ マネージャ]管理ツールを起動し、
    左部分ウィンドウから対象のサーバの[ポリシー]→[リソース承認ポリシー]を右クリック、
    [新規ポリシーの作成]→[カスタム]を選択することで、表示される
    [新規 RD RAP]ダイアログから設定を行う。設定手順は以下のとおり。
    • [全般]タブで[ポリシー名]テキスト ボックスにポリシー名を入力する。
    • 次いで、[このポリシーを有効にする]チェック ボックスをオンに設定する。
    • [ユーザ グループ]タブで「RDセッション ホスト」へのアクセスを許可するユーザ グループを指定する。
    • [コンピュータ グループ]タブで「RD セッション ホスト」を纏めたコンピュータ グループを指定する。
    • [許可されたポート]タブで接続先の「RD セッション ホスト」のポート番号を指定する。

補足(「クライアント コンピュータ グループ メンバシップ」がオプションである理由): 本文の
説明は的確で、インターネット経由の接続では
クライアント PC がドメインに参加していない
ことが多いためである。

【社内からの接続】 ドメイン参加 PC → 「どの PC か」も検証できる
【外出先からの接続】 私物 PC / 自宅 PC → PC の識別ができない

現在は、この「PC を識別できない」問題に対して
より進んだ手段がある。

手段 内容
多要素認証(MFA) NPS 拡張で Microsoft Entra MFA と連携できる
デバイス証明書 クライアント証明書で端末を識別
条件付きアクセス クラウド側で場所・デバイス準拠状態を判定

パスワードのみでインターネットに RD ゲートウェイを公開するのは
現在では推奨されない

NPS 拡張による MFA の追加は比較的容易であり、
導入する価値が高い。

クライアント接続の設定と確認

  • [RD ゲートウェイ サーバー設定]ダイアログ
    • [サーバ名]テキスト ボックスに入力する「サーバ名」は、
      「証明書のサブジェクト名」と一致させるため、正規の FQDN、NetBIOS 名などで指定する必要がある。
    • [ローカル アドレスには RD ゲートウェイ サーバーを使用しない]
      評価環境などで、同一イントラネット内の「ターミナル サーバ」へアクセスする場合、
      ローカル アドレス(プライベート アドレス)が使用されるためチェックを外す。

クライアント接続のトラブルシュート

「RD ゲートウェイ」のサーバ証明書が

  • 自己署名証明書の場合で、
  • かつ AD の外部から、DNS だけ利用して

「RD ゲートウェイ」経由で「RD 接続」した場合は、サーバ証明書の発行元が信頼されず、
以下のメッセージ ボックス表示とともに、「RD 接続」は切断されるため、この場合は、

  • サーバ証明書のルート証明書をエクスポートし、
  • クライアントの「信頼されたルート証明機関」にインストールする

必要がある。

補足(証明書まわりで詰まる 3 つのパターン): RD ゲートウェイの
接続トラブルは大半が証明書に起因する。整理しておく。

症状 原因 対処
「証明機関が信頼されていない」 自己署名証明書(本文の事例) ルート証明書をクライアントに導入、または公的 CA の証明書を使う
「証明書名が一致しない」 接続に使う名前とサブジェクト名(CN / SAN)が違う 接続に使う FQDN で証明書を取り直す
「証明書の有効期限が切れている」 更新漏れ 更新してIIS と RD ゲートウェイの両方に再バインド

2 つ目が特に多い。本文が
「『証明書のサブジェクト名』と一致させるため、正規の FQDN」と
注意しているとおりで、
社内向けの NetBIOS 名と、外部向けの FQDN が違う場合、
どちらか一方でしか繋がらなくなる。
SAN(サブジェクト代替名)に両方を入れるのが正しい対応である。

なお、現在は Let's Encrypt 等で公的な証明書を無償で取得できるため、
インターネットに公開するなら自己署名を使う理由は無い
証明書IISのSSL設定)。

RemoteAppで利用する

[RD RemoteApp マネージャ]管理ツールの右部分ウィンドウの[RD ゲートウェイ設定]ボタンを押下して
表示される[RemoteApp の展開設定]ダイアログの[TS ゲートウェイ]タブから設定が可能。

この設定は、

  • 以下のファイルを作成する際の設定に反映される。
    • RDP ファイル(*.rdp)
    • MSI ファイル(*.msi)
  • また、「RD Webアクセス」にも適用される。

ログ設定・表示

  • 設定
    1. [TS ゲートウェイ マネージャ]管理ツールを起動し、
    2. 左部分ウィンドウから対象のサーバを選択、これを右クリックして
    3. 表示されるプロパティ ダイアログの[監査]タブを選択し、
    4. ここでログに記録するイベントのチェック ボックスをオンにする。
  • 表示
    1. [イベント ビューア]管理ツールを起動し、
    2. 左部分ウィンドウから対象のサーバを選択、
    3. [アプリケーションとサービス ログ]→[Microsoft]→[Windows]→[TerminalService-gateway]と展開する。

補足(このログは「誰がいつどこへ繋いだか」の記録): RD ゲートウェイの
監査ログは、インターネットからの接続の証跡として重要である。

記録される主なイベントは次のとおり。

内容 用途
接続の成功・失敗(ユーザ名、クライアント IP) 不正アクセスの検知
接続先のリソース名 どのサーバに繋いだか
切断(理由つき) セッションの追跡
転送バイト数 大量のデータ持ち出しの検知

接続失敗が短時間に大量に記録される場合、
総当たり攻撃を受けている可能性が高い。
ログの収集と併せ、
SIEM に転送して監視するのが望ましい。

ファーム

負荷分散クラスタ構成(以降、「RD ゲートウェイ ファーム」と呼ぶ)を構築する事も可能。

GPを使用した設定

クライアント側の接続設定は、AD のグループ・ポリシー設定でも可能。
以下の設定項目をダブルクリックして設定する。

  • [ユーザーの構成\ポリシー\管理用テンプレート\Windows コンポーネント\ターミナル サービス\TS ゲートウェイ]
    • [TS ゲートウェイ経由で接続を有効にする]
    • [TS ゲートウェイ サーバアドレスを設定する]

補足(最新化:現在の位置付け): RD ゲートウェイは
Windows Server の役割サービスとして現在も提供されているが、
用途によっては後継の選択肢がある。

状況 現在の選択
オンプレの RDS を外部公開する RD ゲートウェイ(現役)
Azure 上の VM に管理接続する Azure Bastion(パブリック IP 不要)
デスクトップをクラウドで提供する Azure Virtual Desktop(AVD)、Windows 365

AVD ではリバース接続という方式が使われ、
セッション ホスト側から Azure に対して接続を張るため、
受信ポートを一切開けない(RD ゲートウェイすら不要になる)。
「443 番だけで済む」から
**「受信ポートをゼロにする」**へ、という進化である。

なお、本文中の用語が「TS ゲートウェイ」と「RD ゲートウェイ」で
混在しているのは、Windows Server 2008 R2 で
ターミナル サービス(TS)→ リモート デスクトップ サービス(RDS)に
改称された
ためである。同じものを指している。


Tags: 移行, Windows, 仮想化

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally