Managing roles

Roles overview

In the context of Tanium™ role-based access control (RBAC), a role assigns grant permissions to specify allowed activities, or deny permissions to specify prohibited activities. You assign roles to the personas of users and user groups to control what users can see and do in the Tanium system.

If you plan to import users and user groups from a Lightweight Directory Access Protocol (LDAP) or Active Directory (AD) server, do so before configuring or assigning roles. For details, see Integrating with LDAP servers.

The Tanium implementation of RBAC supports the following role types:

Advanced roles

Advanced roles grant or deny content set permissions, which control access to sensors, packages, saved questions, and other types of content.

Micro admin roles

Micro admin roles grant or deny permissions that control access to system administration functions of the Tanium Server, such as the Administration > Management > Client Status page or API token requests.

Module roles

Module roles grant Tanium solution module permissions, which control access to module workbenches and features. Module roles also grant permissions for module-specific content sets. Module roles do not have deny roles. Users who do not have a role that grants module access cannot access the module workbench or features. Some module permissions automatically enable additional provided permissions. For example, if you select the Patch Module Write permission in a module role, it automatically provides the Ask Dynamic Questions permission.

Reserved roles

The predefined reserved roles assign permissions that enable special-purpose capabilities, such as using the Administration > Configuration pages. These special permissions are not available to non-reserved roles. In addition to the special permissions, reserved roles can have some or all of the permissions associated with advanced, micro admin, and module roles.

The following figure shows the configurable components of the different role types, and the order in which you assign them.

Figure  1:  Role configurations

For an overview of how roles relate to other RBAC configuration objects such as content sets, personas, users, user groups, and computer groups, see Tanium RBAC implementation and concepts.

Roles have a many-to-many relationship with users and user groups. For example, all Tanium Interact users can have the Interact Show module role, and each of those users can have additional advanced roles that provide access to the sensors and questions that they use in Interact. Similarly, you can configure permissions for the same content set across multiple roles, and each role can specify permissions across multiple content sets.

As a best practice when configuring roles, take full advantage of their modularity and cumulative effect on user permissions. For example, instead of creating a single role with all the permissions that a particular user needs, and creating another role with only slightly different permissions for another user, create several roles with smaller but unique permissions sets. You can then mix and match these minimalistic roles among various users to achieve the same effective permissions as individual roles that have comprehensive permissions. For details, see Effective role permissions.

Roles that assign write permissions, such as Write Package, implicitly assign read permissions, such as Read Package. For details, see Implied role permissions.

Users inherit roles from the user groups to which you assign those users. For details, see Inherited roles.

For a given Tanium Console session, only the permissions of the currently selected persona are available to a user, even if multiple personas are assigned to that user. For details, see Managing personas.

To add, edit, or delete roles, you must have the Administrator or Content Set Administrator Admin reserved role, or a custom role with the Permission Administrator permission administrator or content set administrator permissions. However, a Content Set Administrator cannot manage the assignment of personas or reserved roles to users and user groups.

Roles do not control access to computer management groups (see Managing computer groups) or action groups (see Managing action groups).

Grant and deny roles

You can assign multiple grant and deny roles to the personas of a user or user group. The Tanium system bases the effective permissions of a persona on the cumulative effect of all the roles assigned to it: all permissions granted or implied, minus those explicitly denied. For details, see Effective role permissions.

In advanced roles, the permission and content set in the deny role must match the permission and content set in the grant role to effectively negate the grant permission. In this example, the deny Write Sensor permission on Content Set A matches the grant Write Sensor permission on Content Set A, so the grant permission is negated.

Figure  2:  Grant and deny roles on content set permissions (match)

In the following example, the deny Write Sensor permission on Content Set D does not match any grant permissions, so it has no impact on Erin’s effective permissions.

Figure  3:  Grant and deny roles on content set permissions (no match)

When you assign content sets to permissions in advanced roles or module roles, the Add all Content Sets that exist or will exist to the permissions option is equivalent to listing each and every content set. In this case, the deny Write Sensor permission on Content Set D has effect.

