[WHfB / FIDO2] RDP で SSO を実現！ Remote Credential Guard とは？

# はじめに
"パスワードレス なアカウント" で ドメインに参加したホストへ RDP 接続を行う際に、SSO を実現することができる Remote Credential Guard を試してみました。
単なる接続だけでなく、いくつかのシーンと組み合わせて利用できるのかどうかも、検証しており、推奨する設定例や手順まで紹介しています。
※パスワードレスなアカウントとは、Windows Hello for Business や FIDO2 を使ってログオンしたユーザーのことです。

**検証済みのシナリオ**
- パスワードレスで ドメインログオン (FIDO2 or WHfB) した物理マシン からの SSO
- Windows Server 2016 に対しての パスワードレス (FIDO2 or WHfB) ログオン SSO
- パスワードレスログオンした AVD からのダブルホップ SSO
- Microsoft Entra Join したマシン からの SSO（要：Microsoft Entra Kerberos）
- Remote Credential Guard でログオンしたマシンから、別のマシンへ ダブルホップ SSO

上記のシナリオが全部実現できます。

**公開情報：Remote Credential Guard**
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/remote-credential-guard?wt.mc_id=mvp_407731

:::note info
**ポイント**
RDP で SSO を実現する方法として有名な **"既定の資格情報の委任を許可する"** がありますが、パスワードレス の場合は、これを実施しても SSO できずに、パスワードの入力を求められてしまいます。

以下の記事も参考にしてみてください。
**RDP & SSO ができる "資格情報の委任" について深堀**
https://qiita.com/carol0226/private/500f5c5a7ed51c699a55

パスワードレスなユーザーの場合は、**Remote Credential Guard** を使うことで、RDP で SSO を利用することができるようになります。
:::

**SSO ではなく、別のユーザーに切り替えたい場合は？**
SSO ではなく、2 枚目の FIDO2 キーを使って 別のユーザーへ切り替えてログオンしたい場合は、以下の記事の方法を活用してください。

https://qiita.com/carol0226/items/6bfbc94a0625d5755329

:::note info
**宣伝**
私が執筆した FIDO2 に関する記事は、他にも 以下の ストックリスト で公開していますので、こちらも 参考にしてみてください。 

**＠carol0226 による FIDO2 の公開ストックリスト**
https://qiita.com/carol0226/stocks/3670cb8678daed11b191
:::

# 1. Remote Credential Guard の動作イメージ
まず、Remote Credential Guard があると、どのような動作になるのかを理解しましょう。

Remote Credential Guard は、リモートクライアント側（接続元）と リモートホスト側（接続先）の設定の組み合わせによって機能します。

|　　　リモートホスト ▶<br>▼ リモートクライアント |(a)<br>Remote Credential Guard 無効|(b)<br>Remote Credential Guard  有効|
|:-:|:-:|:-:|
|**(1)<br>Remote Credential Guard 無効**|（通常の RDP 動作）<br>ユーザー切り替え可<br>パスワード入力|（通常の RDP 動作）<br>ユーザー切り替え可<br>パスワード入力|
|**(2)<br>Remote Credential Guard 有効**|エラー|SSO で 接続|

上記の設定を組み合わせた際の動作イメージは、以下の通りです。

## 1-1. 動作イメージ：(1)+(a) & (1)+(b) Remote Credential Guard を使わない場合
通常のリモートデスクトップの動作と一緒です。
<img width="350" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/d9d07dfc-b9cd-4c11-87b4-dc76d7128190.png">

上記の画面で、**接続** を押すと、以下のとおり、パスワードの入力を求められます。
正しいパスワードを入力すれば、RDP の接続が可能です。
<img width="350" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/8ae08bb3-14de-4500-8cdf-4329c2018abf.png">
※この場合、パスワードレスのユーザーは、パスワードを知らないので 先へ進むことができません。

:::note info
リモートクライアント側 の Remote Credential Guard が **無効** の場合は、リモートホスト側 の Remote Credential Guard の 設定にかかわらず、正しいパスワードを入力すれば、RDP の接続が可能です。
:::

## 1-2. 動作イメージ：(2) クライアント側 の Remote Credential Guard 有効
ユーザー名の欄は、リモートクライアントにログオンした際のアカウントで固定化されていて、その他のユーザーに切り替えることはできません。
<img width="350" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/f79ce0ec-8be1-44bd-8f8b-075d088770b3.png">

### 1-2-1. 動作イメージ：(2)+(a) リモートホスト側 の Remote Credential Guard 無効
リモートクライアント側で Remote Credential Guard が **有効** であっても、リモートホスト側で Remote Credential Guard が **無効** の場合は、以下のエラーが発生して接続が拒否されます。
**エラーメッセージ**："アカウントの制限により、このユーザーはサインインできません。空のパスワードが許可されていない、サインイン時間が制限されている、またはポリシーによる制限が使用されたなどの理由が考えられます。"
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/cd07fab4-3d1f-4703-97eb-e3f4c5330d03.png)
※このあと、パスワードの入力画面へ遷移するので、パスワードの入力によって RDP 接続することは可能です。

