Collecting and managing data remotely via WMI

WMI seems to be a good method to remotely collect Microsoft Windows events and data in an agent-less way. So, as remote access configuration is a bit tricky, i wanted to explain how I've done it from a Debian box using wmic (a wmi client implementation). Also, as it is interesting as well, I have done brief explanations on how to manage WMI namespaces security and how to explore WMI classes.

It's fair to mention that most of the steps described below have been found in the Internet (references are listed at the end of the guide). So I have just put it all together as, at least for me, it makes much more sense this way.

In this case my scenario is composed by two different boxes:

• Microsoft Windows XP SP2: Data source
• Debian Linux: Data collector

1.- Creating a user for remote WMI access.

First step is creating a new limited user, so we don't need to use an administrator account for remote connections. This makes the installation much more secure, but of course the same configuration would work for administrators.
In this case, as an example, I have created the following limited user:

• Name: wmiuser
• Password: wmi

Once this is done, then we need to configure DCOM settings to allow our user to access the computer remotely. This is perfectly described at http://msdn.microsoft.com/en-us/library/aa393266(VS.85).aspx. Nevertheless, to sum up, there are two main points, explained below:

1. Grant DCOM remote launch and activation permissions for our user.
2. Grant DCOM remote access permissions

2.- Grant DCOM remote launch and activation permissions for our user.

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 to add our "wmiuser" user:
   
   1. In the Launch Permission dialog box, click Add.
   2. In the "Select Users, Computers, or Groups" dialog box, add your name in the "Enter the object names to select" box, and then click OK.
6. In the Launch Permission dialog box, select our user in the "Group or user names" box. In the Allow column under Permissions for User, select Remote Launch, Local Activation and Remote Activation, and then click OK.

3.- 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.

4.- Allowing remote administration at Windows firewall.

At this point we have already done the hard part. Now we just need to go ahead allowing remote administration in the Windows firewall. This is needed as when querying WMI, we are going to execute an asynchronous call, so we need to add an exception for it. This all is done executing the following from the command line:

C:\> netsh firewall set service RemoteAdmin enable

5.- For Windows XP and 2003 only: Relaxing the security policy.

Sharing and security model is set to "Guest only" on Windows XP Pro and Windows 2003, so we must to make sure that remote logons are not being coerced to the "Guest" account (this is enabled by default on computers that are not attached to a domain). To do this, open the Local Security Policy editor (e.g. by typing 'secpol.msc' into the Run box, without quotes). Expand the "Local Policies" node and select "Security Options". Now scroll down to the setting titled "Network access: Sharing and security model for local accounts". If this is set to "Guest only", change it to "Classic" and restart the computer.


6.- Querying WMI locally.

At this point your system should be ready to be queried. So you don't need to do any further configuration and we can start playing a little bit. So we can test access this way:

1. Click Start -> Run and type wbemtest. The wbemtest application starts.
2. Click Connect and type \root\cimv2, replacing with the name of the remote server. Click Connect. If you are unable to connect, there is a problem with the authentication between the machines.
3. If you are able to connect, click Query and type select * from win32_service. Click Apply. After a short wait, you should see a list of running services. If this does not work, then the authentication works, but the user is running as does not have enough privileges to run that operation.

7.- Querying WMI remotely from a Debian box.

Using Debian packages manager, "apt-get", I have installed "wmi-client" in my box. It includes a DCOM/WMI client implementation, allowing us to query our Windows box remotely. That can be done using "wmic" command with the following syntax:

# wmic -U wmiuser%wmi --namespace='root\cimv2' //windows_ip_address "select * from Win32_Process"

Of course, "windows_ip_address" should be replaced by the real IP address of your Windows host. One of the resulting events (the one related to the System Idle Process) looks like this:

System Idle Process|(null)|Win32_Process|(null)|Win32_ComputerSystem|WINDOWS-DB0B159|System Idle Process|(null)|0|0|0|(null)|692341250000|0|0|System Idle Process|Win32_OperatingSystem|Microsoft Windows XP Professional|C:\WINDOWS||0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|(null)|(null)|1|0|0|5.1.2600|28672|0|0

8.- Managing WMI namespaces security.

It's also very interesting to mention you can set permissions for each WMI namespace, using wmimgmt.msc tool. In this tool, you can set security that is based off of the root or select individual namespaces. You can also use inheritance that is based on namespace hierarchy.

For example, in case we want to set permission for our "wmiuser" we would open "WMI Control (Local) Properties) and, once selected a namespace, click on "Security" adding our user.


9.- Exploring WMI classes.

Browsing in the Internet I have found "WMI Explorer" which is a useful tool if you want to explore the full set of WMI management classes, objects and their properties. It can be found at the following website:
http://www.ks-soft.net/hostmon.eng/wmi/index.htm

Once you download and run it you will see an easy to use interface that allows you not only to explore the WMI classes but also to execute anny WQL query and view the result set. Playing a little bit with it will give you an idea of how powerful WMI is, and how many different ways you can use it for your own profit. In my case, those will be mainly related to applications inventory.


10.- Where to find more information.

As mentioned at the beginning most of this guide is based on documentation found somewhere in the Internet, so here is a list of useful links where you can find more detailed documentation about issues discussed here:

• WMI documentation: http://msdn.microsoft.com/en-us/library/aa394582(v=VS.85).aspx
• Configuring and securing a remote WMI connection: http://msdn.microsoft.com/en-us/library/aa393266(VS.85).aspx
• Examples: http://msdn.microsoft.com/en-us/library/aa394585(v=VS.85).aspx
• Troubleshooting: http://www.10-strike.com/networkinventoryexplorer/help/wmi.shtml
• WMI Explorer homepage: http://www.ks-soft.net/hostmon.eng/wmi/index.htm