Solve the PowerShell multi-hop problem without using CredSSP

One of the most annoying problems that has existed with PowerShell ever since we got PowerShell remoting in v2 is the infamous double-hop or multi-hop problem. This occurs if you try connect to another remote computer from within your remote session.

Using PowerShell remoting, we can seamlessly connect to a remote computer and run commands on it just like we can on our local computer. PowerShell remoting is similar to psexec in that manner. Once set up, this functionality works great. But you'll soon find it doesn't work so great once you attempt to access network resources from that same remoting session.

To demonstrate, let's say I have three machines: CLIENT1, SRV1, and SRV2 all on the same Active Directory domain. On CLIENT1, I run a command on SRV2 using Invoke-Commmand, which uses PowerShell remoting.

That works great, but now let's try to list some files on the SRV2 server where I know I have rights to do so from the session on the SRV1 server.

It rejected me. The reason is because PowerShell remoting doesn't allow us to pass the credential we inherently used to establish a session with SRV1. When we attempt to connect to SRV2 somehow, it passes no credentials and thus denies us.

If you Google this error, you'll find lots of examples of people "solving" it by using CredSSP. This is supposed to be insecure and also requires additional configuration ahead of time.

I recently discovered a new way to solve this problem that uses session configurations. This "new" way allows you to tie a credential to a PowerShell session configuration and reuse this configuration for all future connections.

To demonstate, let's first connect to SRV1 again but this time register a session configuration on the server using a domain account.

Now I'll use this session configuration the next time I want to run a command on the remote computer that connects to a third computer.

Solving the PowerShell double hop problem with session configurations

Solving the PowerShell double hop problem with session configurations

It works without CredSSP! At this point, you can continue to use Invoke-Command at will without worrying about the multi-hop problem. Just remember to use the ConfigurationName parameter to specify the configuration you've got running under your domain account! Even better, you could just add that parameter to $PSDefaultParameterValues and have PowerShell automatically use that parameter every time you call Invoke-Command.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!

  1. Harald 2 years ago

    Hi Adam,

    did you read my mind? Thanks for this post!

    I was facing exactly that weird multi-hop issue, and I was thinking about giving that CredSSP stuff a try, when your post hit my inbox (luckily).

    One question: Is registering a PSSessionConfiguration a onetime task (persisted on the remote machine), or do I need to do it every time I create a remote session?




  2. johnM 2 years ago

    Hi.  In your second working example you are calling \\Srv2\C$, but the output example shows Srv1.

    Is that a quirk of Powershell, showing the first hop server name, and the second hop server data?   Or is this an incorrect picture?


  3. Stu 2 years ago

    Hi Adam - Thanks for this post.  Once we register the PSSessionConfiguration on the remote machine what is stopping other users from using the configurationName and potentially gaining elevated privileges?


  4. amnich 2 years ago

    By default only the administrators can use this configuration. So if you as Admin1 create a session configuration with your credentials, let's say Admin2 can also use this configuration and will act under your credentials.

    You could restrict the usage of your configuration with Set-PSSessionConfiguration only to you, but the other Admin could change it without any problems.



  5. Babun 2 years ago

    It really sounds like something you're not supposed to do..


  6. Babun 2 years ago

    Or at the very least you should maybe discuss the security implications of doing so, and how the exposure might be limited


  7. Nishanth 2 years ago

    Hey Adam, You are a life saver! I lost almost 4 days with these issue. Thanks a lot for this post.



  8. Darren 1 year ago

    Kudos to you sir.

    This post solved my multi-hop problem (trying to create Windows Failover cluster on two domain-less Win2016 servers using New-Cluster command from a remote Windows 10 client machine.

    Somebody get this man a whiskey!


    • Ashley 1 year ago

      Hi Darren, im having this issue, can you elabourate more on what you did ?


      • Darren 1 year ago

        this is the key section below that I was battling with - after I worked around the SessionConfiguration issue, then it worked. Good luck sir



  9. Simon Norton 1 year ago

    Adam I cannot tell you how much this means to me.  My whole strategy depended on using remote PowerShell sessions from SQL Server Agent Jobs.  I thought I was sunk.  Now I'm running around doing my Happy Dance!

    Thank you, thank you, thank you!

    thank you.


  10. Robert H 11 months ago

    hey Adam, thanks a lot - just as Harald already wrote : "you read my mind".

    Me, too, was searching a lot and always finding these "use CredSSP" - yeah ... isn't there a better way? how about security? how about storing passwords into files?

    thanks !


  11. Sean Lancaster 7 months ago

    So you can pass the credential object as a parameter. So you can create the session with your credential, then pass that object into the session itself and use it there.

    $cred = get-credential

    $mySession = New-PSSession -ComputerName $destinationserver -Credential $cred

    $scriptblockContent =


    $myCred = $args[0]

    $Env:ADPS_LoadDefaultDrive = 0

    import-module ActiveDirectory

    get-aduser -Filter * -SearchBase $mySearchBase -Credential $myCred


    invoke-command -Session $mySession -ScriptBlock $scriptBlockContent -ArgumentList ($cred)


Leave a reply

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


© 4sysops 2006 - 2020


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


Log in with your credentials


Forgot your details?

Create Account