パスワードやユーザーアカウントの入力を何度も繰り返すのは意外と手間がかかり、業務の効率を落としてしまいます。そこで本記事では、WindowsサーバーへのRDP接続時に入力した資格情報を使い回して、サーバー内部での操作をスムーズに進めるための方法を詳しくご紹介します。
WindowsサーバーとRDPの基本概要
Windowsサーバー環境にリモートデスクトップ（RDP）で接続する場合、多くの企業ではネットワークレベル認証（NLA）を有効にし、さらにActive Directory（AD）でユーザーを一元管理しているケースが一般的です。通常、RDPを使ってサーバーに接続するときには以下の流れで認証が行われます。
- クライアント側（PC）でユーザー名とパスワードを入力
- ネットワークレベル認証が通ればサーバーにログオン
- サーバー上で必要な操作を実施
ただし、サーバーで別の管理者権限を要するアプリを起動したり、AD管理コンソールを開いたりする際に、再度資格情報を入力するケースが発生しがちです。これは、アプリケーションごとに明示的に管理者資格情報が要求される設定になっていたり、Windowsのセキュリティポリリシー上で資格情報を使い回さないように制御されていたりするためです。そこで役立つのが「CredSSP（Credential Security Support Provider）」です。
CredSSPとは何か？
CredSSP（Credential Security Support Provider）は、クライアントがサーバーに対して安全に資格情報を渡すためのプロトコルです。Remote Desktop Protocol（RDP）と連携し、クライアントからサーバーへ資格情報を転送する際、暗号化されて安全性を確保します。これにより、下記のようなメリットが期待できます。
- RDPセッションを開始したときのユーザー資格情報をサーバー上で再利用可能
- 同じユーザーアカウントで管理者権限を要する操作を行う際にも、追加入力を省略できる
- ネットワーク経由でも安全に認証情報を扱える
ただし、組織によってはセキュリティポリシー上、CredSSPでの資格情報の使い回しを制限している場合があります。そのため、実運用の前に管理者やセキュリティ担当者と十分に打ち合わせを行うことが重要です。
RDPクライアント側の設定方法
RDPファイルを使った設定
RDP接続を行うとき、通常は「リモートデスクトップ接続」アプリからGUIでサーバー情報を入力して接続します。一方で、.rdp拡張子のファイルを使用すると、接続設定を保存・編集することができます。RDPファイルを編集することで、CredSSP関連の設定を手動で行うことが可能です。
- RDP接続設定を保存する
- Windowsの「リモートデスクトップ接続」アプリを開き、接続先のIPアドレスやホスト名、ユーザー名を入力した状態で「オプションの表示」をクリックし、[既存または保存済みのRDPファイル名を指定 → 保存]を選びます。
- RDPファイルをテキストエディタで開く
- 保存された
.rdpファイルを右クリックし、「プログラムから開く」→「メモ帳」などのテキストエディタで開きます。
- CredSSP関連のパラメータを追記・変更
- 以下の2行を追加または修正します。
authentication level:i:2
enablecredsspsupport:i:1
これにより、RDPクライアント側でCredSSPが有効になります。
GUIでの設定
特に.rdpファイルを直接編集しなくても、GUI上で「常に資格情報を求める」や「このアカウント情報を保存する」などのオプションを適切に選択することで、CredSSPの動作をアシストできます。しかし、GUI操作だけでは細かな制御が難しい場合もあるため、上記のRDPファイル編集方法がより確実です。
サーバー側のポリシー設定
グループポリシーの確認
ドメイン環境であれば、グループポリシー（GPO）でCredSSPや関連するデリゲーションの設定が行われている可能性があります。特に、「Credential Delegation」や「Restrict Delegation of Credentials to Remote Servers」などの項目が制限されていると、クライアントからの資格情報がサーバー側で使い回せません。
下記の手順で確認が可能です。
- ドメインコントローラーや管理用PCで「グループポリシーの管理」を開く
- 対象となるOU（組織単位）やドメイン全体にリンクされているGPOを確認
- [コンピューターの構成] → [ポリシー] → [管理用テンプレート] → [システム] → [資格情報の委任] などの該当項目を展開し、設定をチェック
ローカルセキュリティポリシーの調整
もしドメインではなくスタンドアロン環境のWindowsサーバーであれば、「ローカルセキュリティポリシー」に同様の設定が存在します。以下のように操作します。
- Windowsサーバー上で「ファイル名を指定して実行」を開き、
secpol.mscと入力 - [セキュリティ設定] → [ローカルポリシー] → [セキュリティオプション] または [認証ポリシー] を確認
- 「資格情報の委任」に関する設定がある場合は有効にする、もしくは必要に応じて制限を緩和する
グループポリシーやローカルセキュリティポリシーが組織のセキュリティポリシーと矛盾しないように注意しましょう。特に、会社の規約やセキュリティ監査の要件をよく確認する必要があります。
資格情報の使い回しを有効にする実践的手順
CredSSPの動作に必要な環境条件
- Windows 7以降、およびWindows Server 2008以降
- ネットワークレベル認証（NLA）が無効でも動作はしますが、通常はNLAを有効にするのがセキュリティ上望ましい
- クライアント側とサーバー側の両方がCredSSPをサポートしている必要がある
具体的な手順の例
ここでは、ドメイン参加しているWindowsクライアント（Windows 10/11）から、同じドメイン内のWindows Server 2019へRDP接続する場合の一例を示します。
- クライアントPC上でRDPの設定ファイルを作成・保存する
- 「リモートデスクトップ接続」アプリを起動し、サーバー名（FQDNやIPアドレス）、ユーザー名を入力
- オプションの表示から「保存」をクリックして、任意の場所に
.rdpファイルを保存
.rdpファイルをテキストエディタで開き、以下を修正/追加するauthentication level:i:2 enablecredsspsupport:i:1- サーバー側のグループポリシーで「資格情報の委任」が制限されていないことを確認
- ドメインコントローラーから「グループポリシーの管理」を開く
- 対象のGPOを開き、[コンピューターの構成] → [ポリシー] → [管理用テンプレート] → [システム] → [資格情報の委任] に関連する設定をチェック
- 「Allow delegating fresh credentials」や「Allow delegating saved credentials」の項目が有効になっているか確認
- ローカルポリシーが優先される場合、サーバー側で
secpol.mscを開き同様の項目を確認 - 設定を反映後、クライアントPCから再度RDP接続し、サーバー上で管理コンソールやアプリを起動してみる
もし設定が正しく行われていれば、RDPセッション開始時に入力したユーザーとパスワードがサーバー上で使い回される形で、自動的に認証が通る場面が増えるはずです。
資格情報の再利用がうまくいかない場合のチェックポイント
グループポリシーによる制限
多くの企業ではセキュリティ確保のため、資格情報の委任を厳しく制限しています。特に、以下のポリシーを確認しましょう。
| ポリシー名 | 推奨値 | 備考 |
|---|---|---|
| Allow delegating default credentials | 有効 | 必須の設定ではないが、有効にしないと認証が継承されない場合あり |
| Allow delegating saved credentials | 有効 | 接続先サーバーのFQDNやTERMSRV/*などのワイルドカード指定が必要 |
| Deny delegating saved credentials | 無効 | これが有効だと資格情報の使い回しがブロックされる |
もし「Deny delegating saved credentials」や「Deny delegating fresh credentials」が有効になっていると、クライアント側でどれだけ設定しても、サーバー側で資格情報が再利用されなくなります。
管理者権限の昇格動作
Windowsサーバー上でUAC（User Account Control）が有効になっている場合、特定の管理者操作やアプリケーション起動時に「ユーザーアカウント制御」による権限昇格プロンプトが出ることがあります。この際、再度パスワードを求められることがあります。
特に、ローカルのAdministratorsグループに属していない通常ユーザーが管理者権限を要する操作を行う場合はUACプロンプトが表示され、資格情報を再入力することになる場合もあります。この挙動はCredSSPに関わらず、UACの仕組みによるものです。必要に応じてUACの設定を調整してみてください。ただしセキュリティリスクが高まるため、慎重な運用とテストが大切です。
接続先サーバーのホスト名と認証
RDPファイルやGPOで「Allow delegating saved credentials」の設定を有効にするとき、接続先サーバーのFQDNやワイルドカード指定（TERMSRV/*.example.com など）を正しく設定していないと、資格情報の委任が失敗するケースがあります。特に以下の点に注意してください。
- サーバーにIPアドレスで接続している場合：
TERMSRV/192.168.1.100のように明示的に記述 - サーバーにホスト名（FQDN）で接続している場合：
TERMSRV/server.example.localのように記述
ワイルドカードを使う場合は、TERMSRV/*.example.localなど、必ず「TERMSRV/」プレフィックスを付けましょう。
セキュリティリスクと考慮点
資格情報の使い回しを有効にすると、業務上の利便性は非常に高まります。一方で、セキュリティ面では以下のようなリスクが考えられるため、対応策を検討する必要があります。
- 不正アクセスリスクの増大：資格情報がサーバーに渡されるため、万が一クライアント側がマルウェア感染していると情報漏洩の可能性がある
- 操作ミスによる権限の誤行使：資格情報が自動で使い回されることで、意図せず高権限の操作を行う恐れ
- コンプライアンス違反の可能性：企業ポリシーや監査要件で、資格情報の委任が禁止されている場合がある
これらを踏まえ、以下のような対策を検討しましょう。
- 多要素認証（MFA）の導入 RDP接続時にワンタイムパスワード（OTP）やスマホ認証を導入して、単純なパスワード依存を減らすことが有効です。
- 監査ログの強化 誰がいつ資格情報を使ってどの操作を行ったかを記録する監査ログを徹底することで、不正利用の早期発見が可能です。
- 最小権限の原則 管理者権限が必要な操作は最小限にとどめ、不要なユーザーに権限を与えないようにすることで、被害範囲を限定できます。
- クライアント端末のセキュリティ強化 ウイルス対策ソフトの導入やOSのパッチ適用、情報漏洩防止策を徹底し、クライアント側からの侵害リスクを下げましょう。
別アカウントでログオンしているクライアントPCからの操作
実務では、クライアントPCでログインしているドメインユーザーと、RDPでサーバーに接続するドメインユーザーアカウントが異なるケースも多々あります。このようなケースでも、CredSSPを正しく設定しておけば、RDPセッション開始時に入力した資格情報をサーバー内部で使い回すことが可能です。
ただし、Windows側の仕組み上、「現在ログインしているユーザー（クライアントPCのアカウント）」の資格情報を必ずサーバーに送る」というわけではなく、あくまで.rdpファイルに指定したユーザー名とパスワードが送信されます。したがって、RDPセッションを開始する際に異なるアカウントを指定していれば、そのアカウントの資格情報がサーバーで使い回される形になります。
具体的な運用例
- クライアントPCで「UserA」がログオンしている状態
- RDP接続時に「UserB」のドメインアカウントを使ってサーバーに接続
- サーバー側では「UserB」の資格情報がセッションに保持される
- サーバー上のアプリ起動やAD管理ツールを使う際は「UserB」の権限が有効に
このように、クライアントPCのログオンユーザーとは別のユーザーアカウントを利用してRDP接続したい場合も、CredSSPを活用することで比較的シームレスに運用できるようになります。
CredSSP利用時の代表的なトラブルシューティング
1. RDP接続自体ができなくなった
CredSSPの設定を有効化した後、突然RDP接続ができなくなるケースがあります。特に、Windowsの更新プログラムやセキュリティパッチが適用されたタイミングで、CredSSPのバージョン不整合が起きることがあります。以下を確認してください。
- クライアントPCとサーバーの両方に最新の更新プログラムが適用されているか
- イベントビューアのシステムログまたはセキュリティログにエラーや警告が記録されていないか
- グループポリシー「Encryption Oracle Remediation」の設定が厳密になりすぎていないか
2. 資格情報を再度求められる
RDP接続時に資格情報を入力したのに、サーバー上でアプリを開くときにまた認証ダイアログが出る場合は、以下の可能性があります。
- UACプロンプトの仕様 管理者昇格を要するアプリは、WindowsのUACによって認証を促される場合があります。
- アプリケーション自体の設定 一部のアプリ（SQL Server Management Studioなど）は独自の資格情報を管理する設定があり、Windowsログオンとは別に認証を求める仕組みを持っています。
- GPOで認証の委任が許可されていない サーバー側、またはドメインのグループポリシーで資格情報の委任を制限していると、再度の入力が求められます。
3. マルウェアやウイルス検知ソフトの誤反応
CredSSPは資格情報を暗号化して送信しますが、ネットワークやファイアウォール、ウイルス対策ソフトの設定によっては不審な通信としてブロックされる場合があります。特に企業向けのウイルス対策ソフトや侵入防止システム（IPS）では、設定によっては「不明な認証転送」とみなすことがあります。
この場合は、セキュリティ製品の管理コンソールから例外設定（ホワイトリスト登録）を行い、RDPの通信を許可する必要があります。
コード例：Group Policyの設定をスクリプトで管理する
大規模な環境では、グループポリシーのGUIを手作業で調整するより、スクリプトを使って設定をインポートするほうが効率的です。以下は、PowerShellスクリプトを活用して「Allow delegating default credentials」の値を設定する例です。
# 例：CredSSPのグループポリシーをセットするスクリプト
# 以下は管理者権限のPowerShellで実行することを想定
$PolicyPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\CredSSP\Parameters"
if (!(Test-Path $PolicyPath)) {
New-Item -Path $PolicyPath -Force | Out-Null
}
# Encryption Oracle Remediationのレベルを緩和: Vulnerable=0, Mitigated=1, ForceUpdatedClients=2
Set-ItemProperty -Path $PolicyPath -Name "AllowEncryptionOracle" -Type DWord -Value 2
# ほかのポリシー設定を追加したい場合
# 例：Set-ItemProperty -Path $PolicyPath -Name "EnableCredSspSupport" -Type DWord -Value 1
このようにレジストリベースでポリシーを設定している場合は、再度gpupdate /forceコマンドでポリシーを反映させてからRDP接続をテストすると良いでしょう。
まとめ：利便性とセキュリティのバランスが鍵
WindowsサーバーにRDP接続した際に資格情報を使い回す機能は、業務効率を大きく向上させます。一方で、資格情報の委任はセキュリティ面でのリスク要因にもなり得るため、組織のポリシーや監査要件としっかり整合を取ることが不可欠です。特に、CredSSPを有効にするには下記をしっかり押さえましょう。
- RDPクライアント側（
.rdpファイル）の編集 - サーバー側のグループポリシーやローカルセキュリティポリシーの設定
- 最小権限の原則や多要素認証によるリスク低減
これらを正しく構成できれば、Active Directory上での管理作業や、サーバー内部のアプリケーション操作もスムーズに進められるようになるでしょう。ぜひ、管理者と連携して導入を検討してみてください。
コメント