Cloud IdP Migration with Stale Accounts and Service Credentials
A 4,200-employee manufacturer is migrating from on-premises Active Directory to a cloud identity provider using SAML 2.0 and SCIM. The estate includes 310 SaaS applications, 1,150 AD security groups, and 240 service accounts. An access review found that 12% of active accounts had not authenticated in 90 days, 38% of groups have nested permissions more than three levels deep, and 17 service accounts have passwords set to never expire and are used by scheduled scripts on nine servers. The migration team proposes a big-bang cutover in six weeks, mapping every AD group to a same-named cloud group to preserve access. The CISO requires least privilege, MFA for all interactive users, and no disruption to production scheduling systems that run 24/7. The company has a change freeze during the last two weeks of the quarter.
1. Assess the same-name group mapping. What are the main risks and what would you do instead?
Read the worked answer
Mapping 1,150 AD groups one-for-one preserves the current mess in the cloud. It carries nested permissions more than three levels deep, stale accounts that have not authenticated in 90 days, and role explosion. SCIM may not replicate nested groups correctly, so effective access can differ from what the team expects. The 12% inactive accounts would receive cloud identities and potentially retain access. Least privilege is not achieved by copying groups; it is achieved by deciding which entitlements each role actually needs.
Instead:
- Inventory applications and map them to business roles, not to AD group names.
- Flatten nested groups and resolve effective permissions before migration.
- Disable or deprovision the 12% stale accounts, with owner confirmation.
- Pilot 20 to 30 low-risk applications and compare effective access before and after.
- Keep a small set of break-glass accounts outside SAML.
A same-name mapping is acceptable only as a temporary coexistence bridge with an expiration date, not as the target design.
2. How should the 240 service accounts, especially the 17 with non-expiring passwords, be handled?
Read the worked answer
SAML is for interactive users; service accounts need workload identities. Inventory all 240 by owner, purpose, host, and last use. For the 17 non-expiring accounts on nine servers, rotate passwords in a controlled sequence, but first confirm what will break: scheduled scripts, database links, and backup jobs often embed credentials.
Preferred replacements:
- Windows services: group Managed Service Accounts or managed identities.
- Cloud workloads: OAuth client credentials or workload identity federation with short-lived tokens.
- Scripts: a secrets manager with automatic rotation and no credentials in files.
- Legacy systems that cannot support modern auth: vaulted credentials with rotation, restricted network access, and monitoring.
Run changes in a staging environment and schedule production changes around the 24/7 scheduling systems. Keep a rollback credential in the vault, but do not leave it non-expiring. Add alerting for authentication from unexpected hosts. The 17 accounts are a symptom; the 240-account inventory is the real deliverable.
3. Given six weeks and a two-week change freeze, what migration sequence and controls do you recommend?
Read the worked answer
Six weeks minus the freeze leaves four working weeks, so a big-bang cutover is too risky. Use a phased plan:
Weeks 1-2: rationalize. Complete the access review, disable stale accounts, flatten critical groups, and inventory the 310 apps by criticality. Build the role map and test SCIM with a small app set.
Week 3: pilot 20 to 30 low-risk apps with a volunteer group. Enroll MFA, test provisioning and deprovisioning, and measure help-desk tickets. Keep AD as the source of truth through synchronization.
Week 4: migrate additional non-critical apps and the remaining interactive users, with a rollback path to AD federation. Do not touch the 24/7 scheduling systems before the freeze.
After the freeze: migrate production scheduling systems in a maintenance window with vendor support and a tested rollback. Keep break-glass accounts, monitor sign-in failures, and run an access review 30 days after cutover.
Controls: change approval per wave, rollback criteria, MFA exceptions documented, and no same-name group mapping without review. The CISO's least-privilege requirement is met by rationalization, not by speed.