Active Directory Demystified: A Practical Learning Journey - Day 01

It has long since time to do something on Windows here. Finally getting into Active Directory is important currently, it’s very sought-after and uptodate - OffSec is giving it more and more attention aswell (this change came back when i first thought about getting the OSCP). Let’s begin our work on some Windows fun.

Active Directory (AD) As a Company with Branches

I don’t really appreciate the approach in the “Introduction to Active Directory” module from HTB - it is very vast, not that beginner-friendly, hard to get into.

Let’s make our lives a bit easier by beginning with an example.

HackTheBox loves their InlaneFreight Inc. as a company example, so we’ll also go with this one - imagine this to be a giant international company.

This company has headquarters, regional offices and departments. AD helps the company manage all its employees (users), devices (computers), rules (policies) and permissions across the entire organization.

Top Level - The Forest 🌲

Think of a Forest as the entire company. It’s the security boundary meaning trust and control start and stop here unless explicitly allowed elsewhere.

We name our Forest: INLANEFREIGHT.LOCAL This is the main company, and everything underneath it belongs to this organization. You can have multiple forests, like partner companies - e.g. FREIGHTLOGISTICS.LOCAL might be another company we work with.

Second Level - Domains 🏢

A Domain is like a regional branch of the company.

Within INLANEFREIGHT.LOCAL, there might be several branches

• ADMIN.INLANEFREIGHT.LOCAL → Admin HQ
• CORP.INLANEFREIGHT.LOCAL → Corporate office
• DEV.INLANEFREIGHT.LOCAL → Developer division

Each domain…

• … has its own users, computers and groups
• … can have different rules and security settings
• … can be connected via trusts to other domains/forests (like partnerships between branches)

So AD also handles authentication and authorization.

Third Level - Organizational Units (OUs)

Think of an OU as a department within a domain, e.g. inside ADMIN.INLANEFREIGHT.LOCAL:

OU: EMPLOYEES
  ├── COMPUTERS
  │    └── FILE01         ← a file server
  ├── GROUPS
  │    └── HQ Staff       ← a group of users
  └── USERS
       └── barbara.jones  ← a user

• OUs help organize users and computers neatly
• You can apply different policies (like password rules or software restrictions) to different OUs

Slight Recap

Trusts made simple

Imagine INLANEFREIGHT.LOCAL and FREIGHTLOGISTICS.LOCAL are two companies: They can sign a mutual agreement (trust) that says:

“Employees from your company can access our resources, and vice versa.”

But! If FREIGHTLOGISTICS.LOCAL has sub-branches (like admin.dev.freightlogistics.local) - those sub-branches don’t automatically get full access to every other branch of the other company.

You need to explicitly create a new trust if admin.dev.freightlogistics.local needs to access e.g. wh.corp.inlanefreight.local.

FOREST: INLANEFREIGHT.LOCAL
|
|-- DOMAIN: ADMIN.INLANEFREIGHT.LOCAL
|   |-- OU: EMPLOYEES
|       |-- Users: barbara.jones
|       |-- Computers: FILE01
|
|-- DOMAIN: CORP.INLANEFREIGHT.LOCAL
|
|-- DOMAIN: DEV.INLANEFREIGHT.LOCAL

↔ TRUST ↔

FOREST: FREIGHTLOGISTICS.LOCAL
|-- DOMAIN: DEV.FREIGHTLOGISTICS.LOCAL
|-- DOMAIN: CORP.FREIGHTLOGISTICS.LOCAL

Technically, the term “branch” is an analogy here - a simplified description to help understand AD logic. In technical terms, a “branch” would simply be a Domain, while a “sub-branch” technically is a Child Domain.

AD is huge - so here’s a Glossary

I will have to come back to this section a lot, as might you to grasp the concept of a AD term.

Core Concepts

Identification & Naming

Authentication & Authorization

Infrastructure & Replication

Admin Features & Object Lifespan

Attack-Relevant Terms

Admin Tools & Legacy Stuff

🔍 Why This Terminology Matters

Understanding these terms helps you speak AD fluently — but more importantly, they give you the power to:

• Spot misconfigurations attackers will exploit (e.g. SID history, weak ACLs)
• Understand what tools like BloodHound or SharpHound are showing you
• Recognize juicy targets (like the NTDS.dit file or Domain Admin accounts)
• Know which settings to harden (like AdminSDHolder, RODC, or FSMO roles)

Mastering the language of AD is step one toward owning or defending the network.

☕ Magic lies ahead..

Before the real magic begins, for a moment consider supporting me in my endless pursuit of free educational content :D

🛠 Every coffee helps fuel more content like this — cheatsheets, walkthroughs, and more hacker-fueled documentation.

🔗 Visit: ko-fi.com/niklasheringer

Active Directory Objects — The Real-World Resources of AD

We’ll often see the word “object” in AD. But what exactly is an object?

An object in Active Directory is anything that represents a resource in the domain: a user, computer, printer, group, OU, shared folder, and more. Think of them as files in a giant digital company directory, each with a label (attributes) and some permissions. Some of the following, we’ve already come across, but just to make it whole - here they are again.

Common AD Object Types (with Examples & Pentester Tips)

Users

Analogy: An employee in the company with a name badge, keycard, email, and permissions.

