From Splunk Wiki

Enabling WMI access to Splunk for a non-administrator domain user

This page will give you step-by-step instructions on how to enable access to WMI providers for Splunk without using Administrator-level accounts in your Active Directory domain or forest.

This procedure has been confirmed to work on a Windows Server 2003 R2 Active Directory domain controller, with Windows Server 2003 R2 member servers running the Splunk service. Exact procedure steps may differ slightly if you are using Windows Server 2008, Windows 7 or Windows Vista.

Why do it this way? Why not just add the Splunk user to the appropriate Administrators groups and be done with it?

Simply put, adding the Splunk user directly to Administrator-level groups is a security risk. If you're in the testing phase, granting domain-wide access to your Splunk user may not be a big deal. In a production environment, however, corporate security guidelines are usually very strict, and failure to abide by those guidelines can have a negative impact on your enterprise, particularly if there is some sort of breach. Failure to keep your network secure can be a serious career-limiting move.

Prerequisites

Before starting out, you'll need to have the following available to you:

• Full administrator rights to the domain or forest in which you will be making the changes
• Administrator rights to all servers in your AD for which you wish to enable WMI access (or, access to someone who has these rights)
• 1.5 to 2 hours of free time (or more, depending on the size of your Windows network)

Group membership, security policy assignments and permissions

1. If you haven't create a domain account that will represent the user that Splunk will run as in your environment.

2. Create a domain group that will receive all of the rights that the Splunk user needs.

Note: Always assign permissions to a domain group, instead of directly to a user. Also, when needing to populate a group, do so with the Splunk group, instead of the Splunk user. This allows for more easily-managed security, as there is no way to enumerate a domain user's presence in local groups on member servers.

3. Put the Splunk user into this newly-created group.

4. Put the newly created Splunk group into the following domain groups:

• Performance Log Users
• Distributed COM Users

5.: Run one of the following three Microsoft Management Console (MMC) snap-ins:

• the Local Security Policy snap-in (secpol.msc) for member servers, or
• the Default Domain Security Policy snap-in (dompol.msc) if you wish to configure these settings domain-wide as a GPO, or
• the Default Domain Controller Security Settings snap-in (dcpol.msc) if you wish to assign the rights only on domain controllers.

6. Once the snap-in is started, expand Security Settings, then Local Policies, and finally User Rights Assignment.

7. Assign your new group at least the following rights:

• Act as part of the operating system
• Log on as a batch job
• Log on as a service
• Replace a process level token

8. Exit the Policy Settings utility.

Distributed Component Object Model rights assignments

Now, you must configure DCOM security for the Splunk group.

1. Run Component Services by selecting Start -> Administrative Tools -> Component Services.

2. Once there, expand Console Root, then Computers, and finally My Computer. Right-click on My Computer and select Properties...

3. In the window that appears, click on the COM Security tab.

4. Under Access Permissions, click Edit Limits.

5. Review that the Distributed COM Users group has all items checked under Allow.

6. (optional) Add the Splunk group to this list and ensure that they have full Allow access as well.

Note: This step is not required, since the Splunk group is a member of Distributed COM Users.

7. Once you've reviewed the presence of Distributed COM Users, or added the Splunk group, click OK to save your changes and be returned back to the COM Security tab.

8. Now, under "Launch and Activation Permissions", click Edit Limits.

9. Like with the "Access Permissions" window, you are presented with a list of groups and permissions. You need to make sure that the Distributed COM Users group has all items checked under Allow.

10. (optional) Add the Splunk group here, and assign full Allow access.

Note: This step is not required, since the Splunk group is already a member of Distributed COM Users.

11. Click OK to save your changes.

12. Exit the Component Services utility.

WMI namespace security assignments

Next, set WMI namespace security so that the Splunk group has access to WMI objects.

1. From the Start menu, select Run..., and in the window that opens, type in wmimgmt.msc in the "Open:" field and click OK.

