> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-remove-user-from-groups.md). # Remove User from Groups Remove a user's group memberships directly from query results using the Remove User from Groups remediation action. The **Remove User from Groups** action removes a user's membership in one or more groups in the source identity provider, directly from a query result. Use this when a query surfaces users who hold access through groups they should no longer belong to (over-privileged, stale, or risky group memberships), and you want to revoke that access without leaving Veza. Each membership pairs a user with a group. Removing it revokes the access the user inherited through that group. It does **not** disable the user's account or remove access the user holds directly on a resource. For those actions, use [Disable Accounts](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-disable-accounts.md) or [Revoke Direct Access](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-revoke-direct-access.md). {% hint style="warning" %} **This is a bulk, immediate action. Read this before proceeding.** * The action removes every selected membership at once. A misconfigured query can remove memberships you did not intend to. * There is no approval step after you submit. Any user with access to this action can execute it immediately. * Veza does not provide an undo action. To restore a membership, re-add the user to the group in the identity provider, or use a [Lifecycle Management workflow](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/manage-relationships.md). * Query results reflect data from the last extraction. If extraction is stale, the results might not match the current state of your environment. {% endhint %} ## Enabling write access Veza integrations use read-only service account credentials by default. Before you can use Remove User from Groups, you must grant the Veza service account write permissions and enable the integration for provisioning. This is a one-time setup per integration. 1. Follow the guide for your integration to add the required write permissions to the Veza service account: * [Okta: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta/provisioning.md) * [Azure AD: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/azure/provisioning.md) 2. In Veza, go to **Integrations**, open the integration configuration, and check the **Enable usage for Provisioning** checkbox. ![The Edit Integration panel showing the Enable usage for Provisioning checkbox](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-4602ab239918fa66cf85a42dfffdab3dfae0310d%2Fenable-provisioning.png?alt=media) 3. Click **Save Configuration**. 4. To verify: reopen the integration configuration and confirm the **Enable usage for Provisioning** checkbox is checked. ## Before you begin Because this action is immediate and irreversible, test it on a small, known set before running it against a production query: 1. Run the query and review the memberships it returns. Confirm every membership is one you intend to remove. 2. Check when the integration last completed a successful extraction. Stale extraction data means the results might not reflect current access. Re-run extraction if the data is old. 3. Start with a query that returns a small, controlled set of users and groups. Execute the action, then confirm in the identity provider that the memberships were removed before scaling up. 4. Confirm your team has a process to re-add users to groups in the identity provider if any removal needs to be restored. ## Prerequisites * Provisioning (write access) must be enabled for the target integration. See [Enabling write access](#enabling-write-access) above. * The action must be enabled on the query by an administrator. See [Enabling the action on a query](#enabling-the-action-on-a-query). * The query must return **user → group** pairs: a user source entity type (**Okta User** or **Azure AD User**) that reaches a group destination (**Okta Group** or **Azure AD Group**). ### Role requirements Different controls in this feature are available to different roles: | Action | Minimum role | | ------------------------------------------ | -------------------------- | | View the Remediate dropdown | Viewer | | Execute the Remove User from Groups action | Admin or Remediation Owner | | View the Remediation Log | Viewer | | Enable the action on a query | Admin | Viewers can see the Remediate dropdown but cannot execute actions. The option is unavailable if the action has not been enabled on the query or if provisioning is not enabled for the integration. ## Enabling the action on a query Before Remove User from Groups appears as an executable action, an administrator enables it on the query. On the query details page, open the **Remediate** dropdown and select **Enable Option to Remove User from Groups** at the bottom of the menu. ![The Remediate dropdown on a query details page, showing the Enable Option to Remove User from Groups toggle at the bottom of the menu](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-6a108396a7b4b5e0ff964c581e995ab20657a56e%2Fremove-user-from-groups-remediate-dropdown.png?alt=media) This setting is per-query. Each query that should support the action must be enabled separately. Once enabled, the option appears under the **Automatic** group for all users with the required role. To be eligible, the query must return user-to-group pairs: it must start from a user source entity type (**Okta User** or **Azure AD User**) and reach a group destination (**Okta Group** or **Azure AD Group**). You can build the query with the Query Builder interface or [VQL](/4yItIzMvkpAvMVFAamTf/features/search/vql/vql-quickstart.md). For example, to surface guest users and the Azure AD groups they belong to: ```vql SHOW AzureADUser WHERE is_guest = true RELATED TO AzureADGroup RESULT INCLUDE DESTINATION NODES; ``` Adjust the filters to match your risk criteria: for example, filter the source user on `user_principal_name`, or the destination group on a specific attribute. See the [VQL syntax reference](/4yItIzMvkpAvMVFAamTf/features/search/vql/vql-syntax.md) for the full set of operators and attributes. The query is a targeting aid, not the final removal scope. Because a user can hold access to the same resource through more than one group, confirm the exact memberships before you remove them. Use [Impact Preview](#impact-preview) to see which applications and resources each user would lose. ## How to access Once the action is enabled on the query, you can start it in two ways from the query details page: * **From selected results**: Select one or more rows in the query results table, click **Remediate Selected**, and select **Remove User from Groups** under the **Automatic** group. This opens the [Impact Preview](#impact-preview) page, scoped to the users you selected. * **From the Remediate dropdown**: Open the **Remediate** dropdown and select **Remove User from Groups** under the **Automatic** group. This opens the full-page form described in [Workflow](#workflow), scoped to the whole query. This path does not include Impact Preview. The option is unavailable if provisioning is not enabled for the integration or if the action has not been enabled on the query. ## Workflow Selecting **Remove User from Groups** from the **Remediate** dropdown opens a full-page form, scoped to the query, with three sections: 1. **Safety Conditions**: Checks that must pass before the action can run. The banner states the safety behavior: *if any condition in the query fails, Veza blocks the auto-action*. When the checks pass, the section shows **Passed** and confirms the action is fully auditable. 2. **Preview Action**: The group memberships eligible for removal. An **Impact Summary** reports how many memberships the action will affect. Filter the list by user or by group, then use the checkboxes to select the memberships to remove. Each row pairs a user with a group and shows the group's risk score. 3. **Summary**: A confirmation of what will be removed, with an execution summary of the number of memberships to process. Add a note (required) describing the reason for removing these memberships. ![The Remove Azure AD User From Groups form showing the Safety Conditions section, the Preview Action Impact Summary, and the Group memberships to be Processed table with user-to-group pairs selected](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-f9f8157fd1e3c99640fcfc6227527db2557b0eb0%2Fremove-user-from-groups-workflow.png?alt=media) Click **Execute Action** to submit. Veza removes the selected memberships and records the action, then takes you to the **Remediation Log** for the query, where you can monitor the per-membership status. ### Impact Preview Impact Preview shows the access each user would lose before you remove them from groups. It opens when you start the action from **Remediate Selected** on the query results. See [How to access](#how-to-access). {% hint style="info" %} **Impact Preview is for guidance only.** Remediation actions are an Early Access feature, and Veza is still refining Impact Preview: * The preview simulates the removal against the current Access Graph. Actual results can differ, so review the selected memberships carefully before you remove them. * The preview shows only lost access to applications and resources. See [Limitations](#limitations). * The preview can be slow to load, or fail to load, for users with large amounts of access. * If a preview graph looks wrong, report it to Veza Support. {% endhint %} The **Impact Preview** page has two parts: * **Side panel**: The selected users and their group memberships, with a title that counts the users and groups to remove. Filter the list by user or by group, and use the checkboxes to choose the memberships to remove. * **Graph**: The access the active user would lose if removed from the checked groups. To preview and remove memberships: 1. In the side panel, check the groups to remove the user from. The graph updates for the active user each time you change the selection. 2. Review the graph. The summary above it names the user and the checked groups, and counts the access that will be lost by type, such as applications. Click **See More** to list each lost application and resource. Lost access is highlighted in red, with dashed edges. Access the user keeps is shown in gray. 3. Optional: click **Open in Graph Builder** to explore the user's access paths in Graph Builder. 4. Use the arrows to move to the next user, and repeat for each user. 5. In **Notes**, describe the reason for removing the users from these groups. Notes are required. 6. Click **Remove from Groups**. A confirmation dialog shows how many users and groups are affected and warns that the action cannot be undone. Click **Remove from Groups** again to confirm. Veza submits the checked memberships and takes you to the **Remediation Log** for the query. #### How lost access is calculated Impact Preview shows lost *effective* access. An application or resource is marked as lost only when removing the checked groups leaves the user with no other path to it. If the user can still reach it through another group, role, or inherited permission, Impact Preview does not mark it as lost. For example, User 1 belongs to Group 1 and Group 2. Group 1 grants access to Application 1 and Application 2. Group 2 grants access to Application 2 and Application 3. If you remove User 1 from Group 2, only Application 3 is marked as lost, because User 1 can still reach Application 2 through Group 1. ![A graph where User 1 belongs to Group 1 and Group 2. Group 1 reaches Application 1 and Application 2. Group 2 is selected for removal and reaches Application 2 and Application 3. Only Application 3 is highlighted as lost.](https://1967633068-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MZDkWMxox3pekd0NsZJ%2Fuploads%2Fgit-blob-8d21656211a3960f2a0e8fe7791174ed69fb5b6d%2Fremove-user-from-groups-impact-preview-effective-access.png?alt=media) If the preview takes longer than five minutes, the page shows *The impact preview timed out*, and you can try again. If the preview cannot be generated, the page shows *The impact preview could not be computed*. ## Results Each membership targeted by the action is processed independently and resolves to one of three outcomes: | Outcome | Meaning | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Removed** | The user's membership in the group was removed. | | **Skipped** | The user was not a member of the group, so there was nothing to remove (for example, the membership changed since the last extraction). This is a no-op, not a failure. | | **Failed** | The removal could not be completed for that membership. The reason is recorded with the result. | Memberships are processed independently: a failure on one does not stop the action from removing the others. The removal takes effect in the identity provider when the action runs; it appears in Veza's Access Graph after the next extraction. Confirm the result in the Remediation Log, and re-run extraction if you need the graph to reflect the change before your next review. ## Remediation Log Each Remove User from Groups request is logged per membership in the assessment's [Remediation Log](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-log.md) tab, alongside every other remediation triggered from the query. A bulk submission produces one row per affected user-to-group pair. A row stays as audit evidence even after the membership is later re-added or otherwise modified. See the [Remediation Log](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-log.md) page for the column reference, the status-and-state model, the History tab, and audit guidance. ## Limitations * **Group memberships only.** The action removes a user's membership in a group. It does not disable the account or remove access granted directly to the user on a resource. Use [Disable Accounts](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-disable-accounts.md) or [Revoke Direct Access](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-revoke-direct-access.md) for those. * **The integration must support removing relationships.** The action is available only for integrations whose provisioning capabilities include removing group memberships. If the option does not appear, confirm provisioning is enabled and that the integration supports this action. * **Impact Preview shows lost access to applications and resources only.** Removing a user from a group can also take away other access and permissions that the preview does not show. The preview shows whether the user keeps access to each application or resource, not which permissions they keep. If another path still grants access, the preview shows it as kept. * **Impact Preview is available only for this action**, and only when you start it from **Remediate Selected**. Other remediation actions do not include it. * **No undo.** Removals are not reversible from Veza. To restore a membership, re-add the user to the group in the identity provider or use a [Lifecycle Management workflow](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/manage-relationships.md). ## Supported integrations The following integrations support removing users from groups. Provisioning (write access) must be configured for the Veza service account as described in [Enabling write access](#enabling-write-access): * Okta * Azure AD (Microsoft Entra ID) ## Supported entities | Role | Entity type | | -------------------------------------- | ---------------------------- | | Assignee (whose membership is removed) | Okta User or Azure AD User | | Target (the group) | Okta Group or Azure AD Group | ## See also * [Remediation actions](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions.md) * [Remediation Log](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-log.md) * [Disable Accounts](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-disable-accounts.md) * [Revoke Direct Access in SharePoint](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-revoke-direct-access.md) * [Manage Relationships](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions/manage-relationships.md) * [Okta: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta/provisioning.md) * [Azure AD: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/azure/provisioning.md) * [Veza Query Language (VQL)](/4yItIzMvkpAvMVFAamTf/features/search/vql/vql-quickstart.md) * [Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-remove-user-from-groups.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.