Splunk® SOAR (On-premises)

Administer Splunk SOAR (On-premises)

Acrobat logo Download manual as PDF


The classic playbook editor will be deprecated soon. Convert your classic playbooks to modern mode.
After the future removal of the classic playbook editor, your existing classic playbooks will continue to run, However, you will no longer be able to visualize or modify existing classic playbooks.
For details, see:
Acrobat logo Download topic as PDF

Manage users

View the Users page to see the users configured on your instance, add new users, or edit existing users.

Perform the following steps to access the Users page:

  1. From the Home menu, select Administration.
  2. Select User Management, then Users.

Changes to the admin user account

With the release of version 6.0, the administrator account has changed. This change was made to better support users with the user name admin in single sign on systems.

Release Administrator account name
5.5.0 and lower admin
6.0.0 and higher soar_local_admin
  • On new deployments of version 6.0.0 and higher, the administrator account is created as soar_local_admin.
  • On deployments which have upgraded from versions 5.5.0 or earlier:
    • The existing user account admin will be automatically renamed to soar_local_admin.
    • A copy of the existing user account admin will be created with the user name admin. This copy is for your convenience, and may be deleted.

Default users and types of users

On a new instance, the following default users are available:

  • Admin: This is the default admin account and cannot be disabled or deleted. The admin user is not counted towards the seat count of a seat-based license.
  • Automation: The automation user is not counted towards the seat count of a seat-based license.
  • onprem_integration: A special user account used by the Splunk SOAR Automation Broker. The onprem_integration user is not counted towards the seat count of a seat-based license.

An information card is shown for each user. For a local user the information card displays:

  • The user's full name
  • username
  • last access date and time
  • roles
  • an icon showing the user's initials or custom icon

For automation users, the information card displays a colored ribbon on the left side of the card indicating the user type.

The automation user is a default internal service account used by for running automated playbooks and asset actions, such as data ingestion. The automation user and any other users with the automation type do not have passwords and can't log into the web interface. However they do provide REST authentication tokens that can be used to read and write data to the REST API. For information on how to use the REST API and authentication tokens, see Using the REST API reference in the REST API Reference.

Customize what you see on the Users page

Customize the information you see on the Users page:

  • Select the drop-down list in the Show field to view more or fewer user cards at a time. By default, 24 user cards are shown.
  • Use the filter in the View by field to sort the users by first name, last name, username, last accessed, and last created.
  • Select the ellipsis (...) icon in the upper corner of each user card for additional options, such as viewing the user's effective permissions, editing the user, or deleting the user.

Configure user permissions

All user permissions in are derived from the user's role. To grant permissions to a user, you assign a role with the desired permission. Only the default admin user can have special, hard-coded permissions outside of any roles.

Perform the following steps to view the permissions for a user:

  1. From the Home menu, select Administration.
  2. Select User Management, then Users.
  3. Select a user card and review the permissions assigned to this user.

Users with multiple roles have the sum of all the permissions allowed by those roles.

To view the roles assigned to a user, perform the following steps:

  1. From the Home menu, select Administration.
  2. Select User Management, then Users.
  3. On the appropriate user card, select the ellipsis (...) icon, then select Edit.
    Review the roles listed in the Roles field.
  4. Select Cancel to leave this screen without making any changes.

See Manage roles and permissions in for more information about roles and the permissions provided by each role.

Add users to

You can add users to from the web interface. The user can be authenticated locally by , or by using SAML2. In the case of SAML2, the user account can be created in or created automatically during the user's initial login. In order for accounts to be automatically created, a group mapping to a role must be configured. See Configuring single sign-on authentication for .

Create a local user

Perform the following tasks to add a local user. The user is authenticated by the instance.

  1. From the Home menu, select Administration.
  2. Select User Management, then Users.
  3. Select + User.
  4. Verify that the User type is set to Local.
  5. Enter a username in the Username field.
  6. Enter a password in the Password field.
  7. Select Create.

Create a SAML2 user

