Setting up WMI-access through AD & GPO

The suggested option for WMI discovery in vScope is to use a service account with sufficient reading rights. The account is protected with strong encryption and is never used for any write operations. Using a service account with sufficient rights minimizes the workload and guarantees the best results with minimal efforts.

But vScope can work with a normal user account as well. What’s important is that vScope is allowed to read WMI, and that the local firewall is not enabled. Here is how to set up a domain user-account to enable vScope to perform a discovery.

If you do not want to use a domain admin without a regular user without admin rights, you have to make a few settings on the machines to be scanned. Several of these can be done via Group Policy Objects via Active Directory, but the most important of them all (Rights for WMI namespace below) must be done manually or with a startup-script on each target machine, otherwise the user will not have access to WMI .

vScope users can contact us directly to retrieve scripts to automate the steps in this post.

Follow the examples below:

In our case we run Active Directory on Windows 2008 R2 and we want to scan the target machine which is Windows 2012 R2 machine. Our domain is called “ISL” and we name our dedicated WMI user-account “wmiuser”.

First – Setting done from Active Directory

Open the Active Directory Administrative Center:

  • Go to ISL -> Users
  • Right click and select New -> User
  • Create user as a normal user and ways User UPN logon to wmiuser@ISL.local
  • Make sure Member of is set to Domain Users so that the user is in a valid group.

1 – Create the Group Policy Object

Open the Group Policy Management:

  • Create a new GPO and name it WMI Access
  • Link it to ISL.local domain (drag and drop the it on ISL.local)
  • Make sure that the GPO will be applied to all machines in the domain to be scanned (WMI adjust Security Filtering, etc.)

2 – Settings GPO

DCOM

  • Right-click WMI Access (which is the GPO we just created), select Edit
  • Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
  • Select Properties at: DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
  • Check the Define this policy setting
  • Select Edit Security …
  • Click Add …
  • Under Enter the object names to select: Enter ISLwmiuser and click Check Names. The user is now filled in automatically
  • Click OK
  • Select wmiuser (wmiuser@ISL.local)
  • Under Permissions: Tick Allow on both Local Access and Remote Access
  • Click OK
  • Click OK
  • Select Properties under: DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
  • Check Define this policy setting
  • Select Edit Security …
  • Click Add …
  • Under Enter the object names to select: Enter ISLwmiuser and click Check Names. The user is now filled in automatically
  • Click OK
  • Select wmiuser (wmiuser@ISL.local)
  • Under Permissions: Tick Allow at Local Launch, Remote Launch, Local Activation and Remote Activation
  • Click OK
  • Click OK

Firewall

  • Right-click WMI Access (the GPO we just created), select Edit
  • Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security
  • In the right pane, expand Windows Firewall with Advanced Security until Inbound Rules visible. Right-click on it
  • Choose New Rule …
  • Select Predefined and Windows Management Instrumentation (WMI) in the list
  • Click Next
  • Tick all the Windows Management Instrumentation-rules in the list (usually 3 pieces)
  • Click Next
  • Select Allow The Connection
  • Click Finish

3 – Rights for WMI namespace

These settings can not be done with a regular GPO. For a user who is not Admin this step is critical and must be done exactly as instructed below. If not properly done, login attempts via WMI results in Access Denied.

  • Write wmimgmt.msc in command prompt
  • Right-click WMI Control, and select Properties
  • Select the Security tab
  • Select Root of the tree and click on Security
  • Click Add …
  • Under Enter the object names to select: Enter ISLwmiuser and click Check Names. The user is now filled in automatically
  • Click OK
  • Select wmiuser (wmiuser@ISL.local)
  • Select Allow for Execute Methods, Enable Account, Remote Enable and Read Security under Permissions for wmiuser
  • Mark wmiuser and click Advanced
  • Under the Permission tab: Select wmiuser
  • Click Edit
  • Under Applies To-list: Choose This namespace and all subnamespaces. It is very important that the rights are applied recursively down the entire tree!
  • Click OK
  • Click OK
  • Click OK
  • Click OK

Second – Settings done on each machine

4 – Verify

On the machines which are to be scanned by vScope, make sure that the GPO is applied. To force an update:

  • In a command prompt: type gpupdate /force
  • Ensure that the GPO is applied: Enter gpresult /r
  • Under COMPUTER SETTINGS in the printout, look for WMI Access (the GPO we created) under the Applied Group Policy Objects. If it is listed there, it means that it is applied to the machine.
  • Scan machine with vScope and enter ISL\wmiuser as username and enter the correct password
  • Verify the discovery result

5 – Additional Information

We recommend turning off UAC filtering on the target machines. It can be done by setting a registry key manually or through a GPO.

UAC can in some cases filter information through WMI so that the information is not as complete as it could be. Usually you do not need to do this step, but if information is missing, do the following on the target machine:

  • Open regedit
  • Add or edit the DWORD* key:
     HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy *to 1*
  • Close regedit

0 = Remote UAC access token filtering is enabled.
1 = Remote UAC is disabled.

2018-08-21T11:55:32+00:00