Active Directory Security: Structure, Tiering & Hardening

Active Directory is the directory service that most Windows networks are built on. It decides who a user is, what they can reach, and which machines trust which. When people talk about an organisation getting "fully compromised", they usually mean the attacker reached Domain Admin in Active Directory and could then do anything, anywhere, as anyone.

What makes AD hard to defend is that attackers rarely break it by finding a single dramatic vulnerability. They win by accumulation: a foothold on one workstation, a set of dumped credentials, a reused local admin password, an overprivileged service account, and a path that leads step by step to the top. Defending AD is about removing those steps.

How Active Directory is structured

AD organises identity into a nested hierarchy. Understanding the layers matters because attackers navigate them.

Forest. The top-level container and the true security boundary in AD. Everything inside a forest shares trust by design. When people say the forest is the security boundary, the point is that you cannot fully trust one domain to contain a compromise in another domain of the same forest.
Domain. A management and replication boundary within a forest, with its own set of users, computers, and policies. A large organisation may run several domains in one forest.
Organizational Units (OUs). Containers inside a domain that group objects for delegation and for applying Group Policy.
Objects. The actual entities: user accounts, computers, groups, service accounts.

Two elements deserve special attention. Domain controllers (DCs) are the servers that host the directory and authenticate everyone. Group Policy pushes configuration and security settings across the domain, which makes it both a powerful management tool and, if abused, a powerful attack tool.

Three more concepts shape the security picture. Trusts connect domains and forests so that identities in one can be granted rights in another. A trust that was created for a long-gone business reason, or one that reaches into a forest you no longer fully control, extends your risk surface into places your monitoring may not cover. Security identifiers (SIDs) are the immutable values that actually carry authorisation inside Windows, and the SID history attribute, designed to preserve access during migrations, can carry privileged SIDs from an old domain into a new one. Access control lists (ACLs) on directory objects decide which accounts can read, modify, or take ownership of other accounts, groups, and organisational units. Most escalation paths that defenders miss live in these ACLs, because a single object whose permissions let a low-privilege group reset a high-privilege password quietly links the two together.

Understanding these layers matters for one practical reason. Defenders who picture AD as a list of servers will harden servers. Attackers picture it as a web of rights and will walk the web. The gap between those two mental models is where most standing risk sits.

The domain controller is the crown jewel

Every domain controller holds the material needed to authenticate and impersonate any account in the domain, including the krbtgt key behind every Kerberos ticket. Code execution or memory access on a DC is effectively game over for the domain. Treat domain controllers as the most protected systems you run, with the tightest access, the fewest installed roles, and the most monitoring.

Why AD gets compromised

The typical intrusion is a chain, not a single leap. It usually looks like this:

Initial foothold on an ordinary workstation, through phishing, a stolen VPN or RDP login, or a vulnerable service.
Credential harvesting from that machine: cached credentials, tokens in memory, or password reuse. This maps to MITRE ATT&CK T1003, OS Credential Dumping.
Lateral movement to other machines using the harvested credentials, often over SMB or RDP.
Privilege escalation by finding a path to a more privileged account, frequently an overprivileged service account, a misconfigured delegation, or a reused local administrator password.
Domain dominance once a Domain Admin credential or the krbtgt key is in hand.

Notice how little of this involves a software vulnerability in AD itself. The fuel is credentials and misconfiguration. The most common enablers are depressingly consistent:

Accounts with far more privilege than their job needs.
The same local administrator password on many machines, so one dump unlocks many hosts.
Service accounts with weak passwords and excessive rights.
Privileged accounts used to log into ordinary workstations, leaving their credentials in reach of an attacker who owns that workstation.
No monitoring of changes to privileged groups.

It helps to think about AD the way attackers do, as a graph of relationships rather than a list of machines. Every account that can log into a machine, every group that grants rights over another object, and every delegation that lets one identity act as another forms an edge. Attackers enumerate those edges to find a path from where they landed to Domain Admin, and that path is often far shorter than defenders expect. A single overprivileged helpdesk group or a service account with rights it never uses can collapse a dozen apparent steps into two. Defending well means finding and cutting those edges before an attacker walks them, which is why privilege reduction, not patch cadence, is the center of AD security.

How authentication works and why it is a target

Two protocols carry almost all authentication in an AD environment, and knowing how they behave tells you what to watch.

Kerberos is the primary protocol. A user proves their identity once and receives a ticket-granting ticket, then requests service tickets for the resources they need. The domain controller signs those tickets with the krbtgt account key. This is why the krbtgt key matters so much: an attacker who obtains it can mint tickets for any account, and those tickets look legitimate to every service in the domain. Kerberos ticket abuse maps to MITRE ATT&CK T1558, Steal or Forge Kerberos Tickets, and it is the reason a krbtgt compromise is treated as a full-domain event that requires a careful double reset of that account.

