Security for WMI in .NET Framework

  • Article

Security for WMI in .NET Framework has several aspects: WMI namespace security, DCOM security for accessing both the local and remote computers, and permissions required in .NET Framework applications when using the underlying unmanaged WMI service. For more information, see "Maintaining WMI Security" in the Windows Management Instrumentation documentation in the MSDN Library at https://msdn.microsoft.com/library.

Accessing WMI Data Securely

  • WMI namespace security
    Each WMI namespace has a security descriptor that defines the users and groups that are allowed access to the namespace data. The security descriptor is initially set to default, which allows members of the Administrators group full control both locally and remotely, and members of the Everyone, Local Service, and Network Service groups permission to read data, write data, and to run methods for providers on the local computer. The default security descriptor does not allow members of the Everyone, Local Service, and Network Service groups permission to write a new schema or install new providers. The default settings can be changed by a member of the Administrators group using the WMI Control, an MMC snap-in, available in the Control Panel. For more information, see "Setting Namespace Security" in the Windows Management Instrumentation documentation in the MSDN Library at https://msdn.microsoft.com/library. A security descriptor can also be updated programmatically. For more information, see How to: Update a Security Descriptor of a WMI Namespace.
  • DCOM security
    DCOM security primarily affects obtaining WMI data from remote computers. It requires impersonation and authentication settings. For more information on DCOM security, see "Setting Client Application Process Security," "Setting the Security on IWbemServices and Other Proxies," and "Setting Authentication in WMI" in the Windows Management Instrumentation documentation in the MSDN Library at https://msdn.microsoft.com/library.
  • .NET Framework unmanaged code access security
    The WMI service is an unmanaged component that provides access to data from different operating system sources. Managed code that consumes or provides WMI data and events must have the unmanaged code-access permission. For more information, see "Unmanaged Code" in the Windows Management Instrumentation documentation in the MSDN Library at https://msdn.microsoft.com/library.
  • Connecting Through Windows Firewall to access WMI data on a remote computer
    The Windows Firewall (formerly known as Internet Connection Firewall) service and Distributed Component Object Model (DCOM) can cause access denied errors (such as an "RPC Server Unavailable" error) when your remote computers and accounts that are used for remote connections are not properly configured. The Windows Firewall is enabled by default on Windows XP SP2 computers, but is not enabled by default on Windows Server 2003 SP1 computers. For more information, see "Connecting through Windows Firewall" in the Windows Management Instrumentation documentation in the MSDN Library at https://msdn.microsoft.com/library.

Providing Data to WMI Securely

WMI also provides the mechanisms for defining who can publish data and events into the system. The System.Management.Instrumentation classes use the decoupled provider architecture. A decoupled WMI provider lives in the process of the instrumented application and the lifetime of the provider is controlled by the application. The application is a client to WMI. A non-decoupled WMI provider is loaded and unloaded by the WMI service. For more information on options for decoupled providers, see "Provider Hosting and Security" in the Windows Management Instrumentation documentation in the MSDN Library at https://msdn.microsoft.com/library.

Decoupled providers have the following security restrictions:

  • A decoupled provider cannot impersonate the calling client by default. Calls made from WMI to a decoupled provider are typically made with an Identify impersonation level, so that the provider can identify but not impersonate the caller.
  • By default, the registration of any provider with WMI requires that the user be an administrator on the local computer. Therefore, when an instrumented application is installed, the user installing it must be an administrator to register this application as a provider.
  • The developer of an instrumented assembly can define a security descriptor that identifies the users and groups who will be allowed to publish management data and events from this assembly. In System.Management.Instrumentation, this security descriptor can be passed in Security Descriptor Definition Language (SDDL) format as an argument to the Instrumented attribute. The security descriptor is then used in the registration of the application with WMI. An administrator can change the security descriptor after the deployment of the application. For more information see, "Security Descriptor Definition Language" in the Windows Management Instrumentation documentation in the MSDN Library at https://msdn.microsoft.com/library.

By default, the following users and groups are allowed to publish data and events:

  • Administrators
  • Local System
  • Local Service
  • Network Service
  • Batch Logon

To change this default you can specify an alternate SDDL setting for your application. For more information, see the section below and How to: Update a Security Descriptor of a WMI Namespace.

Specifying Users Who Can Provide Data and Events

To change the default set of users who are permitted to either fire events or expose data from a managed application, you must change the default security descriptor that is assigned to the provider of an application. This can be done by specifying the SecurityDescriptor parameter to the instrumented assembly attribute to be:

O:BAG:BAD:(A;; 0x10000001;;;BA)(A;; 0x10000001;;;SY)
(A;; 0x10000001;;;LA)(A;; 0x10000001;;;NS)(A;; 0x10000001;;;LS)
(A;; 0x10000001;;;S-1-5-3)(A;; 0x10000001;;;S-1-5-6)

Note

For Windows 2000 operating systems, the default security descriptor is as follows:

O:BAG:BAD:(A;;0x10000001;;;BA)(A;;0x10000001;;;SY)

(A;;0x10000001;;;LA)(A;; 0x10000001;;;S-1-5-3)

(A;; 0x10000001;;;S-1-5-6)

When you grant a new user permission to provide instrumentation, you must append the ACE string of the new user to the default security descriptor. If you only specify the new security descriptor in the SecurityDescriptor parameter, the default security descriptor is overwritten. For example, to add the Power Users group to the list of permitted users and to the default SD on Windows 2000 operating systems, provide the following SDDL string:

O:BAG:BAD:(A;; 0x10000001;;;BA)(A;; 0x10000001;;;SY)
(A;; 0x10000001;;;LA)(A;; 0x10000001;;;NS)(A;; 0x10000001;;;LS)
(A;; 0x10000001;;;S-1-5-3) (A;; 0x10000001;;;S-1-5-6)(A;;0x1;;;PU)

In this string, "(A;;0x1;;;PU)" (at the end of the string) is the new ACE string for permitting members of the Power Users group to provide instrumentation. WMI requires you to have the least significant bit set (that is, 0x1) for the user rights value in an ACE string.

See Also

Concepts

More Information about WMI .NET

Send comments about this topic to Microsoft.

Copyright © 2007 by Microsoft Corporation. All rights reserved.