WMI Troubleshooting: Impersonation Rights

[CraigMarcho]

First published on TECHNET on Oct 16, 2007
Today we're going to take a look at an issue that is fairly common when dealing with WMI failures.  Starting with Windows XP, WMI providers are hosted in a separate process called WMIPRVSE.  Most of the time this provider host runs in the context of the Network Service Account.  In order to properly function, this account must have the rights to impersonate a client after authentication.

By default in Windows XP SP2 and Windows Server 2003, the Network Service account which resides within the SERVICE group has impersonation rights.  However, there have been more than a few occasions where we have worked with customers who found out that this right had been removed.  More often than not, the removal was due to an older group policy that was in place that did not include the Network Service account within the list of accounts / groups granted the Impersonate right.

A quick note on the SERVICE group.  This is a special group that includes all security principals that have logged on as a service.  This is not a group that is managed through the Computer Management snap-in, membership in this group is controlled by the operating system.

Resolving the problem is fairly simple - the steps to remedy the issue on a local machine are provided below.  If your problem is caused by a Group Policy within Active Directory, then the same basic steps apply:

1. Click Start , click Run , type gpedit.msc and then click OK
2. Under Local Computer Policy , expand Computer Configuration , and then expand Windows Settings
3. Expand Security Settings , expand Local Policies and then click User Rights Assignment
4. Verify that the SERVICE group is specifically granted the Impersonate a client after authentication right as shown below:

A quick note here - by default, the Default Domain and Default Domain Controller GPO's will show the impersonation right as "Not Defined"

OK, so now that we know what the problem is and how to fix it - how can we quickly identify this failure?  If the SERVICE group is missing the Impersonate right, then the following VB Script will fail with an "Access Denied" message:

set WMI = GetObject("WinMgmts:/root/cimv2")
set objs = WMI.InstancesOf("Win32_OperatingSystem")
for each obj in objs
WScript.Echo obj.GetObjectText_
next

The "Access Denied" message occurs down at the Remote Procedure Call (RPC) level when the WMI Service starts the WMIPRVSE process to retrieve instances of Win32_OperatingSystem.  Conversely, the following script will succeed when WMIPRVSE does not have to be invoked to populate instances of Win32_WMISetting:

set WMI = GetObject("WinMgmts:/root/cimv2")
set obj = WMI.Get("Win32_WMISetting=@")
WScript.Echo obj.GetObjectText_

So there you have it.  When you run into what seems like inconsistent behavior because some WMI scripts work and some don't, try the first script to see if the problem is due to a missing privilege!

Additional Resources:

• Technet: Security Identifiers

- Axel Rivera