Two Forests, 1,100 Ghost Accounts, One Shared POS Login
Halden Retail has 5,000 employees and has just acquired a 700-person online outlet. The two companies run separate Active Directory forests with no trust, different naming conventions, and no shared directory. Halden federates 42 SaaS applications through SAML 2.0 from its Active Directory, but the acquired company's users still authenticate to on-premises applications with local accounts. An access review last quarter found 1,100 enabled accounts belonging to people who left more than 90 days earlier, 60 of which still had mailbox delegation. Point-of-sale administration across 180 stores is performed with a single shared domain account per region, and the password is stored in a spreadsheet on a file share. Multi-factor authentication is enforced only for VPN logins. The board has asked for a plan to bring the acquisition into the same identity model within nine months without a flag-day cutover.
1. Sequence the identity integration. What do you do first, and what architecture do you recommend for the two forests?
Read the worked answer
The first action is not federation, it is the 1,100 orphaned accounts. They are live credentials nobody is watching, and 60 of them read mailboxes. Reconcile against the HR system of record, disable in bulk with an audit trail, revoke sessions and tokens, and remove the delegations before touching anything else. That work is measurable within weeks and buys credibility for the rest.
Then fix the foundation: one authoritative source per population (HR for employees, the vendor system for contractors), a unique immutable anchor attribute per person, and an attribute mapping agreed before any synchronization. Skipping this creates duplicate identities that are far more expensive to merge later than to prevent now.
Architecture. Full forest consolidation in nine months with 100-plus applications is not realistic without disruption. Recommend a cross-forest trust now: the acquired forest continues to authenticate its own users while Halden's forest provides policy baseline, and the acquired forest is treated as a controlled peer with the same password, lockout, and privileged-access policy. Federate SaaS through each population's identity provider with a single sign-on experience, and migrate applications to one forest as their lifecycles permit. The trade-off is two administrative planes and two sets of tier-0 assets to defend, so require equivalent hardening and a documented merger date; a trust is a bridge, not a destination.
Avoid dual identities for the same person in both directories. If a person must exist in both during migration, link them by the anchor attribute and define which one is authoritative for authentication.
2. The shared POS administrative account is a known problem but the vendor application supports only one administrative login. What do you actually do?
Read the worked answer
Name the failure precisely first, because it drives the fix. A shared credential per region breaks accountability (no nonrepudiation for administrative actions), breaks least privilege (everyone gets the region's full rights), and the spreadsheet turns it into a credential exposure incident waiting for a file-share compromise. A shared account with domain-wide rights is also the pivot path to a domain compromise.
Since the vendor constraint is real, contain it rather than pretend to fix it. Put the shared credential in a privileged access management vault and never let a human see it. Administrators authenticate individually, with MFA, to a jump host; the PAM injects the credential into the session; the session is recorded with keystroke and command logging; the password is rotated automatically after each checkout or on a schedule. That restores individual accountability and removes the spreadsheet.
In parallel, reduce what the shared account can do: it should not be a domain administrator. If it only needs local administrative rights on POS terminals and the POS application console, scope it there, and separate the domain-level administration into named accounts with tiered administration. Request a vendor roadmap commitment for per-user roles and track it.
Finally, treat the spreadsheet as an incident until proven otherwise: search file-share access logs for reads by accounts that should not have them.
3. What metrics would you report quarterly to the board to show the identity program is working?
Read the worked answer
Report numbers the board can act on, and pair each with a target and a trend, not a snapshot.
- Orphaned enabled accounts and, more importantly, median days from termination to disable (target under one day, automated from HR). The count is a lagging indicator; the median is the control.
- Privileged accounts under vaulting or PAM as a percentage, and the number of standing domain administrator accounts versus just-in-time elevated ones.
- MFA coverage, reported two ways: percentage of users enrolled and percentage of interactive authentications protected. The second exposes the populations that authenticate rarely but with high privilege. Note the strength of the factor, since SMS is not equivalent to phishing-resistant authenticators for administrators.
- Access recertification completion and the number of entitlements revoked versus attested without change; a recertification where nothing is ever removed is a rubber stamp and should be reported as such.
- Applications federated versus still using local accounts, with the migration burn-down against the nine-month commitment.
- Number of open exceptions (for example, shared POS accounts) with expiry dates, so exceptions cannot quietly become permanent.
Tie each metric to a decision the board owns: funding, risk acceptance, or a deadline extension. Metrics that never change a decision stop being read.