User group management - Create user groups and assign roles and users to further refine your requirements. - Administrator Guide - Cortex XSIAM - Cortex

User group management - Create user groups and assign roles and users to further refine your requirements. - Administrator Guide - Cortex XSIAM - Cortex - Security Operations

Cortex XSIAM 3.x Documentation

Product

Cortex XSIAM

Creation date

2025-07-15

Last date published

2026-06-11

Category

Administrator Guide

Abstract

Create user groups and assign roles and users to further refine your requirements.

Users are assigned roles and permissions either by being assigned a role directly or by being assigned membership in one or more user groups. A user group can only be assigned to a single role, but users can be added to multiple groups if they require multiple roles. You can also nest groups to achieve the same effect. Users who have multiple roles through either method will receive the highest level of access based on the combination of their roles. The same principle for users with multiple roles is followed for both the Role-Based Access Control (RBAC) access permissions and the Scope-Based Access Control (SBAC) granular scoping, so that users receive the highest level of access by combining their roles.

Example 3.

Joe has an Analyst role and is a member of the Tier-1 Analyst user group, which is assigned the Triage role. Joe has the permissions of the Analyst role and the Triage role. Joe is assigned 2 roles, and has the highest permission based on the combination of both roles.
John is a member of two user groups - Tier-1 Analyst and Tier-2 Analyst. One group is configured to use the Triage role and the other group is configured to use the Incident Response role. John is assigned both roles and has the highest permissions based on the combination of all roles.
Jack is a member of the Tier-2 user group, which has an Incident response role. This user group is included in a Tier-3 user group (Threat Hunter role), added as a nested group. Jack is assigned both roles and has the highest permissions based on the combination of all roles.

On the User Groups page, you can create a new user group for several different system users or groups. You can see information including the details of all user groups, the roles, nested groups, IdP groups (SAML), and when the group was created/updated.

You can also right-click in the table to edit, save as a new group, remove (delete) a group, and copy text to the clipboard.

You can create user groups in the tenant or Cortex Gateway. User groups created in Cortex Gateway do not support SAML group mapping and are shared across all your tenants. We recommend managing user groups directly in the Cortex tenant, because only tenant-based groups support scoping and SAML group mapping.

Managing groups directly in the tenant allows you to maintain different user groups for different environments, such as dev/prod. It also allows you to apply granular scoping to a user group by granting access only to the relevant data that the group members require. To use scope-based access control (SBAC), you must enable it in the Server Settings page. For more information, see Manage user scope. Before configuring SBAC, ensure that you review Understand scoping in the Manage user scope section.

To govern user-to-group lifecycle relationships within individual tenant workloads, administrators must utilize one of three core provisioning strategies to ingest or evaluate directory identities:

This default method allows you to associate users with groups created and managed within Cortex XSIAM.

Methodology: System administrators manually build structural custom groups directly in the tenant console or the Cortex Gateway, explicitly assigning individual accounts into the member list.
Prerequisites for allocation: The user identity must first exist in the Customer Support Portal (CSP) or have finished a first Single Sign-On (SSO) authentication sequence. For CSP users, the account must also be assigned the specific Cortex User role within the support portal configuration. For more information, see Set up users, groups, and roles.

This approach establishes your corporate Identity Provider (IdP) as the absolute source of truth, allowing group assignments defined in your enterprise directory to be seamlessly reused inside Cortex XSIAM.