Figure  4:  Add All Content Sets option

Grant and deny micro admin roles follow the same rules as advanced roles. In the following example, Erin is assigned a grant role with specified permissions, and two deny roles with specified permissions. Exact matches are factored out. Erin has all of the capabilities afforded by the grant role assigned to her, minus the capabilities that are specified in the deny roles that are assigned to her.

Figure  5:  Grant and deny roles on micro admin permissions

Module roles do not have deny roles. You can only grant module access. Users who do not have a role that grants module access cannot access the module workbench or functionality.

Implied role permissions

In grant roles, the write permission implies the read permission. The advanced role assigned to Erin and Grace has the write permission on the specified content sets, so the configuration does not need to specify the read permission. A role that has only the Read Sensor permission on the same content set is created for read-only type of users, like Bob in this example.

Figure  6:  Erin and Grace effectively have both read and write permissions

In deny roles, permissions are not implied. Permissions must be explicitly denied and must exactly match the permission configured in the grant role to be factored out. For example, if a deny role asserts that Write Sensor permission is denied on a specified content set, it does not imply that the Read Sensor permission is denied. When effective permissions are evaluated in the following example, the deny role permissions do not exactly match any grant role permissions, so no grant permissions are struck. The deny role is disregarded, and Bob still has Read Sensor permission on the specified content set.

Figure  7:  Bob effectively has read permissions

Inherited roles

Users inherit role permissions from the personas that are assigned to their user groups. Erin belongs to the user group named David’s Team, so she inherits permissions from the personas that are assigned to that user group. She also has permissions from the personas that are assigned to her user configuration. The system enforces the net effect. In the following example, Erin has all the capabilities afforded by group assignment and user-specific grant roles, minus the capabilities that are specified in any deny roles assigned to her.

Figure  8:  Inherited roles

Reserved roles

The predefined reserved roles assign permissions for special-purpose capabilities, such as using the Administration > Configuration pages. The permissions are implicit, so you cannot edit or delete them. The permissions are not available to non-reserved roles. In addition to the special permissions, reserved roles can have some or all of the permissions associated with advanced, micro admin, and module roles. Special logic applies when you assign both a reserved role and non-reserved roles to a user or user group, as described in the following sections.

Admin reserved role

The Admin reserved role has all permissions to all content, modules, shared services, and administrative functionality. When you assign this role, other grant roles are superfluous and deny roles (except Deny All) are ineffective.

During the setup of your Tanium as a Service (TaaS) deployment, an initial administrator account is created with the Admin role. You can use this account to configure RBAC for all other users, including other users who might need the Admin role.

Administrator reserved role

The Administrator role has all permissions to all content, modules, and administrative functionality. When you assign this role, other grant roles are superfluous and deny roles (not including Deny All) are ineffective.

Figure  9:  Administrator reserved role

Exception: An advanced role with the Bypass Action Approval permission does have effect when assigned to a user with the Administrator reserved role. The Administrator reserved role does not have this permission by default. Due to the sensitive nature of bypassing approval, you must explicitly assign this permission in all cases.

Content Set Administrator reserved role

The Content Set Administrator role assigns a permission to read and write content set and role configurations, including role assignments within the personas of user and user group configurations. When a persona has this role, any other grant role is ignored. Deny All is the only role that can affect a user with the Content Set Administrator role.

Figure  10:  Content Set Administrator reserved role

Notice the result when both the Content Set Administrator and Administrator roles are assigned. Only the Content Set Administrator role remains effective. Be careful not to assign the Content Set Administrator role to users who must have other roles. Be careful not to assign (directly or by user group inheritance) the Content Set Administrator role to users who are assigned the Administrator role.

Content Administrator reserved role

The Content Administrator role grants read and write permissions for all content sets, as well as action management permissions. A user with this role can also have grant module roles and micro admin roles. When determining effective permissions, the Tanium system adds grant module roles, factors micro admin roles, and disregards any additional advanced roles.

