Mapping Privilege Paths

An inventory of privileged accounts misses the more important question: who can obtain those accounts, through how many steps.

What a path is

A sequence of permissions that ends in administrative control.

Someone who can reset an administrator's password is effectively an administrator. So is someone who can add themselves to a group, modify a scheduled task running as a privileged account, or deploy code to a privileged host.

None of these appears in a membership list.

The common paths

Password reset rights over a privileged account.

Group modification rights over a group that grants privilege.

Ownership of a directory object, which permits changing its permissions.

Delegated control on an organisational unit containing privileged accounts.

Write access to a script or scheduled task that runs privileged.

Deployment rights to a privileged host.

Backup and restore rights, which permit reading anything and restoring into a controlled environment.

Hypervisor access to a privileged virtual machine.

Console or physical access.

Credential material left on a host that a lower-privileged account can read.

Why paths matter more than accounts

They are invisible to a membership review.

They are numerous, and a large estate has thousands.

They cross tiers, which is the specific failure: a workstation administrator reaching a server, a server administrator reaching the directory.

One path defeats the whole model. Tiering that is enforced everywhere except one forgotten scheduled task is not tiering.

Mapping them

Graph tooling exists for directory environments and is the practical route.

Cloud platforms have their own analysis tools for permission paths.

Where tooling is unavailable, the manual version is: for each tier zero object, list who can modify it, then recurse.

Expect the result to be uncomfortable, including paths from ordinary user accounts to full control in a small number of steps.

Closing them

Start with the shortest paths to tier zero.

Remove the permission where it is not needed, which is most cases and is the cheapest fix.

Break the tier crossing. Enforce that tier zero credentials are never used on lower-tier systems, and that lower-tier administrators cannot modify tier zero objects.

Protect the credential material on hosts, since credential reuse across tiers is the mechanism most paths rely on.

Re-run the analysis after changes, because closing one path frequently reveals another and because new paths appear with every change.

The tiering rule that matters most

A credential used on a system is available to whoever controls that system.

From which follows: a domain administrator who logs into a workstation has given domain administrative rights to whoever controls that workstation.

Enforce it technically, through logon restrictions, rather than by policy. Administrators will otherwise do it during an incident, reasonably, and the exposure is created in one login.

Keeping it current

Re-run monthly where tooling allows.

Re-run after any structural change — a migration, a merger, a new platform.

Track the number of paths to tier zero as a programme metric. It is objective, it responds to work, and it is a better measure of exposure than any count of accounts.

Running the analysis

Graph tooling exists and the output needs interpreting rather than acting on wholesale.

Run it against a copy of directory data, not against production, for the first pass.

Start from tier zero objects and work backwards.

Rank paths by length. Short paths from ordinary accounts are the urgent findings.

Ignore paths that require capabilities you already control, which removes noise.

Expect thousands of paths in a large estate and expect a small number of permissions to account for most of them.

Fix the permissions, not the paths. Removing one over-broad delegation frequently closes hundreds.

The tier crossing rule

The single rule that closes more paths than any other, and the one broken most often under pressure.

A credential used on a system is available to whoever controls that system.

Therefore tier zero credentials are never used on lower-tier systems.

Enforce it technically through logon restrictions, not by policy, because during an incident a reasonable person will do the convenient thing.

Alert on any tier zero authentication to a lower tier, which should be zero and rarely is at the start.

Give administrators a workable alternative — separate accounts per tier and a fast path to each — or the rule will be broken and the breaking will be justified.