Your SCIM sync is complete. Users and groups are showing up correctly in IAM Identity Center. You’ve created a permission set and assigned it to a group for a specific account. But when the user logs into their Access Portal, the account still doesn’t appear. Or the account appears but the permission set is missing. In this post, I’ll show you how to diagnose and fix assignment visibility issues.

The Problem

Group assignment to an account and permission set was created in IAM Identity Center. SCIM shows users and groups successfully synced. But the account still doesn’t appear in the user’s Access Portal. Sometimes the account appears but when the user tries to assume the role, they get a permission denied error.

Common patterns:

Symptom Root Cause
Assignment created but account missing from portal Permission set not yet provisioned or provisioning failed
Assignment visible but permission denied error Inline policy in permission set has an error
Account appears after 5+ minutes but not immediately Permission set still provisioning to account
Assignment disappears after appearing Deprovisioning happened due to group membership change

Why Does This Happen?

  • Permission set assigned but not provisioned: Creating an assignment is not the same as provisioning. The assignment says “apply this permission set to this account for this user/group.” Provisioning actually creates the IAM role in the target account. If provisioning fails, the user can’t access the account.

  • Propagation delay: Even after provisioning succeeds, there can be a 1-5 minute delay before the assignment appears in the user’s Access Portal. The portal caches the assignment list.

  • User portal session cached: The user’s Access Portal page was loaded before the assignment was created. They’re looking at a cached version. Logging out and back in refreshes the cache.

  • Account recently added to organization: If the account was recently added to AWS Organizations, provisioning to that account takes time. The account must be in an active state.

  • Permission set has an inline policy error: If the permission set has an inline policy with a syntax error, provisioning will fail silently. The assignment appears created, but it can’t be provisioned.

The Fix

Step 1: Verify Permission Set is Assigned

In IAM Identity Center, go to AWS accounts > select account > Permission sets.

Check that the permission set is listed here. If it’s not in this view, it hasn’t been assigned to this account yet. Go back and create the assignment:

  1. Go to AWS accounts > select account > Permission sets > Assign permission set
  2. Select the permission set
  3. Select the user or group to assign it to

Step 2: Verify Provisioning Status

After assignment is created, provisioning must complete. Use the CLI to check:

aws sso-admin list-permission-sets-provisioned-to-account \
  --instance-arn arn:aws:sso:::instance/ssoins-7223a5d90eexample \
  --account-id 123456789012 \
  --region us-east-1

If the permission set ARN appears in the output, it’s provisioned. If it doesn’t appear, provisioning hasn’t started or failed.

Step 3: Force Re-Provisioning

If the assignment is created but not provisioned, manually trigger provisioning:

aws sso-admin provision-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-7223a5d90eexample \
  --permission-set-arn arn:aws:iam::aws:permission-set/sso_ps/ssoins-7223a5d90eexample/ps-a1b2c3d4e5f6g7h8 \
  --target-id 123456789012 \
  --target-type AWS_ACCOUNT \
  --region us-east-1

Wait 2-3 minutes for provisioning to complete.

Step 4: Check for Permission Set Errors

If provisioning still fails, the permission set itself may have an error. Go to Permission sets > select permission set > Details.

Check:

  • Inline policy: Click “Edit” and validate the JSON syntax. Use an AWS policy validator if unsure.
  • Customer managed policy attachments: Verify all attached policies still exist.
  • Permissions boundary: If set, verify it’s valid.

If there’s a syntax error, fix it and re-provision.

Step 5: Force Portal Cache Refresh

Once provisioning is confirmed successful:

  1. Ask the user to log out of the Access Portal
  2. Clear cookies for awsapps.com in the browser
  3. Ask the user to log back in

The account should now appear.

How to Run This

  1. In IAM Identity Center console, go to AWS accounts > select account > Permission sets
  2. Verify the permission set is listed
  3. If not, create the assignment
  4. Run the list-permission-sets-provisioned-to-account CLI command to verify provisioning status
  5. If not provisioned, run the provision-permission-set command
  6. Wait 3 minutes and re-run the list command to verify success
  7. Ask user to log out and back into the portal
  8. Test: user should now see the account and be able to assume the role

Debug: Check for Inline Policy Errors

To validate a permission set inline policy:

aws sso-admin get-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-7223a5d90eexample \
  --permission-set-arn arn:aws:iam::aws:permission-set/sso_ps/ssoins-7223a5d90eexample/ps-a1b2c3d4e5f6g7h8 \
  --region us-east-1

If an inline policy is attached, validate its JSON syntax using the AWS Policy Simulator or a JSON validator.

Is This Safe?

Yes. Re-provisioning a permission set creates IAM roles in the target account. This is a standard operation and doesn’t affect existing role or policy configurations.

Key Takeaway

Assignment and provisioning are two separate steps. Always verify both are complete. Use the CLI to check provisioning status before asking the user to test. A 3-5 minute propagation delay is normal—don’t force a fix immediately after creating an assignment.

Have questions or ran into a different SSO issue? Connect with me on LinkedIn or X.