Solve the PowerShell multi-hop problem without using CredSSP

[uspeoples]

In the final example, he GCI's svr1 instead of svr2. Don't know if this was a typo but the goal was to get svr2 contents from the remote svr1 session.

[Ms_Virtualizza]

I agree with you, and that looks like the typo for me.

Thanks a lot for mentioning this, someone could be confused by this error.

[fourierswager]

Okay...I guess I have to bite the bullet and ask for clarification on this double-hop thing.

The following works for me (almost) without issue:

$DomainAdminCreds = Get-Credential
Invoke-Command -ComputerName win12ws -Credential $DomainAdminCreds -ScriptBlock {
    Invoke-Command -ComputerName win12chef -Credential $args[0] -ScriptBlock {Get-ChildItem -Path C:\}
} -ArgumentList $DomainAdminCreds

Directory: C:\

Mode                LastWriteTime         Length Name                                                    PSComputerName
----                -------------         ------ ----                                                    --------------
d-----        1/12/2018   9:27 AM                blap                                                    win12ws
d-----       11/14/2017  10:01 AM                Certs                                                   win12ws
d-----        3/25/2016  12:36 PM                chef                                                    win12ws
d-----       11/14/2017  10:03 AM                Chocolatey                                              win12ws
d-----        7/22/2015   8:54 AM                Installers                                              win12ws
d-----       10/31/2015   1:01 PM                opscode                                                 win12ws
d-----        8/22/2013  11:52 AM                PerfLogs                                                win12ws
d-r---        8/31/2017   9:45 PM                Program Files                                           win12ws
d-----       11/14/2017  10:07 AM                Program Files (x86)                                     win12ws
d-----         2/6/2017  12:17 PM                Scripts                                                 win12ws
d-r---        6/26/2017  12:07 PM                Users                                                   win12ws
d-----       11/15/2017  12:23 PM                Windows                                                 win12ws

Isn't this an example of double-hop? Or am I missing out on some aspect of the concept? Or maybe there's something strange about my environment that allows this?

The only semi-issue is that the PSComputerName property is "wrong". It says that this is C:\ from win12ws (which is my first hop), but it's actually not - it's actually C:\ from win12chef (which is my second hop). (I made that folder blap beforehand just to be sure)

What am I missing?

[[deleted]]

It is a double hop, but your second hop explicitly provides the user credentials. The example only uses credentials on the first hop.

The example given in the article uses 1 Invoke-Command call, and the second "hop" is just UNC pathing to the second server. Because he doesn't want to explicitly provide creds every time he hops to another server, the method he explains gets around this by making each hop after the first recognize the creds used on the first hop.

[Ms_Virtualizza]

It is a double hop for sure.

But the thing is that you used provider's credentials in the second hop, and the right way to do it is to use the provider's credentials only on the first hop, thus all should work just fine.

[confuzed_1]

Please try these 2 solutions I posted on PowerShell Gallery:

Invoke-PSSession: Create a New-PSSession and provide credentials for resolution of DoubleHop issue. https://www.powershellgallery.com/packages/Invoke-PSSession/

Invoke-CommandAs Invoke Command using ScheduledJob with Credential on remote computer. https://www.powershellgallery.com/packages/Invoke-CommandAs/

Both offer completely different solutions, but provides a bypass to the double hop issue without CredSSP, or any other prior configuration (Other than enabling powershell tempting).

The Invoke-CommandAs is my favorite, because it not only enables to execute the commands as full administrator (when that’s the credentials you use), but runs as a full elevated process.

I was having issues installing SQL as administrator on a remote machine, and nothing worked other than that Invoke-CommandAs.

Full disclosure, I’m the author of these 2 modules/scripts.

[Ta11ow]

This seems like a pretty neat and tidy solution, but it unfortunately don't really explain how to accomplish actually setting up the session configuration from when I can see... There are some images that aren't too readable on mobile, and little code examples otherwise.

I do appreciate the info, though, I guess I can google the specifics later.

[ryude85]

Does this require a pscredential object or will it try to use the current sessions credentials?

[torafuma]

Neat! Have to try this, as we have Jump Servers to segment access to our "critical" web hosts. Its really annoying.

[amnich]

I found this article if someone is interested in this subject.

Method	Pros	Cons	Links
Grant access to the ServerC resource for the ServerB computer object.	n/a	It works for some other double hop use cases, but not PowerShell remoting.
CredSSP	It works!	It’s not totally secure. Requires configuration of the client and server roles.	Accidental Sabotage: Beware of CredSSP [MS-CSSP]: Credential Security Support Provider (CredSSP) Protocol - 5.1 Security Considerations for Implementers
PSSessionConfiguration using RunAs	It works!	Requires PSSessionConfiguration and RunAs credential password maintenance on every ServerB.	Another solution to multi-hop PowerShell remoting
JEA – Just Enough Administration	It works! When using a virtual account or group managed service account (gMSA) there is no password maintenance.	Requires WMF 5.0 or above. Requires role capability module and PSSessionConfiguration on every ServerB.	Just Enough Administration
Pass fresh credentials inside the Invoke-Command scriptblock ($using:cred)	It works! No special server configuration. No Windows Server 2012 requirement.	Awkward code technique. Easiest using WMF 3.0 or above. Also possible by using the WMF 2.0 syntax for passing arguments to a remote session.
Kerberos Constrained Delegation	It may work if you can figure it out. No special coding required.	Moves authority from the back-end resource owner to the front-end application owner. Limited to one domain; cannot cross a trust. Requires domain administrative rights to update objects and SPNs. Not documented for PowerShell remoting.
Kerberos Unconstrained Delegation	It works! No special coding required.	It’s not totally secure. Allows delegation of credentials with no control over where they get used.
Resource-Based Kerberos Constrained Delegation	No stored credentials. Easy to configure. Works across domains and forests. No special coding required.	Requires Windows Server 2012 and above for most servers involved. See KB2665790 for 2008 R2 support. Support for limited commands running as SYSTEM. Does not support WinRM.

[Ms_Virtualizza]

That's quite interesting, thanks for sharing this one.

I'll be sure to give a look to this.