<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D5WR00001frBWn0AMOkta Classic EngineAdministrationAnswered2026-05-26T21:42:09.000Z2026-05-20T15:03:58.000Z2026-05-26T21:42:09.000Z

NiviM.71991 (Customer) asked a question.

May 20, 2026 at 3:03 PM
Debugging Group Assignment Issue

I'm trying to debug an issue with assignment of users to groups.

 

I'm using OKTA API to assign users to groups, using the endpoint {OKTA_DOMAIN}/api/v1/groups/{group_id}/users/{user_id}"

 

The request fails with the following:

Add-to-group [403]: {"errorCode":"E0000006","errorSummary":"You do not have permission to perform the requested action","errorLink":"E0000006","errorId":"xxxxx","errorCauses":[]}

2026-05-20 17:58:37,436 [ERROR] Failed [403]: {"errorCode":"E0000006","errorSummary":"You do not have permission to perform the requested action","errorLink":"E0000006","errorId":"xxxxxxx","errorCauses":[]}

 

I know what the error E0000006 means but I need more details. I know of a few cases where this error is thrown when trying to add users to groups but none of them fit my case. I do have the errorId but I tried to look it up in the system logs and I get nothing.

 

How can I get more details why the request failed to add the user to the group?

  • 4 answers
  • 84 views

  • NiviM.71991 (Customer)

    Hi @Paul S. (Okta, Inc.)​ 

     

    Thanks for the detailed answer. It helped me pinpoint the issue.

     

    The app has a custom admin role that is restricted to specific resources. The solution was to add the group in question to the list of resources that the role can manage.

     

    Thank you!

    Expand Post
    Selected as Best

  • Paul S. (Okta, Inc.)

    Hello @NiviM.71991 (Customer)​ Thank you for posting on our Community page!

     

    The reason you aren't seeing this errorID in your System Logs is that 403 Forbidden errors are often blocked at the API authorization layer. Because the request was denied before it could actually attempt to modify the resource, Okta doesn't register it as an auditable event (like group.user_membership.add), meaning it never makes it into your tenant's visible logs.

    Since the Okta UI won't give you the exact trace for that errorId, here is how you can track down the root cause, along with the steps to get the literal details behind that ID.

    Things you can check right now:

    A. Inspect the Group's "Source" and "Type"

    This is the most common culprit. You cannot manually add a user via API to a group that is managed by another system or by Okta rules, even if you are a Super Admin.

    • Action: Make a GET request to {OKTA_DOMAIN}/api/v1/groups/{group_id}.
    • What to look for: Look at the type and the source object in the JSON response:
    • If the type is BUILT_IN or APP_GROUP (e.g., it is sourced from Active Directory, LDAP, Workday, or Google Workspace), you will get a 403 when trying to add a user via API. You must add the user in the downstream application.
    • If it is an Okta-mastered group but uses Group Rules (dynamic membership), you cannot use the API to explicitly add a user.

    B. Verify the Token's Scope / Admin Privileges

    The way you are authenticating matters. A 403 means the token is valid, but the entity behind it lacks the specific right to map that user to that group.

    • If using an SSWS API Token: The token inherits the exact permissions of the user who generated it. Check that user's Admin roles. Do they have Group Admin or User Admin? If they are a custom admin, check the Resource Set. They must have permissions over both the target user's group and the target group itself.
    • If using OAuth 2.0 (Service App): Ensure the application has been granted the okta.groups.manage scope. Additionally, if your Okta tenant uses Custom Admin Roles, check the Admin Role assigned to the Service App and ensure its Resource Set includes the specific group you are modifying.

    C. Cross-Check the User's State

    Check the status of the {user_id}you are trying to add.

    • Action:GET {OKTA_DOMAIN}/api/v1/users/{user_id}
    • What to look for: If the user is DEPROVISIONED or SUSPENDED, adding them to a group will occasionally throw a 403 instead of a 400 or 404, depending on the admin's scope.

     

    Thank you for reaching out to our Community and have a great day!

    --

    Help others in the community by liking or hitting Select as Best if this response helped you.

    Expand Post

  • NiviM.71991 (Customer)

    HI Paul,

     

    Thank you for the detailed response.

     

    • The group is OKTA managed
    • It doesn't have any admin roles attached to it
    • It doesn't have any user assignments by group rules
    • The Service App has the required scopes

     

    One thing I forget to mention is that it only happens to a specific user. The Service App can add other users to the group but not this specific user. The user is active and not suspended or anything like that. What should I look for in the user to determine why they cannot be added to the group?

     

    Thanks!

    Expand Post

    • Paul S. (Okta, Inc.)

      Hello @NiviM.71991 (Customer)​  In this case if this is affecting only one user the root cause could be:

      1. The Target User Has Higher Admin Privileges (Role Hierarchy)

      Okta strictly enforces admin hierarchy. A Service App (whether using an API token tied to a service account or OAuth 2.0 scopes with assigned admin roles) cannot modify a user who holds a higher administrative privilege than the app itself.

      • The Scenario: Your Service App is assigned a "Group Administrator" or "Helpdesk Administrator" role. The specific user you are trying to add is a "Super Administrator" or "Org Administrator."
      • The Result: Okta blocks the lower-privileged Service App from modifying the higher-privileged user, throwing a 403.
      • What to check: Go to the specific user's profile in the Okta Admin Console -> Admin Roles tab. See if they have an admin role assigned that the successful users do not.

      2. The User is Outside the Service App's "Resource Set"

      If your Service App relies on Okta's Custom Admin Roles, the app's permissions are bound by a specific Resource Set (the scope of who and what it can manage).

      • The Scenario: The Service App's custom role only allows it to manage users in "Group A" and "Group B". The successful users belong to those groups, but the failing user does not.
      • The Result: The App lacks the authority to manage that specific user, resulting in a 403.
      • What to check: Review the admin roles assigned to your Service App. If it uses a Custom Admin Role, check the Resource Set to ensure the failing user falls within its management boundary.

      3. The User is Already Managed by a Group Rule

      While adding a user who is already in a group usually returns a 200 OK (idempotent) or a 400 error, conflicting automation can sometimes trigger permission blocks depending on how the group is mastered.

      • The Scenario: The user is already assigned to this group via a Group Rule or through directory integration mappings (like AD/LDAP).
      • The Result: Because Okta evaluates that the user's membership is strictly managed by a rule or an external directory, it explicitly denies manual/API manipulation of that membership.
      • What to check: Check the user's "Groups" tab. Are they already in the group? If so, does it say "Managed by Rule" next to it?

       

      Expand Post

  • NiviM.71991 (Customer)

    Hi @Paul S. (Okta, Inc.)​ 

     

    Thanks for the detailed answer. It helped me pinpoint the issue.

     

    The app has a custom admin role that is restricted to specific resources. The solution was to add the group in question to the list of resources that the role can manage.

     

    Thank you!

    Expand Post
    Selected as Best

Loading
Debugging Group Assignment Issue