• 戻る（仮想化アーキテクチャ、Windows OSの基礎的トピック）
  • リモートデスクトップサービス（旧ターミナルサービス）
  • RDP

以下、

• リモート デスクトップ = RD
• ターミナル サービス = TS

と略す。

「RD サービス」とは、「RD セッション ホスト」上に仮想的に構成された
「Windows デスクトップ」を、クライアント PC から利用して、
サーバ上のアプリケーションや管理ツールなどを実行するための
（周辺機能を含めた）機能群の総称である。

#	旧	新
1	ターミナルサービス	RDサービス
2	ターミナル サーバ	RDセッション ホスト
3	TSライセンス	RDライセンス
4	TSゲートウェイ	RDゲートウェイ
5	TSセッション ブローカ	RD接続ブローカ
6	TS Webアクセス	RD Webアクセス
7	TSマネージャ	RDサービス マネージャ
8	TS構成	RDセッション ホストの構成
9	TSゲートウェイ マネージャ	RDゲートウェイ マネージャ
10	TSライセンス マネージャ	RDライセンス サーバー
11	TS RemoteAppマネージャ	RemoteAppマネージャ

• 中核機能：RD セッション ホスト
• 拡張機能：他 OS からの RD サービスの利用、セキュリティ関連機能
• 周辺機能：RD ライセンス、RD ゲートウェイ、RD Web アクセス、RD 接続ブローカ

操作性の面でメリットの大きい、リッチクライアント アプリケーションは、
各端末への配布・管理が必要であったが、集中管理が可能になる。

クライアント PC へのアプリケーション配布が不要であるため、
クライアント PC の管理と、環境の異なるクライアント PC 毎の
互換性検証が不要になる。

• 在宅時など、遠隔地からも「RD 接続」で業務アプリケーションを使用可能であるが、
  従来、これにはセキュアなネットワーク インフラを構築する必要があった。
• しかし、「RD ゲートウェイ」によって、
  ネットワーク インフラを構築せずに「RD 接続」することが可能になった。
• 「RD ゲートウェイ」を使用すれば、2 層 C/S 方式のリッチクライアント
  アプリケーションを、そのまま遠隔地に配信できるため、
  高い操作性・生産性の両立が可能である。

シンクライアントを使用して「RD セッション ホスト」に接続することにより、
ローカルにデータを保存できなくなるため、
ローカル HDD やノート PC の破損・盗難による
データ損失・漏洩の防止に役立つ。

• 「RD サービス」による 2 層 C/S アプリケーションの 3 層化は、
  「ネットワーク トラフィック」の観点から、性能改善の可能性がある。
• 例えば、クライアント側のネットワーク品質が低い場合、
  システムを 2 層構成（クライアント → DB）から
  3 層構成（クライアント → AP ⇒ DB）へ変更することによって、
  DB との通信処理のオーバヘッドが軽減できる。

補足（この評価は現在も有効）: 「レガシーな技術」に見えるが、
上記 5 つの価値は今も失われていない。
特に「データを端末に置かない」「配布不要」という点から、
現在も次の用途で広く使われている。

用途	例
VDI / DaaS	Azure Virtual Desktop、Windows 365
業務システムの遠隔配信	2層 C/S の基幹システムをそのまま在宅利用
セキュア端末	委託先・海外拠点からのアクセス

クラウド側では Azure Virtual Desktop (AVD) として提供されており、
本ページで解説されている RD セッション ホスト / RD 接続ブローカ /
RD ゲートウェイの概念はそのまま使われている。
歴史資料ではなく、現役の基礎知識である。

• 「RD サービス」の中核機能を提供する「RD セッション ホスト」は、
  クライアント PC からリモート デスクトップ接続（以下、「RD 接続」）により、
  マウスやキーボードなどの入力データを受け取り、画面情報を返す。

• これにより、クライアント PC から、「RD セッション ホスト」上で実行される
  Windows デスクトップ、アプリケーションの表示・操作が可能になる。

• この機能は、管理用の「RD 接続」でも利用されているが、
  「RD セッション ホスト」は、管理用ではなく、
  マルチ ユーザ GUI OS の機能により、複数のユーザへ、
  複数の RD セッションを提供することを目的としている。

インストール中に以下を設定する。

