Finding the Privileged Accounts

Scoping a programme requires knowing what exists. The count is always higher than the estimate, frequently by a large multiple.

The directory

Start here. Membership of administrative groups, resolved through nesting.

Nesting is where the surprises are. A group added to a group added to Domain Admins five years ago, containing a team that has since doubled.

Resolve transitively rather than reading the direct membership, which is the mistake that makes the first count look reassuring.

Include accounts with delegated rights on organisational units, which do not appear in group membership at all.

Include accounts with rights over other accounts — password reset, group modification — which are privilege paths rather than privileges.

Endpoints

Local administrator group membership on every server and workstation, from endpoint management.

Expect inconsistency. Local groups drift, and a machine imaged three years ago has different membership from one imaged last week.

Look for the domain user group in local administrators, which happens and grants everyone administrative rights on that machine.

Look for accounts local to the machine, created outside any process.

Unix and Linux

Root, obviously.

Sudo configuration, parsed rather than assumed. Broad sudo rules are common and frequently grant more than intended.

SSH authorised keys, per host, which is a distribution problem with no central record in most estates.

Accounts with UID zero other than root, which occasionally exist.

Cloud platforms

Role assignments at every scope, which is a larger and more granular problem than on-premises.

Identities with permissions to modify permissions, which is the cloud equivalent of tier zero.

Federated identities and trust relationships into the tenant.

Access keys belonging to identities, which are long-lived credentials outside any interactive control.

Cloud is where standing privilege now concentrates and where discovery is most often incomplete.

Applications and databases

Database administrative accounts, including built-in ones that were never disabled.

Application administrators in each business system, which requires asking each system owner because no central source has it.

Integration accounts between applications, which frequently hold broad rights.

Service accounts

The largest and least documented category, covered in its own note.

Sources: services on Windows hosts, scheduled tasks, application configuration, connection strings, pipeline variables, and asking people.

None of these is complete, and the combination is still not complete.

Recording what you find

Per account: name, system, type, tier, what it can do, who owns it, whether it is shared, how it authenticates, and when its credential last changed.

Nine fields, and the last one is usually the most alarming when first populated.

The first pass finding

Consistently, in order of how often it appears:

Accounts belonging to people who left.

Nested groups granting rights nobody intended.

Service accounts with domain administrative rights for no current reason.

Credentials unchanged for years.

Local administrator rights granted to everyone on some subset of machines.

Break-glass accounts nobody documented, used regularly.

Each is a finding worth acting on before any product is purchased.

Nested groups

The specific place where the first count looks reassuring and is wrong.

Direct membership of an administrative group is not the answer.

Resolve transitively, following every nested group to its leaf members.

Look for groups added years ago whose membership has since grown.

Look for groups that mirror an organisational unit, which grows with headcount.

Look for cross-domain and cross-forest membership, which is easy to miss.

Compare the direct count against the transitive count and report both. The gap is usually large and it is the most persuasive single number in the initial assessment.

The stale account sweep

The cheapest early win, available before any product is purchased.

Privileged accounts with no authentication in ninety days.

Accounts belonging to people no longer in the directory.

Accounts created for projects that ended.

Accounts whose owner cannot be identified.

Disable rather than delete, which is reversible and removes most of the objection.

Wait a defined period, then delete.

Expect a meaningful proportion of the privileged population to fall out, which reduces exposure immediately and costs nothing but the review time.