The WMI provider subsystem runs individual providers in specific COM servers based on their required security level. Only administrators can register providers and configure their required security level, and only trusted providers should be configured to use the LocalSystem account. This Warning event behaves as an audit record to indicate that the provider is running with the permissions of the LocalSystem account.
Some of the WMI changes that are included in Windows XP SP2 are designed to help reduce issues that might occur between different hosting models when these hosting models load providers. Different hosts might include Microsoft Internet Information Services (IIS), a Windows service, or an enterprise service. To start a provider, each host starts a new process that is named WMIPRVSE. The WMIPRVSE process loads the actual provider. When you use different hosting models, the WMIPRVSE process is started by using different Windows credentials. Therefore, the provider that is loaded, such as the OffProv11 provider, tries to load Mngcli.exe to gain access to shared memory by using these different credentials.
WMI security
WMI security is based on namespace security.
The WMI infrastructure maintains a list of users who have access to a specific namespace. You can set this list by using a WMI application or by using script. You can also change namespace security by using the WMI Control component. For additional information about how to set WMI user security or about how to set WMI namespace security, visit the following Microsoft Web sites.
Setting user securitySetting namespace securityDCOM configuration
DCOM security is an authentication and impersonation setting. Authentication means that one process identifies itself to another process. Typically, authentication uses password identification. DCOM authentication levels range from "no authentication" to "per-packet encrypted authentication." Impersonation identifies the authority that a client grants a server to call different processes. During a security verification, the server impersonates the client who requests access to the particular resource. DCOM impersonation levels range from "no identification" to "full delegation."
Shared provider host process
WMI resides in a shared service host with several other services. To avoid stopping all the services when a provider fails, providers are loaded into a separate host process named Wmiprvse.exe. More than one process with this name can be running. Each process can run under a different account with different security.
The shared host can run under one of the following accounts in a Wmiprvse.exe host process:
- LocalSystem
- NetworkService
- LocalService
- LocalSystemHostOrSelfHost
The LocalSystem account
The LocalSystem account is a predefined local account that is used by the service control manager (SCM). This account is not recognized by the security subsystem. It has extensive permissions on the local computer, and acts as the computer on the network. Its security token includes the NT AUTHORITY\SYSTEM security ID (SID) and the BUILTIN\Administrators SID. These accounts have access to most of the operating system objects. The name of the account in all locales is ".\LocalSystem." The name, "LocalSystem" or "
ComputerName\LocalSystem" can also be used. This account does not have a password. If you specify the LocalSystem account in a call to the
CreateService function, any password information that you provide is ignored.
A service that runs in the context of the LocalSystem account inherits the security context of the SCM. The user SID is created from the SECURITY_LOCAL_SYSTEM_RID value. This account is not associated with any logged-on user account. This behavior has the following security implications:
- The HKEY_CURRENT_USER registry hive is associated with the default user, and not the current user. To access another user's profile, impersonate that user, and then access the HKEY_CURRENT_USER registry hive.
- This service can open the HKEY_LOCAL_MACHINE\SECURITY registry hive.
- This service presents the computer's credentials to remote servers.
- If this service starts a command prompt and runs a batch file, the currently logged-on user could stop this batch file by pressing CTRL+C. The currently logged-on user would then have access to a command prompt that is running under LocalSystem permissions.