Methodology: Administrators create user group shells inside Cortex XSIAM and associate them with the user groups defined in the IdP. This allows you to reuse your existing organizational hierarchy, access permissions, and team structures directly into the security operations console without introducing operational fragmentation or duplicative group-association overhead.
Configuration steps:
- For Okta environments: For step-by-step instructions, see Set up Okta as the Identity Provider Using SAML 2.0. Pay close attention to configuring the group attribute statement to pass the user's groups in the SAML assertion token.
- For Microsoft Entra ID (Active Directory) environments: For step-by-step instructions, see Set up Microsoft Entra ID as the Identity Provider Using SAML 2.0. You must configure Entra ID to emit user group claims in the token.
Critical capitalization requirement: String evaluation across authentication mappings, attribute configurations, and group designations enforces absolute case mapping rules. Strict attention to exact character capitalization must be maintained across all configurations. If the group name string in the IdP does not match the string in Cortex XSIAM with identical uppercase and lowercase letters, the mapping will fail completely, and users will not inherit their permissions.
Active session mechanics: This flow operates dynamically during user login and does not alter or update the permanent group mappings listed within the Cortex XSIAM console. The session flow works as follows:
1. The user logs in via SSO.
2. Based on the SAML assertions coming from the Identity Provider (IdP), the list of IdP groups associated with that user is extracted.
3. These extracted groups are used to associate the user with the local Cortex Groups based on the SAML Group Mapping field configured within the Cortex group settings.
4. These mapped groups are associated with the user for the length of the current authenticated session.
5. Consequently, these groups do not appear in the persistent list of Cortex groups associated with this user inside the Cortex XSIAM console.

This process utilizes the CIE directory to manage and arrange organizational group mappings in advance.

Methodology: The Cloud Identity Engine (CIE) uses the System for Cross-domain Identity Management (SCIM) protocol to automatically synchronize groups from your Identity Provider (IdP) directly into CIE. Then, Cortex XSIAM synchronizes the CIE groups that were selected using Import AD Group into its local list of groups.
Configuration steps: To configure and connect the underlying identity engine pipeline to your enterprise directory infrastructure before mapping groups locally, see the step-by-step onboarding instructions in Set up Cloud Identity Engine.
Synchronization processing delay: Because the directory sync between CIE and the Cortex tenant runs on a periodic background schedule, a delay of a few hours may occur after the list of groups changes in your IdP, or when a mapping between groups and users changes in CIE.

Important

The Cloud Identity Engine (CIE) is used exclusively for directory group management; it is not utilized for individual user account management, provisioning, or authentication workflows. Consequently, disabling, suspending, or removing user objects directly within CIE does not automatically disable, restrict, or delete those corresponding users inside Cortex XSIAM. If you use Single Sign-On (SSO) for Cortex XSIAM authentication, see the User De-provisioning and Restrictions section in Authenticate users using SSO for complete instructions on handling directory lifecycle cleanups and managing stale accounts.

Go to Settings → Configurations → Access Management → User Groups.
If creating in Cortex Gateway, go to Permission Management → User Groups.

To create a new user group for several different system users or groups, click New Group, and add the following parameters:

Parameter	Description
Name	Name of the user group.
Description	Description of the user group.
Group for product	(Cortex Gateway only) If you have multiple products, select the relevant Cortex product.
Role	Select the group role associated with this user group. You can only have a single role designated per group. In Cortex Gateway, you can only select either Instance Administrator or a custom role created in the Gateway.
Users	Select the users you want to belong to this user group. Note If users have been created in the CSP, but you want them to access the tenant through SSO only, skip this field and add only SAML group mapping after SSO is set up, otherwise, users can access the tenant through both the CSP and SSO. If you have not yet created any users, skip this field and add them later. See Set up authentication .
Nested Groups	Lists any nested groups associated with this user group. If you have an existing group, you can add a nested group. User groups can include multiple users and nested groups, which inherit the permissions of parent user groups. The user group will have the highest level of permission. For example: Group A has Tier-1 Analyst permissions Group B has Tier-2 Analyst permissions If you add Group A as a nested group in Group B, Group A inherits Group B's permissions (Tier-1 and Tier-2 permissions). In Cortex Gateway, you can only add user groups that are created in Cortex Gateway.
SAML Group Mapping	(Relevant when creating a user group in the Cortex tenant only.) Maps the SAML group membership to this user group. For example, you have defined a `Cortex Admins` group. You need to name this group exactly how it appears in Okta. You can add multiple groups by pressing enter after each name to build a list. Note Capitalization is vital. String evaluation enforces absolute case mapping rules. The name must match your IdP's string configuration exactly. When using Microsoft Entra ID for SSO, the SAML group mapping needs to be provided using the group object ID (GUID) and not the group name. Relevant strategy: For functional context and the session mechanics of this configuration, see Strategy B: SAML dynamic group mapping (IdP is the source of truth). If you have not set up SSO in your tenant, skip this field and add it later. After you have added it, follow the procedure relevant to your IdP. For example, see Set up Okta as the identity using SAML 2.0 .

