Executing a script remotely on non-domain Target from server on Domain
I am stuck with a very specific problem:
1. Driver script on a Server in organization domain – uses delegated creds based on user login
2. Target VM – not on organization domain – different local credentials that need to be passed
3. Shared network drive with data that should be accessible to '2' – same credentials as '1'
What I need to do:
1. Trigger Driver script from Server that is on domain
2. Revert the Target VM to some existing snapshot (using PowerCLI)
3. Map a drive on Target VM – using the domain related credentials
4. Execute some powershell scripts placed on shared network drive (this internally accesses some .dat and .bin files on the same location)
I am unable to connect to the Target VM with Invoke-Command to execute the drive map script.
Error: WinRM cannot process the request. The following error with errorcode 0x8009030e occurred while using
Negotiate authentication: A specified logon session does not exist. It may already have been terminated.
-Kerberos accepts domain user names, but not local user names.
But I do not have any domain user names, as the VM is not on domain
What I have tried:
1. Invoke-Command with script path in ScriptBlock
3. Adding the drive map as a startup script on logon – this however does not work unless I manually login to Target VM after each snapshot revert
1. PSRemoting is enabled on both driver and target VMs
2. The IPs are added as trusted hosts on both
3. WinRM is configured to process requests
4. ExecutionPolicy is Unrestricted
5. Firewall disabled
Will be wonderful if anyone can help me with this!
Well I can tell you why but not sure how much it will help.
This is basically a "double hop" issue, where you are first remoting to one computer and trying to remote to another computer from there. It doesn't matter if it's just mapping a network drive or using Invoke-Command, if you need credentials it's considered remoting. You can't even "remote" to your own computer (say via a PSSession) and connect to another computer from that, at least not easily.
The reason for this is security. To be honest I don't fully understand the technicalities behind it but it basically won't allow you to send credentials to the remote computer in case it is being impersonated. There is a ton of stuff required to allow this and at the end of the day it will only allow you to use Invoke-Command, not copy items or use network paths.
Rather than adding it as a logon script, you are better off creating a Scheduled Task to run "At Startup". This will run before you even log in. Set the Action to run PowerShell.exe and set the Arguments to -File C:\Scripts\MyStartupScript.ps1 or wherever your script is held (use absolute path), you can use arguments and even semicolons to run multiple lines of code, though you are limited to I think 256 characters.
You must be logged in to reply to this topic.