Article ID: 891642 - View products that this article applies to.
After you run the Microsoft System Information 7.0 (MSInfo32.exe), if you view the Application log in the Event Viewer, there may be one or more instances of the warning Event ID 63:
Note A Windows Management Instrumentation (WMI) provider is a software component that behaves as a mediator between the Common Information Model (CIM) storage component and the managed object. The provider handles data requests for the managed object and sends data from the managed object to the CIM object manager component (CIMOM).
Event Type: Warning
Event Source: WinMgmt
Event Category: None
Event ID: 63
A provider, OffProv11, has been registered in the WMI namespace, Root\MSAPPS11, to use the LocalSystem account. This account is privileged and the provider may cause a security violation if it does not correctly impersonate user requests.
For more information, see Help and Support Center at http://support.microsoft.com.
This issue occurs if the following conditions are true:
We do not recommend that you try to configure the provider to use a more restricted account, because the OffProv11 provider is already configured to use SelfHost. Additionally, the OffProv11 provider must be configured to use the LocalSystem account because the OffProv11 provider is an interactive service.
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 securityWMI 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 security
http://technet2.microsoft.com/windowsserver/en/library/089bfd2f-f476-4bfb-ad01-6768b645a2941033.mspx?mfr=trueSetting namespace security
DCOM configurationDCOM 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 processWMI 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:
The LocalSystem accountThe 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:
Article ID: 891642 - Last Review: October 9, 2011 - Revision: 4.0
Contact us for more help
Connect with Answer Desk for expert help.