Configuring the WMI Data Provider

This how-to article will help admins to discover assets with the WMI data provider using the Asset Discovery Service. The user must have purchased the Asset Discovery Service and have it enabled in their environment.

Overview

This article describes how TeamDynamix Asset Discovery works with Windows Management Instrumentation (WMI) to collect information about Windows computers. The Asset Discovery Service will issue WMI queries using a user defined in these settings, and Windows machines that are configured to respond to WMI requests from that user will respond with their data. 

Configuring the WMI Asset Discovery Data Provider

TeamDynamix provides the following settings to configure the WMI data provider on a discovery job:

• Target Selection Type – This controls which IP addresses within the job's range are targeted by WMI. See this article for more information. 
• HTTP or HTTPS – Set this according to whether WMI uses HTTP or HTTPS in your environment. 
• Certificate Validation (HTTPS Only) – If using HTTPS, this determines whether to validate the certificates. 
• Port Number – This allows you to override the default WMI ports. Defaults to port 5985 for HTTP and port 5986 for HTTPS when not provided.
• Retry Count – The number of times to retry a query when there is a timeout or error. Defaults to 3 when not provided.
• Timeout Length – The length of time to wait for a timeout (ms). Defaults to 10000 when not provided.
• Max Concurrent Requests – The number of concurrent requests that can be sent. Defaults to 100 when not provided.
• Username – The username under which that WMI will run. 
• Password – The password for that username.

About WMI Security

By default, WMI uses HTTP as a transport protocol and encrypts all credentials and payloads. Credentials are encrypted using either Kerberos – when machines are in a domain – or NTLM – when machines are not in a domain. Payloads are encrypted using a symmetric 256-bit key algorithm. WMI also supports using HTTPS for transport. In this case, the already-encrypted WMI traffic would be encrypted again. WMI over HTTPS is more difficult to configure upfront but does provide an additional level of security by verifying the identity of the devices being discovered.

Trusted Hosts

When working with WMI, you will need to add the target machines to the trusted hosts list if you are using HTTP with IP-based discovery. Adding a trusted hosts record indicates that the scanning machine should trust the data returned via WMI from the target machine.

To get around setting trusted hosts, you need to either use HTTPS, in which the host is trusted because it presents a certificate, or Active Directory or domain-based discovery in which the host is trusted because of membership in domain.

To set trusted hosts: 

1. Open the Asset Discovery Manager on the computer where the scanner is installed. 
2. In the Utilities menu, open the WMI Tester.
3. Enter the IP addresses which should be trusted in the Trusted Hosts field. You can use an asterisk as a wildcard for a partial IP (e.g., 10.1.1.* represents 10.1.1.1 through 10.1.1.255).
4. Click Save. 

Configuring WMI

Requirements for connecting to and discovering Windows devices vary depending on whether those devices are members of a domain or not.

Regardless of domain membership, the following basic requirements must be met:

1. The Windows Remote Management (WinRM) service must be running on each discovery target or a device you want to discover. WinRM is the Microsoft implementation of the Web Services management (WS-Management) Distributed Management Task Force (DMTF) open standard and is used to transport WMI queries.
   • For devices that are not part of a domain, or if you simply do not want to involve domain group policy in discovery, see the Configuring WinRM or WMI on a Discovery Target section.
   • To enable WinRM/WMI on all devices in a domain, see the Configuring WinRM/WMI for a Domain section. 
2. If a discovery target is running a firewall, the appropriate rules to allow WinRM or WMI traffic must be configured. 
3. An account with proper WinRM or WMI permissions must be configured on each discovery target. For non-domain-joined targets, this must be a local account. For domain-joined targets, this can be a domain account or a local account. Administrative accounts automatically have the necessary permissions for discovery. If you would rather create a non-administrative account for discovery, see the Creating a Local or Domain Account for Discovery section.
4. The account under which the Discovery Service itself is running must have the proper permissions to issue remote WMI queries. This account can be configured in the same way as the account on target machines as outlined in requirement number 3 above. By default, the service is installed using the built-in local system account which already has the necessary permissions.
5. If HTTPS is going to be used for WMI transport, a certificate needs to be installed on each discovery target. This can be a certificate issued by a trusted certificate authority or a self-signed certificate. Self-signed certificates can be created using several tools including the command-line utility <code>makecert</code> and the PowerShell command <code>New-SelfSignedCertificate</code>. The Discovery Service Manager application included with the TDX Discovery Service can also be used to generate a self-signed certificate. 
6. If non-domain-joined Windows devices are to be discovered, their IP addresses or the IP address ranges that include those devices must be configured in WinRM as trusted hosts on the machine running the Discovery Service.
   This can be done by running the following command at an elevated command prompt where the IP addresses shown are examples and should be replaced with a list of IP addresses with or without wildcards:

   winrm set winrm/config/client @{TrustedHosts="192.168.1.*,10.1.0.*"}

