WMI Win32_Process.Create fails with Insufficient Privs

Question

I'm trying to run a simple cmd utility on a remote Windows server from within a vbscript by invoking the Win32_Process class, like so:

serverIP = "10.0.0.3"
Set oWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & serverIP & "\root\cimv2:Win32_Process")
RunCommand = "cmd.exe /c echo hello >c:\hello.txt"
wscript.echo RunCommand
intReturn = oWMI.Create(RunCommand, Null, Null, intProcessID)  
wscript.echo intReturn
Select Case intReturn
        Case 0 Wscript.Echo "Successful"
        Case 2 Wscript.Echo "Access denied"
        Case 3 Wscript.Echo "Insufficient privilege"
        Case 8 Wscript.Echo "Unknown failure"
        Case 9 Wscript.Echo "Path not found"
        Case 21 Wscript.Echo "Invalid parameter"
        Case Else Wscript.Echo "Unable to execute for unknown reason"
End Select

This always fails with insufficient privs (return code 3).

Can anyone see what I'm doing wrong? The script is running from a cmd session invoked as a domain admin, so it should work fine, unless there's something about WMI security that I don't fully understand.

There will probably be people who suggest PSEXEC. I am aware of it and may fall back to it. But this seems like a solvable problem as is, and I'd rather not create dependencies on outside executables for this script.

I'll mention a few things I've tried.

• This fellow says there can be an issue if the profile is not loaded. I have the same problem even if the calling user (a domain admin) is logged into both systems.
• In this thread, Richard Mueller notes that one should specify both impersonationlevel=impersonate and authenticationlevel=Pkt. I tried that. Still no go.
• On this page it seems that one should specify the NT rights needed within the moniker. I have tried specifying SeInteractiveLogonRight, SeNetworkLogonRight, SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege, and SeChangeNotifyPrivilege. Nothing worked.

A common thread I have noticed in googling this, is that people are seeing this issue with some target computers but not others. So it seems to me that what's fundamentally missing is a full breakdown of the security privs one would need to accomplish this task. A lollipop will be gratefully sent to whomever can provide such a breakdown definitively!

In vain hopes it will increase viewership, I'm going to add the .net tag here, since .net folks often deal with the same WMI issues and may have insight.

Awww. Bump, this isn't going to become a tumbleweed is it?

Answer 1

Do you find more info about error at log event at server side. This help to diagnose access right fault, or try monitoring access using FileMon.

Answer 2

Check out this detailed page on MS Technet excerpted from the book "Advanced VBScript for Microsoft Windows Administrators" Specifically it is "Chapter 6: Remote Scripting By Don Jones and Jeffery Hicks" and contains details on ensuring the target device is properly configured for remote scripts.

Also check out c:\winnt\system32\WBEM\logs\wmiprov.txt I bet you're seeing something like this:

(Mon Jun 01 16:57:19 2009.2x) : ***************************************
(Mon Jun 01 16:57:19 2009.2x) : Could not get pointer to binary resource for file:
(Mon Jun 01 16:57:19 2009.2x) : C:\WINNT\system32\DRIVERS\wmiacpi.sys[MofResource](Mon Jun 01 16:57:19 2009.2x) : 
(Mon Jun 01 16:57:19 2009.2x) : ***************************************

Answer 3

Is the target machine running Vista?

Answer 4

On this page it seems that one should specify the NT rights needed within the moniker. I have tried specifying SeInteractiveLogonRight, SeNetworkLogonRight, SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege, and SeChangeNotifyPrivilege. Nothing worked.

Note if you were trying to use the privilege strings listed above (directly from the NT rights), that won't work. You should use the moniker privileges shown in table 6.8 of WMI Security Settings

(But, if you're already a domain admin and you're just trying to cmd.exe echo > file, that's almost certainly not the issue)

Answer 5

I had the similar problem. The suggestion from http://social.technet.microsoft.com/Forums/en-US/winserverManagement/thread/305557c4-df94-4d92-85bf-a049c83f120c helped me. Shortly: ensure that LOCAL SERVICE and NETWORK SERVICE accounts are granted to "Replace a process-level token" (SeAssignPrimaryTokenPrivilege).