Federating an Acquired Identity Estate in 90 Days
Harborline Logistics (6,200 staff on a single corporate identity provider) has acquired a 400-person freight broker with 1,850 accounts in its own separate directory tenant. The acquired estate carries 340 accounts with no sign-in for more than 90 days, 12 service accounts that are used for interactive logon with passwords stored in a shared spreadsheet, and 60 contractors from three staffing agencies sharing a generic 'contractor1' account. The acquired tenant has 22 domain administrators; the parent has five. Leadership has promised 'single sign-on within 90 days'. One critical warehouse management system supports only SAML 2.0 with a persistent NameID containing the user's email address, and the parent's email domain migration is scheduled for month five.
1. Sequence the 90-day identity integration. What must happen first, and what would you deliberately defer?
Read the worked answer
Order of operations: identity hygiene, then authentication, then authorisation. Doing it backwards imports the problem into the parent.
Days 0–30 - clean before connecting:
- Reconcile the 1,850 accounts against HR and agency rosters. Disable the 340 dormant accounts after owner confirmation; the risk of a wrong disable is smaller than 340 unmonitored credentials surviving a migration.
- Inventory entitlements and surface accumulated privilege. The 22 domain admins is the finding, not the migration.
- Establish HR joiner/mover/leaver feeds before cutover, or every subsequent mover is a manual ticket and eventually a wrong one.
Days 30–60 - connect:
- Federate the acquired tenant rather than re-creating users in the parent, using cross-tenant sync or a one-way trust so apps can be cut over individually.
- Enforce MFA and conditional access in the acquired tenant immediately. This is a genuine quick win independent of the parent and should not wait for the integration.
Days 60–90 - migrate applications, not users:
- Cut SSO apps in order of risk × dependency. Anything touching privileged access goes early.
Deliberately defer: the email domain migration (it breaks NameID - see the federation question), full group rationalisation, and collapsing the two tenants into one. Tenant consolidation is a 12-month programme and would consume the entire window. The 90-day goal should be 'one authentication authority per user and MFA everywhere', not 'one tenant'.
2. How do you handle the 340 dormant accounts, the 12 service accounts and the 60 contractors before and after cutover?
Read the worked answer
Dormant accounts. Disable first, delete after 30 days with no objection, logging owner and date. Do not carry them across the federation - dormant accounts in a tenant you are about to trust become dormant accounts in the parent. Where someone is on extended leave, disable and record a reactivation path.
Service accounts (12 with interactive logon, passwords in a spreadsheet). These are the highest-severity item and the least likely to be fixed by the deadline. Order of work:
- Replace interactive logon where the platform supports it - group managed service accounts, managed identities, workload identity, or certificate-based auth. The spreadsheet is proof there is no rotation process.
- Where replacement is impossible, vault the credential, rotate it, restrict logon to named hosts, and alert on interactive sessions.
- Never federate a service account as a user object. They are machine secrets, not identities capable of MFA.
Contractors (60, three agencies, one shared account). A shared account destroys attribution and invalidates every least-privilege claim you will make to an auditor. Issue named accounts sponsored by a hiring manager, with an expiry equal to the contract end, MFA enforced, and access scoped to a single site or system. Require agency notification of terminations and review the roster monthly for the first quarter.
Privileged accounts. Reduce the 22 domain admins to a small set, separate admin accounts from daily-use accounts, and place them in a privileged access management tool with checkout and session recording. Do this before federation so excess privilege never becomes visible through the parent's trust.
3. The warehouse system requires a persistent NameID containing email, and the parent changes email domains in month five. What federation design do you choose, and why?
Read the worked answer
The constraint: SAML NameID must be persistent and stable for the life of the account. If the value changes, the application either creates a duplicate account or fails to match it - and a warehouse management system failing at shift change is an operational incident, not a ticket.
Options:
- NameID = immutable object identifier (directory immutable ID or objectGUID), with the application's user records re-provisioned to that value during a controlled cutover. Best answer where the application accepts an arbitrary NameID or can be re-mapped once.
- NameID = current email, frozen. Do not let the domain migration change the UPN or mail attribute for warehouse users until the app is cut over or re-integrated. Works only if you control attribute flow and can genuinely pin it.
- NameID = a dedicated pseudonymous identifier generated and stored as an attribute, used only for this application. This decouples you from both email and directory changes and is the right answer if custom attributes are supported.
Recommendation: test option 1 with a ten-user pilot in a non-production tenant. If the application rejects an immutable ID, fall back to option 3, not option 2 - pinning an email attribute is fragile precisely when you have a scheduled change that everyone knows is coming.
Regardless of choice: provision the app just-in-time from the directory, keep a vaulted and monitored emergency local account for when federation fails at 06:00, and schedule cutover outside peak shipping. Test the failure path deliberately; the emergency account nobody has tested is not a control.