Mover Strips Access Mid-Close, Rehire Creates a Duplicate
Every mover event from the HR source recalculates roles, and the resulting provisioning plan removes entitlements from the prior department. Last month a finance analyst moved to treasury; the plan stripped her ERP AP-approval entitlement, but month-end close still needed her to approve three legacy invoices, so a colleague approved them under her name. Separately, a leaver returned as a contractor 40 days after termination. Her AD account had already been deleted, so a new account was created with a new sAMAccountName and her mail-flow rules were orphaned. Meanwhile provisioning failures retry every 15 minutes without limit, and the task queue holds 2,100 retries covering the same 30 accounts. The role model itself has not changed.
1. How do you keep the legacy AP-approval entitlement for 45 days after the move without weakening the role model?
Read the worked answer
Decision: a time-bound exception, not a role change and not a manual grant.
- Add the entitlement via a temporary entitlement/role assignment carrying an explicit sunset date (45 days), with a documented business justification and an approver who is accountable for the expiry. The platform removes it automatically; nobody has to remember.
- Reject the two tempting shortcuts. Adding the entitlement to the treasury role grants it to everyone in treasury forever. A manual, untracked grant has no owner and will appear in the next certification as unexplained access.
- Reject the compensating control the business actually used - a colleague approving under the analyst's name - as a design input. It is a SoD violation and it means the access decision was never really made; say so in the design note.
- Verify the forward path: the mover plan ran on the next aggregation, so any temporary assignment must survive role recalculation. Confirm it is held as a direct assignment rather than derived from a role that recalculation will recompute away.
2. Set the policy for the leaver-rehire case: when is the AD account deleted rather than disabled?
Read the worked answer
Decision: disable on termination, delete only after a retention window longer than the observed rehire interval - 120 days, not 30.
Reasoning:
- The 40-day rehire is the data point. A 30-day delete window guarantees the failure repeats; the team should pull the actual distribution of rehire intervals and set the window above the observed 95th percentile, capped by whatever the directory or audit policy allows.
- Disabling preserves sAMAccountName, mailbox, group memberships and mail-flow rules. Deleting forces re-creation with a new account name - exactly the orphaned-rules outcome already suffered.
- If policy requires deletion, then the compensating control is a recorded mapping from the person to the old object identifier, plus an onboarding step that re-links and re-applies mail-flow configuration. Without that, "delete" is just "lose the configuration."
- When the contractor returns, correlation must find the disabled account and reactivate it, not create a second identity. Test the rehire path explicitly: same employee ID, existing identity, disabled link, role recalculation, provisioning enable.
Write the window into policy with the retention rationale, so it is a decision rather than a default.
3. 2,100 retries for 30 accounts are saturating the task queue. What is your remediation order?
Read the worked answer
Stop the amplification first, diagnose second, replay last.
- Pause or disable the failing provisioning tasks. An unbounded 15-minute retry turns 30 defects into 2,100 queue entries and hides the root cause in noise; it also risks this week's queue deleting tomorrow's access if a stale plan finally succeeds.
- Inspect one failed result end to end: the provisioning plan, the target's response, and whether the failure is a constraint violation (required attribute, disallowed value), a permissions problem on the target service account, or a plan that no longer matches the current role model.
- Fix the root cause on a single account and confirm a clean provision before touching the rest.
- Do not bulk-replay the queue. Those plans were built against role assignments that have since changed; replaying them applies yesterday's intent. Cancel the stale entries and let the next identity refresh regenerate correct plans.
- Change the retry setting: bounded attempts with backoff, plus an alert when failures for one account exceed a small threshold. Silent infinite retry is the actual defect here - the 30 broken accounts are the symptom.