Perform the following steps to add a user who is authenticated using single sign-on (SSO). Before you do this, make sure you have single sign-on enabled. See Configuring single sign-on authentication for .

  1. From the Home menu, select Administration.
  2. Select User Management, then Users.
  3. Select + User.
  4. In the User type field, select the SSO provider. Only the configured and enabled SSO providers are available to choose from.
  5. Enter the username in the Username field.
  6. Select Create.

Create an automation user in

Perform the following steps to add an automation user in :

  1. From the Home menu, select Administration.
  2. Select User Management, then Users.
  3. Select + User.
  4. In the User type field, select Automation.
  5. Enter the username in the Username field.
  6. (Optional) In the Allowed IPs field, specify the IP addresses allowed to connect as this user. You can specify individual IP addresses, CIDR ranges, or any to allow all IP addresses.
  7. (Optional) Enter a default label for this user. Any containers that get created by this user use this label if another label is not specified.
  8. (Optional) If multi-tenancy is enabled, select the default tenant in the Default Tenant field.
  9. (Optional) The Automation role is provided to automation users by default. See Manage roles and permissions in for more information about the permissions granted by each role.
  10. Select Create.

Edit an automation user to view the REST API authorization token and associated assets

Select an existing automation user on the Users page to view the following information:

  • The REST API authorization token, which is used to authenticate the user for access to the REST API. See Using the REST API reference in the REST API Reference manual.
  • The assets associated with this user.
    • The automation user is used to test connectivity with the listed assets, and also for ingesting data. Use the automation user configuration to set the permissions of the asset when the asset is running on its own.
    • When the asset is not performing test connectivity or data ingestion, it is running with the permissions of the user performing the action. If the asset is being run from a playbook, the asset has the permissions of the playbook user.
    • You can assign assets to an automation user during asset configuration. If you assigned an automation user to an asset, the asset appears in the automation user's card. See Configure automation users for a asset.

Disable an existing user

Disable a user in to prevent that user from logging in or accessing the system. Disabling a user does not delete the user account.

To disable an existing user, perform the following steps:

  1. From the Home menu, select Administration.
  2. Select User Management, then Users.
  3. Select the ellipsis (...) icon for the user you want to disable, and select Edit.
  4. Select the Disabled checkbox.
  5. Select Save.

Set security parameters

Within User Management, use the Account Security Settings to specify session timeouts and password criteria for your instance. All values are required on this page. Enter a zero (0) in any field to ignore that field.

Set your instance of to timeout, requiring the user to log in again. There are separate settings you can specify:

  • Inactivity timeout: Ends the session if no user activity is detected for the number of minutes you specify. The system checks for inactivity every 2 minutes, so specify a value greater than 2 minutes. Maximum timeout value is 35821 minutes (24 days).
  • Absolute timeout: Ends the session, regardless of level of user activity, after the number of minutes you specify. Maximum timeout value is 35821 minutes (24 days).
  • Remaining session time warning: Warn the user that they have only the specified number of minutes remaining until their session ends, due to inactivity. A value of 5 in this field means the user is warned when there are 5 minutes left in the session.

Here is an example that uses the following settings:

  • Inactivity timeout=10 minutes
  • Absolute timeout=120 minutes
  • Remaining session time warning=3 minutes

In this example, the user opens a session, works for a while, and then becomes inactive. If the user is inactive for 7 minutes, the warning appears, letting them know that the session will soon end.

  • If the user continues to be inactive, their session ends after 3 minutes.
  • If the user closes this warning message, they have become active again. The inactivity timeout is reset to 10 minutes, the original number of minutes you specified. The user can continue their session until they reach the absolute timeout value of 120 minutes from the start of their session. If the user becomes inactive again, the cycle just described occurs again, up to a maximum session length of 120 minutes from the start of the session.

Later on the Account Security Settings page, specify required password strength criteria, including password length number of special characters.

Last modified on 02 April, 2024
PREVIOUS
Use authorized users to grant authorized access
  NEXT
Manage roles and permissions in

This documentation applies to the following versions of Splunk® SOAR (On-premises): 6.2.1


Was this documentation topic helpful?


You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters