Enabling Multihop Remoting

Microsoft Scripting Guy, Ed Wilson, is here. Tonight is our Windows PowerShell User Group meeting in Charlotte, NC, I will be making a presentation about using Windows 8 to perform remote management, We will also be doing a Lync meeting with the Philadelphia User Group at the same time. Click the following link to join us online from 7:00 – 8:00 P.M. Eastern Standard Time: Charlotte Windows PowerShell User Group meeting.

This week we will not have our usual PowerTip. Instead we have excerpts from seven books from Manning Press. In addition, each blog will have a special code for 50% off the book being excerpted that day. Remember that the code is valid only for the day the excerpt is posted. The coupon code is also valid for a second book from the Manning collection.

When you’re remoting into a computer, don’t run Enter-PSSession from that computer unless you fully understand what you’re doing. Let’s say you work on Computer A, which runs Windows 7, and you remote into Server-R2. At the Windows PowerShell prompt, you run this:

[server-r2] PS C:\>enter-pssession server-dc4

Server-R2 is maintaining an open connection to Server-DC4, which can start to create a “remoting chain” that’s hard to keep track of, and which imposes unnecessary overhead on your servers. You may have times when you might have to do this—mainly of instances where a computer like Server-DC4 sits behind a firewall and you can’t access it directly, so you use Server-R2 as a middleman to hop over to Server-DC4. But, as a general rule, try to avoid remote chaining.

Some people refer to “remote chaining” as “the second hop,” and it’s a major Windows PowerShell “gotcha.” We offer a hint: if the Windows PowerShell prompt is displaying a computer name, you’re done. You can’t issue any more remote control commands until you exit that session and “come back” to your computer.

The following drawing depicts the second hop or “multihop” problem: You start on Computer A, and you create a PSSession connection to Computer B. That’s the first hop, and it’ll probably work fine. But, then you try to ask Computer B to create a second hop (or connection) to Computer C—and the operation fails.

The problem is related to the way Windows PowerShell delegates your credentials from Computer A to Computer B. Delegation is the process of enabling Computer B to execute tasks as if it were you, thus ensuring that you can do anything you’d normally have permissions to do—but nothing more. By default, delegation can only traverse one such “hop”—Computer B doesn’t have permission to delegate your credentials to a third computer, Computer C.

In Windows Vista, Windows 7, and Windows 8, you can enable this multihop delegation. Two steps are needed:

On your computer (Computer A in the example), run Enable-WSManCredSSP –Role Client –DelegateComputer x. You’ll replace x with the name of the computer where your credentials may be delegated. You could specify an individual computer name, but you might also use wildcard characters. We don’t recommend using * because that presents some real security concerns, but you might authorize an entire domain, for example: *.company.com.

On the server that you’re connecting to first (Computer B in the example), run Enable-WSManCredSSP –Role Server.

The changes made by the command will be applied to the computers’ local security policies; you could also manually make these changes via a Group Policy Object, which might make more sense in a large domain environment. Managing this via Group Policy is beyond the scope of this blog, but you can find more information in the Help for Enable-WSManCredSSP. Don also authored a Secrets of PowerShell Remoting Guide that covers the policy-related elements in more detail.

I agree with Robert. I have been tasked to create a PS script that needs to function in a 'double hop' scenario. I have discovered that if the source computer, destination computer or even the DC that is used for the authentication backend is not 2008 or above, CredSSP will not work. Which two of the three are in my case. I have seen posts recommending using ConvertFrom-SecureString and ConvertTo-SecureString, but to use in a 'double hop' scenario you must use a 'key' parameter. In which case you would have the lock with the key so to speak, and you might as well be using plain text at that point.

I think I’ve found another way to do the multi-hop remoting that I think should work for any transport. It uses the RunAsCredential property of the PowerShell session configuration on the intermediate machine:

Why, whenever the issue of multi-hop comes up is CredSSP the only solution given? There is another solution that is equally valid (it seems to me), works on a broader set of platforms (for instance Win2003) and might already be part of your current IT infrastructure. AD Credential Delegation (Kerberos delegation). Yes, there are caveats and security concerns (there is with everything) — by why is CredSSP treated as the ONLY way to do this? I would really like to see a comparison article that articulates the steps, pros & cons of using Kerberos delegation to accomplish multi-hop for powershell remoting scenarios.

FOR GODS FREAKING NAME I HAVE SEARCHED FOR THIS FOR MONTHS. i could not find anything because i was not searching for chaining or second hop. Think you can add some more tags so people can find this easier? Like powershell loop session, starting a powershell
session inside another powershell session and other more generic explanations.