Understanding Active Directory: Architecture, Core Components, and Defense-in-Depth

Active Directory Domain Services (AD DS) serves as the primary identity, authentication, and policy fabric for more than 90% of Fortune 1000 organizations. Originally introduced with Windows 2000 Server, Active Directory transitioned enterprise computing away from uncoordinated flat workgroups and disparate account stores into a centrally managed, hierarchical directory service. In modern infrastructure, Active Directory is not merely a database of usernames and passwords. It is the operational engine that governs authentication, cryptographic authorization, access control lists (ACLs), and configuration state across vast fleets of endpoints, application servers, and hybrid cloud bridges.

For enterprise architects, chief information security officers (CISOs), and security engineers, Active Directory represents both the backbone of operational productivity and the crown jewel target for modern threat actors. When adversaries achieve initial access via social engineering, unpatched external edge appliances, or supply chain compromises, their primary objective is almost universally Active Directory reconnaissance and privilege escalation. A single configuration misstep or over-permissioned access control entry can enable an attacker to pivot from a standard workstation to complete control of the domain control plane.

Understanding Active Directory requires dissecting its dual architectural nature: its logical structure, which dictates policy governance and administrative boundaries, and its physical structure, which governs network traffic, high availability, and replication. This article provides an executive and technical breakdown of Active Directory, analyzing its core components, protocol mechanics, prevalent attack surfaces, and defense-in-depth hardening strategies.

Executive Context & The Identity Perimeter

Traditional perimeter-based defense models assumed that internal network traffic was implicitly trustworthy. The modern threat landscape has completely dismantled this assumption. The network perimeter has dissolved into an identity perimeter. In an Active Directory environment, every host, service, database, and employee account represents a node in a complex graph of trust relationships and access rights.

ENTERPRISE IDENTITY FABRIC:
[ Remote & On-Premises Users ] ────┐
[ Workstations & Endpoints   ] ────┼───> [ Active Directory Domain Services ]
[ Core Enterprise Services   ] ────┤         ├── Authentication (Kerberos / NTLM)
[ Hybrid Cloud (Entra ID)    ] ────┘         ├── Authorization (Security Groups / DACLs)
                                             └── Configuration Policy (GPOs / CSPs)

The criticality of Active Directory stems from three core operational realities:

Centralized Authentication and Authorization: AD validates identities via Kerberos v5 and Lightweight Directory Access Protocol (LDAP), issuing cryptographically signed tickets that govern access across filesystems, databases, and enterprise applications.
Deterministic Configuration State: Through Group Policy Objects (GPOs), systems administrators can enforce baseline security configurations, disable vulnerable protocols, and distribute software updates across hundreds of thousands of endpoints simultaneously.
Pivotal Blast Radius: Because AD domain controllers hold the password hashes and cryptographic keys of every domain principal, any compromise of the directory equates to a full compromise of all attached business systems.

Logical Architecture: Forests, Domains, and Organizational Units

Active Directory organizes objects into a structured logical hierarchy. This hierarchy allows enterprises to mirror organizational reporting structures, geographic divisions, and administrative trust boundaries independently of physical hardware locations.