• Leaf objects (they don’t contain other objects).
• Security principals → Have a SID and GUID.
• Attributes include: full name, email, last login, manager, department, etc.

Tip: Low-priv users can enumerate a lot. Gaining access to even one user = foothold, visibility, and possible lateral movement.

Contacts

Analogy: A business card in a rolodex — informational only, no access.

• External users, vendors, clients, etc.
• Not security principals → Only a GUID, no SID.
• Attributes: email, phone, name.

Useful for phishing targets or identifying 3rd parties.

Printers

Analogy: A shared company printer — visible on the network.

• Leaf object, not a security principal (no SID).
• Only a GUID.
• Attributes: name, driver, port.

Can sometimes be abused for printer-based attacks (e.g., Print Spooler abuse if misconfigured).

Computers

Analogy: A company laptop or server registered in the directory.

• Leaf object, is a security principal.
• Has SID and GUID.
• Attributes: hostname, OS version, last logon.

From a pentest view: SYSTEM access on a computer == same power as a domain user.

Shared Folders

Analogy: A network drive or shared team folder.

• Leaf object, not a security principal.
• Controlled via ACLs.
• Attributes: path, permissions, owner.

Great targets for loot, passwords in files, scripts, or lateral movement.

Groups

Analogy: A mailing list or permission group — defines who can do what.

• Container object — can include users, computers, even other groups (aka nested groups).
• Is a security principal → Has SID and GUID.
• Nested group misconfigs = escalation path.

BloodHound excels at visualizing nested membership → Who has hidden privileges?

Organizational Units (OUs)

Analogy: Departments in your org chart — HR, IT, Finance, etc.

• Container objects, used to group and delegate.
• Not security principals.
• Attributes: name, permissions, policies.
• GPOs are often applied at the OU level → so structure matters a lot.

Help desk accounts often get delegated access to OUs → a target for abuse.

Domains

Analogy: A company branch — its own rules, employees, and data.

• Contains users, groups, computers, OUs.
• Has its own AD database and policies.
• Important for trust boundaries and privilege escalation mapping.

Domain Controllers (DCs)

Analogy: The HR + security office — verifies who you are and what you can access.

• The central brain of the domain.
• Handles logins, replication, permissions, GPO enforcement.
• Compromising a DC = total domain compromise.

Key pentest target (especially to dump ntds.dit).

Sites

Analogy: Physical office locations (New York, Berlin, Tokyo).

• Represent subnets and physical layout of the network.
• Used for efficient replication between DCs.

Often overlooked, but can explain slow replication or isolated access paths.

Built-in

Analogy: Default office groups created during company setup.

• Container holding default AD groups like Administrators, Guests, etc.
• Target for misconfigured group membership

Foreign Security Principals (FSPs)

Analogy: Visitors from a partner company who got a temporary badge.

• Created automatically when a user/group from another forest is added to a group in your forest.
• Shows up in ForeignSecurityPrincipals container.

Important in cross-forest trust attacks (SID history, nested groups, etc.)

TL;DR Recap

Flexible Single Master Operations (FSMO) — Who’s in Charge?

Think of FSMO roles as the “executive roles” in an organization. Each one has a very specific job, and only one server at a time is assigned that role to prevent chaos.

Why this matters in Pentesting

If FSMO roles fail or are misconfigured, users may:

• Fail to authenticate
• Be unable to join computers to the domain
• Encounter weird replication or password delay issues

You might spot a stale DC still holding FSMO roles — a misconfig you can exploit during domain takeover.

PDC Emulator is high-value because of its role in password handling and time (important for Kerberos - we’ll come to that later)

Domain & Forest Functional Levels — What Features Can You Use?

Think of functional levels as the “tech baseline” for an AD environment. They define what features are enabled and which Windows Server versions are supported.

Domain Functional Levels

Minimum feature set + allowed DC OS versions - per domain.

Note: No new level was introduced in Server 2019. But to add 2019 DCs, the minimum domain functional level is 2008, and SYSVOL must use DFS-R.

Forest Functional Levels

Affects features across domains in a forest.

Tips for Future Engagements

• Forest trusts + SID history + old functional level = attack surface.
• If AD Recycle Bin is disabled, deleted object recovery is limited → persistence tricks possible.
• Older functional levels = weaker crypto (e.g., no AES in Kerberos), poor delegation control, etc.

Trusts - Making Cross-Domain Friends (or Enemies)

A trust, as seen before, is just like a mutual agreement between companies stating: “Your users can access our stuff — to some extent.”

Trusts let users in one domain authenticate into another.

Trust Types: Who’s Trusting Who?

Trust Directions

Pentest Relevance: Why Trusts Can Be Dangerous

• Improperly configured trusts create unintended access paths
• Trusts from acquired companies often remain open without review

You may:

• Kerberoast a user in another domain
• Gain admin in domain A and jump to domain B via nested group
• Abuse SID history if SID filtering is disabled

BloodHound and AD Explorer are powerful tools to enumerate and map trust relationships.

Trust Example

If you’re on mobile, this might be hard to read and HTB’s example’ll be easier:

That’s it for this one. Next time we’ll continue with Kerberos, DNS, LDAP, MSRPC, all that fun stuff..