CODEWITHSUNDEEP
powershellwmi
Bagheera
Bagheera

Reputation: 1428

Powershell: Invoke-Command Permissions Issue

Summary: Running a "get-wmiobject" on another computer works properly. But when I "invoke-command" "get-wmiobject", I get access denied.

Detail: I have a workstation (Computer-Central) at our central site, from which I run an inventory script. The inventory script loops through several "get-wmi" commands for each IP on all our remote sites. If I log onto Computer-Central as a domain admin, the script works properly.

I'm now at one of those remote sites. My current workstation is (Computer-SiteA). So I can't log into Computer-Central directly; I have to RDP in. The trouble is, the RDP session times out before the script finishes (it takes about 12 hours). So I can't RDP in, start the script, and walk away. For various reasons, making a Scheduled Task is also out.

Powershell Remoting is enabled. I logged onto Computer-SiteA with my domain admin account and ran the following command:

invoke-command -computername Computer-Central {dir c:}

This worked properly. So I kicked off the inventory script with the following command (again, run as domain admin on Computer-SiteA):

invoke-command -computername Computer-Central -filepath c:\inventory.ps1

The script started and ran overnight. But the get-wmi commands all produced "Access Denied" errors. I RDP'd into Computer-Central and ran the following command:

get-wmiobject -class win32_computersystem -property name -computername Computer-SiteB

This worked properly. I got the WMI information back.

Then I logged onto Computer-SiteA and ran the following command:

invoke-command -computername Computer-Central {get-wmiobject -class     win32_computersystem -property name -computername Computer-SiteB}

This failed with "Access Denied." I logged on as Domain Admin and even did a "Run As Different User" to make sure the PS console was open as my domain admin account.

I'm very confused by this. "Invoke-Command" should start the Powershell.exe process on the remote system with the credentials I've used on the local PC. The "get-wmiobject" command should pass the WMI query from the remote PC to the target PC, again with the same credentials. But that doesn't seem to be the case.

Any ideas?

EDIT: I ran this command to make Computer-Central query itself.

invoke-command -computername Computer-Central {get-wmiobject -class     win32_computersystem -property name -computername Computer-Central}

That worked. If I invoke "get-wmiobject" on the remote system targeting itself, it works. If I invoke "get-wmiobject" on the remote system targeting a third system, it fails. I hope this helps.

Upvotes: 5

Views: 7549

Answers (1)

x0n
x0n

Reputation: 52410

The problem is that you're using NTLM (Windows) authentication to the remote machine, and then trying to connect to another machine. This is the classic "double hop" problem: You're on machine A, authenticating to machine B and then trying to connect to machine C from B (via WMI.)

http://blogs.msdn.com/b/besidethepoint/archive/2010/05/09/double-hop-authentication-why-ntlm-fails-and-kerberos-works.aspx

It works with RDP because you're connecting from A to B using RDP and giving B your username and password (which you physically must type in for RDP.) At this point, B is able to use NTLM to connect to C. When you don't use RDP, you are connecting from A to B with NTLM and you are not allowed to then use NTLM a second time from B to C without giving your username and password again.

Thankfully PowerShell has a solution to this and it's called CredSSP authentication. It does need a bit of extra work to set up though, but once it's done you can then do what you need to do. Here's a good walkthrough:

https://blogs.technet.microsoft.com/heyscriptingguy/2012/11/14/enable-powershell-second-hop-functionality-with-credssp/

CredSSP "tunnels" your username and password over to B from A so you can authenticate with NTLM to C. You must give retype your credentials of course - it cannot determine your password from your initial login to A (likely your desktop or laptop.)

Hope this helps,

Upvotes: 3

Related Questions