Credential Security Support Provider (CredSSP) allows you to delegate user credentials across multiple remote computers. In PowerShell you sometimes need CredSSP for second-hop remoting,

Timothy Warner

Timothy Warner is a Microsoft Cloud and Datacenter Management Most Valuable Professional (MVP) who is based in Nashville, TN. Check out his Azure and Windows Server video training at Pluralsight, and feel free to reach out to Tim via Twitter.

Latest posts by Timothy Warner (see all)

Our lab scenario

Our lab scenario

Consider the following scenario: We need to run some PowerShell on the Windows Server 2012 R2 member server named mem2 from our local server named dc1. Because mem2 resides on a high-security subnet, we can’t access mem2 directly.

We’ll use adfs1 as a “jump box” because adfs1 is allowed to communicate with mem2. To start, we’ll open a remoting session from dc1 to adfs1 by using our current domain administrator credentials:

Next, we’ll use Invoke-Command to initiate WS-Man PowerShell remoting and hit mem2:

Yikes! As you can see in the following screenshot, I received a heap of fatal errors.

Connecting to remote server mem2 failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x800903e occurred while using Kerberos authentication . . .

This is the dreaded second hop problem

This is the dreaded Kerberos “second hop” problem.

The behavior we see here is actually by design and is referred to as the Kerberos “second hop” problem. In our example, the remoting session from dc1 to adfs1 passes on my domain administrator credentials, and any remoting stuff I do on adfs1 occurs within that security context.

However, when we “reach out” from adfs1 to mem2, Kerberos assumes that it isn’t allowed to impersonate my identity for the second hop. One way to solve this problem permanently is to configure Kerberos constrained delegation in Active Directory.

Another alternative is to use the Credential Security Service Provider (CredSSP) protocol. The long story short is that CredSSP allows us to delegate user credentials manually across the network. Obviously, this is a security-sensitive operation and should be implemented judiciously.

Windows PowerShell includes only three CredSSP commands:

Let’s set up CredSSP delegation and test it out, shall we?

Enabling CredSSP ^

Take another look at the image I gave you at the beginning of this article. To pass my administrator credentials through adfs1 to mem2, we’ll temporarily configure dc1, my local server, as a CredSSP client, and adfs1 as a CredSSP server. We don’t have to touch the target box, mem2.

First, I’ll run Enable-WSManCredSSP on dc1:

Some administrators like to swing the heavy hammer by enabling delegation globally (–DelegateComputer *.company.pri), but I feel that’s a bit too permissive.

Please note that we specify the CredSSP server in our –DelegateComputer parameter, not the local box. You can verify your configuration by running Get-WSManCredSSP:

Second, let’s configure adfs1 as the CredSSP server:

You should also run Get-WSManCredSSP afterward to verify the configuration.

Okay, then. Let’s get this party started! The “secret sauce” to the delegated remoting session is specifying CredSSP as our authentication provider:

“The proof is in the pudding,” my old mentor Bernie Carr used to say. Let’s see if we can complete the second-hop to mem2:

We solved the second hop problem

We solved the Kerberos second hop problem!

To quote Hannibal from The A-Team, “I love it when a plan comes together!”

Sweeping up the shavings ^

Go ahead and close your local PowerShell session. Then open a fresh one using the same credentials. I wonder if the CredSSP client settings persisted?

If you run Get-WSManCredSSP on your local and remote servers, you’ll see that we did, in fact, make a permanent change. For security’s sake, let’s reset the CredSSP environment to the way it was originally:

 

Join the 4sysops PowerShell group!

0
Share
1 Comment
  1. Seth 3 years ago

    Hi Timothy,

     

    Thanks for the detailed explanation. I'm curios if this will also work:

    (dc1 and adfs1 have different admin credentials)

    1) I need to run enter-pssession from dc1 to adfs1 with -credential adfs1\administrator (or run powershell as adfs1\administrator)

    2) now  in pssession  I need to run cmdlet to modify something on mem2 with mem2\administrator

    Is is possible to pass the mem2 credentials from within the pssession?

    I cannot run poweshell as mem2\administrator from dc1.

    Thanks in advance

    1+

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2019

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account