Figure  11:  Content Administrator reserved role

Deny All reserved role

Users with the Deny All role cannot access anything in the Tanium Core Platform, regardless of any other role that you assign to them, including the Admin reserved role Administrator reserved role. In the following example, the only role assigned to Frank that has any effect is Deny All.

Figure  12:  Deny All

Tasks that require reserved roles

To perform the following tasks, a user must have a reserved role because the tasks are not associated with micro admin permissions that you can assign to micro admin roles.

Table 1:   Tasks requiring a reserved role
Task Administrator Content Administrator Content Set Administrator
Manage content alignment

Use the Administration > Content > Content Alignment page to move module-specific content to the appropriate module content set.

Check mark X X
Manage permissions

Create, edit, or delete user role or content set configurations.

Check mark X Check mark
Manage role configurations and assignments

Edit roles and edit the role assignments of users, user groups, and personas.

Check mark X Check mark
Manage personas

Create, edit, assign, or delete personas.

Check mark X X
Manage Tanium solutions

Import Tanium modules, content packs, or Tanium Console User Interface updates. View and import lab content.

Check mark X X
Manage Tanium Core Platform configuration

View or manage any of the Administration > Configuration pages, including those for proxy settings, logging levels, plugins, plugin schedules, sensor threshold indicators, package file repository, Tanium Client subnets, bandwidth throttles, Tanium licenses, Tanium root keys, trust among Tanium Core Platform servers, LDAP servers, SAML, API tokens, and Tanium Console customizations.

Check mark X X
Load questions from Question History

Load a question from the Administration > Management > Question History page.

Check mark X X
Manage Interact categories

Read and manage the Other Dashboards category.

Check mark Check mark X

Effective role permissions

The effective permissions of a user persona are based on the cumulative effect of all the assigned and inherited roles, including the following:

  • Permissions specified in grant roles minus permissions specified in deny roles
  • Implied permissions in grant roles
  • Roles assigned to the persona that a user selects for a Tanium Console session
  • Roles inherited from a persona that is assigned to user groups, after the user selects that persona for a Tanium Console session

The user and user group configuration pages have a Roles and Effective Permissions section that clarifies how the Tanium system derives effective permissions.

Figure  13:  Effective permissions

In the roles section, hover over the tile for an inherited role to see the user group from which it was inherited. Click the tile for a role to highlight the associated permissions in the permissions sections. Click the All Roles tile to redisplay the permissions without highlighting.

View roles

  1. From the Main menu, go to Administration > Permissions > Roles.

    The page displays each role name and category, and the number of users, user groups, and personas to which each role is assigned.

  2. (Optional) To display attributes that the grid hides by default, click Customize Columns Customize columns and select the attributes.
  3. (Optional) Use the filters to find specific roles:
    • Filter by text: To filter the grid by column values, enter a text string in the Filter items field.
    • Filter by attribute: Filter the grid by one or more attributes, such as the Role Name. Expand the ExpandFilters section, click Add Add, select an attribute and operator, enter a text string that contains all or part of the attribute value, and click Apply. If you add multiple attribute filters, the Boolean AND operator applies. After you finish specifying attributes, click Apply All to filter the grid.
  4. (Optional) To see the permissions that are assigned to a role and to see the names of users, user groups, and personas to which the role is assigned, select the role and click Edit.

Create an advanced role

