Big-Bang Identity Consolidation Before Peak Season
Following an acquisition, Northwind (1,100 staff, identity provider A) now shares a parent with Harrow Logistics (480 staff, identity provider B). Both issue SAML assertions to the same CRM, expense platform and HR system, and 60 percent of Harrow's staff need access to both. The integration team has proposed a 30-day big-bang cutover: recreate all 480 Harrow accounts in tenant A, disable tenant B, and re-enrol MFA in a single weekend. Discovery also found 180 service accounts with static passwords, a spreadsheet holding 40 shared credentials for the WMS and label printers, and 340 Harrow accounts with no identifiable owner because the HR feed was never connected. Harrow's peak season starts in nine weeks and the warehouse cannot tolerate an authentication outage during it. Leadership wants one directory and one login as fast as possible.
1. Evaluate the 30-day big-bang plan and propose a sequence.
Read the worked answer
The plan fails on three counts: it lands during peak season, it makes an irreversible change in one step, and it rebuilds accounts instead of migrating identity.
- Recreation destroys permissions. New accounts in tenant A get new object identifiers, so file ACLs, mailbox delegations, application authorisations and distribution lists break - usually silently, usually discovered by warehouse staff at 2 a.m.
- MFA re-enrolment is a people problem. 480 users in one weekend turns the helpdesk queue into the outage.
- Peak season is a hard constraint. Nine weeks out, no authentication change should be in flight when the scanners need to authenticate.
Better sequence: connect the HR feed and clean the 340 ownerless accounts first (low risk, high value); establish federation so Harrow users reach shared SaaS with existing credentials; then migrate in cohorts ordered by application criticality - expense and HR before CRM, warehouse systems only after peak - with dual trust during the overlap and a tested rollback. Each cohort needs a named owner, a go/no-go check and a rollback trigger.
2. How do you remediate the 180 service accounts and 40 shared passwords, and why not rotate everything at once?
Read the worked answer
Rotate by blast radius, not alphabetically. Changing 220 credentials in one window is a self-inflicted outage: label printers drop offline, the WMS integration fails, and nobody can say which credential broke what.
Order:
- Inventory and dependency map - for each account, the owner, the systems that authenticate it, and whether it holds interactive, server or domain rights.
- Highest privilege first - any service account with domain or server admin rights, anything used by backups, and anything used by the integration platform. Move to group managed service accounts or managed identities where the platform supports it; otherwise vault with checkout and automated rotation.
- Then shared human accounts - eliminate them by issuing named accounts; where impossible short term (printer administration), vault them with checkout logging so every use is attributable.
- Break-glass accounts into the vault under dual control, excluded from routine rotation, tested quarterly.
After each batch, watch authentication failures so breakage is attributed rather than guessed at. The principle is that a shared credential is an accountability gap as much as a security one.
3. How do you safely determine which of the 340 ownerless accounts to disable?
Read the worked answer
Ownerless accounts are a finding, not a deletion list. Start with a source of truth: connect the HR feed, then match accounts against active employees and contractors. For the residue:
- Check last interactive and non-interactive logon, and where the authentication came from. An account with recent service logons from a server is probably a service identity nobody documented.
- Look for dependencies before touching it: scheduled tasks, IIS application pools, SQL jobs, mailbox rules, certificate templates.
- Require manager attestation with a deadline that has a consequence - no reply means default deny.
Then stage it: notify, block sign-in while retaining mailbox and data for 30 days, watch the helpdesk, then disable, and only later consider deletion with retention policy applied.
The reason not to delete today is that ownerless in the CMDB does not mean unused in the business, and the data behind the account may be the only copy of something. 'We deleted it' is not a defensible answer six weeks later.