Jun 11, 2025 ad-challenge

Active Directory Demystified: A Practical Learning Journey - Day One

Active Directory powers most enterprise networks, and attackers love it. This guide simplifies AD with real-world analogies and attacker-focused insights to help you learn, enumerate, and exploit it effectively.

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): 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

AD Concept	Analogy	Example
Forest	The entire company	`INLANEFREIGHT.LOCAL`
Domain	A regional branch	`ADMIN.INLANEFREIGHT.LOCAL`
OU (Organizational Unit)	A department	EMPLOYEES
User	An employee	`barbara.jones`
Computer	A company laptop or server	`FILE01`
Group Policy (GPO)	Company rules for a department	Password Policy
Trust	Agreement to collaborate	Allow users from another forest

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

Term	Meaning & Analogy
Object	Any item in AD — like a file in a big cabinet. This could be a user, printer, computer, OU, etc.
Attribute	Details about the object — like a label on the file: name, email, title, etc.
Schema	The blueprint for AD objects — defines what types of files (objects) we can store, and their fields.
Domain	A branch of the company — a logical container of objects (users, computers, OUs).
Forest	The whole company — contains one or more domains, and is the top-level security boundary.
Tree	A group of domains connected via parent-child trust — shares a namespace.
OU (Org Unit)	A department inside a branch — allows applying policies to grouped users/computers.
Container	A folder that can hold objects (but can't have policies like OUs).
Leaf	A document in the folder — an object that doesn’t contain other objects.

Identification & Naming

Term	Analogy
Distinguished Name (DN)	Full file path in the AD folder structure — e.g. `CN=Bob,OU=Sales,DC=inlanefreight,DC=local`.
Relative DN (RDN)	Just the file name — e.g. `Bob`. It must be unique inside its folder (OU).
GUID	Like a passport number — globally unique, never reused. Internal ID for the object.
SID	Social Security Number for security — uniquely identifies a user or group in AD.
FQDN	Complete DNS name — e.g. `DC01.INLANEFREIGHT.LOCAL`, used to locate systems in AD.
sAMAccountName	Old-school logon name — like `bjones`. Max 20 characters.
userPrincipalName (UPN)	Email-style logon name — like `bjones@inlanefreight.local`.

Authentication & Authorization

Term	Description
Security Principal	Anything you can log in with — user, computer, or even a process.
Access Token	Your access card — contains your SID + group SIDs + permissions.
SPN (Service Principal Name)	Ticket identifier for a service — used in Kerberos to bind a service to an account.
ACL (Access Control List)	Access sheet — a list of who can do what with an object.
DACL	Who is allowed or denied access — checked whenever you access an object.
SACL	Audit log settings — specifies what access attempts should be logged.

Infrastructure & Replication

Term	What It Means
Domain Controller (DC)	The local branch manager — handles logons, keeps a copy of the AD database.
FSMO Roles	Special admin jobs across the company — like handling IDs, managing the schema, and resolving changes.
Global Catalog (GC)	The company’s address book — contains data about all objects across the whole forest.
SYSVOL	Company-wide public share — stores scripts, policies, and shared files used in logon procedures.
Replication	Keeps branches in sync — when a change happens on one DC, it’s copied to others.

Admin Features & Object Lifespan

Term	Purpose / Analogy
Tombstone	Soft delete — when an object is deleted, it’s not immediately wiped. It becomes a tombstone and sits in a "trash can" (for 60–180 days) with minimal data until it's purged. Used for replication and recovery.
AD Recycle Bin	Modern undo feature — lets admins restore deleted objects with most of their attributes intact (much better than tombstones). Think of it as Ctrl+Z for Active Directory.
AdminSDHolder	Security template for high-priv users — makes sure members of sensitive groups (like Domain Admins) have consistent and protected permissions.
SDProp (SD Propagator)	The enforcer — a process that runs regularly (by default every 60 mins) and resets the ACLs of protected users based on AdminSDHolder.
adminCount	Is this user protected? — if this attribute is set to `1`, the user is considered sensitive, and SDProp will enforce secure ACLs. Attackers look for this.
dsHeuristics	Settings switchboard — a flag that controls forest-wide behaviors, like which groups are considered protected. Changing it can weaken protection.

Attack-Relevant Terms

Term	Pentester Relevance & Analogy
sIDHistory	Access from another life — tracks previous SIDs from another domain. Can be abused to impersonate privileged accounts after migrations, if SID filtering isn't enforced.
NTDS.DIT	The crown jewels — this is the AD database file on a Domain Controller. It contains all user data, including password hashes. Dumping this = full domain compromise.
RODC	Branch office with read-only copy — a Domain Controller that can’t be changed remotely, good for security in remote locations. Doesn’t cache passwords unless explicitly allowed. Attackers can't change objects from here, but may still dump cached creds.

Admin Tools & Legacy Stuff

Term	Description
ADUC	Active Directory Users and Computers — the GUI used by most sysadmins to manage AD objects.
ADSI Edit	Advanced AD editor — can view/edit everything (even dangerous stuff). Not for the faint-hearted.
MSBROWSE	Obsolete discovery method — old Windows networks used it to list devices. Still sometimes shows up in legacy environments. Attackers may abuse it to find DCs or shared resources.

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

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

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

Object Type	Security Principal	Container?	Leaf?	Common Use / Pentest Relevance
User	Yes	❌	✅	Initial access, privilege escalation
Contact	No	❌	✅	Info only (phishing, recon)
Computer	Yes	❌	✅	SYSTEM access → domain access
Shared Folder	No	❌	✅	Loot, secrets, password.txt, lateral movement
Group	Yes	✅	❌	Privilege escalation, nested abuse
OU	No	✅	❌	GPOs, delegation → escalation targets
Domain	Yes (DCs)	✅	❌	Trust boundaries, domain persistence
Domain Controller	Yes	❌	✅	Crown jewel – dump secrets, own the domain
Printer	No	❌	✅	Lateral movement, printer abuse (rare)
FSP	Yes (Proxy)	❌	✅	Cross-domain attacks, SID history abuse
Site	No	✅ (logical)	❌	Helps understand replication, but rarely targeted
Built-in	Yes (groups inside)	✅	❌	Default groups – often ignored but dangerous if misconfigured

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.

FSMO Role	Analogy	What it Does
Schema Master	Chief Architect — defines what kinds of things can exist in the company database	Manages the schema — the blueprint of AD: object types, attributes. Only one per forest.
Domain Naming Master	Company Registrar — ensures no two branches have the same name	Ensures unique domain names in the forest. Only one per forest.
Relative ID (RID) Master	ID Distributor — hands out unique IDs to new employees	Assigns Relative IDs (RIDs) so SIDs stay unique. One per domain.
PDC Emulator	Timekeeper + VIP — handles urgent requests, password resets, and time sync	Responds to auth requests, syncs passwords, manages GPOs, and time. One per domain.
Infrastructure Master	Translator — ensures names make sense when interacting across domains	Converts SIDs ↔ names across domains in a forest. One per domain (unless all DCs are GCs).

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.

Functional Level	Key Features Enabled	Supported DC OSes
2000 Native	Basic group features (nesting, SID history)	Server 2000–2008 R2
2003	Selective auth, constrained delegation, `lastLogonTimestamp`	Server 2003–2012 R2
2008	DFS-R for SYSVOL, AES support for Kerberos, fine-grained passwords	Server 2008–2012 R2
2008 R2	Authentication mechanism assurance, Managed Service Accounts	Server 2008 R2–2012 R2
2012	Claims-based auth, Kerberos armoring	Server 2012–2012 R2
2012 R2	Authentication Policies, Protected Users group enhancements	Server 2012 R2
2016	Smart card enforcement, new Kerberos & credential protections	Server 2016–2019

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.

Forest Level	New Capabilities
2003	Forest trusts, domain renaming, Read-Only DCs (RODCs)
2008	No new forest-level features, but sets new domains at 2008 level by default
2008 R2	AD Recycle Bin (undelete objects with attributes intact)
2012 / R2	No major new forest-level features
2016	Privileged Access Management (PAM) — isolates and limits the use of high-priv accounts

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?

Type	Analogy & Use
Parent-Child	In-family trust — child domain trusts its parent automatically (two-way, transitive)
Cross-Link	Shortcut between sibling domains to speed up authentication
External	Temporary visitor pass — between two unrelated domains (non-transitive)
Tree-Root	New branch of the company — connects a new root domain in the same forest (transitive)
Forest Trust	Merger agreement — connects two separate forests (transitive between roots only)

Trust Directions

Type	Description
One-way	Only users from Domain A can access Domain B — not vice versa
Two-way	Users from both domains can access each other's resources

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

graph LR

%% Define Nodes
INL["🌲 inlanefreight.local (Forest Root)"]
FL["🌲 freightlogistics.local (Forest Root)"]
SL["🌲 shippinglanes.local (Forest Root)"]
CORP["🏢 corp.inlanefreight.local"]
DEV["💻 dev.inlanefreight.local"]
WH["🏭 wh.corp.inlanefreight.local"]

%% Define Trust Lines (Links)
INL -->|Parent-Child Trust| CORP
INL -->|Parent-Child Trust| DEV
CORP -->|Parent-Child Trust| WH

WH -- Cross-Link --> DEV
INL -- Forest-Trust --> FL
INL -- Tree-Root --> SL

FL -- External --> SL

%% Define Classes for Styling
classDef foresttrust stroke:#4a90e2,stroke-width:2px;
classDef treeRoot stroke:#27ae60,stroke-dasharray: 5 5;
classDef crosslink stroke:#e67e22,stroke-width:2px,stroke-dasharray: 5 5;
classDef external stroke:#c0392b,stroke-width:2px,stroke-dasharray: 2 2;

%% Apply Classes to Nodes (Syntax: class NodeID ClassName)
class WH,DEV crosslink;

%% Apply Classes to Links (Syntax: linkStyle IndexOfLink ClassName)
linkStyle 4 foresttrust
linkStyle 5 treeRoot
linkStyle 6 external

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..

Subscribe to my monthly newsletter

No spam, no sharing to third party. Only you and me.