Maintaining WMI Security

WMI security focuses on protecting access to namespace data. WMI first grants access to groups of users as specified by the WMI Control and DCOM settings and then providers determine if the user should have access to namespace data.

The following sections are discussed in this topic:

Namespace Security

Namespace security depends on standard Windows user security identifiers (SID) and the security descriptor for the WMI namespace.

You can set namespace security by performing the following actions:

Distributed Component Object Model (DCOM) Security Settings.

DCOM security requires an authentication setting and an impersonation setting. Authentication means that one process identifies itself to another. Impersonation identifies the authority that a client grants a server to call different processes. During a security check, the server impersonates the client. For more information, see Securing C++ Clients and Providers or Securing Scripting Clients.

Scripts and C/C++/C# applications either establish an authentication and impersonation levels when they connect to a WMI namespace or they use the default settings. Connections to remote computers require different settings than to the WMI namespaces on the local computer. For more information, see Connecting to WMI on a Remote Computer.

WMI, Shared Service Hosts, and Authentication

WMI resides in a shared service host with several other services running under the NetworkService account. In a Svchost process, WMI shares the same authentication as the other processes in the host.

If you want to run the WMI process with a different level of authentication, you can run WMI as a separate Svchost process by using the winmgmt command with the /standalonehost switch. You supply the authentication value in the level parameter. This parameter sets the authentication level for WMI generally. You cannot use dcomcnfg.exe to change the authentication level.

Windows Server 2003:  The /standalonehost switch is not available.

Provider DLLs are loaded into separate service host processes from WMI. The HostingModel property in the __Win32Provider system class that represents a provider specifies the system account under which the provider runs. Setting this property causes the provider to be loaded into a shared host process that has a specified level of privilege. For more information, see Provider Hosting and Security.

Security for WMI Client Scripts and Applications

Scripts and applications must establish the correct security to connect to WMI namespaces on local and remote computers. For more information, see Securing C++ Clients and Providers, Securing Scripting Clients, and Securing WMI Events.

The following table lists the topics on maintaining WMI security.

TopicDescription
Securing WMI Namespaces You can limit namespace data access to authorized users through the WMI Control.
Securing Your Provider Information about writing secure providers.
Securing C++ Clients and Providers Both C++ providers and client applications must perform many of the same operations to maintain WMI security.
Securing Scripting Clients Scripts and Visual Basic applications (automation clients) must set appropriate security to get access to WMI data and events.
Securing WMI Events WMI events are delivered by the event provider to a temporary or permanent consumer. Events are delivered in the form of an instance of an event class.
Changing Access Security on Securable Objects With appropriate permissions, you can call methods on the WMI objects that represent securable objects that read or change security descriptors on securable objects.

 

Related topics

Using WMI

 

 

Show:
© 2014 Microsoft