Windows PowerShell: Make the second hop
You can run into some tricky situations when Remoting with Windows PowerShell. Just be careful how many times you make the hop.
Don Jones
Windows PowerShell Remoting is an amazing way to manage multiple remote computers as easily as if you were only managing one. In a domain environment, it just works. Having said that, there are a few caveats to watch for that can really mess you up. The “second hop” is one of those.
One especially cool thing about Remoting is how well it integrates with specific Windows technologies, such as the Kerberos authentication protocol. Unlike older tools that could accept and execute remote commands, Remoting doesn’t run under some all-powerful LocalSystem account. Instead, when you connect, your Windows credential (the one with which you logged on or specified when making the connection) is delegated to the remote computer or computers.
Delegation is a native feature of Kerberos and Active Directory. It’s completely secure. Your password isn’t transmitted across the network in the clear, encrypted or otherwise. At most, it’s used as a shared encryption key.
Delegation means the remote computer’s copy of Windows PowerShell can run commands just as you do, meaning Remoting becomes security-transparent. Anything you have permission to do, you’ll be able to do remotely. If you don’t have permission, you can’t do it. Remoting is executing commands as you.
So you sit at your client computer and connect to ServerA, which is a remote machine. Your credential is delegated to that machine. From ServerA, you now initiate another connection of some kind to a third machine. That doesn’t have to be a Remoting connection. You might try to map a network drive to that third computer, access a certificate store or do anything else. You’ve just made a second hop.
The first hop was from your client to ServerA. The second is from ServerA to the other machine to which you’re trying to connect. The problem arises because your credentials can’t be delegated a second time.
That’s actually a security feature, designed to prevent your credential from being passed around without your knowledge. So your second hop operation fails, because ServerA isn’t able to send any credentials along for the ride.
In just about every Windows PowerShell class I’ve taught, there’s someone who has encountered this. It’s easy to forget you’re remoted into a machine because it’s so transparent and simple to do. So it’s easy to end up trying to remote to a third machine without realizing you’re initiating a second hop.
There’s no credential delegation, the second hop fails, you see weird error messages and everyone ends up confused. This can even happen in some instances where you only have one hop, but you try to perform an operation on the remote machine that requires a delegated credential.
The Windows PowerShell Blog post, “CredSSP for second-hop remoting,” describes what happens. It also describes the fix, which is to enable the new CredSSP authentication protocol. This has to be enabled on your client machine and any machines to which you plan to remote. You can run a command to enable it:
Enable-WSManCredSSP –Role client –DelegateComputer * Enable-WSManCredSSP –Role server
It should be obvious which one gets run on the client and which one on the server. You can also enable this protocol through a Group Policy Object (GPO) in the Windows Remote Management (WinRM) settings. You’ll also need to specify the CredSSP protocol when using Invoke-Command, Enter-PSSession, New-PSSession or any other cmdlet that utilizes Remoting.
Check out the free PDF, “A Layman’s Guide to PowerShell 2.0 Remoting,” by Ravikanth Chaganti. It includes more detail (especially in Chapter 10) on the second-hop issue and how to resolve any confusion. For example, it notes that domain controllers don’t need CredSSP in order to do the second-hop magic, because they’re configured to support it by default.
There’s a bunch of other tricky scenarios you can run into with Remoting. You could encounter non-domain computers, cross-domain connections, Remoting through a proxy server and so on. In Windows PowerShell, run help about_remote_troubleshooting to read detailed instructions for dealing with these and other scenarios. If you’re still stuck, drop me a line.
.jpg "Don Jones")
Don Jones is a Microsoft MVP Award recipient and author of “Learn Windows PowerShell in a Month of Lunches” (Manning Publications, 2011), a book designed to help any administrator become effective with Windows PowerShell. Jones also offers public and on-site Windows PowerShell training. Contact him through ConcentratedTech.com or bit.ly/AskDon.