2. Once there, right-click on WMI Control (Local) and click Properties.

3. Click on the Security tab.

4. Click on the Security button at the bottom right of the window. This action edits the security settings for the Root WMI namespace.

5. You'll now see a window that has the security settings for WMI on this machine. Click Advanced...

6. You'll now see the Advanced security settings for this WMI namespace. Add the Splunk group to the list, and give at least the following "Allow" permissions:

• Execute Methods
• Enable Account
• Remote Enable
• Read Security

Note: Make sure that these permissions apply to this namespace and all the namespaces under it. Do that by selecting This namespace and subnamespaces in the dropdown box above the permissions list window.

7. Click OK to save the new permissions.

8. Then, click OK again to exit out of the Advanced Security Settings.

9. Click OK a third time to exit the security properties.

Firewall changes, UAC, restarts and testing

Now that you've set WMI namespace security, you need to make sure that Windows Firewall is not blocking WMI traffic.

1. Make sure that you've either disabled or configured Windows Firewall services on both the Splunk server(s) and the server(s) you wish to get data from over WMI.

• Enabling and disabling Windows Firewall in Windows Server 2003 (TechNet)
• Enabling and disabling Windows Firewall in Windows Server 2008, Windows Vista and Windows 7 (TechNet)

Note: If you do not have permission to disable Windows Firewall/ICS on servers on your network, then you must explicitly configure it to allow WMI traffic. See your system administrator for information on how to do this.

2. If you're running Windows Server 2008, Windows Vista or Windows 7, you'll need to make changes to or disable User Account Control settings.

• Review this MSDN article on the interaction between UAC and WMI.

3. Restart Splunk on all server(s) that run it in order for the security changes above to take effect. This is required because the Splunk user logs into the domain - and only then gets a new authentication token - at service start.

After Splunk has been restarted, you should then be able to create WMI data inputs off of your remote member server or domain controller.

Troubleshooting

• Review splunkd.log in %SPLUNK_HOME%\var\log\splunk for errors encountered when defining WMI inputs. You'll only get a generic "WMI error" message in Splunk Web if something goes wrong, but splunkd.log will give you additional information as to what the cause of the error is, including the HRESULT of the offending query.

Some common errors:

• "Access is denied." (HRESULT 0x80070005): The user or group is not a member of the Performance Log Users domain group, or has not been assigned the appropriate rights in Security Policy.
• "The current user does not have permission to perform the action." (HRESULT 0x80041003): The user or group is not a member of the Distributed COM Users domain group, and needs to be.
• "Invalid class." (HRESULT 0x80041010): The selected counter or instance is not valid for the previously specified object class of WMI providers. This is not a problem with Splunk, but rather an issue with WMI. You won't get data from the selected instance, so choose a different, valid counter or instance in Splunk Web.
• "Query was not syntactically valid." (HRESULT 0x80041017): This usually happens when attempting to define an event notification query without the appropriate query keywords. Splunk Web should not generate this error.
• "Call failed." The user has not been assigned the appropriate permissions in the WMI namespace (usually, this is a result of giving the user/group access to the Root namespace, and not the namespaces under Root.)

Additional notes

• If you are configuring a non-administrator Splunk user for a large AD forest, you may need to wait a short time while AD replication takes place - up to 15 minutes - before remote queries over WMI will work.

• There's no non-esoteric way at this time to globally configure WMI security settings domain-wide. Each server in the domain has its own setting. There is an MSDN blog that lists the steps you can take to create a script that contains the appropriate security descriptors, which you can then subsequently place into a GPO as a startup script, and have your computers get the updated namespace security settings at boot time.

• If you're collecting event logs over WMI - and, in particular, the Security event log - you'll need to enable access to that log on the machine you're collecting the logs from. This is not trivial (You'll need to have knowledge of SDDL, and will additionally need to make INF file edits if you're thinking about putting it in a GPO).

--Malmoore 14:13, 13 January 2011 (PST)