NTLM is the older challenge-response protocol that Windows still falls back to in many situations. It does not rely on tickets, which means it leaves less useful audit detail and it enables relay and pass-the-hash style credential reuse. Many hardening programs work to reduce NTLM usage precisely because it is harder to monitor and easier to abuse than Kerberos.

Service accounts sit at the intersection of both protocols and cause an outsized share of escalation. Any account configured with a service principal name can have a service ticket requested for it, and the encrypted portion of that ticket can be taken offline for password cracking. The defensive answer is not a single control but a posture: long random passwords or group managed service accounts, minimal rights, and monitoring of the service ticket requests themselves.

Legacy protocols widen the attack surface quietly

NTLM, unconstrained delegation, and old cipher suites often remain enabled for backward compatibility long after the application that needed them is gone. Each one gives an attacker a quieter path than modern Kerberos would. Inventory where legacy authentication is still accepted, retire what no application depends on, and put extra monitoring on whatever must stay.

The tiered administration model

The single most important structural defense is separating administration into tiers so that credentials from a high-privilege level are never exposed on a lower-privilege machine. Microsoft frames this in its enterprise access model. The classic three tiers:

Tier	Contains	Rule
Tier 0	Domain controllers, AD, identity systems, the accounts that control them	Tier 0 credentials are used only on Tier 0 systems
Tier 1	Servers and applications	Tier 1 admins manage servers, never log into Tier 0 or workstations with those credentials
Tier 2	Workstations and end-user devices	Tier 2 admins manage endpoints, never with higher-tier credentials

The core rule is that credentials never flow downward. A Tier 0 admin account must never authenticate to a Tier 2 workstation, because that workstation might be compromised and the credential would be captured. Tiering directly breaks the escalation path from a phished laptop to Domain Admin, because the high-value credentials are simply never present where the attacker landed.

Privileged Access Workstations (PAWs), dedicated hardened machines used only for administrative work, are how Tier 0 admins do their job without ever placing those credentials on a general-purpose device.

Tiering is a discipline more than a product, and it fails in predictable ways. The most common is convenience: an administrator uses their powerful account to quickly fix something on a user's laptop, and in that moment the credential that controls the domain is sitting in the memory of a Tier 2 machine. Another is scope creep in Tier 0, where systems that should never hold domain-controlling rights (backup servers, monitoring agents, management tools) quietly accumulate them and become soft paths to the top. Enforcing tiering means both drawing the boundaries and auditing them, because a boundary that is respected on the org chart but ignored in daily practice provides no protection at all.

Hardening priorities

The controls that pay off most are about privilege and credential hygiene, in roughly this order.

Least privilege, ruthlessly. Audit privileged group membership (Domain Admins, Enterprise Admins, and the rest) and cut it to the few accounts that truly need it. Most environments have far more privileged accounts than they can justify.

Unique local administrator passwords. Randomise and rotate the local admin password on every machine so a single dump does not unlock the fleet. Microsoft's LAPS solves this directly.

Protect service accounts. Use group managed service accounts where possible, give long strong passwords otherwise, and grant only the rights each service needs. Overprivileged service accounts are a favourite escalation path.

Separate and protect admin accounts. Give administrators a separate privileged account from their daily one, keep those accounts out of everyday workstations, and use PAWs for Tier 0 work.

Multi-factor authentication on privileged access and remote entry points, so a stolen password is not enough.

Monitor the things that matter. Alert on changes to privileged groups, on unusual authentication patterns, and on Kerberos anomalies. CISA's guide on detecting and mitigating Active Directory compromises catalogues the specific techniques and detections worth prioritising.

Know which groups target AD

Ransomware crews and intrusion sets share a small playbook against Active Directory: dump credentials, move laterally, escalate to Domain Admin. Our threat group intelligence maps which active groups rely on AD credential abuse and lateral movement, so you can align your hardening with the techniques currently in use rather than a generic checklist.

Common weaknesses as hardening targets

It helps to list the recurring weaknesses next to the risk they create and the control that closes them. This turns a vague sense of exposure into a work list.

