Powershell: Command Call Permissions Issue

Question

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

Details: I have a workstation (Computer-Central) on our central site from which I run the inventory script. In the inventory script, several get-wmi commands are executed for each IP address on all our remote sites. If I log on to Computer-Central as a domain administrator, the script is working correctly.

I am currently on one of these remote sites. My current workstation (Computer-SiteA). Therefore, I cannot directly enter Computer-Central; I need RDP. The problem is that the RDP session ends before the script completes (it takes about 12 hours). Therefore, I can not start RDP, run the script and leave. For various reasons, the Scheduled task is also called.

Allowed by PowerShell Remoting. I logged on to Computer-SiteA with a domain administrator account and ran the following command:

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

This worked correctly. So I released the inventory script with the following command (again, running as a domain administrator on Computer-SiteA):

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

The script runs and runs all night. But get-wmi commands all throw "Access denied" errors. I RDP'd in Computer-Central and ran the following command:

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

This worked correctly. I received WMI information.

Then I went into Computer-SiteA and ran the following command:

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

This failed using Access Denied. I registered as a domain administrator and even did “Run as user” to make sure the PS console is open as a domain administrator account.

I am very confused about this. "Invoke-Command" should start the Powershell.exe process on the remote system with the credentials that I used on the local PC. The get-wmiobject command should transfer the WMI request from the remote PC to the target computer, again with the same credentials. But this does not seem to be the case.

Any ideas?

EDIT: I ran this command to execute the computer-central request itself.

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

It worked. If I call "get-wmiobject" on the targeting of the remote system itself, it works. If I call get-wmiobject on a remote system targeting a third system, it fails. Hope this helps.

Answer 1

The problem is that you are using NTLM authentication (Windows) on the remote computer and then trying to connect to another machine. This is a classic double-hop problem: you are on machine A, authenticating on 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 connect from A to B using RDP and give B your username and password (which you must physically enter for RDP.) At this point, B can use NTLM to connect to C when you are not using RDP , you are connecting from A to B using NTLM, and you are not allowed to use NTLM a second time from B to C without again specifying your username and password.

Fortunately, PowerShell has a solution for this, and it's called CredSSP authentication. It takes a little extra work, but once you do, you can do what you need. 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 for B from A so that you can authenticate with NTLM to C. You must provide your credentials, of course - it cannot determine your password from your initial login (most likely your desktop or laptop.)

Hope this helps,