Enabling Splunk as a Windows Domain User with Group Policy

Many times, we develop Windows-based apps (for example, the Splunk App for Exchange or the Splunk App for Active Directory) without special privileges. We recommend installing the Universal Forwarder on the target system with system-level privileges, which has all the necessary rights we need. Sometimes, we come across situations where we need to install Splunk with domain privileges. If you have set up WMI-based remote audit log collection, then this applies to you. Recently, we found that some of the upcoming apps needed domain privileges, so we set about researching exactly how this could be accomplished through the application of group policy in an Active Directory server. We learned that, although the process is long-winded, it is possible and makes the maintenance of many domain-enabled Splunk systems easier to manage.

We start logged in to a domain controller in the relevant domain as a Domain Admin.

1. Open up Administrative tools -> Active Directory Users & Computers.
2. Open the domain in question and select an appropriate place to put Groups.
3. Right-click on this area and select New -> Group
4. Enter the name “Splunk Service Accounts”, then click on OK
5. Right-click on the groups area again and select New -> Group
6. Enter the name “Splunk Enabled Computers”, then click on OK

You have now created two groups – one for computers that will have Splunk running as a Domain User, and the other for the service accounts that Splunk will run as. The next step is to create a suitable group policy object:

1. Open up Administrative Tools -> Group Policy Management
2. Open up domains and then your domain, then the Group Policy Object folder
3. Right-click the Group Policy Object folder and select “New”
4. Enter a new name for the group polict, for example “Splunk Permissions”, then click on OK
5. Right-click on the newly created policy object and select “Edit…”
6. Browse to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment
7. Double-click on “Act as part of the operating system”
8. Check “Define these policy settings”
9. Click on “Add User or Group”
10. Click on “Browse”
11. Enter “Splunk Service Accounts”, then click on “Check Names” (the name will be underlined)
12. Click on OK
13. Double-click on “Bypass traverse checking” and repeat steps 8-12
14. Double-click on “Log on as a batch job” and repeat steps 8-12
15. Double-click on “Log on as a service” and repeat steps 8-12
16. Double-click on “Replace a process-level token” and repeat steps 8-12
17. Browse to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Restricted Groups
18. Right-click and select “Add Group…”
19. Click on the “Add” button next to “Members of this group.”, then click on “Browse”.
20. Enter “Splunk Service Accounts”, then click on “Check Names” (the name will be underlined)
21. Enter “Domain Admins”, then click on “Check Names” (that name will also be underlined)
22. Click on OK twice to close the dialog, then close the Group Policy Editor console

You can add other permissions to this group policy. For example, if you wish to use the SA-ModularInput-PowerShell add-on, then you will want to set the execution policy for PowerShell to RemoteSigned and this can be done within this GPO. Now that we have our Group Policy object, we need to ensure it is only applied to those systems and accounts that we need. To do this, we use Security Filtering.

1. Find the group policy object you just created in the Group Policy Management console
2. Click on the group policy object to select it – the Security Filtering portion will filll the lower half of the panel.
3. Click on the “Add” button beneath “Security Filtering”
4. Enter “Splunk Enabled Computers”, then click on “Check Names” (the name will be underlined)
5. Enter “Splunk Service Accounts”, then click on “Check Names” (that name will also be underlined)
6. Click on “OK”
7. Highlight the “Authenticated Users” setting
8. Click on “Remove”

Our final preparatory step is to apply the group policy you just created to the domain. We could also place all the computers in a specific organizational unit and apply the group policy to that group, but we have limited the application of this GPO to specific computers already, so we don’t need to put in artificial organization.

1. Within the Group Policy Management console, right click on the domain and select “Link an Existing GPO…”
2. Select your group policy object and click on OK
3. Wait for the group policy to replicate everywhere

This final step – replication – can take some time depending on your Active Directory configuration. Replication needs to happen before we continue because we cannot be certain which domain controller the target systems are bound to. Normally, replication will complete within 24 hours and there are ways to force a replication if your topology is small enough. That’s it for the one-off steps. We can now move to installing a new server with domain privileges. This is a three step process. Let’s assume the computer in question is already bound to the domain. We firstly need to create a service account for running Splunk.

1. Log on to a domain controller as a Domain Admin
2. Open Active Directory Users & Computers
3. Browse to the domain and open a suitable organizational unit for the account (I use “Managed Service Accounts”)
4. Right-click on the container and select New -> User
5. Enter a suitable login ID, full name and click on Next
6. Enter a suitable password and click on Next
7. Click on Finish
8. Make a note of the username and password – you will need them later

Our second step is to enable the service account and computer to enable the GPO we created earlier.

1. Right-click on the service account you just created and select “Add to a group…”
2. Enter “Splunk Service Accounts” and click on “Check Names” (the name will be underlined)
3. Click on OK, then on OK again when the success dialog appears
4. Find the computer account for the system you are installing Splunk on. It will normally be under the “Computers” container
5. Right-click on the computer account and select “Add to a group…”
6. Enter “Splunk Enabled Computers”, then click on “Check Names” (the name will be underlined)
7. Click on OK, then on OK again when the success dialog appears

We have now added the appropriate permissions into Active Directory. All that remains is installing Splunk on the target system. I recommend rebooting the target system at this point as it will cause the computer to pick up the new permissions when it binds to the domain. When you log back into the system, log in as a local Administrator – you can use the Splunk service account you just created if you like. Finally, let’s install Splunk:

1. Use the Start->Search for the Command Prompt (enter “cmd” in the search box)
2. Right-click on the command prompt and select “Run as Administrator”
3. Change drive and directory to where the MSI installer is located
4. Run “msiexec /i splunkforwarder-*.msi” – if you need to get more specific to run the correct version, then do so.
5. When the installer asks “Local System Data” or “Remote Data”, select “Remote Data”
6. Enter the username and password for the service account you created earlier
7. Continue with the rest of the installation as normal.

Once you are completed, the SplunkForwarder service will be running with domain credentials and there should not be any errors. If you get an error at the end of the Splunk install, it will have an “ExitCode”. That’s a sure-fire indication that you left a step off, such as not waiting long enough for replication.

Of course, this isn’t the whole story. There are multiple methods of getting to this same point, but this is the one we use in our labs now. It works with an Active Directory environment based on Windows Server 2008R2 or Windows Server 2012, and we currently use Splunk Universal Forwarder version 5.0.2 internally for our development (we always use the latest version). This isn’t the whole story, but it’s a major piece of the Splunk on Windows piece. I’ll be covering other parts in future blog posts.