資格情報の委任とは?
以下のサポートブログでも説明されていますが、リモートデスクトップ接続 を行う際に、シングルサインオン (SSO) をさせたい場合に、よく見かける設定です。
上記の記事より抜粋
"既定の資格情報の委任を許可する"
-> "有効" に設定する
-> "サーバーに追加" の "表示" から、接続先の FQDN を指定します。
例:TERMSRV/<コンピューター名>.contoso.com
TERMSRV/*
"NTLM のみのサーバー認証で既定の資格情報の委任を許可する"
-> "有効" に設定する
-> "サーバーに追加" の "表示" から、接続先の FQDN を指定します。
例:TERMSRV/<コンピューター名>.contoso.com
TERMSRV/*
上記の設定は、どのような意味を持っているのでしょうか?
今回は、この設定の意味を紐解いていくことで、応用した設定などを使いこなすための材料にしていただければと思います。
このポリシーの適用先
資格情報の委任は、CredSSP コンポーネントを使用しているアプリケーションに適用されます。
代表的なものは、リモートデスクトッププロトコル(RDP) ですが、他にも 以下のようなアプリケーションでも使われています。
- PowerShellのリモートセッション
- Hyper-V Manager
- SQL Server Management Studio(SSMS)
- Windows Management Instrumentation(WMI)
・・・など(3rd Party 製品とかでもあるかもしれない)
資格情報の委任 を行わない場合のデフォルト動作については、以下の記事で説明しています。
資格情報の委任に関する設定ポリシー の場所
[コンピューターの構成] (Computer Configuration)
+-[ポリシー] (Policies)
+-[管理用テンプレート] (Administrative Templates)
+-[システム] (System)
+-[資格情報の委任] (Credentials Delegation)
ポリシー設定の一覧
グループポリシー管理エディターに表示されている、資格情報の委任 に関する設定値の一覧(日本語・英語)を抜き出すと、以下のようになっています。似たような名前が混在していて、意味不明ですよね。
日本語 | English |
---|---|
NTLM のみのサーバー認証で既定の資格情報の委任を許可する | Allow delegating default credentials with NTLM-only server authentication |
NTLM のみのサーバー認証で新しい資格情報の委任を許可する | Allow delegating fresh credentials with NTLM-only server authentication |
NTLM のみのサーバー認証で保存された資格情報の委任を許可する | Allow delegating saved credentials with NTLM-only server authentication |
リモート サーバーへの資格情報の委任を制限する | Restrict delegation of credentials to remote servers |
リモート ホストでエクスポート不可の資格情報の委任を許可する | Remote host allows delegation of non-exportable credentials |
暗号化オラクルの修復 | Encryption Oracle Remediation |
既定の資格情報の委任を許可する | Allow delegating default credentials |
新しい資格情報の委任を許可する | Allow delegating fresh credentials |
保存された資格情報の委任を許可する | Allow delegating saved credentials |
既定の資格情報の委任を拒否する | Deny delegating default credentials |
新しい資格情報の委任を拒否する | Deny delegating fresh credentials |
保存された資格情報の委任を拒否する | Deny delegating saved credentials |
設定項目の分析
上記の一覧をグループ化して整理してみると、以下の5パターンに分類できます。
- NTLM のみのサーバー認証 で(既定・新しい・保存された)資格情報の委任を許可する
- (既定・新しい・保存された)資格情報の委任を 許可 する
- (既定・新しい・保存された)資格情報の委任を 拒否 する
- リモート 〇〇 の資格情報の委任を 〇〇 する
- 暗号化オラクルの修復
3つの対象 "既定"・"新しい"・"保存された" について
ここで、"既定"・"新しい"・"保存された" という3種類の表現が出てきますが、これは 何を指しているのでしょうか?
この意味を把握しておくと、理解をしやすくなります。
- 既定 = Windows へ最初にログオンする際に使用する資格情報
- 新しい = アプリケーションを実行するときに要求される資格情報
- 保存された = Windows 資格情報マネージャーを使用して保存または記録できる資格情報
5つのパターンごとの動作について
前章で分類した 5つのパターンについて、個別に 設定の意味を見ていきます。
1. NTLM のみのサーバー認証で(既定・新しい・保存された)資格情報の委任を許可する
このポリシー設定は、サーバー認証が NTLM を通じて行われた場合に適用されます。
- NTLM のみのサーバー認証で既定の資格情報の委任を許可する
- NTLM のみのサーバー認証で新しい資格情報の委任を許可する
- NTLM のみのサーバー認証で保存された資格情報の委任を許可する
# | 既定 | 新しい | 保存された |
---|---|---|---|
対象 | Windows へ最初にログオンする際に使用する資格情報 | アプリケーションを実行するときに要求される資格情報 | Windows 資格情報マネージャーを使用して保存または記録できる資格情報 |
有効 | [対象の資格情報] を どのサーバーに委任できるかを指定できます。 | [対象の資格情報] を どのサーバーに委任できるかを指定できます。 | [対象の資格情報] を どのサーバーに委任できるかを指定できます。 |
未構成 | [対象の資格情報] は どのコンピューターにも委任できません。 | 適切な相互認証の後、[対象の資格情報] の委任は、任意のコンピューターで動作しているリモート デスクトップ セッション ホスト (TERMSRV/*) に許可されます。 | クライアント コンピューターがどのドメインのメンバーでもない場合、適切な相互認証の後、[対象の資格情報] の委任は、任意のコンピューターで動作しているリモート デスクトップ セッション ホスト (TERMSRV/*) に許可されます。 クライアントがドメインに参加している場合、既定では、[対象の資格情報] の委任は、どのコンピューターにも許可されません。 |
無効 | [対象の資格情報] の委任はどのコンピューターにも許可されません。 | [対象の資格情報] の委任はどのコンピューターにも許可されません。 | [対象の資格情報] の委任はどのコンピューターにも許可されません。 |
委任する対象サーバーの指定方法
ポリシーで、委任を許可(または拒否)する際に、対象のホスト名を指定する必要がありますが、その際に指定方法についての説明です。
TERMSRV/*
→ すべてのコンピューターで動作しているリモート デスクトップ セッション ホスト。
TERMSRV/host.humanresources.fabrikam.com
→ host.humanresources.fabrikam.com コンピューターで動作しているリモート デスクトップ セッション ホスト
TERMSRV/*.humanresources.fabrikam.com
→ *.humanresources.fabrikam.com 内のすべてのコンピューターで動作しているリモート デスクトップ セッション ホスト
2. (既定・新しい・保存された)資格情報の委任を許可する
このポリシー設定は、サーバー認証が、信頼された X509 証明書 または Kerberos を使用して行われた場合に適用されます。
- 既定の資格情報の委任を許可する
- 新しい資格情報の委任を許可する
- 保存された資格情報の委任を許可する
# | 既定 | 新しい | 保存された |
---|---|---|---|
対象 | Windows へ最初にログオンする際に使用する資格情報 | アプリケーションを実行するときに要求される資格情報 | Windows 資格情報マネージャーを使用して保存または記録できる資格情報 |
有効 | [対象の資格情報] を どのサーバーに委任できるかを指定できます。 ポリシーは、Windows を実行しているコンピューターにユーザーが次回サインオンするときに有効になります。 |
[対象の資格情報] を どのサーバーに委任できるかを指定できます。 | [対象の資格情報] を どのサーバーに委任できるかを指定できます。 |
未構成 | [対象の資格情報] は どのコンピューターにも委任できません。この委任動作に依存するアプリケーションでは認証に失敗する可能性があります。 サポート技術情報の FWlink:http://go.microsoft.com/fwlink/?LinkId=301508 |
適切な相互認証の後、[対象の資格情報] の委任は、任意のコンピューターで動作しているリモート デスクトップ セッション ホスト (TERMSRV/*) に許可されます。 | 適切な相互認証の後、[対象の資格情報] の委任は、任意のコンピューターで動作しているリモート デスクトップ セッション ホスト (TERMSRV/*) に許可されます。 |
無効 | [対象の資格情報] は どのコンピューターにも委任できません。この委任動作に依存するアプリケーションでは認証に失敗する可能性があります。 サポート技術情報の FWlink:http://go.microsoft.com/fwlink/?LinkId=301508 |
[対象の資格情報] の委任はどのコンピューターにも許可されません。 | [対象の資格情報] の委任はどのコンピューターにも許可されません。 |
3. (既定・新しい・保存された)資格情報の委任を拒否する
このポリシー設定は、資格情報の委任を 許可 する ポリシー設定と組み合わせて使用します。
ワイルドカード文字を使用して許可した対象に対して、例外を定義できます。
例: "TERMSRV/*" で全てを許可したが、このポリシーを使って、"TERMSRV/abc.domain.local" だけを除外する
- 既定の資格情報の委任を拒否する
- 新しい資格情報の委任を拒否する
- 保存された資格情報の委任を拒否する
# | 既存 | 新しい | 保存された |
---|---|---|---|
対象 | Windows へ最初にログオンする際に使用する資格情報 | アプリケーションを実行するときに要求される資格情報 | Windows 資格情報マネージャーを使用して保存または記録できる資格情報 |
有効 | [対象の資格情報] を どのサーバーに委任できないかを指定できます。 | [対象の資格情報] を どのサーバーに委任できないかを指定できます。 | [対象の資格情報] を どのサーバーに委任できないかを指定できます。 |
未構成 or 無効 |
このポリシー設定でどのサーバーも指定されません。 | このポリシー設定でどのサーバーも指定されません。 | このポリシー設定でどのサーバーも指定されません。 |
4. リモート 〇〇 の資格情報の委任を 〇〇 する
- リモート ホストでエクスポート不可の資格情報の委任を許可する
- リモート サーバーへの資格情報の委任を制限する
Remote Credential Guard については、以下の記事で詳しく解説しています。
ポイント
Windows Hello for Business や FIDO2 を使っている場合は、資格情報の委任で RDP の SSO は実現できません。その場合 Remote Credential Guard を使うと RDP の SSO が実現できます。
リモート ホストでエクスポート不可の資格情報の委任を許可する
リモートホスト(リモートデスクトップの接続先)側で構成する設定です。
資格情報の委任を使用する場合、エクスポート可能なバージョンの資格情報がデバイスからリモート ホストに提供されます。これにより、ユーザーの資格情報はリモート ホスト上の攻撃者によって盗み取られる危険にさらされます。
# | 動作 |
---|---|
有効 | ホストは制限付き管理モードまたは Remote Credential Guard モードをサポートします。 |
未構成 or 無効 |
制限付き管理モードと Remote Credential Guard モードはサポートされません。ユーザーは常に資格情報をホストに渡す必要があります。 |
リモート サーバーへの資格情報の委任を制限する
リモートクライアント(リモートデスクトップの接続元)側で構成する設定です。
有効 にした場合は、3種類のオプションから選択する必要があります。
# | 動作 |
---|---|
有効 |
資格情報の委任を制限する 制限付き管理または Remote Credential Guard を使用してリモート ホストに接続する必要があります。 Remote Credential Guard を要求する Remote Credential Guard を使用してリモート ホストに接続する必要があります。 制限付き管理を要求する 制限付き管理を使用してリモート ホストに接続する必要があります。 |
未構成 or 無効 |
制限付き管理モードと Remote Credential Guard モードは適用されず、リモート デバイスに資格情報を委任できます。 |
注意: ほとんどの資格情報の委任を無効にするには、管理用テンプレートの設定を変更して、Credential Security Support Provider (CredSSP) での委任を拒否するだけで十分です (この設定は、"コンピューターの構成\管理用テンプレート\システム\資格情報の委任" にあります)。
注意: Windows 8.1 および Windows Server 2012 R2 では、このポリシーを有効にすると、選択しているモードに関係なく制限付き管理モードが適用されます。これらのバージョンでは、Remote Credential Guard はサポートされていません。
説明がわかりづらいのですが、設定を有効にすることで、クライアント側で 資格情報の委任 を禁止しています。必ず ポリシーで指定された接続方法(制限付き管理 または Remote Credential Guard)を使う必要があり、資格情報が クライアントに保存されたり、リモートホストに渡ることがなくなります。
5. 暗号化オラクルの修復
このポリシー設定だけは、前章までの資格情報の委任とは毛色が違います。
一部のバージョンの CredSSP プロトコルには、クライアントに対する暗号化オラクル攻撃を受けやすい脆弱性があります。このポリシーを使用すると、暗号化オラクル攻撃に対する脆弱性について、望ましい保護レベルを設定できます
具体的には、脆弱性のある状態での RDP 接続は、以下のようなメッセージが表示されて ブロックされてしまいます。
認証エラーが発生しました。
要求された関数はサポートされていません。
原因は CredSSP 暗号化オラクルの修復である可能性があります。
詳細については、https://go.microsoft.com/fwlink/?linkid=866660 を参照してください
Windows Vista SP2 以降 または Windows Server 2008 SP2 以降 ホストを使って RDP しようとすると発生することがあります。これは、必要な更新プログラムが適用されておらず、CredSSP の接続に脆弱性があると判断された結果ブロックされています。
この場合の対応策としては、最新の KB を適用するか、暗号化オラクルの修復 のポリシー設定を変更することで対処することができます。
詳しくは、以下の公開情報に記載されています。
公開情報:ユーザーがサインインできず、"認証エラー" および "CredSSP 暗号化オラクルの修復" のメッセージを受け取る
https://learn.microsoft.com/ja-jp/troubleshoot/windows-server/remote/cannot-authenticate-must-authenticate-twice?wt.mc_id=mvp_407731#user-cant-sign-in-and-receives-authentication-error-and-credssp-encryption-oracle-remediation-messages
公開情報:2018 年 5 月の更新プログラム適用によるリモート デスクトップ接続への影響
https://learn.microsoft.com/en-us/archive/blogs/askcorejp/2018-05-rollup-credssp-rdp?wt.mc_id=mvp_407731
脆弱 を選択することで、CredSSP を使用するクライアント アプリケーションは安全でないバージョンにフォールバックされ、暗号化オラクルの修復エラーが発生しなくなります。
なお、この動作はリモート デスクトップを攻撃の危険にさらされているという点は、理解しておきましょう。
"資格情報の委任" の設定例
私の記事以外にも、ネット上で見つけた記事から選別しています。
これらの記事を見比べていただくと、"既定"・"新しい"・"保存された" の違いも判りやすくなると思います。
既定 = Windows へ最初にログオンする際に使用する資格情報 の使用例
私の記事: 設定方法や動作イメージのキャプチャまで細かく記載してあります。
Support Blog:シングル サインオン (SSO) での RDP 接続
https://jpwinsup.github.io/blog/2023/06/15/RemoteDesktopService/RDS/RDS-Basic-Logon/#5-シングル-サインオン-SSO-での-RDP-接続
新しい = アプリケーションを実行するときに要求される資格情報 の使用例
あまり良い例が見つからなかったのですが、Hyper-V Manager を使って、別のホストの VM に接続しようとするシチュエーションが、"新しい" アプリを実行するときの要求 に該当していそうです。
20231114_【小ネタ】Hyper-Vのワークグループ環境でリモート管理を実施
https://www.challenge-cf.jp/post/20231114_【小ネタ】hyper-vのワークグループ環境でリモート管理を実施
保存された = Windows 資格情報マネージャーを使用して保存または記録できる資格情報 の使用例
MHIROBLOG:Windows 資格情報を利用したRDP接続について
https://mhiroblog.wordpress.com/2016/12/05/windows-資格情報を利用したrdp接続について/
MSeeeeN:Windows のリモートデスクトップで保存したパスワードで接続できないときの対策
https://mseeeen.msen.jp/allow-delegating-saved-credentials-with-ntlm-only-server-authentication/
Qiita:リモートデスクトップ接続 ローカル→ADユーザー 備忘録
https://qiita.com/daisei0311/items/b2f5209b79a0f6d8bd89
私が思うに、資格情報の 保存 が出来てしまうと、企業ユースの場合に セキュリティ 的なリスクが生じたりする場面があったり、保存したパスワードと、リモートホストのパスワードが一致せずに、アカウントロックが発生する場合があります。きちんと、リスクを把握したうえで、利用する方が良いと思います。
そのため、保存された資格情報の委任を拒否する のポリシーを使って ドメイン内のユーザーには 資格情報を保存させないようにする・・・という対処を行うことも、一考かと思います。
ドメイン環境で、パスワードが保存できない場合、すでに 管理者によって この設定が行われているという事かもしれません。