Hello there! Last year i made a series on the HTB AD intro module, to get an introductionary overview on the whole of "Windows Security". These posts contain a looot of names and terms you seemingly need to recognize?

As that is something i myself struggle quite extensively with, let's try a different approach here. Let's again attack the topic, but from the actual perspective of.. well, attackers. Pentesters!

We will still reference the older posts as I think they serve quite well as a "Terms and Figures" overview with examples and metaphors to help you better grasp the base concepts conveyed.

Now before we get offensive here, let's make sure the.. fundamental fundamentals are locked in.

This post and part 2 will be on securing fundamentals, setting our heads right for the quests ahead hehe.

Full bore and into the abyss.

Getting to Know Active Directory

Active Directory (AD) is Microsoft's directory service, introduced with Windows 2000 Server, still running the world in 2026.

Think of it as the central nervous system of a Windows enterprise environment. It stores information about every object in the network (users, computers, groups, printers, policies) and controls access to all of it.

AD is built on several open standards stitched together: LDAP for the directory itself, Kerberos for authentication, DNS for name resolution, and SMB for file sharing and RPC. We covered all of these in Day Two of the series, they're worth knowing cold before pentesting them.

Geniunely, check the post out, keep it open in another tab to have a reference for understanding. The post holds up pretty well in my opinion for a grounded understanding hehe.

The Domain Controller

The Domain Controller (DC) is the server running Active Directory Domain Services (AD DS). It holds the authoritative copy of the directory database (ntds.dit) and handles:

• Authentication: validating credentials (Kerberos tickets, NTLM hashes)
• Authorization: enforcing access control based on group memberships and ACLs
• Policy enforcement: distributing and applying Group Policy Objects
• Replication: syncing directory changes to other DCs

There's usually more than one DC per domain for redundancy (more on that below). But conceptually: the DC is where all trust decisions happen. Every login, every resource access, every policy check flows through it.

The DC Should Do One Thing

A Domain Controller should run AD DS and nothing else. No IIS, no SQL Server, no file shares, no print spooling.

Every additional service you bolt onto a DC expands the attack surface.
Every vulnerable web app on a DC is a potential direct code execution on the machine that holds every credential hash in the domain. The blast radius is total.

The DC Is Our Primary Target

From an attacker's perspective, our perspective, the DC is the crown jewel. Here's why:

The ntds.dit file, the AD database sitting on every DC, contains the password hashes of every domain account. All of them. If you get code execution on a DC (even as SYSTEM on a domain-joined machine via DCSync rights), you can dump the entire credential store. That's every user, every service account, every admin.

Owning a DC means owning the domain. Full stop.

