Choose the Windows user Splunk Enterprise should run as

The options for choosing the Windows user that Splunk Enterprise runs as have changed.

As of version 10.4, running Splunk Enterprise on Windows as the Local System user is no longer possible for new installations. When you upgrade Splunk Enterprise on Windows to version 10.4 and higher, the installer updates the instance to run as a non-privileged local service account unless you currently run the instance with a domain user. See Splunk has changed how you install Splunk Enterprise on Windows.

Splunk implemented this change to improve security and reduce complexity overall when installing and using Splunk Enterprise on Windows.

In general, if you currently run Splunk Enterprise in a domain user configuration, you can continue using this configuration by following the instructions in this topic.

Read on to understand further how these changes affect you and what you must do to maintain your existing user configuration during an upgrade.

Splunk has changed how you install Splunk Enterprise on Windows

These changes mean that you must adjust how you install or upgrade Splunk Enterprise on Windows.
  • There is no longer an option to install Splunk Enterprise as the Local System user for new installations. It is no longer possible to continue running the instance as the Local System user after an upgrade.
  • If you want to collect data from a Windows machine using a local administrator or domain user, install a Universal Forwarder instead. The UF lets you select the Local System user or choose a domain user. See Install a Windows universal forwarder from an installer.
    Note: It is possible to run both a Universal Forwarder and a Splunk Enterprise indexer or search head on the same machine, with the UF collecting the data and sending it to the local Splunk Enterprise instance.

  • When you upgrade an existing installation of Splunk Enterprise to versions 10.4 and higher:

    • IIf you ran the instance previously as the Local System user, it configures the instance to run as the unprivileged local service account NT SERVICE\Splunkd by default

    • If you ran the instance previously as a domain user and that user is a member of the local Administrators group, it halts the installation and directs you to perform that removal

    • If you ran the instance previously as a local service or virtual service account, it retains that configuration

User limitations for running Splunk Enterprise on Windows

These changes introduce limitations to how you can run Splunk Enterprise on Windows.

  • When Splunk Enterprise runs as the NT SERVICE\Splunkd user, the software cannot access network resources that require domain authentication. This is because the NT SERVICE\Splunkd user is a local service user and lacks the following:

    • Access Control List (ACL) permissions on network shares

    • The network privileges required to collect data remotely from other machines using Windows Management Instrumentation (WMI)

      Alternative: Install the Splunk Universal forwarder on Windows machines where you need to use domain users or local administrative access. The Universal Forwarder can still be installed as the local administrator or a domain user.

  • When Splunk Enterprise runs as a domain user, that user no longer has local administrative access to the system. You must grant the user permission explicitly to the resources to which you need it to have access.

  • For Splunk Enterprise installations where the Splunk database directory is separate from the SPLUNK_HOME directory, you must grant the NT SERVICE\Splunkd user or the domain user appropriate ACL permissions on the database directory tree. Failure to do so prevents Splunk Enterprise from accessing its databases. Use the icacls command-line utility in Windows to set the ACL permissions.

    Example:
    JSON 
    icacls {path-to-db-tree} /grant "NT SERVICE\Splunkd:(OI)(CI)(F)" /t /c

    where:

    • {path-to-db-tree} - path to the Splunk database directory

    • (OI) - Object Inherit permissions that apply to files and subdirectories.

    • (CI) - Container Inherit permissions that apply to subdirectories.

    • (F) - Assign "Full control" permissions to the resource

    • /t - Applies permissions to the target directory and all its subdirectories and files. Without /t, the command applies permissions to the target directory only.

    • /c - Instructs the command to continue on access denied errors. This option attempts to apply the permissions to all files and subdirectories in {path-to-db-tree}. If it encounters an access denied error on any file or folder, it skips that file or folder and continues processing the remaining items in the path.

The user you choose depends on what you want Splunk Enterprise to monitor

The user that Splunk Enterprise runs as determines what Splunk Enterprise can monitor. The Local System user has access to all data on the local machine by default, but nothing else. A user other than Local System has access to whatever data you want, but you must give the user that access before you install Splunk Enterprise.

About the Local System user and other user choices

The Windows Splunk Enterprise installer provides two ways to install it:

  • As the Local System user
  • As another existing user on your Windows computer or network, which you designate

To do any of the following actions with Splunk Enterprise, you must install it as a domain user:

  • Read Event Logs remotely
  • Collect performance counters remotely
  • Read network shares for log files
  • Access the Active Directory schema using Active Directory monitoring

