Configure users and roles in ITSI

Splunk IT Service Intelligence (ITSI) uses the access control system integrated with the Splunk platform. The Splunk platform authorization allows you to add users, assign users to roles, and assign those roles custom capabilities to provide granular, role-based access control for your organization.

Never delete the default admin user from your Splunk instance. The admin user is necessary for many IT Service Intelligence features, such as notable event grouping in Episode Review. For more information about users, see About user authentication in the Securing Splunk Enterprise manual.

Overview of ITSI roles

Splunk IT Service Intelligence provides four default roles with predefined capabilities:

Role	Description
itoa_user	Assign this role to users who need basic read access to ITSI.
itoa_analyst	Assign this role to knowledge managers in your organization who will create glass tables, deep dives, and service analyzers and work with episodes in Episode Review.
itoa_team_admin	Create team admin roles that inherit from this role. Team admins can create and administer services, and update objects for ITSI teams to which they are assigned read/write access. This role can also create and manage notable event aggregation policies.
itoa_admin	Assign this role to ITSI administrators. Admins create teams for team administrators to administer as well as create objects in the Global team. This role is required to assign access to objects such as glass tables to other ITSI roles. Note that users with the Splunk admin role also have the itoa_admin role.

Splunk Enterprise administrators can assign users to these roles to grant an appropriate level of access to specific ITSI functions. The role to which you assign a user depends on the specific tasks the user performs inside of ITSI, and level of security access that a user requires. Because this option is not available in Splunk Cloud Platform, you can instead use use Splunk Web to create and manage roles.

You can also create custom roles. If your organization is planning to use teams to manage service-level permissions, you need to create custom roles that inherit from the provided ITSI roles. See Create custom roles for teams for information.

ITSI roles and capabilities

The following table summarizes ITSI roles, inheritance, and capabilities. For a full list of ITSI capabilities, see ITSI capabilities reference.

Role	Inherits from role	Capabilities
itoa_user	user, user_ad_user*	read services, KPIs, and entities read service templates read KPI base searches read KPI threshold templates read glass tables and write their own private glass tables read the default Service Analyzer (homeview) read deep dives read/write/delete deep dives context (drilldown from Service Analyzer or notable events) read correlation search read/write/delete notable event management state read notable events read notable event actions read team objects
itoa_analyst	itoa_user, user, power, user_ad_user*	All capabilities of itoa_user plus the following: read/write/delete glass tables read/write/delete deep dives read/write/delete saved service analyzers read/write/delete notable events read/execute notable event actions read notable event aggregation policies read/write/delete episode exports
itoa_team_admin	itoa_analyst, user, power, metric_ad_admin*	All capabilities of itoa_analyst plus the following: configure permissions read/write/delete services, KPIs, and entities read/write/delete KPI base searches read/write/delete KPI threshold templates read/write/delete correlation search read/write/delete maintenance windows read/write/delete modules read/write/delete notable event aggregation policies write/delete team objects read/write/delete episode exports
itoa_admin	itoa_team_admin, user, power, metric_ad_admin*	All capabilities of itoa_team_admin plus the following: read/write/delete service templates perform bulk import of entities and services via CSV/search read/write/delete backups and restores edit the default notable event aggregation policy read/write/delete episode exports

*The user_ad_user and metric_ad_admin roles are inherited by ITSI roles for the purposes of using anomaly detection in ITSI. Do not assign these roles to users separately.

ITSI role capabilities apply only to shared objects. Users assigned to the itoa_user role can create and manage private service analyzers, glass tables, and deep dives.

If you have the itoa_admin or itoa_team_admin role, or the capabilities of these roles, you need write access to the Global team to write and delete global objects such as service templates, entities, KPI templates, base searches, and threshold templates.

Splunk Admin capabilities and ITSI roles

Some ITSI roles inherit capabilities that are typically only available to Splunk administration roles.

The following table lists the capabilities and ITSI roles that have these capabilities:

Capability	itoa_user	itoa_analyst	itoa_team_admin	itoa_admin
edit_token_http	x	x	x	x
list_storage_passwords		x	x
list_search_head_clustering			x	x
dispatch_rest_to_indexers			x	x
list_settings			x
edit_monitor			x