Please note that the steps provided here offer specific approaches to configuring local hosts and domains. Windows networking or domain experts may choose alternate methods that are more appropriate for your environment.

Configuring WinRM or WMI on a Discovery Target

This section describes how to set up WinRM on discovery targets. There are different steps required depending on whether you are running WMI over HTTP or HTTPS: 

HTTP

For devices that are not part of a domain, or if you simply do not want to involve domain group policy in your setup, setting up WinRM over HTTP involves running just a single command. Run the command below from the command line as administrator on each discovery target:

winrm quickconfig

This command will start the WinRM service, set it to start automatically in the future, and configure the appropriate local firewall rules to allow WinRM traffic. For more information on configuring winrm in a non-default manner, use the following command:

winrm /?

HTTPS

To configure WinRM over HTTPS using a self-signed certificate, follow the steps below. Using a certificate issued by a certificate authority would be similar but would require installing the certificate directly instead of creating and exporting a self-signed certificate. Similarly, if you want to use the same self-signed certificate on multiple discovery targets, you will install the certificate generated by the procedure below instead of generating a new one.

1. Create and install the self-signed certificate. This can be done using the PowerShell command shown below where [name] should be replaced with the DNS name of the target or, if you want to use the same certificate for multiple targets, a name of your choosing. Note that setting the name to something other than the DNS name of the target will require that common name validation to be turned off in the Discovery Service since the name of the certificate will not match the name of the machine presenting the certificate.
   For instance:

   $cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName [name]

2. While not required, you may want to then export the certificate so it can be used on other discovery targets and/or be installed on the discovery server. To export the certificate to install on the Discovery Server, use the PowerShell command shown below where C:\temp\cert should be replaced with an existing path where the certificate file should be placed. To export the certificate to use on other discovery target machines, use the <code>Export-PfxCertificate </code> command instead.
   For instance: 

   Export-Certificate -Cert $cert -FilePath C:\temp\cert

3. Now that the certificate is installed, configure an HTTPS WinRM listener using the following command:

   New-Item -Path WSMan:\LocalHost\Listener -Transport HTTPS -Address * -CertificateThumbPrint $cert.Thumbprint

4. Finally, allow inbound HTTPS traffic to the WinRM listener as follows:

   New-NetFirewallRule -DisplayName 'Windows Remote Management (HTTPS-In)' -Name 'Windows Remote Management (HTTPS-In)' -Profile Any -LocalPort 5986 -Protocol TCP

Configuring WinRM or WMI for a Domain

The procedures for configuring WinRM or WMI for a domain differ depending on whether HTTP or HTTPS transport is to be used. Both transports require Group Policy Objects (GPOs) to be created or modified to have the WinRM service start on each member of the domain and to configure firewall rules to allow incoming WinRM or WMI traffic to each member of the domain. The way these items are configured is different between HTTP and HTTPS. Finally, if HTTPS is to be used, two additional procedures are required: distributing a certificate to each domain member and starting the WinRM HTTPS listener on each domain member.

Configure the WinRM Service to Start Automatically on All Members of the Domain (HTTP or HTTPS)

1. Launch Group Policy Management.
2. Create a new Starter GPO.

• Right-click Starter GPOs, then click New and give the GPO a name. For example, “Turn on WinRM Listener” and comment if needed.
• Right-click the created Starter GPO and click Edit. A “Group Policy Starter GPO Editor” window is shown.
• In the left navigation of the Group Policy Starter GPO Editor window, navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service.
• Double-click the policy setting Allow remote server management through WinRM.
• In the Allow remote server management through WinRM window, click the Enabled button. In the options area, put a filter for IPv4 and IPv6. For example, enter * in both the IPv4 and IPv6 text boxes and click OK.
• Close the Group Policy Starter GPO Editor window.

3. Create a new Group Policy Object.

• Right-click Group Policy Objects, then click New.
• Select a name for the GPO and select the Starter GPO created in step 2.
• Click OK.

4. Link the new Group Policy object to the domain.

• Right-click your domain name and click Link an existing GPO.
• In the Select GPO dialog window, select the GPO created in step 3.
• Click OK.

Configure Firewall Rules to Allow WinRM or WMI Traffic on All Members of the Domain (HTTP only)

1. Run the Group Policy Management Editor. This is a Microsoft Management Console (MMC) snap-in and is often accessed from Administrative Tools.
2. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security – LDAP://*>Inbound Rules.
3. In the context menu, select New Rule.
4. On the Rule Type page:

• Select Predefined, then select Windows Management Instrumentation (WMI) from the dropdown.
• Click Next.
• On the Predefined Rules page, uncheck the rule with a profile of Public, then click Next.
• Select Allow the connection.
• Click Finish.

Once you have created the rules, you can edit them to add additional restrictions if needed.

Configure Firewall Rules to Allow WinRM or WMI Traffic on All Members of the Domain (HTTPS only)

The following procedure can be used to configure firewall rules to allow WinRM or WMI traffic on all members of the domain:

1. Run the Group Policy Management Editor. The Group Policy Management Editor is an MMC snap-in and is often accessed from Administrative Tools.
2. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security – LDAP://*>Inbound Rules.
3. In the context menu, select New Rule.
4. On the Rule Type page, select Port, then click Next.
5. On the Protocol and Ports page:

• Select Specific local ports and enter 5986, then click Next.
• On the Action page, click Next.
• On the Profile page, uncheck Public then click Next.
• On the Finish page, give the rule a name, such as WinRM HTTPS, and click Finish to save the new rule.

Distribute a Certificate to Domain Members (HTTPS Only)

You can use the Domain Certificate Authority to create and distribute unique certificates to each domain member or you can distribute a single certificate to all members of the domain. For directions on how to use the Domain Certificate Authority, see the Domain Certificate Authority documentation.

The following procedure can be used to distribute a single certificate to all members of the domain:

1. Launch Group Policy Management.
2. Find an existing Group Policy Object (GPO) or create a new GPO to contain the certificate settings. Ensure that the GPO is associated with the domain, site, or organizational unit (OU) where the discovery targets reside.
3. Right-click the GPO, then click Edit.
4. In the console tree, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies, then right-click Trusted Root Certification Authorities, and then click Import.
5. On the Welcome to the Certificate Import Wizard page, click Next.
6. On the File to Import page, type the path to the appropriate certificate files (for example, \\fs1\c$\fs1.cer), and then click Next.
7. On the Certificate Store page, click Place all certificates in the following store, and then click Next.
8. On the Completing the Certificate Import Wizard page, verify the accuracy of the information that you provided, then click Finish.

Enable the WinRM HTTPS Listener on Domain Members (HTTPS Only)

By default, WinRM runs an HTTP listener only. To use HTTPS, you will need to add a new HTTPS listener on each discovery target by running the command shown below in an admin PowerShell on each target. In the command, [Thumbprint] should be replaced with the thumbprint of the certificate installed on the machine in the previous procedure.

Execute this command manually on each machine or set it up as a one-time logon script via group policy:

new-item WSMan:\localhost\Listener -Transport HTTPS -Address * -CertificateThumbprint [Thumbprint]

Creating a Local or Domain Account for Discovery

The account used by the Discovery Service to discover WMI-capable devices must be an admin account or needs to be a member of two built-in groups – the Users group and the Remote Management Users group. The process for creating a new user account varies in look-and-feel depending on the version of Windows on which you are doing it, and if you are adding a local or domain account. As a result, specific screenshots are not shown here. If you choose to create a specific user account, the Remote Management Users group must also be granted specific WMI permissions.

To grant specific WMI permissions to the Remote Management Users group:

1. Run the MMC. One way to do this would be to type mmc.exe at a command prompt.
2. From the File menu, select Add/Remote Snap-In.
3. From the Available snap-ins list, select WMI Control, then click Add.
4. Leave the Local Computer selection in the popup dialog window and click Finish.
5. Click OK.
6. Right-click on the WMI Control (Local) node in the tree, then click Properties.
7. Click on the Security tab in the popup dialog window.
8. Select CIMV2 in the tree, then click Security.
9. Click Add in the resulting security dialog and add the Remote Management Users group. This group should already exist if WinRM is running on your machine.
10. Once the group is added, click Advanced in the security dialog window.
11. In the resulting Advanced Security Settings for CIMV2 dialog window, select the Remote Management Users group in the list and click Edit.
12. From the Applies to dropdown, select This namespace and subnamespaces.
13. Click the Enabled Account and Remote Enable permissions checkboxes and uncheck any others that might be checked.
14. Click Close.
15. Click OK on all open dialog windows until you return to the MMC. Exit the MMC.