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.

Adam Bertram

Adam is a Microsoft Cloud and Datacenter Management Most Valuable Profressional (MVP) who specializes in Windows PowerShell. You can reach Adam at or on Twitter at @adbertram.

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.

Win the monthly 4sysops member prize for IT pros


Users who have LIKED this post:

  • avatar

Related Posts

  1. Harald 1 week 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 1 week 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 1 week 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 5 days 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 3 days ago

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


  6. Babun 3 days ago

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


Leave a reply

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



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

© 4sysops 2006 - 2018

Log in with your credentials


Forgot your details?

Create Account