Lion Cipher Lab
Find dormant, orphaned, and never-logged-in accounts
- Identity & Access Management
- Intermediate
- ~45 min
- Free · no account required
Why it matters
Every directory slowly fills with ghosts. Someone leaves and their account is never disabled. A contractor's access outlives the contract. A test account gets spun up for a migration and nobody ever cleans it up. A service account is created, forgotten, and left with the keys still in the ignition. Each of these is an enabled login that belongs to no one who is watching it -- and an attacker who finds one has a foothold that triggers no 'a real person is behaving oddly' alarm, because there is no real person. These stale identities are exactly how breaches start and how they stay quiet. The…
What you'll learn
- defining DORMANT (an enabled account with no login in more than N days), NEVER-LOGGED-IN (enabled, provisioned long ago, no login ever recorded), and ORPHANED (an enabled human account with no matching active HR record -- a leaver who was never deprovisioned) and never conflating the three
- joining two real-world exports -- a directory/identity export and an HR roster of current employees -- to find accounts that exist in the directory but belong to nobody on the active roster
- writing a pure standard-library Python tool (csv, datetime -- no pip, no network) that flags each account and rolls the directory up into a dashboard: total accounts, enabled count, counts by flag, percent of enabled accounts that are stale, and the count of dormant PRIVILEGED accounts
- spotting the single highest-risk pattern -- STILL-ENABLED-PRIVILEGED-DORMANT: an admin account that is both dormant and still enabled, standing privileged access nobody is using and nobody is watching
- pinning a fixed reference date (TODAY) inside the script so the report is deterministic and reproducible, and understanding why that matters for a check you can re-run and defend
- understanding why this DETECTIVE control is distinct from an access-recertification campaign (a human manager sign-off on who should keep access) and from joiner-mover-leaver lifecycle automation (the process that provisions and deprovisions on HR events) -- and why it exists precisely to catch what those two miss
- handling the honest negatives of last_login: break-glass accounts legitimately never log in, some service principals never record an interactive login, and staff on leave look dormant but are not -- so the correct response is disable-with-a-grace-window plus owner confirmation and an explicit allowlist, never auto-delete on dormancy
- producing a before/after result: from 4 orphaned and 2 dormant-privileged accounts (60.0% of reviewed enabled accounts stale) to 0 and 0 (0.0% stale, CLEAN), with the allowlist demonstrably cutting the false positives in between
Steps in this lab
- The three kinds of stale account -- every term, defined once
- What this is NOT: recertification vs lifecycle automation vs this
- Create the two exports -- directory and HR roster
- Write the detection tool and pin 'today'
- Measure the BEFORE directory
- The honest negatives -- why last_login lies, and the allowlist
- Remediate and measure the AFTER directory
- What you built -- and the reflexes to keep