Weakness	Why it helps an attacker	Hardening target
Excess members in Domain Admins and Enterprise Admins	Every extra privileged account is another credential worth stealing	Cut standing membership to a named few, review quarterly
Shared local administrator password across machines	One credential dump unlocks many hosts at once	Unique rotated local admin passwords per machine
Service accounts with weak passwords and broad rights	Offline cracking plus standing privilege gives a fast escalation path	Group managed service accounts, minimal rights, monitor ticket requests
Privileged accounts logging into workstations	Their credentials land in the memory of low-trust machines	Tiering, separate admin accounts, privileged access workstations
Dangerous ACLs on directory objects	A low-privilege group can reset a high-privilege password or edit a group	Review object permissions, remove inherited over-grants
Unconstrained delegation on servers	A compromised server can impersonate any user that authenticates to it	Constrained or resource-based delegation, remove where unused
Stale accounts and old trusts	Forgotten identities and links widen the surface and dodge monitoring	Disable stale objects, retire trusts that no longer serve a purpose
No alerting on privileged group changes	Escalation completes silently before anyone notices	Alert on group membership changes in real time

Working this list from the top down removes the steps attackers rely on most. None of these are exotic. They are the standing conditions that turn a single compromised laptop into a domain takeover.

Detection signals: what to watch

Prevention reduces the number of paths. Detection catches the attacker walking one you missed. Windows writes specific security events that, when collected centrally and correlated, expose the stages of an AD intrusion. The point is to forward these to a SIEM and alert on the patterns, since the events sitting unread on a domain controller help no one.

Signal	Windows event or source	What it may indicate	ATT&CK
Change to a privileged group	4728, 4732, 4756 (member added)	Escalation or persistence via group membership	T1098
New account created then privileged	4720 followed by group add	Attacker establishing durable access	T1136
Directory object attribute change	5136 on sensitive objects	ACL or SID history tampering	T1484
Directory access to replication rights	4662 with replication GUIDs	Credential replication abuse from a non-DC host	T1003
Kerberos service ticket requests at scale	4769 for many SPNs from one host	Bulk service ticket harvesting	T1558
Ticket requests with weak encryption	4769 with RC4 where AES is expected	Downgrade to ease offline cracking	T1558
NTLM authentication spikes	4776 volume and source anomalies	Relay or reuse activity, legacy path abuse	T1550
Account lockouts in clusters	4740 across many accounts	Spraying or brute forcing	T1110
Logon of a Tier 0 account on a workstation	4624, 4672 on a Tier 2 host	Tiering violation exposing high-value credentials	T1078
New service installed on a DC	7045 on a domain controller	Execution or persistence on the crown jewel	T1543

A few detection principles make these useful rather than noisy. Baseline normal first, because a helpdesk group that changes twice a day is not the same alert as one that never changes. Correlate across stages, since a single 4769 means little but a burst followed by lateral logons tells a story. Watch the domain controllers hardest of all, because legitimate administrative activity there is rare and predictable, which makes anomalies stand out. Finally, protect the logs themselves. An attacker who reaches a DC can clear or tamper with local logs, so forwarding events off the host in near real time is what preserves the evidence.

Detection depth beats detection breadth

Turning on every audit policy produces a flood that buries the signals that matter. Start with the handful of events above, tune them against your own baseline, and make sure each one has an owner who will act on the alert. A small set of well-understood detections that someone watches outperforms a firehose that no one reads.

Kerberos and NTLM compared

Because so much AD defense turns on authentication behaviour, it is worth setting the two protocols side by side.

Aspect	Kerberos	NTLM
Model	Ticket based, mutual authentication	Challenge response, no mutual authentication
Domain controller role	Issues and signs tickets with the krbtgt key	Validates the challenge, less structured audit trail
Audit richness	Detailed ticket events (4768, 4769)	Sparse (4776), harder to attribute
Common abuse	Ticket forging and service ticket cracking	Relay and credential reuse across hosts
Defensive posture	Protect krbtgt, prefer AES, watch ticket patterns	Reduce usage, block relay, monitor what remains

The takeaway for defenders is to move authentication toward Kerberos with strong encryption where you can, monitor the ticket events it produces, and treat every remaining NTLM path as something to inventory and eventually retire.

Common misconceptions

Several beliefs lead teams to spend effort in the wrong place.

"If our domain controllers are patched, AD is secure." Patching matters, and it closes real remote vulnerabilities, yet most AD compromise runs on stolen credentials and misconfiguration rather than an unpatched flaw. A fully patched forest with reused local admin passwords and Tier 0 credentials on workstations is still an easy target.

"The domain is our security boundary." The forest is the boundary. Trust flows freely inside a forest, so a compromise in one domain can reach the others. Separation you rely on for security belongs at the forest level.

"Service accounts are low risk because nobody logs in with them." Service accounts often carry broad standing rights and weak passwords, and their tickets can be requested and cracked offline without ever touching the account interactively. They are a favourite escalation route precisely because teams overlook them.

