Remotely Execute a Script that Connects to a Third Remote Computer

PROBLEM:

In BatchPatch you want to deploy a script to target computers that will connect to a third remote machine when it’s executed. That is, BatchPatch is running on computerA, your target computer where the script will run is computerB, and the script will create a connection to computerC. How do you do this in BatchPatch?

You might have noticed that if you have multiple hops involved (e.g. BatchPatch computerA remotely executes a script on target computerB [HOP1], which then establishes a remote connection to server computerC [HOP2]), you might encounter an error or unexpected failure.

The issue in the example described above occurs as a result of how authentication is handled in Windows. If you were to perform a Google search for something like double hop authentication you’ll be able to find more on this topic. Essentially the issue is that when BatchPatch authenticates from computerA to computerB, it doesn’t mean that this authentication is then able to automatically cross another hop from computerB to computerC. However, it’s actually still possible to accomplish this in BatchPatch, but there are a few things that you need to consider first.

SOLUTION:

1. Permissions: This might seem obvious, but first make sure that the account that is being used to execute the script has the necessary permissions to connect to both computerB and computerC.
2. Execution context: In BatchPatch under Tools > Settings > Remote Execution > Remote Execution Context… SYSTEM will not have access to network resources. This is by design in Windows. The SYSTEM account is a highly privileged account for the local system, but it cannot authenticate across a network. So, when BatchPatch deploys ascript to target computerB under SYSTEM, when the script actually runs on computerB it will not be able to reach any network locations, so a script that attempts to connect to a path on computerC will never be able to do so. In order for it to be able to work properly and have access to network resources, the BatchPatch remote execution context setting needs to instead be set to Elevated token + Interactive.
3. Integrated security vs alternate credentials: In addition to the remote execution context, there is a consideration regarding how you authenticate to the target computer. While we generally always recommend using integrated security for authentication whenever possible, in this double-hop scenario you’ll actually have to instead specify alternate credentials for authentication to be successful across the second hop. In the case of integrated security, when BatchPatch on computerA tries to connect to computerB to run a script that connects to computerC, it will fail because Windows doesn’t allow authentication to make that extra step from computerB to computerC after it has already allowed authentication from computerA to computerB. However, when you use alternate credentials, you get an extra hop, essentially, because those credentials are used directly on computerB to execute the script. With integrated security the first hop is to computerB and the second hop is to computerC. However, with alternate credentials it’s more like having two first hops. You can authenticate from computerA to computerB (first hop), but then the credentials can be employed directly on computerB to authenticate on computerC (also a first hop, essentially), thus allowing your script to complete successfully.