Multi-hop problem of PowerShell remote machine

What is a multi-hop problem , that is, a machine remote to the B machine, and then to C machine copy or get files.

For PowerShell novice, multi-Hop problem (multi-hop) is a difficult thing, obviously winrm to remote machine no problem, the remote machine directly operation is also able to do, why two jump, will be reported access is deny and a series of problems. The most fundamental reason is to lose credential from a machine to a B machine. Many of the domestic blogs on the solution, never worked, did not mention the most critical step: Group Policy changes.
First step: Trustedhost
Because you want to connect the remote machine, the remote machine must be trusted. A very simple order to get it done.

Set-item Wsman:\localhost\client\trustedhosts-value *-force

If not added, the following error may be reported:

Step Two: CredSSP
Because the remote to the B machine lost credential, so the first thought is ENABLE-WSMANCREDSSP, the document says:

The ENABLE-WSMANCREDSSP cmdlet enables credential Security support Provider (CredSSP) authentication on a client or on A server computer. When CredSSP authentication was used, the user credentials was passed to a remote computer to be authenticated. This type of authentication was designed for commands, a remote session from another remote session. For example, if the want to run a background job on a remote computer, use this kind of authentication. The
is roughly translated as follows:
ENABLE-WSMANCREDSSP can open CredSSP authorized computer as a client or server. CREDSSP authorization allows the generation of user credentials to the authorized remote machine. This type of authorization is designed to establish a link to another remote session from one remote session. For example, when you perform a background task in a remote machine, this authorization
needs to understand, which is the server which is the client, the credential is taken from the client machine to the server machine, so do not authorize the reverse, that certainly no effect, or the above example, A is client,b for the server, and the credentials from a machine will be to the B machine. No problem. Nonsense less say, on the code.

# #当前A机器为cosdesdev1, we control the B machine Vmaosupse2 go to the UNC path of the C machine COSMOXYDEV8 read the folder List
enable-wsmancredssp-role "Client"- Delegatecomputer *-force | Out-null
$secPassword = convertto-securestring "Guguji5"-asplaintext-force
$cred = New-object system. Management.Automation.PSCredential ("Advent\axyssu", $secPassword)

invoke-command-computername Vmaosupse2- Credential $cred-scriptblock {
    enable-wsmancredssp-role "Server"-force | out-null
}
Invoke-command- ComputerName vmaosupse2-credential $cred-authentication credssp-scriptblock{
    $path = "\\cosmoxydev8\c$\Moxy\ Client "
    get-childitem-path $path
}

The resulting error is probably the following figure

From the only few English words I know, I can pick out "Group Policy" does not allow proxy users ' credentials to the target machine. Next, it's the next step and the key to success.

Step Three: Group Policy modifications
I refer to a lot of articles are not successful, because they have only made the first step, in fact, the change of Group Policy is the key. First in the panel that runs Gpedit.msc to open Group Policy, Computer Configuration (computer config)->administrative Templates (Administrator template)->system (System), Credentials Delegation (credential proxy), double-click "Allow server-only proxy NTLM credentials" (the blue one), set to "Enable", and add "*" to the Add Servers list.


Then go to Windows Servers restart WinRM servers and execute the code in the first step again to succeed.

Thank you, Tian General's guide, Tian Jin sentence "Tell you how many times than you try again"