LOGICAL ARCHITECTURE HIERARCHY:
+-------------------------------------------------------------+
|                          FOREST                             |
|  (Ultimate Security Boundary, Shared Schema, Global Catalog)|
|                                                             |
|  +---------------------------+  +------------------------+  |
|  |     TREE (corp.local)     |  |   TREE (subsidiary.com)|  |
|  |                           |  |                        |  |
|  |    +-----------------+    |  |    +--------------+    |  |
|  |    |  Root Domain    |    |  |    | Child Domain |    |  |
|  |    +--------┬--------+    |  |    +--------------+    |  |
|  |             │             |  +------------------------+  |
|  |    +--------┴--------+    |                              |
|  |    |  Child Domain   |    |                              |
|  |    | (emea.corp.local|    |                              |
|  |    +--------┬--------+    |                              |
|  |             │             |                              |
|  |    +--------┴--------+    |                              |
|  |    |    OUs & GPOs   |    |                              |
|  |    +-----------------+    |                              |
|  +---------------------------+                              |
+-------------------------------------------------------------+

1. The Forest (The True Security Boundary)

The forest is the highest container level in an Active Directory deployment. A forest represents the definitive security and administrative boundary of the identity infrastructure. All domains within a forest share three critical components:

A Single Common Schema: The formal definition of every object class (such as user, computer, group) and attributes (such as sAMAccountName, userPrincipalName, mail) that can exist within the directory.
A Unified Configuration Partition: The forest-wide metadata defining the physical topology, sites, and directory service configuration.
The Global Catalog: A forest-wide searchable index containing a partial attribute set of every object across all domains in the forest.

Administrators of the forest root domain (specifically members of the Enterprise Admins and Schema Admins groups) wield ultimate authority across the entire forest. Microsoft explicitly notes that individual domains within a forest are management boundaries, but not isolated security boundaries; an administrator with Domain Admin rights in a child domain can escalate privileges to compromise the forest root.

2. Trees and Domains

A domain is the fundamental administrative and replication unit of Active Directory. It groups objects that share a common security policy, user account database, and administrative permissions. Each domain maintains its own distinct domain partition within the directory database.

A domain tree consists of a collection of one or more domains that share a contiguous Domain Name System (DNS) namespace. For example, corp.local can serve as the root domain of a tree, while emea.corp.local and apac.corp.local operate as child domains within that same tree. Domains within the same forest are bound together by automatic, two-way transitive Kerberos trust relationships.

3. Organizational Units (OUs)

Organizational Units are container objects residing within a domain. Unlike domains, OUs do not act as separate replication partitions or namespaces. Instead, they provide administrative compartmentalization. OUs serve two fundamental functions:

Delegation of Administration: Granting specific administrative privileges over a subset of objects (e.g., allowing the Helpdesk team to reset passwords for accounts inside the OU=Staff,DC=corp,DC=local container without giving them full Domain Admin rights).
Group Policy Application: GPOs are linked to OUs, allowing distinct configurations, security baselines, and restriction policies to be applied selectively to specific user groups or device pools.

Physical Architecture: Domain Controllers, Sites, and FSMO Roles

While logical architecture defines how policies and administrative rights are arranged, the physical architecture defines how directory services communicate, replicate, and maintain uptime across geographical networks.

PHYSICAL INFRASTRUCTURE TOPOLOGY:
                      SITE: London (Subnet 10.10.0.0/16)
               +──────────────────────────────────────────────+
               |  [DC01] (PDC, GC) <─── Intra-site ───> [DC02]|
               +───────────────────────┬──────────────────────+
                                       │
                               Site Link (RPC/IP)
                                       │
               +───────────────────────┴──────────────────────+
               |  [DC03] (RODC)    <─── Intra-site ───> [DC04]|
               +──────────────────────────────────────────────+
                      SITE: New York (Subnet 10.20.0.0/16)

Domain Controllers and the NTDS.dit Database

A Domain Controller (DC) is a Windows Server system running the Active Directory Domain Services server role. Each writable DC maintains a full, writable replica of the directory database, stored in %SystemRoot%\NTDS\ntds.dit. This database is structured on the Extensible Storage Engine (ESE / JET Blue engine).

Active Directory employs a multi-master replication model. Unlike traditional primary-replica database models where writes must occur on a designated primary node, administrators can create, modify, or delete objects on any writable domain controller. The change is then propagated asynchronously to all other domain controllers in the partition via State-Based Replication using Update Sequence Numbers (USNs).

Sites, Subnets, and Intersite Topology

An Active Directory Site represents one or more well-connected IP subnets, typically corresponding to a high-speed Local Area Network (LAN) in a physical office or data center. Configuring sites accurately delivers two key advantages:

Intra-site vs. Inter-site Replication: Within a site, replication occurs uncompressed using change notifications with minimal latency. Between sites, replication is scheduled, compressed, and throttled to prevent saturating Wide Area Network (WAN) bandwidth.
Client Localization: When a workstation attempts to authenticate, it queries DNS for local SRV records to discover the closest domain controller within its assigned site, avoiding unnecessary latency and cross-WAN dependency.

Flexible Single Master Operation (FSMO) Roles

Although Active Directory relies on multi-master replication for day-to-day operations, certain specialized operations require strict single-master coordination to avoid database conflicts. Active Directory dedicates five specialized single-master roles, known as FSMO (Flexible Single Master Operation) roles:

FSMO Role Name	Scope	Operational Responsibility	Impact of Offline Role
Schema Master	Forest-wide	Controls all modifications, additions, and updates to the forest directory schema.	Schema updates (e.g., Exchange or OS upgrades) fail; normal user authentication is unaffected.
Domain Naming Master	Forest-wide	Governs the addition or removal of domains, application partitions, and directory trees in the forest.	Cannot add or decommission domains; runtime authentication unaffected.
PDC Emulator	Domain-wide	Processes password changes immediately, acts as the root time server (NTP), handles account lockouts, and edits GPOs.	Password changes face replication delay; time drift may disrupt Kerberos tickets; GPO conflict risk.
RID Master	Domain-wide	Allocates pools of relative identifiers (RIDs) to DCs for creating security principals with unique SIDs.	New object creation fails once local DC exhausts its current RID pool (typically 500 RIDs).
Infrastructure Master	Domain-wide	Translates object references, cross-domain SIDs, and group memberships in multi-domain setups.	Cross-domain object name updates delay; unnoticeable in single-domain forests or where all DCs host GC.

Core Authentication Protocols: Kerberos v5, NTLM, and LDAP

Authentication is the mechanism by which Active Directory verifies that a client is who they claim to be. Active Directory relies on two primary authentication suites, with Kerberos v5 operating as the modern default and NTLM serving as a legacy fallback.

KERBEROS AUTHENTICATION CYCLE:
[ Client ] ───── 1. AS-REQ (Pre-Auth Timestamp encrypted with User Hash) ────> [ Key Distribution Center ]
           <──── 2. AS-REP (TGT + Session Key) ────────────────────────────── (KDC / Domain Controller)
           ───── 3. TGS-REQ (TGT + Requested Service SPN) ───────────────────>
           <──── 4. TGS-REP (Service Ticket + Service Session Key) ───────────
           ───── 5. AP-REQ (Service Ticket with PAC) ────────────────────────> [ Target Application Server ]
           <──── 6. Access Granted / Mutual Authentication ───────────────────

The Kerberos v5 Protocol Flow

Authentication Service Exchange (AS-REQ / AS-REP): The client requests a Ticket Granting Ticket (TGT). The client encrypts a current timestamp using a key derived from the user's password (pre-authentication). The Key Distribution Center (KDC), running on the Domain Controller, decrypts the timestamp using its copy of the user's secret key. Upon validation, the KDC issues a TGT encrypted with the domain's secret KRBTGT account key, alongside a client session key.
Ticket-Granting Service Exchange (TGS-REQ / TGS-REP): When the user wants to access a network resource (such as a file share or MSSQL database), the client presents its TGT to the KDC and specifies the Service Principal Name (SPN) of the destination target. The KDC validates the TGT, validates the user's Privilege Attribute Certificate (PAC), and issues a Service Ticket encrypted with the secret key of the target service account.
Application Exchange (AP-REQ / AP-REP): The client presents the Service Ticket directly to the target application server. The application server decrypts the ticket using its own local password hash, extracts the user's PAC (which lists the user's SID and group memberships), and determines whether to permit access without querying the DC again.

