When dealing with PowerShell remoting across multiple hops, CredSSP (Credential Security Support Provider) often becomes necessary to handle the infamous "double-hop" authentication problem. Here's what typically happens when the configuration isn't perfect:

# Common error you might encounter
Invoke-Command -ComputerName Server01 -ScriptBlock { Get-ChildItem \\FileServer\Share } -Credential $cred -Authentication CredSSP

# Error output:
# Connecting to remote server failed with the following error message:
# The WinRM client cannot process the request. A computer policy does not allow
# the delegation of the user credentials to the target computer.

The problem manifests in two distinct phases:

1. Initial WinRM configuration problems preventing CredSSP setup
2. Group Policy restrictions blocking credential delegation

1. Server-Side Configuration

First, ensure WinRM is properly configured on the target server:

# Run as Administrator on the server
Enable-PSRemoting -Force
Enable-WSManCredSSP -Role Server

2. Client-Side Configuration

On the client machine that initiates the remote session:

# Run as Administrator on the client
Enable-PSRemoting -Force
Enable-WSManCredSSP -Role Client -DelegateComputer "*.yourdomain.com"

3. Group Policy Configuration

The most critical and often missed step involves configuring the correct Group Policy settings:

# These are the GPO paths you need to configure:
# Computer Configuration -> Administrative Templates -> System -> Credentials Delegation
# 
# Required policies to enable:
# 1. Allow Delegating Fresh Credentials
# 2. Allow Delegating Fresh Credentials with NTLM-only Server Authentication

Use these commands to validate each component:

# Check WinRM listeners
Test-WSMan -ComputerName Server01

# Verify CredSSP configuration
Get-WSManCredSSP

# Test basic WinRM connectivity
winrs -r:http://Server01:5985 -u:DOMAIN\user "hostname"

For more complex environments, consider these additional steps:

# For constrained delegation with specific SPNs
Set-Item -Path WSMan:\localhost\Service\Auth\CredSSP -Value $true

# When dealing with non-domain joined machines:
Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value "Server01" -Force

• Verify WinRM service is running on both ends
• Check firewall rules (TCP 5985/5986)
• Confirm SPNs are registered correctly in Active Directory
• Validate Group Policy has applied (gpupdate /force)
• Review WinRM and PowerShell logs for detailed errors

Here's how to properly structure a multi-hop operation:

$session = New-PSSession -ComputerName Server01 -Credential $cred -Authentication CredSSP

Invoke-Command -Session $session -ScriptBlock {
    # This second hop will now work
    Get-ChildItem \\FileServer\Share | Export-CSV C:\temp\files.csv
}

Remove-PSSession $session

---

The CredSSP authentication problem stems from Windows security architecture's restriction on credential delegation across multiple network hops. When attempting PowerShell remoting with nested authentication requirements (like accessing a network share from a remote session), you encounter the "double-hop" limitation.

First, verify WinRM is properly configured on both machines:

# On both client and server
winrm quickconfig
Test-WSMan -ComputerName targetServer

Configure the server to allow credential delegation:

# On the target server
Enable-WSManCredSSP -Role Server -Force
Get-WSManCredSSP # Should show "This computer is configured to receive credentials"

The client needs proper delegation settings and SPN configuration:

# On the client machine
Enable-PSRemoting -Force
Enable-WSManCredSSP -Role Client -DelegateComputer "*.yourdomain.com" -Force

The most critical yet often overlooked step is configuring the Credential Delegation policy:

1. Open gpedit.msc
2. Navigate to: Computer Configuration → Administrative Templates → System → Credentials Delegation
3. Enable "Allow Delegating Fresh Credentials"
4. Add server SPNs: WSMAN/server.yourdomain.com or WSMAN/*.yourdomain.com

Here's how to test the CredSSP authentication:

$cred = Get-Credential
Invoke-Command -ComputerName server.yourdomain.com -ScriptBlock {
    # Try accessing a network resource
    dir \\fileserver\share
} -Authentication CredSSP -Credential $cred

• Verify firewall rules allow WinRM traffic (port 5985/5986)
• Check Event Viewer for detailed WinRM logs
• Use winrm enumerate winrm/config/listener to verify listener configuration
• For domain environments, ensure proper DNS resolution of FQDNs

These mistakes often cause CredSSP failures:

• Using IP addresses instead of FQDNs
• Not including the domain suffix in SPN configuration
• Forgetting to restart WinRM service after configuration changes
• Mismatched authentication protocols between client and server

If CredSSP remains problematic, consider these alternatives:

# Using Kerberos constrained delegation
Set-Item WSMan:\localhost\Service\Auth\Kerberos -Value $true

# Using SSL certificate authentication
New-Item -Path WSMan:\localhost\ClientCertificate -Credential $cred