Orphaned Identities, a Shared DBA Account, and a Silent Provisioning Connector
Northwind Logistics runs an 1,800-person hybrid workforce on a single identity provider. A quarterly access review surfaced 42 enabled accounts whose owners no longer appear in the HR feed; 17 of these still authenticate at least weekly, and three hold membership in Domain Admins. The root cause is that the HR-to-IdP provisioning connector has been failing silently since a schema change nine weeks ago, and the nightly reconciliation report is being mailed to a distribution list nobody reads. Separately, the database team shares one dba_admin service account across 11 engineers, with the password pasted into a team wiki page. The CISO wants every orphan account disabled today. The platform lead warns that two of the orphaned identities are still used, respectively, by an automated backup job and a nightly payment reconciliation batch, and that disabling them would stop both. The company is midway through an external audit and must produce evidence of timely deprovisioning.
1. Rank the three exposures - the 42 orphaned accounts, the shared `dba_admin` account, and the silent provisioning connector - by risk, and justify the ordering you choose.
Read the worked answer
Rank by privilege × active use × accountability, not by account count.
1. The three orphaned Domain Admin accounts. They are privileged, they authenticate weekly, and no human owns them. Any attacker who finds the credentials inherits full directory control, and every log entry will look like a legitimate administrator because the account is still "in service." There is no one to notice anomalous behaviour.
2. The shared dba_admin account. Eleven people use one credential stored in a wiki, which means the password is effectively public inside engineering, no action can be attributed to a person, and revoking one departing engineer requires breaking everyone. The blast radius is the production database, so it ranks just below domain control but above any single orphan.
3. The silent connector and the unread report. This is a control failure, not an exposure in itself - it is what keeps manufacturing new orphans. It must be fixed, but it does not directly grant access to anything.
The common wrong answer ranks by volume (42 → 11 → 1), which ignores that three domain-level identities outweigh forty low-privilege ones. Note the ranking is about current exposure; the connector is the highest-priority fix because it is the root cause and cheap to repair.
2. The platform lead says two orphaned identities drive automation. How do you proceed so the dangerous capability is removed immediately without breaking the backup and reconciliation jobs?
Read the worked answer
Separate capability from account existence, and act in the order that removes risk fastest.
Step 1 - strip privilege before disabling anything. Remove all 42 accounts from privileged groups (the three Domain Admins first) and revoke their interactive logon rights. This kills the dangerous capability within minutes while leaving the account object intact, so any dependency reveals itself as an error rather than as a silent outage.
Step 2 - triage the two automation consumers. For the backup and reconciliation identities, create dedicated service accounts: named owner, documented purpose, credentials in the vault rather than a wiki, Deny logon interactively and Deny logon through Remote Desktop, restricted to the specific hosts and time windows they need. Cut over, verify one successful run of each job, then disable the original human-shaped account.
Step 3 - disable the remaining 40 in waves. Check last logon source and any live processes bound to each account; disable in batches of ten with a short observation gap, keeping a documented break-glass account and a rollback path so a surprise dependency costs minutes, not hours.
Step 4 - force credential reset on anything that authenticated with the orphans in the last 30 days, since an unattended orphan may already be known to someone outside the company.
The judgement point: never disable a privileged orphan "temporarily" while you investigate - the privilege comes off first, the account dies second.
3. What evidence do you give the auditor for the nine-week gap, and what control changes turn this from a recurring finding into a closed one?
Read the worked answer
The auditor is testing two things: whether you can detect and remove access promptly, and whether the control will hold next quarter.
Evidence for the deficient period:
- Discovery date and method, with the raw reconciliation output showing the 42 accounts.
- A per-account record: creation date, last logon, group memberships before and after, and the timestamped action taken, tied to a ticket number and an approver.
- A statement of root cause (connector schema change) and the affected window, disclosed rather than hidden - undisclosed gaps are what turn a finding into a qualification.
Control changes:
- Heartbeat monitoring on the provisioning connector so a failed sync pages an owner within 15 minutes, rather than producing a report.
- The reconciliation report routed to a monitored queue with a named owner and a weekly sign-off, with an escalation path if unanswered for one cycle.
- Automated quarterly review of privileged group membership with manager attestation, and a standing rule that accounts with no HR record are auto-disabled after a grace period.
- A service-account inventory so automation never again runs under a human identity.
Present the post-fix state as a 30-day sample: new joiner provisioned, leaver disabled within the SLA, and the alert firing in a test. Evidence of a working control is stronger than a promise.