Lightweight Directory Access Protocol (LDAP) and Directory Queries

LDAP is the communication protocol used to query, search, and update objects inside the Active Directory database. Standard LDAP communicates over TCP port 389 in cleartext, leaving credentials and query parameters vulnerable to network sniffing and manipulation. Secure LDAP (LDAPS) encrypts traffic over TCP port 636 using Transport Layer Security (TLS). Enforcing LDAP signing and LDAPS channel binding is a baseline requirement to defend against Adversary-in-the-Middle (AiTM) relay attacks.

Threat Modeling: Primary Active Directory Attack Surfaces

Because Active Directory is fundamentally interconnected, modern attackers do not attack individual machines in isolation. They identify trust paths, exploit misconfigurations, and abuse protocol weaknesses to move laterally and escalate privileges.

ATTACK ESCALATION PATHWAY:
[ Initial Access Workstation ]
           │
           ├── (LLMNR/NBT-NS Poisoning) ──> Intercept NTLM Hash ──> Crack Password
           ├── (BloodHound Reconnaissance)──> Map Weak DACLs & Unconstrained Delegation
           ├── (Kerberoasting) ───────────> Request TGS for SPN ──> Offline Cracking (T1558.003)
           ├── (Local LSASS Dump) ─────────> Obtain Stale Admin Creds (T1003.001)
           └── (DCSync Attack) ───────────> Impersonate DC Replication ──> Extract Full KRBTGT Hash

