Okta SSO Group Sync Gap: Manual UI Additions Break Okta-Driven Membership Removal – DataHub Customer Support Portal

Area: Deployment Issues

Sub-Area: SSO / Identity Provider Group Synchronization

Issue

When using Okta SSO with group extraction (groups_filter claim), DataHub reads a user's group memberships only at login time — there is no background polling of Okta. This means removals from an Okta security group do not take effect in DataHub until the affected user next signs in. Additionally, a critical and non-obvious behavior exists: the first time any member is added or removed from a DataHub group via the DataHub UI, DataHub converts all Okta-synced members of that group into DataHub-managed memberships. Once converted, Okta can no longer remove those members, even if they are subsequently removed from the corresponding Okta security group. This leads to stale memberships, apparent duplicate user rows in the UI, and a permanent loss of Okta-driven membership management for the affected groups.

Error Messages

Remove from group operation shows success in the UI but the Okta-synced user remains listed in the group

You Might Be Asking

Why do users removed from my Okta security group still appear in the corresponding DataHub group?
Why are some users appearing twice in a DataHub group?
Why does removing a user from a group in the DataHub UI not work for Okta-synced members?
Which DataHub groups are still managed by Okta versus converted to manual management?
How do I force a group membership removal for an Okta-synced user without waiting for their next login?

Solution

Understanding the Root Cause

Login-only sync: DataHub with Okta OIDC group extraction updates a user's group memberships only when that user logs in. There is no background synchronization job. A removal from an Okta security group only propagates to DataHub the next time that specific user authenticates.
UI edit triggers permanent conversion: The first time any group membership change is made via the DataHub UI (adding or removing any member), DataHub converts all existing Okta-synced memberships in that group to DataHub-managed memberships. After this conversion, the DataHub UI's "Remove from group" action will appear to succeed for Okta-synced members but will have no effect — those users remain in the group.
Duplicate rows: If a user is simultaneously on the Okta-synced list and was also added manually via the UI, DataHub renders both memberships, causing the user to appear twice. This is a display artifact of double membership — there is no duplicate user account in the backend.
Groups not yet converted: Groups whose memberships have never been edited in the DataHub UI retain full Okta-driven sync behavior. For these groups, make all membership changes in Okta only, not in the DataHub UI, to preserve this behavior.

Identifying Converted vs. Okta-Managed Groups

Contact DataHub Support to obtain a breakdown of which groups have been converted. Internally, a converted group will show members with a DataHub-managed membership aspect rather than an Okta-claimed one. Groups where no UI edits have ever been made retain clean Okta sync.

Removing Stale Members from Converted Groups (API Workaround)

Because the DataHub UI cannot remove Okta-synced members from a converted group, use the DataHub GraphQL API to rewrite the user's groupMembership aspect directly, omitting the group they should be removed from. This overwrites the entire group list for that user, so include all groups the user should retain.

mutation UpdateGroupMembership {
  upsertUserGroupMembership(
    urn: "urn:li:corpuser:user@example.com",
    input: {
      groups: [
        "urn:li:corpGroup:group-they-should-keep-1",
        "urn:li:corpGroup:group-they-should-keep-2"
        # Omit the group being removed
      ]
    }
  )
}

Replace user@example.com with the exact URN of the user and list all groups that user should remain in.

Suspending a User's Access Immediately (Optional)

To revoke sign-in access and invalidate access tokens without waiting for the next login, suspend the user via the API:

mutation SuspendUser {
  updateUserStatus(
    urn: "urn:li:corpuser:user@example.com",
    input: {
      status: SUSPENDED
    }
  )
}

The status value is case-sensitive: use SUSPENDED exactly.

Removing Manual (Duplicate) Memberships from the UI

For users who appear twice because they have both an Okta-synced membership and a manually added membership, remove the manually added entry through the DataHub UI. This collapses the duplicate row to a single Okta-synced entry and does not affect the Okta-side membership.

Preventing Future Conversion of Okta-Managed Groups

Never add or remove group members via the DataHub UI for groups that you want to remain fully Okta-managed.
Make all membership changes for Okta-managed groups in Okta only (add/remove from the security group). The change will propagate to DataHub the next time each affected user logs in.
If you need removals to apply immediately — without waiting for user login — consider migrating from OIDC group extraction to SCIM with Push Groups. SCIM provides push-based, real-time provisioning and is the supported method for immediate group membership updates. See the documentation links below for setup guidance.

Planning a Migration to SCIM or a New Identity Provider

If you plan to migrate to a new identity provider (such as Microsoft Entra ID / Azure AD) or to SCIM-based provisioning, note the following before cutover:

DataHub matches users and groups on exact email address and group name as they appear in the token. Verify that email casing is consistent between the new IdP and existing DataHub user URNs.
Entra ID sends group object IDs by default in the token claims, not group names. Confirm that your Entra ID application is configured to send group names or display names, and that the claim name matches what DataHub is configured to read (e.g., groups_filter).
Open a new support ticket when you are ready to begin the SCIM or Entra cutover so the configuration can be validated beforehand.

Additional Notes

This behavior — UI edits converting Okta-synced memberships to DataHub-managed — is a fundamental aspect of how DataHub arbitrates between SSO-claimed and manually managed group memberships. Once a group is converted, there is no automatic way to revert it to Okta-only management; the API-based rewrite described above is the ongoing remediation path until SCIM is in place. The groupMembership aspect rewrite approach permanently holds as long as the user is not in the Okta security group at their next login; if the user is still in the Okta group at login, the Okta claim will re-add them. For groups that have never been edited in the UI (and thus retain Okta-driven sync), avoid any UI-based membership changes to preserve that behavior indefinitely.