SCIM Deprovisioning Failures and Group Push Drift
A 9,000-user financial services firm deploys a new expense SaaS application from the OIN. The app supports SAML 2.0 and SCIM 2.0. Okta group push is configured for 48 AD groups, and application assignment is driven by those groups. Two weeks after launch, the vendor’s audit shows 620 stale accounts: 410 users deactivated in Okta 3–10 days earlier are still active, and 190 accounts have group memberships that do not match Okta. The vendor confirms SCIM PATCH is supported but filters on userName only and returns 100 records per page. The Okta org has 210,000 group memberships across the 48 pushed groups, and the vendor’s SCIM endpoint returns HTTP 429 during nightly reconciliation. The identity team wants deprovisioning within 15 minutes and no orphaned accounts. Direct app assignments were allowed during the pilot and were never removed.
1. Diagnose the 410 stale active accounts and the 190 membership mismatches. What evidence would you collect first?
Read the worked answer
Start with the Okta System Log filtered to the app and to provisioning events. Look for user deactivation events, outbound SCIM PATCH requests, HTTP status codes, and group push membership events. A 410-account pattern across 3–10 days suggests a systemic failure, not 410 separate mistakes.
The most likely causes are: direct app assignments left over from the pilot, so removing group membership does not remove the app assignment; the provisioning action set to something other than Deactivate; SCIM PATCH returning 200 while the vendor ignores active=false; and 429 responses causing retries that never complete. The 190 membership mismatches point to group push limits or nested AD groups: group push does not necessarily flatten nested groups the way a policy group does, and the vendor pages at 100 records, so a reconciliation that stops after the first page will miss users.
Collect the app’s SCIM audit log, the Okta app provisioning log, and a sample of 10 affected users. Confirm whether each has a direct assignment, whether Okta sent active=false, and what HTTP response the vendor returned. Do not bulk-deactivate until you know whether the app supports delete, deactivate, or both.
2. Design a remediation and ongoing reconciliation process that meets the 15-minute deprovisioning goal and avoids orphaned accounts.
Read the worked answer
First remove all direct app assignments and make group membership the only assignment path. Set the app’s deprovisioning action to Deactivate, not None, and confirm with the vendor that PATCH active=false is honored. For the 410 stale users, export the vendor’s user list, match on a stable key such as employeeNumber or externalId, and deactivate the orphans in controlled batches after validating the first 20.
For 15-minute deprovisioning, do not rely only on group push or a nightly reconciliation. Add an Okta Workflows flow triggered by user deactivation that immediately calls the vendor’s SCIM endpoint for that user. Keep a scheduled delta reconciliation as a safety net, but make it idempotent: paginate all pages using startIndex and count, compare against Okta, and only patch differences. Handle 429 with exponential backoff and jitter, respect Retry-After or X-Rate-Limit-Reset, and cap concurrency. Alert to the SIEM when a deprovisioning PATCH fails twice.
Finally, test with a pilot group: deactivate a user, confirm the vendor loses access within 15 minutes, and verify the System Log shows a successful outbound request.
3. The vendor filters on userName and the company’s email addresses change after marriage. How should userName be mapped, and what would you do about the existing mismatches?
Read the worked answer
Do not let a mutable email address be the only matching key. If the app allows it, map userName to an immutable employee ID or subscriber ID, and map email separately as a mutable attribute. If the app requires userName to look like an email, use an app username override that is stable and not the person’s primary email. Store the Okta user ID or employeeNumber in the app’s externalId field so reconciliation never depends on email.
For the 190 existing mismatches, do not bulk-rename by email. Export the vendor’s users, match them to Okta on employeeNumber or legacy subscriber ID, and build a mapping table. Update userName in controlled batches, and verify that the app’s unique constraint does not create a second account. If the vendor cannot change userName without creating a new record, escalate to the vendor for a data migration rather than accepting duplicates.
Document the rule for the service desk: an email change updates the email attribute, not the app userName. Add a test case to the pre-production checklist that changes a user’s email and confirms the app still matches the same account.