The user that you specify must meet the following requirements. If the user does not satisfy these requirements, Splunk Enterprise installation might fail. Even if installation succeeds, Splunk Enterprise might not run correctly, or at all.

  • Be a member of the Active Directory domain or forest that you want to monitor (when using AD)
  • Be a member of the local Administrators group on the server on which you install Splunk Enterprise
  • Be assigned specific user security rights

If you are not sure which user Splunk Enterprise should run as, then see Considerations for deciding how to monitor remote Windows data in the Getting Data In manual for information on how to configure the Splunk Enterprise user with the access it needs.

User accounts and password concerns

The user that you select to run Splunk Enterprise as also has unique password constraints.

If you have a password enforcement security policy on your Windows network, that policy controls the validity of any user passwords. If that policy enforces password changes, you must do one of the following to keep Splunk Enterprise services running:

  • Before the password expires, change it, reconfigure Splunk Enterprise services on every machine to use the changed password, and then restart Splunk Enterprise on each machine.
  • Configure the account that Splunk Enterprise uses so that its password never expires.
  • Use a managed service account. See "Use managed service accounts" later in this topic.

Use managed service accounts

You can use a managed service account (MSA) to run Splunk Enterprise if you can meet all of the following conditions:

  • You run Windows Server 2008 R2 or later, or Windows 8 or later in Active Directory
  • At least one domain controller in your Active Directory runs Windows Server 2008 R2 or later

The benefits of using an MSA are:

  • Increased security from the isolation of accounts for services.
  • Administrators no longer need to manage the credentials or administer the accounts. Passwords automatically change after they expire. They do not have to manually set passwords or restart services associated with these accounts.
  • Administrators can delegate the administration of these accounts to non-administrators.

Some important things to understand before you install Splunk Enterprise with an MSA are:

  • The MSA requires the same permissions as a domain account on the machine that runs Splunk Enterprise.
  • The MSA must be a local administrator on the machine that runs Splunk Enterprise.
  • You cannot use the same account on different machines, as you would with a domain account.
  • You must correctly configure and install the MSA on the machine that runs Splunk Enterprise before you install Splunk Enterprise on the machine. See Service Accounts Step-by-Step Guide on MS Technet.

To install Splunk Enterprise using an MSA, see Prepare your Windows network for a Splunk Enterprise installation as a network or domain user.

Security and remote access considerations

Minimum permissions requirements

If you install Splunk Enterprise as a domain user, the machine that runs the instance requires that some default permissions change.

The splunkd and splunkforwarder services require specific user rights when you install Splunk Enterprise using a domain user. Depending on the sources of data you want to monitor, the Splunk Enterprise user might need additional rights. Failure to set these rights might result in a failed Splunk Enterprise installation, or an installation that does not function correctly.

Required basic permissions for the splunkd or splunkforwarder services

  • Full control over the Splunk Enterprise installation directory.
  • Read access to any files that you want to index.

Required Local/Domain Security Policy user rights assignments for the splunkd or splunkforwarder services

  • Permission to log on as a service.
  • Permission to log on as a batch job.
  • Permission to replace a process-level token.
  • Permission to act as part of the operating system.
  • Permission to bypass traverse checking.

How to assign these permissions

This section provides guidance on how to assign the appropriate user rights and permissions to the Splunk Enterprise service account before you install. For procedures, see Prepare your Windows network for a Splunk Enterprise installation as a network or domain user.

Use Group Policy to assign rights to multiple machines

To assign the policy settings to a number of machines in your AD forest, you can define a Group Policy object (GPO) with these rights, and deploy the GPO across the forest.

After you create and enable the GPO, the machines in the forest pick up the changes, either during the next scheduled AD replication cycle (usually every 1.5 to 2 hours), or at the next boot time. Alternatively, you can force AD replication by using the GPUPDATE command-line utility on the machine that you want to update Group Policy.

When you set user rights with a GPO, those rights override identical Local Security Policy rights on a machine. You cannot change this setting. To retain the Local Security Policy rights, you must assign those rights within the GPO.

Troubleshoot permissions issues

The rights described are the rights that the splunkd and splunkforwarder services require to run. The data you want to access might require that you assign additional rights. Many user rights assignments and other Group Policy restrictions can prevent Splunk Enterprise from running. If you have problems, consider using a tool such as Process Monitor or the GPRESULT command line tool to troubleshoot GPO application in your environment.