"We have MFA, so credential theft is handled." MFA on the front door is valuable, and it stops many password-only attacks. It does not protect credentials already cached in memory on a machine an attacker controls, and it rarely covers every internal authentication path. MFA is one layer among several.

"Tiering is done once we write the policy." Tiering is a daily discipline. A boundary respected on the org chart but violated whenever an admin fixes a laptop with a domain account provides no protection. It has to be audited, not just declared.

How AD security thinking evolved

For years the working model of Windows security was the network perimeter. Defenders assumed that if the firewall held and the domain controllers were patched, the directory was safe. Two shifts changed that. First, tooling matured that let defenders and attackers alike map AD as a graph of rights, which made the shortest path to Domain Admin visible and showed how often it ran through misconfiguration rather than software bugs. Second, ransomware operators industrialised the same small playbook of dump credentials, move laterally, and escalate, which turned a theoretical concern into a routine business risk.

The response was a move toward identity as the real perimeter. The tiered administration model, privileged access workstations, unique local admin passwords, and managed service accounts all come from the same realisation: the way to defend AD is to deny attackers the credential paths they string together, and to watch the few chokepoints where escalation shows itself. Public guidance from vendors and from national cyber agencies now reflects this, treating privilege reduction and monitoring as the core work rather than an afterthought.

Frequently asked questions

What is the single most impactful AD hardening step? Reducing standing privilege. Cut the membership of Domain Admins and other privileged groups to the few accounts that genuinely need it, and remove standing rights wherever a just-in-time grant would do. Every privileged account you remove is one fewer credential worth stealing and one fewer step available to an attacker.

Why is the krbtgt account treated as so critical? The krbtgt key signs every Kerberos ticket in the domain. An attacker who obtains it can create tickets for any account that every service will accept as valid, which is effectively unlimited persistence. Recovering from a krbtgt compromise requires resetting that account's password twice in a controlled way, so protecting it and detecting replication abuse against it are high priorities.

Do we still need to worry about NTLM if we use Kerberos? Yes. Windows falls back to NTLM in many situations, and it is easier to relay and reuse than Kerberos while producing thinner audit records. Inventory where NTLM is still accepted, retire the paths no application depends on, and monitor whatever must remain.

Is the tiered model realistic for a small team? The full three-tier model with dedicated hardware suits larger environments, and even small teams can apply its core rule. Keep the accounts that control your domain controllers off ordinary workstations, use a separate admin account for privileged work, and never sign into a user's machine with a domain-controlling credential. That single habit closes the most common escalation path.

How do we find dangerous ACLs and delegation before an attacker does? Review the permissions on your privileged groups, on the domain object, and on service accounts, looking for low-privilege identities that can reset passwords, edit group membership, or modify sensitive attributes. Check servers for unconstrained delegation and remove it where nothing requires it. These reviews find the quiet links between low and high privilege that escalation depends on.

What should we log first if resources are limited? Start with changes to privileged group membership, logons of high-privilege accounts on machines where they do not belong, service creation on domain controllers, and unusual Kerberos ticket activity. Forward those events off the hosts to a central place in near real time so an attacker on a domain controller cannot erase them, and make sure each alert has an owner.

How often should AD hardening be revisited? Continuously, with a formal review at least quarterly. Privilege creeps back, new service accounts appear, and every merger or new application adds objects and trusts. An environment that was tight a year ago is rarely tight today unless someone maintains it, so treat hardening as a standing program with recurring audits of privileged membership, delegations, and stale accounts.

A starting checklist

Inventory privileged accounts and cut the count. Fewer Domain Admins, fewer standing privileges, everywhere.
Deploy unique local admin passwords across all machines and rotate them automatically.
Implement tiering, starting by keeping Tier 0 credentials off workstations and standing up privileged access workstations.
Fix service accounts: managed accounts, strong passwords, minimal rights.
Require MFA on remote access and privileged logons.
Harden and isolate domain controllers, with minimal roles, tight access, and heavy monitoring.
Monitor privileged group changes and authentication anomalies so an in-progress escalation is visible before it completes.

None of this is a one-time project. Privilege creeps back, new service accounts appear, and each merger or new application adds objects and trusts. Treat AD hardening as a standing program with periodic review of privileged membership, delegations, and stale accounts, rather than a hardening sprint you finish once. An environment that was tight a year ago is rarely tight today unless someone has been maintaining it.

Active Directory security is less about patching a product and more about denying attackers the credential and misconfiguration paths they string together. Reduce privilege, keep high-value credentials away from low-trust machines, protect the domain controllers, and watch the privileged groups. Each of those closes off steps in the chain, and an attack that runs out of steps never reaches the top.