Advanced roles grant or deny content set permissions, which control access to sensors, packages, saved questions, and other content.

  1. From the Main menu, go to Administration > Permissions > Roles.
  2. Select New Role > Grant Advanced Role or New Role > Deny Advanced Role.
  3. Specify a Name to identify the role.
  4. (Optional) In the All Content Sets Option section, select Add all Content Sets that exist or will exist to the permissions selected below to grant or deny permissions across all existing and future content sets. This option is useful, for example, when you want a user to always be able to read sensors or never be able to write actions.
  5. In the Ask Dynamic Question section, click Add Add to enable users with this role to ask dynamic (ad-hoc) questions.

    Ask Dynamic Questions is a global permission. If it is enabled in any role assigned to a user, the user has permission to create dynamic questions that use any of the sensors for which they have read access.

  6. In the Advanced Permissions section, click Add Add for each permission that you want the role to grant or deny. Table 2 describes the permissions.
  7. Add content sets to each permission. Skip this step if you selected Add all Content Sets that exist or will exist to the permissions selected below.

    To create a custom content set without leaving the role configuration page, click Apply New Content Set, click New Content Set, enter a Name and (optional) Description, and click Save.

    • Add the same content sets to all permissions: Click Apply New Content Set, select content sets, and click Save.
    • Add content sets to a specific permission: Click Add in the permission tile, select content sets, and click Save.
  8. Click Save to save the role configuration.
Table 2:   Content Set Permissions
Permission Description
Bypass Action Approval Actions created by a user with this permission are not subject to approval requirements.

No role, including the Administrator reserved role, includes this permission by default.

This is the one advanced permission that has effect when granted to a user with the Admin Administrator reserved role.

Read Sensor Can view sensors in the Question Builder and similar user interfaces throughout the console. Can use sensors in questions if the user also has the ability to ask questions. Cannot view the Administration > Content > Sensors page unless the user also has the Write Sensor permission.
Write Sensor Can view the Administration > Content >Sensors page. Can create, modify, and delete sensor configurations. Implies the Read Sensor and Show Preview permissions.
Read Action Can view the Administration > Actions pages. Visibility of rows in the grid depends on the Read Action permission on the content set for the underlying package. The permission enables users to re-download package files and copy grid rows to the clipboard.

Implies the Read Own Action permission.

Read Own Action Determines whether the actions of the signed in user appear in the Administration > Actions > All Pending Approval grid.
Write Action Can view the Administration > Actions > Scheduled Actions page. Users can see rows for actions they issued. If a user has the Read Action permission on the content set for the underlying package, that user can see rows for actions that other users issued.

Can see and use the Deploy Action button on the Question Results grid for dynamic questions and saved questions.

Implies the Read Own Action, Read Package, and Show Preview permissions.

To deploy an action, edit an action, or check action status, a user also needs Read Sensor and Read Saved Question on the Reserved content set. The Reserved content set includes content used to ask preview and polling questions.

Write Action for Saved Question Can see the Administration > Actions > Scheduled Actions page, but the only rows are for the actions that the user has deployed.

Can see and use the Deploy Action button on the Question Results grid but only for saved questions that have associated actions. The Read Package permission is not required for the associated actions. If the saved question does not have associated actions, the Deploy Action button does not appear.

Tip: Use this permission instead of the Write Action permission to limit use by action users who use Tanium products to execute standard operating procedures that someone else created.

Read Filter Group Can see the Administration > Content > Filter Groups page, and use filter groups for filtering questions, question results, and various lists in the Tanium Console.
Write Filter Group Create, modify, and delete filter group configurations. Implies the Read Filter Group permission.
Approve Action Can approve actions that another user created. Users with this permission cannot approve their own actions.

To view the actions on the Administration > Actions > Actions I Can Approve and Administration > Actions > All Pending Approval pages, you must also have the Read Package and Read Own Action permissions.

Read Plugin Reserved for future use.
Execute Plugin Reserved for future use.
Read Package Can view packages in the Browse Packages dialog opened from the Deploy Action workflow page. Cannot view the Administration > Content > Packages page unless the user also has the Write Package permission.
Write Package Can view the Administration > Content > Packages page. Can create, modify, and delete package configurations. Implies the Read Package and Show Preview permissions.
Read Saved Question Can view saved questions in the Question Results grid drill-down and similar user interfaces. Can view the Interact Saved Questions page, if the user also has access to the Interact workbench. Cannot view the Administration > Content > Saved Questions page unless the user also has the Write Saved Question permission.