Enable or disable ITSI capabilities for a role

You can enable or disable object capabilities for ITSI roles in authorize.conf in Splunk Enterprise. Because this option is not available in Splunk Cloud Platform, you can instead use use Splunk Web to create and manage roles.

1. Open or create a copy of authorize.conf in $SPLUNK_HOME/etc/apps/itsi/local/ directory.
2. In the local file, enable or disable the appropriate capabilities for ITSI-specific roles. To disable a capability, replace enabled with disabled or delete the capability from the file.

The following example shows a portion of the authorize.conf file with read_itsi_glass_table = disabled for role_itoa_user:

## ITOA Admin
## The ITOA admin role inherits itoa_analyst;power;itoa_user;user roles
## This allows users assigned to the itoa_admin role to perform all capabilities of an itoa_team_admin, itoa_analyst and itoa_user
[role_itoa_admin]
importRoles = itoa_team_admin;power;user;metric_ad_admin

edit_itsi_modules_conf = enabled

## Core dependent capabilities
# Capabilities copied from Splunk admin role to enable write permissions
list_storage_passwords = enabled

# Add capability to lookup settings (regular and search head)
# Search head configuration is used by ITSI modular inputs
list_search_head_clustering = enabled
list_settings = enabled

rtsearch = enabled

# For event management
edit_token_http = enabled

## ITSI specific/controlled capabilities

# Notable Event Rules Engine
read_itsi_notable_aggregation_policy = enabled
write_itsi_notable_aggregation_policy = enabled
delete_itsi_notable_aggregation_policy = enabled
interact_with_itsi_notable_aggregation_policy = enabled
edit_default_itsi_notable_aggregation_policy = enabled

# Set Role Based Access Control
configure_perms = enabled

# Glass Table
read_itsi_glass_table = disabled
write_itsi_glass_table = disabled
delete_itsi_glass_table = disabled
interact_with_itsi_glass_table = disabled

Create custom roles for teams

If you decide to create teams in ITSI to segment your service-level data, you must create custom roles that inherit from the standard ITSI roles. Then you can assign permissions to specific roles that correspond to specific teams. See Implement teams in ITSI for information about service-level permissions and teams.

Create a new custom role and configure the role to inherit from the itoa_team_admin role so it has the appropriate capabilities. Then assign users to each team admin role you created.

For example, the Splunk admin creates an itoa_finance_admin role to administer the Finance team. The role inherits from the itoa_team_admin. The Splunk admin then assigns the Finance team administrator to the itoa_finance_admin role.

The Finance team administrator can then create custom roles for the analysts and users on the Finance team. For example, create an itoa_finance_analyst role that inherits from the itoa_analyst role for the analysts in the Finance department. Likewise, create an itoa_finance_user role that inherits from the itoa_user role for the users in the Finance department.

The team administrator can then assign permissions to the Finance team for the itoa_finance_analyst and itoa_finance_user roles without allowing access to analysts and users from other departments.

You must configure the itoa_admin role to inherit from the custom roles you create, otherwise the itoa_admin role cannot assign permissions to the custom roles. Alternatively, use the admin role to assign permissions.

For information about creating custom roles, see About configuring role-based user access in the Securing Splunk Enterprise manual.

Using teams in conjunction with other access controls

Teams provide a more granular level of access control than the roles provided with ITSI. Teams let you restrict read/write access to services and the KPIs associated with services within ITSI views such as glass tables, deep dives, and service analyzers.

For example, a user might have permission to view a particular glass table, but if a KPI in that glass table belongs to a service in a team for which the user does not have read permission, the KPI is not displayed. Only the data related to services for which the user has read access are displayed on the glass table.

To prevent users from being confronted with widgets they cannot view in glass tables or lanes they cannot view in deep dives, keep in mind the intended audience when creating a shared glass table or deep dive and create these visualizations for a particular team.

For example, if you are creating a glass table for the Finance team, create a shared glass table that only includes services and KPIs in the Finance team or Global team and assign read/write permissions for the glass table to the Finance team roles. Then users from other teams won't try to access the glass table and get frustrated when they can't view all of the information.

See Overview of teams in ITSI for detailed information about service-level permissions and teams.