### 1-2-2. 動作イメージ：(2)+(b) リモートホスト側 の Remote Credential Guard 有効
クライアント と ホスト が共に Remote Credential Guard が **有効** の場合に SSO が機能します。
その結果、パスワードレス のユーザーでも RDP を行うことができます。

認証が不要になるので、**接続** ボタンを押したあとに すぐに リモートホストの画面が表示されるので、お見せできる画面キャプチャがありません・・・

動作イメージは、以下の公開情報の動画を参照してください。ホントに 一瞬でつながります。

**公開情報：ユーザー エクスペリエンス**
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/remote-credential-guard?wt.mc_id=mvp_407731&tabs=gpo#user-experience

# 2. Remote Credential Guard の活用シーン
- RDP 接続の際に、資格情報 の入力を省略したい（OS の資格情報をつかって SSO させたい）
- ユーザーがパスワードを持っていない（FIDO2 や WHfB、スマートカード ログオンを使っている）

結果として、冒頭でも紹介していますが、以下のようなシーンに適用することができます。

**検証済みのシナリオ（再掲）**
- パスワードレスで ドメインログオン (FIDO2 or WHfB) した物理マシン からの SSO
- Windows Server 2016 に対しての パスワードレス (FIDO2 or WHfB) ログオン SSO
- AVD からのダブルホップ SSO
- Microsoft Entra Join したマシン からの SSO（要：Microsoft Entra Kerberos）
- Remote Credential Guard でログオンしたマシンから、別のマシンへ ダブルホップ SSO

:::note info
上記のようなニーズがある場合に、Remote Credential Guard は、強力なソリューションです。

しかしながら、後述する 制限事項 を理解しておく必要があります。
:::

# 制限事項
Remote Credential Guard に関する注意点があります。
代表的な２点の注意点を挙げておきます。

**RD ゲートウェイ、RD コネクションブローカー には対応していない**
冗長構成の RDS 環境を運用する場合、RD ゲートウェイや RD コネクションブローカーが使われることが多いですが、このような環境の場合は Remote Credential Guard は使えません。とても残念です。

**Kerberos 認証を必要とする点**
Kerberos 認証が必要であるため、RDP 接続時に ホスト名 を使う必要があります。
通常の RDP では、IP アドレスを使った場合、通常は NTLM 認証へ切り替わって接続が成功するのですが、Remote Credential Guard が有効な場合は、Kerberos が強制されるため、IP アドレス での接続ができません。

※Remote Credential Guard が有効なクライアントから、IP アドレスで接続しようとした場合
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/08e307fd-3451-4910-815a-600c522e7c42.png)

その他も含めた詳細は、以下の公開情報に記載されています。

**考慮事項**
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/remote-credential-guard?wt.mc_id=mvp_407731&tabs=gpo#considerations

# 3. 構成手順
## 3-1. リモートホスト側

### 3-1-1. リモートホスト側の おススメ構成
リモートホスト側の Remote Credential Guard は、有効 になっていても害は無いと思います。そのため、ドメイン内の 全ホスト に対して、GPO で有効化しましょう。

※Intune でも設定は可能なのですが、ドメイン環境が前提ですし、Windows Server にも適用させることを考えると、GPO 一択 なのかなと思います。

### 3-1-2. リモートホスト側の設定手順
以下の公開情報の内容をキャプチャで紹介します。

**公開情報：リモート ホストで nonexportable 資格情報の委任を有効にする**
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/remote-credential-guard?wt.mc_id=mvp_407731&tabs=gpo#enable-delegation-of-nonexportable-credentials-on-the-remote-hosts

1. ポリシーを ドメイン全体に適用するか、一部の コンピューター のみに適用するかを決めてください。
→　一部の コンピューター に適用する場合は、事前に OU を作成しておきます。
　<br>
1. グループポリシー管理エディターを開き、ドメイン名 または、事前に作成した OU を右クリックして、**このドメインに GPO を作成し、このコンテナーにリンクする** を選択します。
　<br>
1. GPO には、任意の名前を付けてください。
今回の手順用のキャプチャでは **RemoteCredentialGuard_Host** という名称をつけました。
　<br>
1. 作成された GPO を右クリックして開きます。
　<img width="250" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/4a6f53a9-397d-401d-8f32-27035e7e0adf.png">
　<br>
1. 左ペインから、**コンピューターの構成** - **ポリシー** - **管理用テンプレート** - **システム** - **資格情報の委任** を開きます。 
　<img width="250" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/dc28c571-8b8f-4a24-a692-fee9e17695f5.png">
　<br>
1. 続いて **リモートホストでエクスポート不可の資格情報の委任を許可する** を開きます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/451d7991-0f8c-47ee-8501-b45bf5106c8c.png)
　<br>
1. 値を **有効** に変更します。
　<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/6165f300-a5a1-43a2-98c2-a82b0fa4bab3.png">
　<br>
1. ポリシーを保存したら、ドメコン上で **Gpupdate /force** を実行したあと、リモートホスト側でも **Gpupdate /force** を実行してください。