To issue a saved question as expected, the user also requires the Read Sensor permission for the pertinent sensor.

Write Saved Question Can view the Administration > Content > Saved Questions page. Can create, modify, and delete saved question configurations. Implies the Read Saved Question permission.

Note: Does not imply the Ask Dynamic Questions permission.

Read Associated Packages Not an explicit permission. Implied in the Write Action for Saved Question permission.
Read Dashboard Can view dashboards in the Interact Content page, if the user also has permission to the Interact workbench.

A user also needs the Read Saved Question and Read Sensor permission for the related content to use the dashboard.

Write Dashboard Can create, modify, and delete dashboard configurations. Implies the Read Dashboard permission.
Read Dashboard Group Can view categories in the Interact Content page, if the user also has permission to the Interact workbench.

A user also needs the Read Dashboard, Read Saved Question, and Read Sensor permissions on the related content to use the category.

Write Dashboard Group Can create, modify, and delete category configurations. Implies the Read Category permission.
Show Preview Not an explicit permission. Implied in the Write Action, Write Action for Saved Question, Write Sensor, and Write Package permissions. Enables authors to ask questions necessary to preview the impact of new and changed configurations. To ask preview questions, the user also needs Read Sensor on the Reserved content set. The Reserved content set includes content used to ask preview questions.

Create a micro admin role

Micro admin roles assign Tanium system administration permissions.

  1. From the Main menu, go to Administration > Permissions > Roles.
  2. Select New Role > Grant Micro Admin Role or New Role > Deny Micro Admin Role to display the role configuration page.
  3. Enter a Name to identify the role.
  4. Click Add Add for each permission that you want the role to grant or deny (see Table 3), and click Save.

    Some administrative tasks in the Tanium Console are not associated with micro admin permissions; only users who have a reserved role can perform these tasks. For details, see Tasks that require reserved roles.

    To create a role that can perform all administrative tasks in the Tanium Console, assign the Permission Administrator, Write User, Write User Group, Write Computer Group, and Write Persona permissions. The Admin reserved role has all these permissions.

Table 3:   Micro admin permissions
Permission Description
Permission Administrator Provides the following micro admin permissions as a bundle:
  • Read User
  • Read User Group
  • Read Role
  • Write Role
  • Grant Role
  • Read Content Set
  • Write Content Set
  • Read Persona
Read Client Status Can view the Administration > Management > Client Status page.
Read Question History Can view the Administration > Management > Question History page. To issue a question from the Question History page, the user also needs advanced role permissions on the corresponding content sets.
Read User Can view and export user configurations.

Additional permissions are required to view the role, user group, persona, and computer management group assignments of users: see Manage users.

Write User Can create, modify, and delete users. Implies the Read User permission.

Additional permissions are required to edit the role, user group, persona, and computer management group assignments of users: see Manage users.

Read User Group Can view and export user group configurations.

Additional permissions are required to view the role, user, persona, and computer management group assignments of user groups: see Manage user groups.

Write User Group Can create, modify, and delete user groups. Implies the Read User Group permission.

Additional permissions are required to edit the role, user, persona, and computer management group assignments of user groups: see Manage user groups.

Read Computer Group Can view and export computer management groups and filter groups. Implies the Read Filter Group permission.

Additional permissions are required to view the user group, user, and persona assignments of computer management groups: see Manage computer groups.

Write Computer Group Can create, modify, and delete computer management groups and filter groups. Implies the Read Computer Group and Write Filter Group permissions.

To create a computer management group or filter group in which membership is based on a sensor filter, the following permissions are required in addition Write Computer Group:

  • Read Sensor (advanced) permission on the Reserved content set, which includes content that is used to ask preview questions.
  • Interact Module Write (module) permission.

Computer groups with manually defined membership do not require the Read Sensor or Interact Module Write permissions.

Additional permissions are required to edit the user group, user, and persona assignments of computer management groups: see Manage computer groups.

