CredSSP と資格情報の委任

概要

Credential Security Support Provider (CredSSP) は、client から target server へ user credential を安全に委任するための Security Support Provider (SSP) / composite protocol です。Remote Desktop Protocol (RDP) の Network Level Authentication (NLA) や、WinRM / PowerShell Remoting の CredSSP authentication で利用されます。

CredSSP は単独の暗号方式ではありません。Transport Layer Security (TLS)、Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)、Kerberos または NTLM を組み合わせます。

flowchart TB
    C[CredSSP client] -->|1. TLS channel| S[CredSSP server]
    C -->|2. TLS 内で SPNEGO| S
    C -->|3. Kerberos または NTLM で相互認証| S
    C -->|4. SPNEGO context を TLS server public key に bind| S
    C -->|5. User credential を暗号化して委任| S

Microsoft の CredSSP 文書が強調する重要点は、これは constrained delegation ではなく、user の完全な credential を制約なしに server へ渡す方式だということです。通信が暗号化されていても、委任先 server は credential を利用できるため、委任先そのものを信頼できる必要があります。

認証の流れ

CredSSP の概念的な処理は次の順序です。

1. Client と server が TLS channel を確立します。この時点で client はまだ匿名の場合があります。
2. TLS channel 内で SPNEGO token を交換し、通常は Kerberos または NTLM を選択します。
3. 選択した mechanism で client と server を認証し、SPNEGO security context の encryption key を確立します。
4. CredSSP は SPNEGO context と TLS handshake で使った server public key を bind し、認証相手と TLS endpoint の取り違えを防ぎます。
5. Client は password credential、smart card credential、または対応する redirected credential を暗号化して server に送ります。
6. Server は受け取った credential で local logon session を作成し、必要な場合は別の network resource へ user として認証できます。

User credential は SPNEGO の session key で保護され、さらに CredSSP message 全体が TLS channel 内を通ります。ただし、二重に暗号化されることと、credential を受け取る server が安全であることは別問題です。

ダブルホップとの関係

Double hop problem は、多要素認証（Multi-Factor Authentication）の「二段階」とは別の概念です。

Client -- user として接続 --> ServerB -- user として接続 --> ServerC
             first hop                    second hop

通常の Kerberos / NTLM remote authentication では、ServerB は user の password を受け取りません。そのため、ServerB 上の remote session から ServerC へ user として接続するための reusable credential がなく、second hop が失敗する場合があります。

CredSSP を使うと ServerB に credential が委任されるため、ServerB はその credential を使って ServerC へ接続できます。これは設定が容易な一方、ServerB が侵害されていれば credential theft につながります。

CredSSP と Kerberos delegation の違いは次のとおりです。

項目	CredSSP	Kerberos constrained delegation / RBCD
Server に渡るもの	Reusable な user credential	KDC が発行する委任先 service 用 ticket
委任範囲	Credential を受け取った server が利用できる範囲	AD で許可した service / resource に制約可能
主な risk	Target server からの credential theft	Delegation 設定、SPN、service account の侵害
代表用途	RDP NLA、WinRM の明示的な second hop	Frontend から特定 backend service への代理アクセス

主な利用場面

RDP と NLA

RDP は CredSSP を使い、desktop session を完全に確立する前に network layer で user を認証し、remote logon 用 credential を server へ委任できます。NLA は unauthenticated session の resource consumption を減らしますが、CredSSP の credential delegation risk が消えるわけではありません。

Remote Credential Guard など credential を remote host に直接渡さない RDP mode は、通常の CredSSP credential delegation と security property が異なります。利用可能な環境では、特権 account の remote administration に対する代替として検討します。

WinRM / PowerShell Remoting

WinRM の CredSSP authentication は second hop を成立させる選択肢です。Client role と server role の両方で明示的に有効化する必要があり、既定では無効です。

# Client: 委任先を限定して有効化
Enable-WSManCredSSP -Role Client -DelegateComputer 'serverb.corp.example.com'

# ServerB: CredSSP credential を受け入れる
Enable-WSManCredSSP -Role Server

# 状態確認
Get-WSManCredSSP

# CredSSP で接続
$credential = Get-Credential
Enter-PSSession -ComputerName 'serverb.corp.example.com' `
    -Authentication CredSSP `
    -Credential $credential

検証後に不要になった場合は両 role を無効化します。

Disable-WSManCredSSP -Role Client
Disable-WSManCredSSP -Role Server

これらの command は system configuration と credential delegation policy を変更します。本番環境では Group Policy の適用範囲、既存 WSMan 設定、変更管理を確認してから実行してください。

ポリシーと制約

• CredSSP delegation は Computer Configuration > Administrative Templates > System > Credentials Delegation の Group Policy で制御されます。
• Wildcard で広い委任先を許可せず、必要な server / service に限定します。
• Client と server の両方を patch 済みに保ちます。Encryption Oracle Remediation を互換性目的で Vulnerable に下げたまま運用しません。
• Protected Users group の account は CredSSP delegation を利用できません。
• Account is sensitive and cannot be delegated など、account 側の delegation 制限も確認します。
• TLS server authentication と target name を検証し、意図した server に接続していることを確認します。

セキュリティ上の注意

• CredSSP は、credential theft を想定しても信頼できる管理対象 server にだけ使用します。
• Domain Admin など Tier 0 credential を、通常 server や workstation へ CredSSP で委任しません。
• Second hop が必要という理由だけで恒久的に有効化せず、JEA (Just Enough Administration)、RunAs endpoint、service account、resource-specific delegation、Remote Credential Guard などの代替を評価します。
• Client / server role と許可対象を定期的に棚卸しし、不要になった設定を削除します。
• RDP / WinRM event、logon event、Group Policy change を監視します。
• TLS は盗聴を防ぎますが、credential を復号して利用する正規の target server 自体が侵害されている場合は保護できません。

トラブル時の切り分け

症状	確認点
CredSSP が許可されていない	Client / server role、Group Policy、Get-WSManCredSSP を確認する。
Kerberos ではなく NTLM が選択される	FQDN、SPN、DNS、domain trust、時刻同期を確認する。
Encryption oracle 関連 error	Client / server の patch level と Encryption Oracle Remediation policy を確認する。Policy を Vulnerable に下げるのではなく更新を優先する。
Protected Users で失敗する	CredSSP 非対応という account protection の仕様を確認し、別方式を選ぶ。
Second hop だけ失敗する	接続が本当に -Authentication CredSSP か、ServerB が credential を受け入れる構成か、ServerC 側の認可を確認する。

関連

• Negotiate / SSPI / SPNEGO
• Secure Channel: Netlogon と Schannel
• Kerberos Delegation と SPN Abuse

Microsoft の公式資料

• Credential Security Support Provider: CredSSP、TLS、SPNEGO、完全な credential delegation の注意。
• MS-CSSP: Overview: TLS、SPNEGO、public key binding、credential transfer の protocol flow。
• MS-CSSP: Relationship to Other Protocols: CredSSP と TLS、Kerberos、NTLM、RDP の関係。
• Security Support Provider Interface Architecture: CredSSP SSP と既定の delegation policy。
• Making the second hop in PowerShell Remoting: CredSSP による second hop、credential cache risk、代替方式。
• Enable-WSManCredSSP: Enable-WSManCredSSP の role と delegation target。
• ADMX_CredSsp Policy CSP: Credentials Delegation と Encryption Oracle Remediation policy。