(Optional) When creating the user group in the tenant, configure granular scoping for the user group.

If creating the user group in the Cortex Gateway, you can skip this step, as scoping is only supported in the tenant.

Click the Scope tab.

Expand the scoping areas that you want to grant the user role access to in the tenant by clicking the chevron icon (>) beside the scoping area title, and make any changes required. The following table explains the options available to configure:

Scoping Area	Granular Scoping Configurations
Assets	Set the Scope by selecting one of the following: No assets: No asset is accessible. All assets: Defines access to all assets. Select asset groups: Defines access to the specific assets associated with the Asset Groups selected, and to view all their related cases, issues, and findings for these specific assets and Asset Groups. Under Select asset groups, define the specific asset groups that you want to grant access. Only Asset Groups relevant for scoping are listed, which are asset groups that are using only the asset attributes listed in Manage user scope (under Understand scoping → Scoping Areas → Assets). The scoping of assets also affects the scoping of cases, issues, and findings. Note Visibility of Security domain Issues that refer to assets with agents is controlled by the Endpoints scoping configuration.
Cases and Issues	Set the Scope by selecting one of the following: No cases and issues: Defines access to no cases and issues. All cases and issues: Defines access to all cases and issues. Users can view cases or issues referencing assets within their scope. Use the Assets section to define which assets are in scope. Select domains: Defines access to the domains selected to view their related cases and issues. Under Select domains, define the specific domains that you want to grant access. Users can only view cases or issues referencing assets and endpoints within their scope. Use the Assets section to define which assets are in scope. When selecting All cases and issues or Select domains, you can separately configure access to issues and cases that lack an asset reference or where the referenced asset is not in All Assets and All Endpoints inventories. To provide access, select the Allow access to cases and issues that are not referencing known assets or endpoints checkbox. Once selected, you can specifically control which users have access to issues and cases that lack Affected Assets (as seen in the issue’s panel) and Assets (as seen in the case's panel), or where the listed assets are not part of the Asset or Endpoint inventories. When the assets listed are not part of the inventories, the asset string is typically non-clickable. In some cases, such as for identity-related issues, assets may open a dedicated User Risk View, which differs from the standard inventories panels. In the Issues and Cases tables, such items can be identified by empty values in the following columns: Asset IDs, Target Agent Identifier, and Source Agent Identifier.
Endpoints	Set the Scope by selecting one of the following: No endpoints: Defines access to no endpoints with no ability to view their related agent management and enterprise policies. All endpoints: Defines access to all endpoints with the ability to view their related agent management and enterprise policies. This configuration can impact the visibility of related Security domain Cases and Issues, but will not affect asset visibility. Select specific (at least one required): Defines specific access to all endpoint groups by selecting Endpoint Groups or all endpoint tags by selecting Endpoint Tags to view their related agent management and enterprise policies. This configuration can impact the visibility of related Security domain Cases and Issues, but will not affect asset visibility.
Datasets Rows	Configure a `filter` to define the specific subset of rows a user is allowed to access in each raw dataset. A raw dataset is every dataset where Palo Alto Networks data is ingested out-of-the-box or third-party data is ingested using a configured dedicated collector, also called a data source. This filter configuration does not impact the visibility of cases and issues. Follow these steps to configure a `filter`: For datasets where no `filter` is defined, determine how to set the When no filter is defined option as either: No rows are accessible (default): Without a configured `filter`, no rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, but the results will be empty. All rows are accessible: Without a configured `filter`, all rows are accessible. Users can query the datasets in Cortex Query Language (XQL) as they have access, and view all results. Note When defining a filter for row-level scoping on raw datasets, queries based on the Cortex Data Model (XDM) are not supported. XDM queries return specific rows only when All rows are accessible is selected and no filter is defined in the Datasets Rows scoping area. Otherwise, no rows are returned. Define any filters for the applicable datasets listed in the table: Scroll down the list of datasets to the dataset you want to apply a `filter` on, and click the Edit Scope icon. In the Define what rows are accessible window, continue to write the query for the `filter` in the query box (where the syntax is a limited subset of XQL) to limit the data rows for the selected dataset according to the access permissions you want the user to have. The beginning of the query is already defined before the query box, and there is no need to include this in your query. Important For optimal performance, we recommend using a single field in the `filter` definition and simple comparison operators. Supported syntax Fields You can define the rest of the `filter` in the query box, where only the following system fields are supported: `_broker_device_id`, `_broker_device_ip`, `_broker_device_name`, `_collector_id`, `_collector_ip`, `_collector_name`, `_collector_type`, `_device_id`, `_final_reporting_device_ip`, `_final_reporting_device_name`, `_log_type`, `_product`, `_scope`, `_reporting_device_ip`, `_reporting_device_name`, and `_vendor`. For more information on these fields, see the table that describes all the fields in the `metrics_source` dataset and `metrics_view` preset in Overview of data ingestion metrics. For more information on the `_scope` field (relevant when `_scope` is defined in the Parsing Rule), see [Scenario 3: Supported fields don't provide the necessary segmentation] in Scenarios related to Datasets Rows scoping.Manage user scope Comparison operators The following comparison operators are supported: Exact matches (`=`, `!=`) Comparing numerical values (`>`, `<`, `>=`, `<=`) Checking membership in lists (`in`) Querying arrays (`array_contains`) Partial matches (`contains`, `starts_with`): Using this operator has additional performance overhead, and we recommend avoiding its use. Example 4. If you only want a user to be able to access rows in the `pan_dds_raw` dataset, when the `_collector_name` is `bu2_collector` , you'd have to define the `filter` in the query box as: _collector_name = “bu2_collector” (Optional) Set the Time frame for the query. The default is Last 1 day. (Optional) You can preview the query results displayed based on your defined query by clicking Preview. You can edit your query until you're satisfied with the output. By default, the query results are limited to 1000 records. When you are finished, click Done. The Scope field for the dataset that you added the filter on is updated with the query. Example 5. In the above example, the Scope field displays `_collector_name = “bu2_collector”`.

Important

By default, Enable Scope Based Access Control is disabled in Settings → Configurations → General → Server Settings, and granular scoping is not enforced. Before enabling SBAC, we recommend that an administrator or a user with Access Management permissions first ensures that the users, user groups, and API Keys defined in Cortex XSIAM are granted the required access by assigning the relevant scopes. For more information, see Manage user scope.

Click Create to create the user group.

Note

To automatically synchronize group membership with your organization's Active Directory, you can import an AD group. When someone joins or leaves a team in AD, their Cortex permissions update automatically.

The Import AD Group feature is only enabled when the Cloud Identity Engine (CIE) is connected and configured.

Select Settings → Configurations → Access Management → User Groups.
Click Import AD Group.

In the Role tab, define the following parameters:

Parameter	Description
Import AD Group	Type to search the CIE in real time, and choose a group or Organizational Unit (OU) to import from Active Directory. Note Only CSP and SSO users already existing in Cortex will be imported.
Description	Description of the imported user group.
Role	Select the group role associated with this user group. You can only have a single role designated per group.
SAML Group Mapping	Maps the SAML group membership to this user group. For example, you have defined a `Cortex Admins` group. You need to name this group exactly how it appears in Okta. You can add multiple groups by pressing enter after each name to build a list. Note When using Microsoft Entra ID for SSO, the SAML group mapping needs to be provided using the group object ID (GUID) and not the group name. If you have not set up SSO in your tenant, skip this field and add it later. After you have added it, follow the procedure relevant to your IdP. For example, see Set up Okta as the identity using SAML 2.0 .

Click the Scope tab to configure granular scoping for the imported group. You can limit the data and content that users can access by configuring the Assets, Cases and Issues, Endpoints, and Datasets Rows options the same as detailed in the custom user group instructions.
Click Import.
Cortex creates a new User Group of type AD Group and immediately fetches the current members in the background. An update appears in Notifications when the import is complete. Following the import, Cortex XSIAM automatically runs periodic background syncs with the CIE to ensure the group's membership stays up to date.
Note
If an imported group is later deleted from your Active Directory, Cortex XSIAM automatically deletes the corresponding user group at the next sync cycle.