• ネットワーク レベル認証
• ライセンス モード（構成するまで 120 日の猶予期間がある）
• マルチ セッション環境下で使用する
  アプリケーションのインストール

• 下記のような、クライアント PC のローカル リソースを、
  「RD セッション ホスト」側にリダイレクトする機能

  • クリップボード / ドライブ / オーディオ / プリンタ
  • LPT ポート / COM ポート
  • サポートされているプラグ アンド プレイ デバイス

• サーバ側にプリンタ ドライバが不要であり、以下の問題を解決できる。

  • PCL、PS などの「ページ記述言語」との非互換性の問題
  • サーバでサポートされないプリンタの問題
  • クライアント PC のプリンタ（＋ 印刷設定）を利用できない問題

移行メモ（正誤）: 元ページの「PLC」は、
プリンタの文脈では PCL（Printer Command Language、HP のページ記述言語）の
誤記と解される。
PLC は Programmable Logic Controller（制御機器）を指す別語である。

補足（リダイレクトはセキュリティ設定の要所）: 「データを端末に
置かせない」ことが RDS 採用の目的である場合、
ドライブ リダイレクトとクリップボードは無効化する必要がある。
既定では有効なため、グループ ポリシーで明示的に禁止する。

リダイレクト	情報漏洩リスク
ドライブ	高（サーバ上のファイルを端末に持ち出せる）
クリップボード	高（コピー＆ペーストで抜ける）
プリンタ	中（印刷して持ち出せる）
オーディオ / デバイス	低

• グループ・ポリシーで「RD サービス」の管理・設定が可能
• RD 移動ユーザー プロファイル
  ログオフ時にサーバの共有フォルダにセーブされ、ログオン時にロードされる。
• RD サービスのホーム ディレクトリの設定
• フォルダ リダイレクトの設定
  （RD）移動ユーザ プロファイルと併用し、ログオン・ログオフの NW 負荷を軽減する。

デスクトップ全体ではなく、個別のアプリケーションのウィンドウだけを
クライアントに表示する機能。

古い Windows、macOS でも、対応する RD クライアントを
追加インストールすることで、「RD サービス」を利用できる。

補足（現在のクライアント）: 現在は Microsoft 公式の
リモート デスクトップ クライアントが
Windows / macOS / iOS / Android / Web ブラウザ向けに提供されている。
実質的にどの端末からでも利用できる。

［RDP-Tcp プロパティ］ダイアログから行う。

#	セキュリティ層	説明
1	SSL (TLS 1.0)	サーバ認証、送信データの暗号化に SSL が使用される。
2	ネゴシエート（既定）	クライアントがサポートしている最も安全な層が使用される。 サポートできる環境の場合は、SSL が使用される。 できない場合は、RDP セキュリティ層が使用される。
3	RDP セキュリティ層	通信に、ネイティブな RDP 暗号化が使用される。 この場合「ネットワーク レベル認証」は使用できない。

#	暗号化レベル	説明
1	FIPS 準拠	FIPS 140-1 で確認された暗号化方式を使用。
2	高	128bit の暗号化。
3	クライアント互換（既定）	クライアントがサポートしている最高のキーの強度で暗号化。
4	低	56bit。サーバ → クライアント方向は暗号化されない。

補足（最新化：現在の設定）: この表は歴史的な選択肢である。
現在は次のとおり考える。

• セキュリティ層は SSL（TLS）一択。
  RDP セキュリティ層はサーバー認証が無く、
  中間者攻撃を防げないため使ってはならない。
• TLS 1.0 / 1.1 は既に非推奨。TLS 1.2 以上を使う。
• 「暗号化レベル：低」は論外（片方向が平文）。
• ネットワーク レベル認証 (NLA) は必須（既定で有効）。

グループ ポリシーの
「リモート (RDP) 接続に特定のセキュリティ レイヤーの使用を required する」で
SSL に固定するのが定石である。

CredSSP セキュリティ サポート プロバイダにより提供される、新しい認証方法

• 「RD 接続」でログオン画面を表示させずにユーザ認証を完了させることができる。
• これには、正しいサーバ証明書と、FQDN 名を使用し、
  NLA に対応した RD クライアントが必要。

補足（NLA が重要な理由）: NLA は利便性のための機能ではなく、
セキュリティ機能である。

	NLA なし	NLA あり
