5

I am gathering performance data via WMI and would like to avoid having to use an account in the Administrators group for this purpose. The target machine is running Windows Server 2003 with the latest SP/updates.

I've done what I believe to be the appropriate configuration to allow our user access to WMI (similar to what is described here: http://msdn.microsoft.com/en-us/library/aa393266.aspx).

Here are the specific steps that were followed:

  1. Open Administrative Tools -> Computer Management: Under Computer Management (Local) Expand Services and Applications, right click WMI Control and select properties. In the Security tab, expand Root, highlight CIMV2, click Security (near bottom of window); add Performance Monitor Users and enable the options : Enable Account and Remote Enable.

    2. ­
  2. Open Administrative Tools -> Component Services: Under Console Root go to Component Services-> Computers -> Right click My Computer and select properties, select the COM security tab, in “Access Permissions” click "Edit Default" select(or add then select) “Performance Monitor Users” group and allow local access and remote access and click ok. In “Launch and Activation Permissions” click “Edit Default” select(or add then select) “Performance Monitor Users” group and allow Local and Remote Launch and Activation Permissions.

    3. ­
  3. Open Administrative Tools -> Component Services: Under Console Root go to Component Services-> Computers -> My Computer -> DCOM Config -> highlight “Windows Management and Instrumentation” right click and select properties, Select the Security tab, Under “Launch and Activation Permissions” select Customize, then click edit, add the “Performance Users Group” and allow local and remote Remote Launch and Remote Activation privileges.

I am able to connect remotely via WMI Explorer but when I perform this query:

Select CommandLine, ProcessId FROM Win32_Process

I get a valid result but every row has an empty CommandLine. If I add the user to the Administrators group and re-run the query, the CommandLine column contains the expected data.

It seems there is a permission I am missing somewhere but I am not having much luck tracking it down.

Many thanks in advance.

user57935
  • 51
  • 1
  • 2

4 Answers4

2

Granting the 'debug programs' user right in the local security policy allows access to the CommandLine/ExecutablePath information. And while it is still better than using a (local) administrator account it still poses a security risk. Which is why I have posted a follow up question to see if it can be accomplished with lower priviliges here:

What are the minimal permissions for WMI access to processes CommandLine?

Community
  • 1
Basdoorn
  • 51
  • 1
  • 5
0

I don't believe this is a permissions issue but perhaps a subtlety of your query structure, and I'll explain by way of code I've created to perform just this operation (to be able to later cache the command lines).

In my CacheMyWork app's code (which you can browse here), the specific query that I issue - and which definitely returns CommandLine results - is

SELECT CommandLine FROM Win32_Process WHERE ProcessId =

I haven't used the WMI Explorer for a while, but maybe it returns the CommandLine for a single process, but not for the whole array at once? Dunno.

I've had this app available for three years, and while I don't recall at the moment the last time I tested it while running as a non-Admin user, I am 99% sure that it must work in that scenario because thousands have downloaded it and no one has yet reported that it wasn't restarting cached apps after rebooting. [Yes, I know what happens to people who ASSUME, but this hasn't stopped me from being a foolhardy assumer here.]

ParanoidMike
  • 101
  • 2
  • Maybe you could try running the CMW app (http://cachemywork.codeplex.com) as one of these unprivileged users, select a few listed apps, and then check their HKCU\...\RunOnce registry key, to see if any command lines have been cached? – ParanoidMike Oct 29 '10 at 00:39
  • Hi Mike, your answer gave me a couple of ideas that have moved things a long at least a little bit. First, I was only running the query from a remote machine via WMI explorer. I tried logging the user in via RDP and doing the same query via WMI explorer on the host and voila, CommandLine etc. all appear. What is even more bizarre, is that while I am logged in, the remote WMI query also returns the CommandLine but when I logout it goes back to being blank.. Very bizarre. Thanks for your response! – user57935 Oct 29 '10 at 18:05
0

It's a bit embarrassing to turn around my opinion on this so fully, but your follow-up comment to my first attempt makes the permissions theory sound much more convincing all of a sudden.

Windows these days has carried with it permissions that are assigned differently based on whether the requesting process is remote or local, and this stinks of the kind of behaviour I've seen when an object is ACL'd so that INTERACTIVE is allowed but REMOTE is not. When you logon via RDP, your access token will include the INTERACTIVE SID; when you perform a remote query (which uses RPC, which usually comes in over Named Pipes or straight TCP/IP), your access token doesn't include INTERACTIVE but instead REMOTE. Further, I've seen cases where two different access attempts or logon sessions end up somehow "pooling" their combined access rights, so your case of "when I am logged in, the remote WMI query also succeeds" actually makes some sense. I'd have to re-read Windows Internals to understand if the sessions, WinStations or access tokens are actually being shared, but certainly what you report is consistent with some experiences I've had.

There's no good reason why the CommandLine attribute should be ACL'd differently than the ProcessID attribute, but it sure looks like that's what's going on. Wish I knew whether this was something you could alter through deeply-embedded configuration settings, or if it's simply hard-coded in the Windows OS.

I went back through the permissions-altering steps you outlined in the original question, and there were two places where the local/remote difference seemed to show up:

  • (2) Component Services > COM Security > Launch and Activation Permissions - INTERACTIVE is granted full permissions
  • (3) Component Services > DCOM Config > Windows Management and Instrumentation > Security > Launch and Activation Permissions - both "Launch" and "Activation" provide permissions that differ whether you're Local or Remote.

I'd focus your investigations on these areas and anywhere else you happen to notice such local/remote (INTERACTIVE/REMOTE) differential permissions. While none of these definitively points to the CommandLine attribute you're after, it's nearly-certain in my mind (yes, even more certain than my previous answer) that differences like these will account for the behaviour you're seeing, and closing the gap between "remote" and "local" would enable the results you seek. [Let's just hope that Microsoft hasn't hard-coded things so that - no matter what you configure - you can't expose the CommandLine attribute to remote queries. It wouldn't be the first time a short-sighted hard-coded design has frustrated our use of their OS...]

ParanoidMike
  • 101
  • 2
0

oh sorry this is a old question, but i think this would work if anybody have a similar issue:

Please try out the following:

Instead of "Performance Monitor Users" try YOUR step 1 with "Performance LOG Users" and allow only "Execute Methods" and "Remote Enable" for the "Performance Log Users" Group. And apply the rights to "this and subordinate namespaces". And don't forget to add you User to the new group...

i had a similar problem (but other WMI-Class) and it worked with the group "Performance LOG Users" but not with "Performance Monitor Users"...

Hope this works for you too...

p.s. on win08 or higher, if think you can leave your Steps 2 or 3. But i don't know if they are needed for win03.

frupfrup
  • 853
  • 3
  • 13
  • 27