Spawning processes with administrative privileges RRS feed

  • Question

  • Hello

    I have a question. I try to build a powershell script that runs a batchfile with Robocopy on multiple servers. It uses Powershell jobs to spawn script that creates a cmd-file on each server and then try to run the cmd-file on that server. The script manages to create the cmd-file and also to start it. In the cmd-file there's a line that specifies that Robocopy should run. The logfile generated by Robocoppy says that Robocopy DOES start but gets an "Access Denied" error when it tries to connect to the destination. If I run the cmd-file manually on the server it works and CAN copy the files properly. My suspicion is that the Robocopy-cmdfile runs in a non administrative mode. But I'm not sure.

    To start the cmd-file on the server I run this command:

    $qresult = ([WmiClass]"\\$s\ROOT\CIMV2:Win32_Process").create("$cmd")

    $s holds the name of the server. And the command in $cmd is "cmd /c C:\Windows\temp\EZRoboPop\rb_local_work.cmd".

    I tried to add a whoami command to see that the cmd-file runs under the proper user, which it does.

    Robocopy writes this in it's log:

    "2018/08/07 12:26:01 ERROR 5 (0x00000005) Getting File System Type of Destination \\afsefile01\rbeztest\

    Access is denied."

    Any ideas?

    Tuesday, August 7, 2018 11:54 AM

All replies

  • Why are your using both PowerShell and a CMD file.  Just run RC from PowerSHell.

    You cannot remotely run RC if it tries to access a third computer.


    Tuesday, August 7, 2018 3:13 PM
  • I believe this is likely to be a double hop issue.  Run the command from Server A as User X  to execute local commands on Server B is not an issue (single hop).  But when you instruct Server B to access network resources such as AFSEFILE01, it is no longer passing the credentials of User X (double hop).

    The most reliable way to solve this issue is with Kerberos delegation.  But you may be able to do it with a workaround passing a Get-Credential.

    Tuesday, August 7, 2018 4:27 PM
  • No workaround and delegation is not secure unless designed into the network correctly.

    CredSSP is the PS method of on-demand delegation and can be limited by user and target.

    It may be a bit slower but just work from the source computer and reference both remotes.

    You can also schedule a task on the remote system that can access a network share.


    • Edited by jrv Tuesday, August 7, 2018 4:39 PM
    Tuesday, August 7, 2018 4:39 PM
  • CredSSP is widely regarded as insecure - I would not advise using it just because it works.
    Tuesday, August 7, 2018 5:21 PM
  • CredSSP is widely regarded as insecure - I would not advise using it just because it works.

    No. It doesn't.  Credentials are always passed encrypted.  Contents may be passed unencrypted.

    CredSSP can use SSL to encrypt everything.

    Invoke-Command -ScriptBlock $script -Authentication CredSSP -Credential $cred -UseSSL


    • Edited by jrv Tuesday, August 7, 2018 5:31 PM
    Tuesday, August 7, 2018 5:30 PM