:::note warn
**注意点：Windows Server 2016 の場合**
Windows Server 2016 には、GPO を適用しても、機能しませんでした。
試しに、ローカルのポリシーエディタを開いてみてみると、該当の項目（**Remote host allows delegation of nonexportable credentials**) がありませんでした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/131fd5aa-9146-480f-bfa5-87a372c5202f.png)

**解決策**
仕方がないので、以下の通り レジストリ で設定したところ、期待通りに動きました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/a49a3021-6068-41c6-a3d9-47a4f113c75c.png)
:::

## 3-2. リモートクライアント側

### 3-2-1. リモートクライアント側の おススメ構成
リモートクライアント側の Remote Credential Guard は、有効 になっている場合、必ず SSO の動作になり、ユーザーの切り替えができなくなります。
Remote Credential Guard の設定は、GPO で一律で有効化もできますが、コマンド起動時のパラメーターで制御することも可能です。

ユーザー切り替えを必要（または許容）とするシステムの場合は、GPO で設定してしまうと融通が利かなくなります。
そのため、コマンド起動時のパラメーターを使って、都度 リモートクライアントを起動するようにすることをおススメします。

ドメイン内の全ホストで、ユーザー切り替えを禁止して 一律で SSO をさせるような運用シーンでは、GPO で構成するのが良いと思います。

### 3-2-2. リモートクライアント側の設定手順

以下の公開情報の内容をキャプチャで紹介します。

**公開情報：クライアントでの資格情報の委任を構成する**
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/remote-credential-guard?wt.mc_id=mvp_407731&tabs=gpo#configure-delegation-of-credentials-on-the-clients

#### ① コマンドで都度 指定する場合
用途に応じて、以下のように 起動方法を切り替えてください。
- ユーザー切り替え＆パスワード認証を使う場合は、**mstsc.exe**
- SSO を行いたい場合は、**mstsc.exe /remoteguard**

指定した起動方法に応じて、冒頭の **動作イメージ** で紹介した通りの リモートデスクトップ画面 が表示されます。

#### ② GPO で一律 Remote Credential Guard を有効化する場合

:::note alert
**ドメイン全体に GPO を適用する場合の注意**
リモートホスト側が 無効 の状態で、リモートクライアント側の 有効 を GPO でドメイン全体に適用すると、RDP で接続できなくなってしまうので、注意してください。
:::

1. ポリシーを ドメイン全体に適用するか、一部の コンピューター のみに適用するかを決めてください。
→　一部の コンピューター に適用する場合は、事前に OU を作成しておきます。
　<br>
1. グループポリシー管理エディターを開き、ドメイン名 または、事前に作成した OU を右クリックして、**このドメインに GPO を作成し、このコンテナーにリンクする**　を選択します。
　<br>
1. GPO には、任意の名前を付けてください。
今回の手順用のキャプチャでは **RemoteCredentialGuard_Client** という名称をつけました。
　<br>
1. 作成された GPO を右クリックして開きます。
　<img width="250" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/4009a8bb-b560-42ef-932f-129b6fb499fa.png">
　<br>
1. 左ペインから、**コンピューターの構成** - **ポリシー** - **管理用テンプレート** - **システム** - **資格情報の委任** を開きます。
　<img width="250" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/5219421b-c8af-439d-a802-448d0249f197.png">
　<br>
1. 続いて **リモートサーバーへの資格情報の委任を制限する** を開きます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/872939ee-1a0f-4dd0-b30f-745bffeb180a.png)
　<br>
1. 値を **有効** にし **Remote Credential Guard が必要** を選択して OK を押します。
　<img width="500" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/54610383-b564-4258-bda6-934818eae2fc.png">
　<br>
1. ポリシーを保存したら、ドメコン上で **Gpupdate /force** を実行したあと、リモートホスト側でも **Gpupdate /force** を実行してください。

以上の設定で、Remote Credential Guard が動作するようになりました。

# 4. 動作確認
クライアント側の構成を GPO で設定した場合は、いつもの通りに、**リモートデスクトップ接続** のアプリ (mstsc.exe) を起動します。

クライアント側の構成を GPO で設定しなかった場合は、以下のコマンドを使って起動します。
**mstsc.exe /remoteguard**

以下のウィンドウが開けば OK です。

**Remote Credential Guard が有効な リモートデスクトップ接続**
- （赤下線）コンピューター名は、かならず **ホスト名** で指定してください。
- （緑枠）　グレーアウトされており、変更することはできません。
- （青下線）「Windows ログオン資格情報は、接続に使用されます」と書かれており、ログオンアカウントの認証がそのまま引き継がれるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/74dd5c65-07bc-4605-8123-f583ab5325ab.png)

動作イメージは、以下の公開情報の動画を参照してください。ホントに 一瞬でつながります。

**公開情報：ユーザー エクスペリエンス**
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/remote-credential-guard?wt.mc_id=mvp_407731&tabs=gpo#user-experience

うまく接続できない場合は、１章 の動作イメージ で紹介した設定の組み合わせ や エラー画面 を再確認してください。