1. Kerberoasting (MITRE ATT&CK T1558.003)

Any authenticated domain user can request a Kerberos service ticket (TGS) for any valid Service Principal Name (SPN) registered in the domain. Because the service ticket is encrypted with the password hash of the service account associated with that SPN, the attacker can extract the encrypted ticket from memory and attempt offline dictionary or brute-force cracking. If service accounts utilize weak passwords, adversaries can recover the cleartext plaintext password without generating account lockout events on the domain controller.

2. DCSync (MITRE ATT&CK T1003.006)

The DCSync technique abuses the directory replication protocols (DS-Replication-Get-Changes and DS-Replication-Get-Changes-All). If an attacker compromises an account that has directory replication privileges (such as a Domain Admin or an account with delegated sync rights), the attacker can simulate the behavior of a legitimate Domain Controller using tools such as Mimikatz. The attacker queries the DC for the password hashes of any user in the domain, including the critical krbtgt account hash, without executing code on the domain controller itself.

3. AS-REP Roasting (MITRE ATT&CK T1558.004)

If a user account has the configuration flag DONT_REQ_PREAUTH ("Do not require Kerberos preauthentication") enabled, any user can send an AS-REQ request to the KDC on that user's behalf. The KDC responds with an AS-REP packet encrypted with the victim's password hash. The attacker captures this packet and cracks the user's password offline without sending any alert to the victim.

4. Overpass-the-Hash and Pass-the-Ticket (T1550.002 / T1550.003)

When administrative users log into compromised workstations, their credentials and Kerberos tickets remain cached in the Local Security Authority Subsystem Service (lsass.exe) process memory. Adversaries use credential-dumping tools to harvest these artifacts, injecting stolen TGTs or using NTLM hashes to request Kerberos tickets, bypassing multi-factor authentication controls.

Actionable Governance: Hardening Active Directory

Securing Active Directory requires moving away from the outdated paradigm where every IT administrator shares a single Domain Admin account. Organizations must implement strict architectural segregation, modern credential hygiene, and continuous auditing.

1. The Enterprise Access Model (Tiered Administration)

Microsoft's classic Tier Administration Model and modern Enterprise Access Model divide enterprise assets into distinct planes of control to prevent credential theft escalation:

TIERED ADMINISTRATION ARCHITECTURE:
+-------------------------------------------------------------------+
| TIER 0: CONTROL PLANE (Highest Security, Zero Internet Egress)    |
| - Domain Controllers, PKI/CA, Entra ID Connect, Active Directory  |
| - Dedicated Privileged Access Workstations (PAWs)                 |
| - Strictly NO logon to Tier 1 or Tier 2 systems                   |
+-------------------------------------------------------------------+
                                 │ (No down-tier credential exposure)
+--------------------------------▼----------------------------------+
| TIER 1: SERVER & APPLICATION PLANE                                |
| - Enterprise Databases, Line-of-Business Servers, Cloud VMs       |
| - Server Administrators with dedicated Tier 1 credentials         |
+-------------------------------------------------------------------+
                                 │ (No down-tier credential exposure)