Domain Hierarchy (it's just like DNS)

Active Directory's logical structure maps almost perfectly onto DNS naming, which is not a coincidence. Microsoft built AD namespaces to be DNS namespaces. Once that clicks, the whole hierarchy will feel less and less arbitrary haha.

What is a Domain?

A domain is the basic administrative unit in AD. It groups users, computers, resources under a common security boundary and a shared policy.

Every domain has a DNS name: corp.local, inlanefreight.com (for those HTB initiates), eu.contoso.com, whatever.

To get the basic grasp on all those terms, again, part 1 and part 2 of my blog series on them convey all you need to know (for now).

The key property of a domain: it is a replication and policy boundary. Everything inside it shares the same directory database, replicated between Domain Controllers.

What is a Domain Tree?

A domain tree is a hierarchy of domains that share a contiguous DNS namespace. When you add a child domain to a parent, it slots in as a DNS subdomain.

inlanefreight.com          ← root domain (parent)
├── us.inlanefreight.com   ← child domain
└── eu.inlanefreight.com   ← child domain
    └── de.eu.inlanefreight.com  ← grandchild domain

Domains in the same tree automatically form two-way transitive trusts with each other. What that means practically: a user in de.eu.inlanefreight.com can, in principle, authenticate to resources in us.inlanefreight.com. This is exactly the kind of trust chain attackers follow during lateral and upward movement.

Why would you use this? Large enterprises split into geographic or organizational units want delegated admin control per region while keeping a shared namespace. The German subsidiary manages their own domain (de.eu.inlanefreight.com) with their own DCs and GPOs, but HR can still run single sign-on across all of them.

What is a Forest?

A forest is the outermost logical container and the true security boundary in AD. It consists of one or more domain trees that share a common schema, global catalog, and configuration. The first domain created in a forest becomes the forest root domain.

INLANEFREIGHT.LOCAL  ←  Forest root
├── us.inlanefreight.local
└── eu.inlanefreight.local
 
FREIGHTLOGISTICS.LOCAL  ←  Separate forest (different company / security boundary)

Trust between forests is not automatic. If INLANEFREIGHT.LOCAL needs to talk to FREIGHTLOGISTICS.LOCAL, an admin must explicitly configure a forest trust. And unlike within a forest, those trusts are not automatically transitive beyond what's configured.

Why does this matter for pentesting? The forest is where the security boundary actually is. Domains within the same forest already trust each other implicitly. If you compromise any domain in a forest, you have a path, through trust relationships, to escalate toward the forest root.

Compromising the forest root means game over for the entire forest: you can forge tickets (Golden Ticket), abuse SID history, and own every domain underneath.

Cross-forest attacks are a whole separate chapter.
For now: forest = security boundary, domain = admin boundary.

📚 I covered the forest/domain/OU structure in detail in Day One of my AD series, worth a revisit before going further.

Authentication, SSO, and Why a Domain Account Is Worth More Than It Looks

AD uses Kerberos as its primary authentication protocol. The idea is elegant: you authenticate once at logon, receive a Ticket Granting Ticket (TGT) from the DC, and then use that TGT to request Service Tickets for any resource in the domain: file shares, RDP sessions, web apps, SQL servers, without re-entering your password. That's Single Sign-On.

The full Kerberos flow is covered in Day Two of the series. Worth keeping open as a reference.

What a Domain Account Actually Gives You

This is something that surprises people coming from a non-Windows background: a standard, low-privileged domain account is not just a login. It's a key to the directory itself.

By default, any authenticated domain user can query Active Directory. Users, groups, computers, group memberships, who has admin rights where, which services are registered on which machines. The directory is designed to be readable. That's a feature, not a bug, and it's one of the reasons AD environments are so enumerable once you have any foothold at all.

The implications compound as privilege increases. A standard account gets you visibility. An account with admin rights on one machine gets you that machine. An account with admin rights on many machines, say, a service account that was granted local admin across a fleet of servers, gets you a lot more.

And a Domain Admin account? The DC vouches for it to every machine in the domain. There's nothing left to break. You just authenticate, and every door opens.

Understanding this escalation is the foundation of AD attack paths. Almost every technique we'll cover later is really just answering the question: how do we move from one level of this ladder to the next?

PDC, BDC, and How Replication Works

A Bit of History

Before Windows 2000, the Windows domain model was straightforward but rigid. There were two roles:

The Primary Domain Controller held the single writable copy of the domain database. Every change, new user, password reset, policy update, happened here and nowhere else.

The Backup Domain Controllers were read-only replicas. They could authenticate users when the PDC was under load or offline, but they couldn't accept any writes. If the PDC went down while you needed to make a change, you were stuck until it came back up or an admin manually seized the role to a BDC.

That strict master-replica model was the ceiling of Windows NT. It didn't scale, it created a single point of failure at the heart of every domain, and it made large distributed environments painful to manage.

Multi-Master Replication

Modern Active Directory replaced all of that with multi-master replication. Every DC holds a fully writable copy of the directory database, and changes propagate between them automatically.

The mechanism: when you make a change on DC01, it gets stamped with a USN or Update Sequence Number. Other DCs periodically check whether they're behind on changes from DC01 by comparing USNs. If they are, they pull the delta. Conflicts between simultaneous changes on different DCs are resolved by timestamp and originating DC priority.

Replication within a site is fast, typically a matter of minutes. Replication across sites runs over site links, which can be scheduled to avoid saturating WAN links during peak hours. This matters in large environments: a change made on a DC in Frankfurt may not immediately be visible on a DC in Singapore. Knowing this helps you understand why behaviour in distributed AD environments sometimes seems inconsistent.

The PDC Emulator

The PDC as a dedicated role is gone, but its responsibilities didn't disappear; they were redistributed across the FSMO roles (Flexible Single Master Operations). One of those roles, the PDC Emulator, carries most of the PDC's original duties, and there's exactly one per domain.

It's the authoritative time source for the entire domain. This matters more than it sounds. Kerberos authentication is time-sensitive, it requires all participants to have clocks within five minutes of each other. Drift beyond that threshold and ticket validation starts failing. The PDC Emulator is what keeps every DC and every domain-joined machine in sync.

It also processes password changes out of band, ahead of normal replication. When a user changes their password, the change reaches the PDC Emulator immediately. If they then authenticate to a machine whose local DC hasn't replicated yet, that DC forwards the validation request to the PDC Emulator rather than incorrectly locking the account. This is why password changes in large environments take effect quickly even before full replication completes.

Finally, it's the preferred target for GPO edits — when multiple admins edit Group Policy simultaneously, having one authoritative DC reduces conflicts.

# See which DC holds the PDC Emulator (and all other FSMO roles)
netdom query fsmo

# Or in PowerShell
[System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().PdcRoleOwner

Understanding what the PDC Emulator does matters because it comes up repeatedly as you go deeper, in authentication troubleshooting, in replication analysis, and later when we start looking at what makes certain DCs more interesting than others during an assessment.

Multiple DCs in Enterprise Networks

In any real enterprise, there isn't one DC. There are many, and that's entirely by design.

Redundancy is the obvious reason. If the only DC in a domain goes offline, nobody can log in. Authentication stops. Group Policy stops. Every domain-dependent service stops. Multiple DCs mean the environment keeps functioning through hardware failure, maintenance windows, and network issues.

Geographic distribution is the less obvious but equally important reason. A company with offices in Frankfurt, Singapore, and Chicago doesn't route every login request across a transatlantic link. Each site has its own DC, and users authenticate locally. Site and Site Link objects in AD define these geographic boundaries and control which DCs replicate with which, and on what schedule.

Read-Only Domain Controllers (RODCs) are a special variant worth understanding even at this stage. They're designed for locations where the physical security of a server can't be guaranteed — branch offices, warehouses, remote sites. An RODC holds a read-only replica of the directory and only caches credentials for accounts explicitly configured to do so. The underlying idea: if the machine is physically compromised or stolen, the damage is limited to whatever was cached on that specific device. The rest of the domain is unaffected.

In a large enterprise, you'll encounter all three of these. Understanding why they exist shapes how you think about the environment, which machines serve which purpose, how changes flow between them, and what the failure modes look like. That mental model becomes load-bearing once we start moving through real environments.

What We've Covered

That's Part 1 done. No exploits yet, no tools, no shells. Just the foundation, and the foundation matters more than people give it credit for.

We went through the full structural picture of Active Directory: what a domain is and why it exists, how domain trees inherit trust automatically, why the forest is the boundary that actually counts. We looked at the Domain Controller as both the architectural centrepiece and the primary target of any AD assessment. We covered how authentication flows through Kerberos and why a single domain account is worth far more than its privilege level suggests. And we unpacked replication, from the rigid PDC/BDC model of the NT era to multi-master replication, the PDC Emulator, and how large enterprises distribute DCs across geography.

None of this was abstract. Every concept here is load-bearing for what comes next.

Part 2 is where we start getting hands-on. A good friend of mine set up GOAD, part 2 will be on the infrastructure to the lab environment, as understanding those is crucial to our understanding aswell, especially when we attack from linux: C2 frameworks, a SOCKS tunnel, a proxy chain, and tmux holding it all together. It sounds like plumbing. It is plumbing. But understanding that plumbing is the difference between running a tool and understanding why it works.

If anything in this post felt shaky, the AD series is still the best place to fill in the gaps, Day One for structure and objects, Day Two for protocols. Both hold up well as references.

Otherwise, see you in Part 2. We've got infrastructure to build.