User Account Control and WMI
User Account Control (UAC) affects the WMI data that is returned from a command-line tool, remote access, and how scripts must run. For more information about UAC, see Getting Started with User Account Control.
The following sections describe UAC functionality:
- User Account Control
- Account Needed to Run WMI Command-Line Tools
- Handling Remote Connections Under UAC
- UAC Effect on WMI Data Returned to Scripts or Applications
- Related topics
Under UAC, accounts in the local Administrators group have two access tokens, one with standard user privileges and one with administrator privileges. Because of UAC access token filtering, a script is normally run under the standard user token, unless it is run "as an Administrator" in elevated privilege mode. Not all scripts required administrative privileges.
Scripts cannot determine programmatically whether they are running under a standard user security token or an Administrator token. The script may fail with an access denied error. If the script requires administrator privileges, then it must be run in the elevated mode. Access to WMI namespaces differs depending on whether the script is run in elevated mode. Some WMI operations, such as getting data or executing most methods, do not require that the account run as an administrator. For more information about default access permissions, see Access to WMI Namespaces and Executing Privileged Operations.
Because of User Account Control, the account running the script must be in the Administrators group on the local computer to have the ability to run with elevated rights.
You can run a script or an application with elevated rights by performing one of the following methods:
To Run a Script In Elevated Mode
- Open a Command Prompt window by right-clicking Command Prompt in the Start menu and then clicking Run as administrator.
- Schedule the script to run elevated using Task Scheduler. For more information, see Security Contexts for Running Tasks.
- Run the script using the built-in Administrator account.
To run the following WMI Command-Line Tools, your account must be in the Administrators group and the tool must be run from an elevated command prompt. The built-in administrator account can also run these tools.
The first time you run Wmic after system installation, it must be run from an elevated command prompt. The elevated mode may not be required for subsequent executions of Wmic unless the WMI operations require administrator privilege.
To run the WMI Control (Wmimgmt.msc) and make changes to WMI namespace security or auditing settings, your account must have the Edit Security right explicitly granted or be in the local Administrators group. The built-in Administrator account can also change the security or auditing for a namespace.
Wbemtest.exe, a command-line tool that is not supported by Microsoft Customer Support services, can be run by accounts that are not in the local Administrators group, unless a specific operation requires privileges that are normally granted to Administrator accounts.
Whether you are connecting to a remote computer in a domain or in a workgroup determines whether UAC filtering occurs.
If your computer is part of a domain, connect to the target computer using a domain account that is in the local Administrators group of the remote computer. Then UAC access token filtering will not affect the domain accounts in the local Administrators group. Do not use a local, nondomain account on the remote computer, even if the account is in the Administrators group.
In a workgroup, the account connecting to the remote computer is a local user on that computer. Even if the account is in the Administrators group, UAC filtering means that a script runs as a standard user. A best practice is to create a dedicated local user group or user account on the target computer specifically for remote connections.
The security must be adjusted to be able to use this account because the account never has had administrative privileges. Give the local user:
- Remote launch and activate rights to access DCOM. For more information, see Connecting to WMI on a Remote Computer.
- Rights to access the WMI namespace remotely (Remote Enable). For more information, see Access to WMI Namespaces.
- Right to access the specific securable object, depending on the security required by the object.
If you use a local account, either because you are in a workgroup or it is a local computer account, you may be forced to give specific tasks to a local user. For example, you can grant the user the right to stop or start a specific service through the SC.exe command, the GetSecurityDescriptor and SetSecurityDescriptor methods of Win32_Service, or through Group Policy using Gpedit.msc. Some securable objects may not allow a standard user to perform tasks and offer no means to alter the default security. In this case, you may need to disable UAC so that the local user account is not filtered and instead becomes a full administrator. Be aware that for security reasons, disabling UAC should be a last resort.
Disabling Remote UAC by changing the registry entry that controls Remote UAC is not recommended, but may be necessary in a workgroup. The registry entry is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy. When the value of this entry is zero (0), Remote UAC access token filtering is enabled. When the value is 1, remote UAC is disabled.
If a script or application is running under an account in the Administrators group, but not running with an elevated privilege, then you may not get all the data returned because this account is running as a standard user. The WMI providers for some classes do not return all instances to a standard user account or an Administrator account that is not running as a full administrator because of UAC filtering.
The following classes do not return some instances when the account is filtered by UAC:
The following classes do not return some properties when the account is filtered by UAC: