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:
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:
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:
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:
- Axel Rivera
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.