認証のタイミング	セッションを作ってからログオン画面	接続前に認証
未認証の攻撃者	セッションを消費できる（DoS）	接続を確立できない
既知の脆弱性	BlueKeep (CVE-2019-0708) の影響を受ける	緩和される

BlueKeep のような認証前リモートコード実行の脆弱性に対して、
NLA は有効な緩和策になる。無効化してはならない。

• SSO を構成すれば、各クライアント端末に AD のユーザ アカウントで
  ログオンした後、再ログオンせずに「RD セッション ホスト」に
  アクセスできるようになる。
• 要件
  • クライアントと「RD セッション ホスト」が、同じドメインに参加している。
  • ログオンに使用する AD のユーザ アカウントに、両方にログオンするための
    適切な権限が付与されている。
  • 「セキュリティ層」を「ネゴシエート」または「SSL」に設定する。
  • 「ログオン設定」で、都度パスワードの入力を求めるように指定しない。
  • グループ・ポリシーで認証の委任を設定する。

Remote Desktop Users（RDU グループ）というビルトイン グループがあり、
以下のアクセス許可を持つ。

#	アクセス許可セット	アクセス許可
1	フル コントロール	情報の照会、ログオン、接続、情報の設定、リモート制御、ログオフ、メッセージ、切断、仮想チャネル
2	ユーザ アクセス	情報の照会、ログオン、接続
3	ゲスト アクセス	ログオン

• RD ライセンス（リモート デスクトップ ライセンス）
• RD ゲートウェイ（リモート デスクトップ ゲートウェイ）
• RD Web アクセス（リモート デスクトップ Webアクセス）
• RD 接続ブローカ（リモート デスクトップ接続ブローカー）

「RD セッション ホスト」へは、RDPを使用して、「RD 接続」する。

一般的に、「RD 接続」には以下の 2 つの接続モードがある。

モード	用途	制限
管理用 RD モード	管理用途	実行可能な同時リモート接続は 2 つまで（RDS-CAL 不要）
RD セッション ホスト モード	マルチ ユーザへ RD セッションを提供	RDS-CAL が必要

• 管理用 RD モードには、利用可能なセッション数がある。
• 「ネットワーク レベル認証」が必要な「RD セッション ホスト」に接続する場合、
  FQDN 名で指定しないで、IP アドレスや NetBIOS 名で指定すると、
  認証エラーになることがある。
• これは、FQDN 名とサーバ証明書のサブジェクトが比較されているためである。

補足（ライセンスの落とし穴）: 「管理用は 2 セッションまで無料」という点は
よく知られているが、
業務利用で 3 人目が接続した時点で RDS-CAL が必要になる。
「とりあえずリモートデスクトップで使わせている」という運用が
ライセンス違反になっている例は少なくない。
RDS-CAL にはユーザー CAL と デバイス CAL があり、
「1 人が複数端末から」ならユーザー CAL、
「1 端末を複数人が交代で」ならデバイス CAL が有利になる。

• もともとシングル ユーザ環境のクライアント PC から出発した Windows では、
  UNIX の「telnet を使用してリモートからログインし、システムを利用する」
  というような使い方は、一般的ではなかった。

  • Windows 9x、Me までマルチ ユーザ機能を持っていなかった。
  • また、Windows NT も、マルチ ユーザ GUI OS としては作られていなかった。

• このような中、Windows NT の GUI をマルチ セッション環境下で
  利用できるようにした「Windows NT Server 4.0, Terminal Server Edition」という
  単体製品が登場し、Windows 2000 Server 以降のバージョンアップで機能拡張されて、
  現在の「リモートデスクトップサービス」に至っている。

• Windows ServerでRDS（Remote Desktop Service）を構築する手順 | Minory
  https://minory.org/windows-rds.html

• リモート デスクトップ サービス環境で使用するポートについて
  https://jpwinsup.github.io/blog/2022/03/24/RemoteDesktopService/RDS/ports-used-in-remote-desktop-service-environment/

• リモート デスクトップ サービス
  https://learn.microsoft.com/windows-server/remote/remote-desktop-services/welcome-to-rds

• Azure Virtual Desktop のドキュメント
  https://learn.microsoft.com/azure/virtual-desktop/

---

Tags: 移行, Windows, 仮想化, セキュリティ, クラウド