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
- Distributed Component Object Model (DCOM) Security Settings.
- WMI, Shared Service Hosts, and Authentication
- Security for WMI Client Scripts and Applications
- Related topics
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:
- Grant or deny access rights to namespaces for users using the WMI Control or when the namespace is created. For more information, see Setting Namespace Security with the WMI Control and Setting Namespace Security When the Namespace is Created.
- Use the WMI Control Security tab to establish security auditing. Security auditing results in event log entries when a user fails or succeeds in an audited action, such as writing data to a WMI object or reading the security descriptor. For more information, see Access to WMI Namespaces.
- Use the MOF file that defines the namespace to require a user to make an encrypted connection. For more information, see Requiring an Encrypted Connection to a Namespace.
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.
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.
| Topic | Description |
|---|---|
| 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