+--------------------------------▼----------------------------------+
| TIER 2: WORKSTATION & USER PLANE                                  |
| - Laptops, Workstations, Mobile Devices, General Helpdesk         |
| - Local workstation administrator passwords randomized via LAPS   |
+-------------------------------------------------------------------+

Tier 0 (Control Plane): Houses systems that control enterprise identity, including Domain Controllers, ADFS, and PKI infrastructure. Tier 0 administrative accounts must never log onto lower-tier machines, eliminating the risk of credential scraping from compromised endpoints.
Tier 1 (Server Plane): Contains enterprise servers, storage arrays, and line-of-business applications.
Tier 2 (Workstation Plane): Contains end-user laptops, printers, and client workstations.

2. Windows Local Administrator Password Solution (Windows LAPS)

Attackers routinely leverage shared local administrator passwords to execute Pass-the-Hash attacks and pivot across endpoints. Organizations must deploy Windows LAPS, which automatically generates a unique, cryptographically random password for the built-in local administrator account on each domain-joined workstation and server. The password is periodically rotated and stored in an encrypted attribute inside Active Directory or Microsoft Entra ID, accessible only to authorized personnel.

3. Service Account Hardening: Transition to gMSAs

Traditional service accounts rely on static passwords that rarely change and frequently possess administrative permissions. Organizations should replace standard user accounts running background services with Group Managed Service Accounts (gMSAs):

Windows automatically rotates the 120-character password every 30 days without requiring service restarts.
gMSAs cannot be used for interactive console logins.
Complex cryptographic passwords neutralize offline Kerberoasting attacks.

Active Directory Security Checklist

The following audit checklist outlines essential operational tasks aligned with ISO/IEC 27001:2022 (Control A.9 - Access Control) and the CIS Microsoft Windows Server Benchmark:

1. Identity & Privileged Access Baselines

✓ Enforce the 3-Tier Enterprise Access Model; isolate Tier 0 administrative credentials.
✓ Mandate dedicated Privileged Access Workstations (PAWs) for all directory administration.
✓ Restrict Domain Admin and Enterprise Admin group memberships to emergency break-glass scenarios.
✓ Implement Windows LAPS across all domain-joined endpoints and member servers.
✓ Replace static service account credentials with Group Managed Service Accounts (gMSAs).

2. Protocol Hardening & Legacy Decommissioning

✓ Disable NTLMv1 domain-wide; audit and transition systems to Kerberos or NTLMv2.
✓ Enforce LDAP Server Signing and LDAPS Channel Binding to prevent relay attacks.
✓ Disable LLMNR and NetBIOS Name Resolution via Group Policy across all subnets.
✓ Enforce AES-128 and AES-256 encryption types for Kerberos; disable DES and RC4 cipher suites.
✓ Audit user accounts for the "Do not require Kerberos preauthentication" flag and remove it.

3. Continuous Monitoring & Threat Detection

✓ Enable Advanced Audit Policy configuration: Monitor Event IDs 4768 (TGT Request), 4769 (TGS Request), and 4728 (Member Added to Security Group).
✓ Monitor replication rights on domain root objects to detect unauthorized DCSync permissions.
✓ Regularly execute BloodHound or PingCastle audits to uncover hidden privilege escalation paths.
✓ Implement periodic rotation of the krbtgt account password (double rotation procedure with a 24-hour gap).

Strategic Summary

Active Directory remains the foundation of enterprise trust, authentication, and directory data. While logical structures such as forests and domains define policy hierarchy, the physical infrastructure of domain controllers, sites, and FSMO masters ensures business continuity across global operations. Because Active Directory concentrates access to all enterprise assets, securing it requires treating directory services as a Tier 0 control plane. By adopting structured tiering models, eliminating legacy protocols such as NTLM and cleartext LDAP, and continually monitoring the Kerberos authentication cycle, enterprises can establish a resilient identity architecture prepared for modern hybrid threats.

Love it? Share this article: