I'm using WinRS to run an executable on a remote machine. That executable, in turn, needs to access a UNC network share. I'm on a Windows network with AD, and running everything as a domain admin account (not a local account) that is a machine admin of the servers in question, and has Full Control (folder and share) of the network share. But when I use WinRS to run a remote process, that remote process doesn't seem to have network access. The simplest example I could distill it down to is:
winrs -r:RedServer dir \\BlueServer\SomeSharedFolder
which gives the error
Access is denied.
Note that WinRS itself works on RedServer, because this runs fine:
winrs -r:RedServer dir C:
So, it sounds like a permissions issue, right? But to prove this account does have Full Control over the \\BlueServer\SomeSharedFolder
share, I logged into RedServer with that same account and ran this at the command prompt there:
dir \\BlueServer\SomeSharedFolder
It ran fine, giving me the contents of that folder. It's only the combination of WinRS + UNC path that causes errors.
Is there something I need to configure differently, or is this a limitation/safeguard of Windows? I experienced a similar limitation with Sysinternals' PsExec.exe; I could access anything on the target machine, but nothing on the network. Incidentally, I found a somewhat-related SO question here: "Error when creating mapped drive using winrs", but no answers there.
What you describe is a double hop scenario which requires additional configuration on the client and server to support. A double hop scenario is remotely logging in to a Windows server and then accessing a remote network share:
client -> server -> file share
You can accomplish this via CredSSP or Kerberos delegation.
While I haven't tried these instructions, they seem like a reasonable place to start. Additionally this blog post by Travis Gan appears to be helpful.