CredSSP and Credential Delegation

Overview

Credential Security Support Provider (CredSSP) is a Security Support Provider (SSP) and composite protocol for securely delegating user credentials from a client to a target server. It is used by Network Level Authentication (NLA) in Remote Desktop Protocol (RDP) and by CredSSP authentication in WinRM / PowerShell Remoting.

CredSSP is not a standalone encryption method. It combines Transport Layer Security (TLS), Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), and Kerberos or NTLM.

flowchart TB
    C[CredSSP client] -->|1. TLS channel| S[CredSSP server]
    C -->|2. SPNEGO within TLS| S
    C -->|3. Mutual authentication with Kerberos or NTLM| S
    C -->|4. Bind SPNEGO context to TLS server public key| S
    C -->|5. Encrypt and delegate user credentials| S

An important point emphasized by Microsoft’s CredSSP documentation is that this is not constrained delegation: it passes the user’s full credentials to the server without restrictions. Even when the connection is encrypted, the destination server can use those credentials, so the server itself must be trusted.

Authentication flow

Conceptually, CredSSP proceeds in this order:

1. The client and server establish a TLS channel. The client may still be anonymous at this point.
2. They exchange SPNEGO tokens inside the TLS channel, usually selecting Kerberos or NTLM.
3. They authenticate the client and server with the selected mechanism and establish an encryption key for the SPNEGO security context.
4. CredSSP binds the SPNEGO context to the server public key used in the TLS handshake to prevent confusion between the authenticated peer and the TLS endpoint.
5. The client encrypts and sends password credentials, smart card credentials, or supported redirected credentials to the server.
6. The server creates a local logon session with the received credentials and, when necessary, can authenticate as the user to another network resource.

The user’s credentials are protected by the SPNEGO session key, and the entire CredSSP message also travels inside the TLS channel. However, double encryption and the safety of the server receiving the credentials are separate matters.

Relationship to the double-hop problem

The double-hop problem is a different concept from the “two steps” in multi-factor authentication (MFA).

Client -- connect as user --> ServerB -- connect as user --> ServerC
             first hop                    second hop

With ordinary Kerberos / NTLM remote authentication, ServerB does not receive the user’s password. A remote session on ServerB may therefore lack reusable credentials to connect to ServerC as that user, causing the second hop to fail.

With CredSSP, credentials are delegated to ServerB, which can use them to connect to ServerC. This is easy to configure, but it can lead to credential theft if ServerB is compromised.

CredSSP and Kerberos delegation differ as follows:

Item	CredSSP	Kerberos constrained delegation / RBCD
What the server receives	Reusable user credentials	A ticket issued by the KDC for the delegated service
Scope of delegation	Wherever the server receiving the credentials can use them	Can be restricted to services or resources allowed in AD
Main risk	Credential theft from the target server	Compromise of delegation settings, SPNs, or service accounts
Typical use	RDP NLA, explicit second hop with WinRM	Delegated access from a frontend to a specific backend service

Common uses

RDP and NLA

RDP uses CredSSP to authenticate the user at the network layer before fully establishing a desktop session, and can delegate remote-logon credentials to the server. NLA reduces resource use by unauthenticated sessions, but it does not remove the risks of CredSSP credential delegation.

RDP modes such as Remote Credential Guard, which do not send credentials directly to the remote host, have different security properties from ordinary CredSSP credential delegation. Where available, consider them as alternatives for remote administration with privileged accounts.

WinRM / PowerShell Remoting

CredSSP authentication in WinRM is one option for making a second hop work. It must be explicitly enabled in both the client and server roles and is disabled by default.

# Client: enable delegation to a limited destination
Enable-WSManCredSSP -Role Client -DelegateComputer 'serverb.corp.example.com'

# ServerB: accept CredSSP credentials
Enable-WSManCredSSP -Role Server

# Check the status
Get-WSManCredSSP

# Connect with CredSSP
$credential = Get-Credential
Enter-PSSession -ComputerName 'serverb.corp.example.com' `
    -Authentication CredSSP `
    -Credential $credential

Disable both roles when they are no longer needed after verification.

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

These commands change system configuration and credential delegation policy. In production, check the scope of Group Policy, existing WSMan settings, and change management before running them.

Policies and restrictions

• CredSSP delegation is controlled by Group Policy under Computer Configuration > Administrative Templates > System > Credentials Delegation.
• Do not allow a broad set of delegation targets with wildcards; limit them to necessary servers and services.
• Keep both clients and servers patched. Do not leave Encryption Oracle Remediation set to Vulnerable for compatibility.
• Accounts in the Protected Users group cannot use CredSSP delegation.
• Check account-level delegation restrictions such as Account is sensitive and cannot be delegated.
• Validate TLS server authentication and the target name to confirm that the connection goes to the intended server.

Security considerations

• Use CredSSP only with managed servers trusted even in the face of credential theft.
• Do not delegate Tier 0 credentials, such as Domain Admin credentials, to ordinary servers or workstations through CredSSP.
• Do not leave it permanently enabled solely because a second hop is needed. Evaluate alternatives such as JEA (Just Enough Administration), RunAs endpoints, service accounts, resource-specific delegation, and Remote Credential Guard.
• Regularly review the client and server roles and allowed targets, and remove settings that are no longer needed.
• Monitor RDP / WinRM events, logon events, and Group Policy changes.
• TLS prevents eavesdropping but cannot protect credentials if the legitimate target server that decrypts and uses them is compromised.

Troubleshooting

Symptom	What to check
CredSSP is not allowed	Check the client and server roles, Group Policy, and Get-WSManCredSSP.
NTLM is selected instead of Kerberos	Check the FQDN, SPN, DNS, domain trust, and time synchronization.
Encryption oracle error	Check the client and server patch levels and the Encryption Oracle Remediation policy. Prioritize updates instead of lowering the policy to Vulnerable.
Failure with Protected Users	Confirm that the account protection disallows CredSSP and choose another method.
Only the second hop fails	Check whether the connection actually uses -Authentication CredSSP, whether ServerB accepts credentials, and whether ServerC grants access.

Related

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

Official Microsoft documentation

• Credential Security Support Provider: CredSSP, TLS, SPNEGO, and the warning about full credential delegation.
• MS-CSSP: Overview: Protocol flow for TLS, SPNEGO, public key binding, and credential transfer.
• MS-CSSP: Relationship to Other Protocols: How CredSSP relates to TLS, Kerberos, NTLM, and RDP.
• Security Support Provider Interface Architecture: The CredSSP SSP and default delegation policy.
• Making the second hop in PowerShell Remoting: The second hop with CredSSP, credential caching risk, and alternatives.
• Enable-WSManCredSSP: The roles and delegation targets for Enable-WSManCredSSP.
• ADMX_CredSsp Policy CSP: Credentials Delegation and Encryption Oracle Remediation policies.