Export (0) Print
Expand All

Securing a Remote WMI Connection

To connect to a remote computer using WMI, ensure that the correct DCOM settings and WMI namespace security settings are enabled for the connection.

Note  Content in this topic applies to computers running on Windows Vista and earlier operating systems. For more information, see Connecting to WMI Remotely Starting with Vista.

Basic remote connection between Computer A and Computer B

WMI has default impersonation, authentication, and authentication service (NTLM or Kerberos) settings that the target computer (Computer B) in a remote connection requires. Computer A may use different defaults that Computer B does not accept. For more information, see Connecting Between Different Operating Systems. You can change these settings in the connection call.

The following sections are discussed in this topic:

Setting DCOM Security to Allow a User to Access a Computer Remotely

Security in WMI is related to connecting to a WMI namespace. WMI uses DCOM to handle remote calls. One reason for failure to connect to a remote computer is due to a DCOM failure (error "DCOM Access Denied" decimal -2147024891 or hex 0x80070005). For more information about DCOM security in WMI for C++ applications, see Setting Client Application Process Security.

You can configure DCOM settings for WMI using the DCOM Config utility (DCOMCnfg.exe) found in Administrative Tools in Control Panel. This utility exposes the settings that enable certain users to connect to the computer remotely through DCOM. Members of the Administrators group are allowed to remotely connect to the computer by default. With this utility you can set the security to start, access, and configure the WMI service.

The following procedure describes how to grant DCOM remote startup and activation permissions for certain users and groups. If Computer A is connecting remotely to Computer B, you can set these permissions on Computer B to allow a user or group that is not part of the Administrators group on Computer B to execute DCOM startup and activation calls on Computer B.

Aa393266.wedge(en-us,VS.85).gifTo grant DCOM remote launch and activation permissions for a user or group

  1. Click Start, click Run, type DCOMCNFG, and then click OK.
  2. In the Component Services dialog box, expand Component Services, expand Computers, and then right-click My Computer and click Properties.
  3. In the My Computer Properties dialog box, click the COM Security tab.
  4. Under Launch and Activation Permissions, click Edit Limits.
  5. In the Launch Permission dialog box, follow these steps if your name or your group does not appear in the Groups or user names list:
    1. In the Launch Permission dialog box, click Add.
    2. In the Select Users, Computers, or Groups dialog box, add your name and the group in the Enter the object names to select box, and then click OK.
  6. In the Launch Permission dialog box, select your user and group in the Group or user names box. In the Allow column under Permissions for User, select Remote Launch and select Remote Activation, and then click OK.

The following procedure describes how to grant DCOM remote access permissions for certain users and groups. If Computer A is connecting remotely to Computer B, you can set these permissions on Computer B to allow a user or group that is not part of the Administrators group on Computer B to connect to Computer B.

Aa393266.wedge(en-us,VS.85).gifTo grant DCOM remote access permissions

  1. Click Start, click Run, type DCOMCNFG, and then click OK.
  2. In the Component Services dialog box, expand Component Services, expand Computers, and then right-click My Computer and click Properties.
  3. In the My Computer Properties dialog box, click the COM Security tab.
  4. Under Access Permissions, click Edit Limits.
  5. In the Access Permission dialog box, select ANONYMOUS LOGON name in the Group or user names box. In the Allow column under Permissions for User, select Remote Access, and then click OK.

Setting COM Security Settings for Authentication and Impersonation

You can also supply COM security settings for authentication and impersonation in parameters of the C++ calls to CoInitializeSecurity or CoSetProxyBlanket. Use CoInitializeSecurity to set the security for an entire process. Use CoSetProxyBlanket to set security on a specific proxy, such as IWbemServices, IEnumWbemClassObject, IWbemCallResult, IWbemConfigureRefresher, or IWbemObjectSink. For a list of all the C++ impersonation and authentication constants, see Setting the Default Process Security Level Using C++.

In scripts and Visual Basic, you can establish security settings in a call to SWbemLocator.Security_ after obtaining an SWbemLocator object or in the scripting moniker string. For more information about Visual Basic constants and scripting strings needed to use the moniker connection, see Setting the Default Process Security Level Using VBScript.

Allowing Users Access to a Specific WMI Namespace

You can allow or disallow users access to a specific WMI namespace by setting the "Remote Enable" permission in the WMI Control for a namespace. If a user tries to connect to a namespace they are not allowed access to, they will receive error 0x80041003. By default, this permission is enabled only for administrators. An administrator can enable remote access to specific WMI namespaces for a nonadministrator user.

The following procedure sets remote enable permissions for a non-administrator user.

Aa393266.wedge(en-us,VS.85).gifTo set remote enable permissions

  1. Connect to the remote computer using the WMI Control.

    For more information about the WMI Control, see Setting Namespace Security with the WMI Control.

  2. In the Security tab, select the namespace and click Security.
  3. Locate the appropriate account and check Remote Enable in the Permissions list.

Setting Namespace Security to Require Data Encryption for Remote Connections

An administrator or a MOF file can configure a WMI namespace so that no data is returned unless you use packet privacy (RPC_C_AUTHN_LEVEL_PKT_PRIVACY or PktPrivacy as a moniker in a script) in a connection to that namespace. This ensures that data is encrypted as it crosses the network. If you try to set a lower authentication level, you will get an access denied message. For more information, see Requiring an Encrypted Connection to a Namespace.

Windows Server 2003 and Windows XP:  Before Windows Server 2003 with Service Pack 1 (SP1), providers could not set namespace security to require encryption before returning data.

The following VBScript code example shows how to connect to an encrypted namespace using "pktPrivacy".


strComputer = "RemoteComputer"
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate," _
    & "authenticationLevel=pktPrivacy}!" _
    & "\\" & strComputer & "\root\EncryptedNamespace")

Related topics

Connecting Between Different Operating Systems
Connecting to a 3rd Computer-Delegation
Connecting Through Windows Firewall
Creating Processes Remotely
Securing C++ Clients and Providers
Securing Scripting Clients

 

 

Show:
© 2014 Microsoft