You’ve set up SCIM provisioning between your identity provider and AWS IAM Identity Center. Users are showing up correctly. But here’s the problem: a user is a member of a group in Azure AD or Okta. That group is assigned a permission set in IAM Identity Center. Yet the user still doesn’t see the account in their Access Portal. In this post, I’ll walk you through why group membership sync fails and how to fix it.
The Problem
User is confirmed as a member of a group in Azure AD/Okta. That group is assigned a permission set in IAM Identity Center. But the user doesn’t see the account in their Access Portal. Sometimes the group appears in IAM Identity Center, but the user isn’t listed as a member of it. Other times, the group doesn’t appear at all.
Common patterns:
| Symptom | Likely Cause |
|---|---|
| Group created in IAM Identity Center but no members | Group synced but membership sync hasn’t run |
| User in group in IdP, but not in IAM Identity Center group | Group membership sync is separate from group provisioning |
| Account missing from portal despite group assignment | Group membership not yet synced to IAM Identity Center |
| Duplicate group names in IAM Identity Center | Manual group created with same name as synced group |
Why Does This Happen?
-
Group not assigned to the app in the IdP: In Azure AD, Okta, and other IdPs, the group must be explicitly assigned to the IAM Identity Center enterprise application. Groups that aren’t assigned to the app are not synced.
-
SCIM sync interval hasn’t completed: Azure AD syncs every 40 minutes by default. Okta syncs every 24 hours by default unless on-demand sync is enabled. The user might have been added to the group after the last sync cycle.
-
Group membership sync is separate from user provisioning: When SCIM provisions a user, it doesn’t automatically sync their group membership. The system provisions users and groups independently. A user can be synced without their group membership being synced.
-
User was added to group after initial sync: If the user was already provisioned before being added to a group, the sync cycle that runs may not re-evaluate group memberships.
-
IAM Identity Center has duplicate groups: A manual group was created with the same name as a synced group. Assignments go to the manual group, but the user is in the synced group, so the assignment doesn’t apply.
The Fix
Step 1: Verify Group is Assigned in IdP
Azure AD:
- Go to Enterprise applications > AWS IAM Identity Center
- Click Users and groups
- Verify the group is listed and assigned (not just listed under “See more”)
- If the group is not assigned, click “Assign users and groups” and add the group
Okta:
- Go to Applications > AWS IAM Identity Center
- Click Assignments > Groups
- Verify the group is assigned to the application
- If not, click “Assign” and select the group
Step 2: Force SCIM Sync
Azure AD:
- Go to Enterprise applications > AWS IAM Identity Center > Provisioning
- Click “Restart provisioning” (this immediately starts a sync cycle)
- Check the Provisioning logs tab for errors
Okta:
- Go to Applications > AWS IAM Identity Center > Provisioning
- In the “To App” section, click the refresh icon next to the rule
- This forces an immediate sync of that provisioning rule
Step 3: Verify Group in IAM Identity Center
aws identitystore list-groups \
--identity-store-id d-xxxxxxxxxxxxxxxx \
--region us-east-1
This returns all groups. Verify the group from your IdP is in the list. If it is:
aws identitystore list-group-memberships \
--identity-store-id d-xxxxxxxxxxxxxxxx \
--group-id d-xxxxxxxxxxxxxxxx/12345678-1234-1234-1234-123456789012 \
--region us-east-1
This shows all members of the group. Verify the user is listed.
Step 4: Check for Duplicate Groups
In the IAM Identity Center console, go to Groups. Search for the group name. If there are two groups with the same name, one is likely the SCIM-synced group and one is a manual group. Delete the manual group to avoid conflicts.
Step 5: Re-Test Permission Set Assignment
Once the group membership is synced:
- Go to AWS accounts > select account > Permission sets
- Verify the permission set is assigned to the group
- Verify the permission set is provisioned to the account
- Ask the user to log out and back into their Access Portal
Wait 2-3 minutes for the portal cache to refresh.
How to Run This
- In your IdP, confirm the group is assigned to the IAM Identity Center app
- Force an immediate SCIM sync cycle in your IdP
- Wait 5-10 minutes for sync to complete
- In IAM Identity Center, run the CLI commands above to verify group and membership synced
- Check for duplicate groups with the same name
- Verify permission set assignment and provisioning
- Have user log out and back in to the Access Portal
Is This Safe?
Yes. SCIM sync operations don’t modify user data or AWS resources. They only sync identity and group membership information from your IdP to IAM Identity Center.
Key Takeaway
Group membership syncing is a separate process from user provisioning. Always verify three things: the group is assigned to the app in your IdP, the group has synced to IAM Identity Center, and the user is a member of the group in IAM Identity Center. SCIM sync cycles take time—be patient and always check the provisioning logs for errors.
Have questions or ran into a different SSO issue? Connect with me on LinkedIn or X.