Privileges always tell a story
An Active Directory audit that begins with "who is a Domain Admin?" misses the point. The privileges that actually matter in a living information system are almost never where you first look for them.
An audit that starts at the wrong perimeter
A client asks us for an Active Directory security audit. The scope sounds clear, almost reassuring: find the accounts to remove, cut down the number of Domain Admins, fix the obvious anomalies. The first questions coming from the teams confirm it. Who is a Domain Admin? Who holds the elevated privileges? Which accounts should be disabled?
At the start of the engagement, everyone is looking in the same direction. Sensitive privileges are assumed to sit in a handful of well-identified administrative groups; all that is needed, apparently, is some tidying up and a report.
After a few workshops, a different picture emerges. Privilege does not live only in administrator accounts. It flows across the whole information system. In a service account. In a delegation set on an OU. In a trust relationship between forests. In an API key. In a certificate issued by an internal authority. In a scheduled task that has been running for years. In a nested group nobody has opened in a long time. In the synchronisation between Active Directory and Entra ID. In a forgotten business application that still carries its old rights.
At that point the team stops chasing administrators. It starts mapping privilege. The nature of the work changes. We are no longer asking who is powerful. We are asking why the privileges exist, how they were granted, and which paths lead to them.
Every privilege was created, one day, by someone
Privileges always tell a story. Every delegation, every group, every role, every service account, every secret, every certificate exists because at some point someone made a decision. That decision had a reason — a project, a technical constraint, an operational workaround, an exception granted for a fortnight and never revoked.
Our work is to reconstruct that story. Why does this group exist? Why was this delegation put in place? Why does this application still hold those rights? Why is this technical account still active when the service it supported was decommissioned three years ago?
Very often, nobody remembers. The privilege stayed; the context is gone. We think of it as the memory of privilege. It survives projects, people, migrations and reorganisations. It is not an anomaly; it is a normal property of an information system that has been alive for a while.
A few scenes we keep encountering
Four situations we have seen recently, in different forms, across several environments. Each one looks local; together they say the same thing about how privilege quietly builds up over time.
- 01
A service account more powerful than the admins
A team discovers that a service account carries more privilege than the administrators themselves. It was created, a decade ago, to support a backup tool, or a monitoring stack, or an automation platform — the story changes, the shape is always the same. Nobody dares change its password. Nobody knows precisely which applications depend on it. It has quietly become a permanent standing privilege that no runbook mentions.
- 02
Delegations that outlived their project
A former migration project set up several Active Directory delegations on sensitive OUs so the cutover could happen on time. The project has been closed for years. The team that ran it no longer exists in the same shape. The delegations, however, are still in place. Each one is a potential attack path, and nobody in the organisation has a clear interest in removing them, because nobody has a precise memory of what they actually authorise.
- 03
Technical groups and business profiles that don't speak the same language
A business application automatically syncs Active Directory groups with its own application roles. AD administrators know the groups. Business owners know the profiles. Neither side can describe the mapping between the two precisely, let alone who defined it. The result is a business entitlement whose real technical reach is no longer readable by the people who grant it.
- 04
No direct Domain Admin, several indirect paths
An audit shows that no named user is a direct member of Domain Admins. On paper the issue is closed. In practice, a chain of delegations nested across several groups and two forests lets a completely ordinary account reach the same level of privilege. The subject is no longer the Domain Admins group. The subject is how privilege moves through the access graph. Shadow administrators are almost never labelled as such in a directory.
None of these situations shows up on a classical compliance dashboard. They only surface when we look at the relationships between objects — the identity relationships — rather than enumerating the objects themselves.
Tooling, when it earns its place
Products are not the main subject of our engagements. They come in when they help answer a question that has already been asked. Here is, briefly, how we use them in this context.
- Netwrix Auditor
- We use it to reconstruct history. Who set up this delegation, when, in what context. What privileged activity took place on sensitive objects over the last few months. It is a memory tool — the memory the organisation has often lost.
- Netwrix Access Analyzer
- We use it to rebuild the paths that lead to sensitive resources. This is the point where an audit changes character. We stop asking who is an administrator; we start asking who could, through which paths, reach equivalent privilege. It is reading the estate through attack paths, not through directory listings.
- Netwrix Directory Manager
- Once the clean-up is under way, the real question becomes: how do we prevent the same situation from rebuilding itself in three years? Directory Manager puts a frame back around day-to-day delegations. Requests become traceable, approvals are documented, temporary extensions are actually temporary.
- Microsoft Entra ID
- Privilege no longer stops at Active Directory. It flows between several directories, several SaaS platforms and several tenants. An identity can look ordinary in AD and hold real power in Entra ID through an application role or a delegated permission on an API. We map both sides, because a modern attack path routinely crosses both.
- Keeper PAM
- The vault protects technical secrets: service-account passwords, access keys, automation credentials. But before we protect a secret, we need to understand why it exists and who actually uses it. The visible part — the vault — is only useful if the invisible part — the reason — has been made explicit first.
What we want the CISO to take away
Privileges have a memory. They survive projects. Sometimes they survive the people who created them. They pass through migrations, org changes, application evolutions, mergers and acquisitions. A serious audit begins by accepting this reality: half of the work consists in recovering the original intent.
That memory also tells us something about the organisation. It shows where decisions were made under pressure, where projects were delivered half-way, where exceptions were quietly made permanent, where accountability drifted. A directory is, in the end, a form of archaeology.
An Identity Security audit is therefore not a hunt for a few administrator accounts. It is an effort to understand how privilege was built up over time, which projects it is attached to, which applications still benefit from it, and which paths can lead to it. Once that story has been reconstructed, remediation becomes coherent. When it has not, remediation simply moves the identity attack surface from one place to another.
Understand the relationships before touching the objects
Identity security is not only about protecting a handful of sensitive accounts. It is about understanding the relationships that tie together identities, groups, applications, delegations, technical accounts and secrets. It is that web of relationships, far more than a list of objects, that defines the real identity attack surface of an organisation.
We want to understand those relationships before we start any remediation. It is that understanding that later allows the tooling — Netwrix Auditor, Access Analyzer and Directory Manager, Microsoft Entra ID, Keeper PAM — to deliver its full value. Without it, an audit stays an inventory. With it, an audit becomes a decision.