Configuring WMI permissions for a service account

This article details configuring permissions for a non-Administrator service account on Windows for discovery. The instructions in the 7.2.2 documentation were not very good but they are much improved in the 7.3 documentation so I would suggest that you use that.

There are some restrictions involved when you configure for non-Admin discovery of Windows. Those restrictions for 7.3 can be found here. Take specific note that custom servers or even application sensors that use the process argument field will not launch because the argument field is not available to a non-Admin service account.

Also with 7.3 there are auto configuration scripts that you can run on Windows that will automatically configure the system for non-Admin access. Note that these scripts require PowerShell and will not run on PowerShell versions prior to 3.0 so they won't work on Windows 2003 SE.

Tested on Windows 2003 SE SP2 and Windows 2008 R2.

Create the service account. The sensor guide states that this account must be either in the local Users group or the Domain Users group if it's a domain user. Yet in my testing the service account was added to the local 'Distributed COM Users' group.

Open the Computer Management window by running the compmgmt.msc command. Right click on WMI Control and click Properties.

In the WMI Control Properties window, click the Security tab. Then click the Security button at the bottom of the window.

Click Add button and add the TADDM discovery service account to the list of users

Ensure that the TADDM service account discovery user has each of the following access permissions enabled:

• Execute Methods
• Enable Account
• Remote Enable

Ensure that the service account has Allow privileges for This namespace and subnamespaces. With the service account selected click the Advanced button at the bottom.

With the service account selected click the Edit button. In the Apply To field set This namespace and subnamespaces. Click OK on all the open dialogs to apply.

With the limited permissions available, the WMI provider files cannot be copied on-the-fly during discovery to the target system. So you will need to copy those files to every target and run a few commands to register them. The WMI provider files can be found under $COLLATION_HOME/lib/ms/gateway on any discovery or domain server. Copy the following files to %SystemRoot%\System32\wbem folder:

• TaddmWmi.pdb
• TaddmWmi.exe
• TaddmWmi.mof
• TaddmWmi.dll

It is important to note that when these files are updated through a TADDM fixpack or upgrade, these files may need to be redeployed. Check the fixpack or upgrade readme for further instructions.

Configure DCOM by running the dcomcnfg command. Drill down to My Computer, right click and select Properties.

Click on the COM Security tab.

In the Access Permissions section, click Edit Default. Add the TADDM service account discovery user to the list and from the Permissions section, select Allow for Remote Access. Click OK.

In the Launch and Activation Permissions section, click Edit Default. Add the TADDM service account discovery user to the list and from the Permissions section, select Allow for Remote Launch and Remote Activation. Click OK.

In the Access Permissions section, click Edit Limits. If the button is greyed out then you must configure this setting using the Local Security Policy tool. Run secpol.msc to start the Local Security Policy tool. Expand Local Policies and click Security Options. Right click the policy "DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax" and choose Properties. Click Edit Security.

Select ANONYMOUS LOGON name in the Group or user names box. In the Allow column under Permissions for User, select Remote Access. Click OK.

In the Launch and Activation Permissions section, click Edit Limits. If the button is greyed out then you must configure this setting using the Local Security Policy tool. Run secpol.msc to start the Local Security Policy tool. Expand Local Policies and click Security Options. Right click the policy "DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax" and choose Properties. Click Edit Security.

Add the TADDM service account discovery user to the list and from the Permissions section, select Allow for Remote Launch and Remote Activation. Click OK.

Click OK on all open dialog windows to save the changes.

The sensor guide suggests to restart the server to make the DCOM permission changes but this shouldn't be necessary unless there is some extenuating circumstance.

TADDM 7.3 Updates to TaddmWmi.exe

In TADDM 7.3 (and perhaps one of the fixpacks for 7.2.2) the TaddmWmi.exe file was updated. In a default environment TADDM would just push the new file out to the targets during discovery time, but if you are configured for a non-Admin set up this will not work and you will have to manually upgrade the file.

As a work-around, you can use the previous TaddmWmi.exe from 7.2.2. Assuming you backed up your server files look a good boy/girl you can fetch that file and just place it under lib/ms/gateway on your discovery server(s). Don't forget to save the new TaddmWmi.exe for when you are ready to upgrade. I recommend to not rename the file when you back it up or do anything to change the last modified time on the file, it's just cleaner that way.

I have done some research into this topic and from what I can tell, the only thing that needs done to upgrade this file (which is the only one that has changed in this instance) is to just copy it to all the targets and over-write the old one. You shouldn't need to restart anything. I will include a big COA with this though, make sure you test this in your development environment before rolling out.

Troubleshooting

It can be very frustrating to troubleshoot WMI because of the lack of error feedback. 99% of the time you will just see a message like "Access Denied" and you are left to look for the needle in the haystack that is Windows security settings. Often times the best angle is to simplify and attack. With that in mind, you can take TADDM out of the picture here, assuming you have access to the Windows gateway. Download and extract the Microsoft Scriptomatic tool to the gateway. This tool allows you to script out little WMI queries easily. Run scriptomatic, select any of the WMI classes to generate a sample script. Then you can delete that and use the script below to help you test your WMI connection. This script assumes that a domain account is being used to connect. Make sure you change all the values in bold to match your environment.

' On Error Resume Next
 
Const wbemFlagReturnImmediately = &h10
Const wbemFlagForwardOnly = &h20
 
strUser = "srvcTADDM"
strPassword = "XXXXX"
strDomain = "XXX"
arrComputers = Array("XXX.ibm.com")
For Each strComputer In arrComputers
   WScript.Echo
   WScript.Echo "=========================================="
   WScript.Echo "Computer: " & strComputer
   WScript.Echo "=========================================="
 
   Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
   Set objSWbemServices = objSWbemLocator.ConnectServer(strComputer, _
       "root\cimv2", _
        strUser, _
        strPassword, _
        "MS_409", _
        "ntlmdomain:" + strDomain)
   Set colSwbemObjectSet = _
       objSWbemServices.ExecQuery("Select BuildVersion From Win32_WMISetting")
   For Each objProcess in colSWbemObjectSet
       Wscript.Echo "WMI Version: " & objProcess.BuildVersion  
   Next
Next

Click the Run button on Scriptomatic to run your script.