Read Management Rights Can view the computer management group assignments of users, user groups, and personas when combined with the Read Computer Group permission.

Read Management Rights is not an explicit permission. The Permission Administrator permission implies this permission.

Write Management Rights This is one of the permissions that are required to edit the computer management group assignments of users, user groups, and personas. For additional required permissions, see Manage computer groups.

Write Management Rights permission implies the Read Management Rights permission.

Write Management Rights is not an explicit permission. The Permission Administrator permission implies this permission.

Read Content Set Can view content set configurations. This is not an explicit permission. The Permission Administrator permission implies the Read Content Set permission.
Write Content Set Can create, edit, and delete content sets; move content between content sets; and export content sets. This is not an explicit permission. The Permission Administrator permission implies the Write Content Set permission.
Read Role Can view and export role configurations. This is not an explicit permission. The Permission Administrator permission implies the Read Role permission.
Write Role Can create, edit, and delete roles. This is not an explicit permission. The Permission Administrator permission implies the Write Role permission.
Grant Role This is one of the permissions that are required to edit the role assignments of users, user groups, and personas. This is not an explicit permission. The Permission Administrator permission implies the Grant Role permission. Editing role assignments requires the following combined permissions:
  • Permission Administrator and Write User permissions are required to edit the role assignments of users.
  • Permission Administrator and Write User Group permissions are required to edit the role assignments of user groups.
  • Permission Administrator and Write Persona permissions are required to edit the role assignments of personas.
Read Persona Can view and export persona configurations and assignments. The Permission Administrator permission implies the Read Persona permission.
Write Persona Can create, edit, and delete personas when combined with the Permission Administrator permission. Implies the Read Persona permission.

Additional permissions are required to edit the user group, user, and computer management group assignments of personas: see Manage personas.

Read Global Settings Can view the Administration > Management > Global Settings page.
Write Global Settings Can create, modify, and delete global settings. Implies the Read Global Settings permission.
Read Allowed Urls Can view the Administration > Management > Allowed URLs page.
Write Allowed Urls Can create, modify, and delete the allowed URLs configuration. Implies the Read Allowed Urls permission.
Read Audit Can view:
  • Last Login information on the Administration > Management > Users page
  • Last Modified on information on the user details page (go to Administration > Management > Users and click View User)
  • Last Modification information on the Administration > Management > Global Settings page
Read Server Status Can view the https://<Tanium_Server>/info page. For details, see About Us.
View Token Can view the Administration > Configuration > Authentication > API Tokens page.
Use Token Can send requests to the Tanium Server for new API tokens.
Revoke Token Can revoke API tokens that are used to access the Tanium Server.
Import Signed Content Can import digitally signed content files.
Read Action Group Can view specific action groups in the Administration > Actions > Scheduled Actions page.
Write Action Group Can create, modify, and delete action groups. Implies the Read Action Group permission.

Create a module role

Module roles grant Tanium solution module permissions, which control access to module workbenches and features. Module roles also grant permissions for module-specific content sets. Module roles do not have deny roles. Users who do not have a role that grants module access cannot access the module workbench or features. Some module permissions enable provided permissions, which a role configuration includes automatically when you select module permissions. For example, if you select the Patch Module Write permission, the role automatically includes the Ask Dynamic Questions permission.

Refer to the module user guides for information about module-specific roles:

Perform the following steps to create a module role:

  1. From the Main menu, go to Administration > Permissions > Roles.
  2. Select New Role > Grant Module Role to display the role configuration page.
  3. Enter a Name to identify the role.
  4. (Optional) In the All Content Sets Option section, select Add all Content Sets that exist or will exist to the permissions selected below to grant permissions across all existing and future content sets that are associated with the module. This option applies only to modules such as Trends that have module-specific content.
  5. In the Module Permissions section, click Add Add beside each module for which you want the role to grant permissions.
  6. For each module, click Edit, select permissions, and click Save.
  7. For each module that has module-specific content, click Add in each permission tile, select content sets, and click Save. Skip this step if you selected Add all Content Sets that exist or will exist to the permissions selected below.

    To create a custom content set without leaving the role configuration page, click Apply New Content Set at the top right of the Module Permissions section, click New Content Set, enter a Name and (optional) Description, and click Save.

    • Add the same content sets to all permissions: Click Apply New Content Set, select content sets, and click Save.
    • Add content sets to a specific permission: Click Add in the permission tile, select content sets, and click Save.
  8. Click Save to save the role configuration.

