> ## Content Index > Fetch the complete content index at: https://niklas-heringer.com/llms.txt > Use this file to discover other available public pages before exploring further. # Active Directory Demystified: A Practical Learning Journey - Day One - URL: https://niklas-heringer.com/penetration-testing/introduction-to-active-directory/ - Published: 2025-06-11T13:43:00.000Z - Updated: 2025-11-19T18:37:51.000Z - Description: 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. - Author: Niklas Heringer - Tags: ad-challenge, active-directory, windows-security, domain-escalation, ad-infrastructure, network-enumeration, penetration-testing 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](https://www.offsec.com/blog/oscp-exam-structure/?ref=niklas-heringer.com) (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`: ```text 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`. ```text 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 ## Sign up for Niklas Heringer Cybersecurity & Math: Aspiring penetration tester at ERNW, exploring risk, automation, and offense through analysis and experience. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. --- # 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**](https://www.crowdstrike.com/en-us/cybersecurity-101/cyberattacks/kerberoasting/?ref=niklas-heringer.com) **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: ![](https://storage.ghost.io/c/a1/92/a19235e1-df52-43a1-9f25-1151fdb92c82/content/images/2025/11/trusts-diagram.png) --- > That's it *for this one*. Next time we'll continue with Kerberos, DNS, LDAP, MSRPC, **all that fun stuff**..