Assign users and user groups to a role

You can assign users and user groups to roles in the role configuration (as follows) or in the user and user group configurations.

  1. From the Main menu, go to Administration > Permissions > Roles.
  2. Select a role and click Edit to display the role configuration page.
  3. Click Edit User Assignment to display the Assign Users and User Groups page.
  4. Next to User Groups, click Edit. Select groups and click Save.
  5. Next to Users, click Edit. Select users and click Save.
  6. Click Show Preview to Continue, review the effective permissions, and click Save.

Clone a role

To add a role that has many settings in common with an existing role, cloning the existing role and then modifying the clone is often a quicker method than configuring a new role. Note that you must still assign users and user groups to the clone, and optionally enter a description; the clone will not inherit those settings from the original role. You can clone any role except the reserved roles.

  1. From the Main menu, go to Administration > Permissions > Roles.
  2. Select a role and click Clone.
  3. Enter a Name to identify the role, update the permissions as needed, and click Save.
  4. Assign users and user groups to the role (see Assign users and user groups to a role).

Export and import roles

The following procedures describe how to export and import the configurations of specific roles or all roles.

Develop and test content in your lab environment before importing that content into your production environment.

Export roles

Export roles as a CSV file to view their settings in an application that supports that format. If you have the Administrator reserved role, you can also export roles as a JSON file to import them into another Tanium Server.

If you want to export other types of content in addition to roles, see Manage Tanium shared services and content.

  1. From the Main menu, go to Administration > Permissions > Roles.
  2. Select rows in the grid to export only specific roles. If you want to export all roles, skip this step.
  3. Click Export Export.
  4. (Optional) Edit the default export File Name, which is in the format: export-roles-<date>T<time>.csv<format>.

    The file suffix (.csv or .json) changes automatically based on the Format selection.

  5. Select an Export Data option: All roles in the grid or just the Selected roles.
  6. Select the file Format: JSON (Administrator reserved role only) or CSV.
  7. Click Export.

    TaaSThe Tanium Server exports the file to the downloads folder on the system that you used to access the Tanium Console.

Import roles

You can import content files that are in JSON or XML format.

  1. Digitally sign the content file and ensure a public key is in place to validate the signature. See Authenticating content files.
  2. From the Main menu, go to Administration > Configuration > Solutions.
  3. Scroll to the Content section and click Import Import Content.
  4. Click Choose File, select the content file, and click Open.
  5. Click Import.

    If object names in the file are the same as for existing objects, the Tanium Console itemizes the conflicts and provides resolution options for each one.

  6. Select resolutions for any conflicts. For guidance, see Conflicts and Best practices.
  7. Click Import again, and click Close when the import finishes.

Copy role configuration details

Copy information from the Roles page to your clipboard to paste the information into a message, text file, or spreadsheet. Each row in the grid is a comma-separated value string.

  1. From the Main menu, go to Administration > Permissions > Roles.
  2. Perform one of the following steps:
    • Copy row information: Select one or more rows and click Copy Copy.
    • Copy cell information: Hover over the cell, click Options Options, and click Copy Copy.

Delete a role

When you delete a role configuration, the role is removed from any user and user group configurations that had included it. When deleting a role configuration, we recommend:

  1. Delete the users and user group assignments from the role configuration.
  2. Go to the effective permissions page for your users and review the resulting impact on the users' effective permissions.
  3. Delete the role configuration.