8.1 Active Directory Architecture & Domain Reconnaissance

8.1 Active Directory Architecture & Domain Reconnaissance

Active Directory Domain Services (AD DS) is the central identity, authentication, and authorization backbone for over 90% of enterprise environments globally. For security analysts preparing for the CREST Practitioner Security Analyst (CPSA) examination, assessing an Active Directory environment requires moving beyond isolated host testing to evaluating interconnected forest structures, protocol exchanges, directory service queries, and relational access control lists (ACLs).

---

Active Directory DS Architecture: Forests, Trees & Domains

Active Directory is structured as a hierarchical, distributed database that coordinates access to network resources across an enterprise.

+-----------------------------------------------------------------------------+
|                             ACTIVE DIRECTORY FOREST                         |
|                               (Security Boundary)                           |
|                                                                             |
|   +------------------------------------+   +----------------------------+   |
|   |             TREE 1                 |   |           TREE 2           |   |
|   |       (corp.internal)              |   |     (partnercorp.net)      |   |
|   |                                    |   |                            |   |
|   |  [Forest Root: corp.internal]      |   | [Root: partnercorp.net]    |   |
|   |          /             \           |   +----------------------------+   |
|   | [emea.corp.internal] [apac.corp...] |                                   |
|   +------------------------------------+                                    |
|                                                                             |
|   Forest-Wide Partitions: Schema & Configuration                            |
|   Domain-Specific Partitions: Domain (Users, Groups, Computers)             |
+-----------------------------------------------------------------------------+

1. Logical Hierarchy Components

• Domain: The fundamental administrative unit in Active Directory. A domain stores identity objects (users, computers, groups) and security policies that apply uniformly to those objects. Every domain possesses a unique Security Identifier (Domain SID) and DNS namespace (e.g., corp.internal).
• Domain Tree: A collection of one or more domains that share a contiguous DNS namespace. For example, emea.corp.internal and apac.corp.internal form child domains branching from the parent tree root corp.internal.
• Forest: The top-level container and ultimate security boundary in Active Directory. A forest consists of one or more trees that share a common directory schema (object definitions and attribute rules), configuration partition (site topology and service bindings), and Global Catalog. The first domain created in a forest is designated as the Forest Root Domain.

2. Active Directory Database Partitions (Naming Contexts)

The directory database (NTDS.dit) is partitioned into distinct logical naming contexts:

1. Schema Partition: Defines every object class (e.g., user, group, computer) and attribute (e.g., sAMAccountName, servicePrincipalName) that can exist in the forest. Replicates forest-wide.
2. Configuration Partition: Contains the physical and logical forest topology, including AD sites, subnets, directory-enabled services, and domain partitions. Replicates forest-wide.
3. Domain Partition: Stores all directory objects specific to that particular domain (accounts, security groups, OUs, and Group Policy Objects). Replicates exclusively among Domain Controllers within that specific domain.
4. Application Partitions: Stores application-specific data, such as Active Directory-Integrated DNS zones (ForestDnsZones and DomainDnsZones).

---

Domain Controllers & The Global Catalog (GC)

Domain Controllers (DCs)

A Domain Controller is a Windows Server running the AD DS server role that stores a replica of the directory database, authenticates user and computer logons, and enforces enterprise security policies. Domain Controllers utilize multi-master replication, meaning changes to directory objects can be made on any writable DC and subsequently replicated to peer DCs. Specific single-master operations that cannot tolerate concurrent modifications are delegated to five Flexible Single Master Operation (FSMO) roles:

• Forest-wide: Schema Master and Domain Naming Master.
• Domain-wide: PDC Emulator (handles password changes and Kerberos time synchronization), RID Master (allocates RID pools to DCs), and Infrastructure Master (updates cross-domain object references).

The Global Catalog (GC)

The Global Catalog is a specialized Domain Controller role designed to facilitate cross-domain searches and accelerate authentication across complex multi-domain forests.

• Storage Architecture: The GC maintains a full replica of all objects in its own host domain partition, plus a partial attribute replica (the Partial Attribute Set, or PAS) of every object across every other domain in the entire forest. Attributes in the PAS include commonly queried fields such as sAMAccountName, displayName, userPrincipalName, and object SIDs.
• Network Ports:
  • TCP Port 3268: LDAP queries targeting the Global Catalog (unencrypted).
  • TCP Port 3269: LDAPS queries targeting the Global Catalog (TLS-encrypted).
• Authentication Role: During user authentication, the GC resolves Universal Group memberships. If a GC is unavailable and universal group membership caching is disabled, logon requests in multi-domain environments will fail.

---

Active Directory Trust Relationships & Security Boundaries

Trusts establish communication channels between domains or forests to enable cross-boundary authentication and resource authorization.

                    TRUST DIRECTION vs ACCESS DIRECTION
                    
        Trusting Domain (Resource)  -------- Trusts -------->  Trusted Domain (Account)
     [Holds File Shares & Services]                            [Holds User Accounts]
     
             User Access Direction  <=== Access Granted ======  Enterprise Users

Trust Characteristics

1. Directionality:
   • One-Way Trust: Domain A trusts Domain B. Users in Domain B can access permitted resources in Domain A. Users in Domain A cannot access resources in Domain B. The direction of access is the exact inverse of the direction of trust.
   • Two-Way Trust: Both domains trust each other. Users in either domain can access authorized resources in the partner domain.
2. Transitivity:
   • Transitive Trust: Trust extends beyond two immediate domains. If Domain A trusts Domain B, and Domain B trusts Domain C, Domain A automatically trusts Domain C. All parent-child and tree-root trusts within an AD forest are two-way and transitive by default.
   • Non-Transitive Trust: Trust is strictly bounded to the two partner domains. It does not extend to any child or parent domains.

Trust Classifications

• Parent-Child & Tree-Root Trusts: Created automatically within a forest; two-way and transitive.
• External Trust: A non-transitive trust established between a domain in one forest and a domain in another forest, or with a legacy Windows NT 4.0 domain.
• Forest Trust: A transitive trust established between two Forest Root Domains. Permits Kerberos ticket referrals across forests and allows administrators in one forest to grant permissions to users in the other forest.

The Forest as the True Security Boundary

A fundamental security principle heavily tested on CREST examinations is that the Forest is the ultimate security boundary in Active Directory, not the individual domain.

CREST Exam Focus: Domain vs Forest Boundary Individual domains within a forest provide administrative segregation, but not absolute security isolation. An administrator with Domain Admin or local SYSTEM rights on a Domain Controller in a child domain can exploit forest-wide schema and configuration replication, compromise Enterprise Admins, or abuse the krbtgt architecture to gain complete control over all other domains in the forest.

SID Filtering (Quarantine)

When Kerberos authentication traverses an inter-forest trust, the client presents a Privilege Attribute Certificate (PAC) containing the user's SIDs and security group memberships. In legacy configurations, an attacker possessing administrative control over trusted Forest B could inject the Domain Admin or Enterprise Admin SID of Forest A into the PAC's sIDHistory attribute, resulting in unauthorized administrative access within Forest A.

SID Filtering mitigates this vulnerability by inspecting the PAC at the trust boundary and stripping any foreign SIDs that do not belong to the relative namespace of the trusted forest. On external and forest trusts, SID filtering is enabled by default to preserve the security boundary between distinct enterprise forests.

---

Core Active Directory Network Ports

Assessing an AD environment requires identifying the operational state of core infrastructure ports on Domain Controllers and domain members:

---

DNS SRV Record Discovery for Active Directory

Active Directory clients locate Domain Controllers dynamically using Domain Name System (DNS) Service (SRV) records. SRV records map a requested service and protocol to the fully qualified domain name (FQDN) and listening port of the authoritative host.

_Service._Proto.Name    TTL   Class  Priority  Weight  Port   Target
_ldap._tcp.corp.local.  3600  IN SRV 0         100     389    dc01.corp.local.

Essential SRV Records for Assessment

Penetration testers query specific SRV records under the _msdcs.<forest-root> sub-domain to enumerate infrastructure roles from an unauthenticated network position:

# Enumerate all Domain Controllers offering LDAP services in the domain
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.internal

# Query using dig to resolve all Kerberos Key Distribution Centers (KDCs)
dig -t SRV _kerberos._tcp.corp.internal

# Discover all Global Catalog servers across the forest root
dig -t SRV _gc._tcp.corp.internal

# Locate the Primary Domain Controller (PDC) Emulator
nslookup -type=SRV _ldap._tcp.pdc._msdcs.corp.internal

---

LDAP Reconnaissance: Unauthenticated vs Authenticated

The Lightweight Directory Access Protocol (LDAP) is the primary mechanism for interrogating and updating the Active Directory database.

1. Anonymous / Unauthenticated LDAP Reconnaissance (RootDSE)

Most modern Domain Controllers restrict anonymous directory searches. However, RFC 4512 mandates that every LDAP server maintain a RootDSE (Root Directory System Agent Specific Entry) object that clients can query without authentication to determine the server's capabilities, supported protocols, and directory naming contexts.

An unauthenticated tester can query the RootDSE to extract foundational domain intelligence:

ldapsearch -x -H ldap://192.168.10.10 -s base -b "" "(objectclass=*)" namingContexts defaultNamingContext dnsHostName domainFunctionality

# Critical Metadata Returned by RootDSE:
defaultNamingContext: DC=corp,DC=internal
configurationNamingContext: CN=Configuration,DC=corp,DC=internal
schemaNamingContext: CN=Schema,CN=Configuration,DC=corp,DC=internal
dnsHostName: DC01.corp.internal
ldapServiceName: corp.internal:dc01$@CORP.INTERNAL
supportedLDAPVersion: 3
supportedLDAPVersion: 2
domainFunctionality: 7   (Windows Server 2016 / 2019 / 2022 level)

2. Authenticated LDAP Enumeration

Once a tester obtains valid domain credentials (even for a low-privileged user or service account), LDAP provides broad visibility into the domain's objects, group memberships, and security configurations.

A. High-Value Object Queries

• Domain Users: (&(objectCategory=person)(objectClass=user))
• Domain Groups: (objectCategory=group)
• Domain Controllers: (&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=8192))
• Organizational Units (OUs): (objectCategory=organizationalUnit)

B. Identifying Protected Administrative Objects: AdminCount=1

Active Directory protects high-privilege accounts (e.g., Domain Admins, Enterprise Admins, Backup Operators) using a background system thread called AdminSDHolder. Every 60 minutes, the SDProp (Security Descriptor Propagator) process runs on the PDC Emulator, copies the restrictive security descriptor from CN=AdminSDHolder,CN=System,DC=domain,DC=com to all protected objects, and sets their adminCount attribute to 1.

Querying for (adminCount=1) reveals all current and historically privileged accounts in the domain:

ldapsearch -x -H ldap://192.168.10.10 -D "user@corp.internal" -W -b "DC=corp,DC=internal" "(adminCount=1)" sAMAccountName description

C. Identifying Kerberoastable Accounts via SPNs

Any domain user account with a registered servicePrincipalName can be targeted for Kerberoasting. By excluding computer accounts, testers extract high-value user service accounts:

ldapsearch -x -H ldap://192.168.10.10 -D "user@corp.internal" -W -b "DC=corp,DC=internal" "(&(servicePrincipalName=*)(!(objectCategory=computer)))" sAMAccountName servicePrincipalName

D. UserAccountControl (UAC) Flags & Bitwise LDAP Filters

The userAccountControl attribute is an integer bitmask that controls account properties. LDAP filters utilize the Extensible Match Rule 1.2.840.113556.1.4.803 (LDAP_MATCHING_RULE_BIT_AND) to evaluate individual bits within the bitmask:

# Query for accounts vulnerable to AS-REP Roasting (DONT_REQ_PREAUTH = 4194304)
ldapsearch -x -H ldap://192.168.10.10 -D "user@corp.internal" -W -b "DC=corp,DC=internal" "(userAccountControl:1.2.840.113556.1.4.803:=4194304)" sAMAccountName

# Query for active accounts with non-expiring passwords (DONT_EXPIRE_PASSWORD = 65536)
ldapsearch -x -H ldap://192.168.10.10 -D "user@corp.internal" -W -b "DC=corp,DC=internal" "(&(userAccountControl:1.2.840.113556.1.4.803:=65536)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" sAMAccountName

---

Graph-Based Attack Path Modeling: BloodHound & SharpHound

Traditional enterprise security reviews evaluate Active Directory through static checklists (e.g., checking if password policies enforce 14 characters). However, modern adversaries and penetration testers analyze Active Directory as a directed graph.

+-----------------------------------------------------------------------------+
|                        BLOODHOUND ATTACK PATH GRAPH                         |
+-----------------------------------------------------------------------------+
| [Standard User]                                                             |
|        |                                                                    |
|        | (MemberOf)                                                         |
|        v                                                                    |
| [Helpdesk Group]                                                            |
|        |                                                                    |
|        | (AdminTo)                                                          |
|        v                                                                    |
| [Workstation WS-042] <---- (HasSession) ---- [Domain Admin Session]         |
|        |                                              |                     |
|        | (Dump LSASS Credentials)                     |                     |
|        +--------------------------------------------->+                     |
|                                                       |                     |
|                                                       | (MemberOf)          |
|                                                       v                     |
|                                               [Domain Admins Group]         |
+-----------------------------------------------------------------------------+

Conceptual Mechanics

• Graph Primitives: BloodHound represents AD entities as nodes (Users, Computers, Groups, OUs, GPOs, Domains) and administrative relationships or privileges as directed edges.
• Relational Attack Vectors: High-privilege access is rarely achieved via a single vulnerability. Instead, attackers chain non-obvious relationships:
  • MemberOf: Nested group memberships.
  • AdminTo: Local administrative rights over endpoints.
  • HasSession: Active user logon sessions residing in workstation LSASS memory.
  • GenericAll / WriteDacl: Object-level discretionary access control list (DACL) permissions granting the ability to grant oneself full rights or reset passwords.
  • GenericWrite: Ability to alter attributes (e.g., modifying scriptPath or servicePrincipalName).
  • ForceChangePassword: Direct password reset capability over target user objects.

SharpHound Ingestion Mechanics

SharpHound is the data collection engine for BloodHound. It queries Domain Controllers via authenticated LDAP, invokes MSRPC/NetAPI (NetSessionEnum, NetLocalGroupGetMembers) over SMB port 445 against domain endpoints, and collects directory metadata:

• DCOnly: Collects only directory data stored directly on Domain Controllers (group memberships, domain trusts, object ACLs, SPNs). Generates zero network traffic to individual workstations, making it fast and stealthy.
• Session: Interrogates domain workstations using MSRPC (NetWkstaUserEnum) or the Windows Registry to determine where high-privilege users (such as Domain Admins) are actively logged in.
• ComputerOnly / LoggedOn: Resolves local group memberships (Administrators, Remote Desktop Users) on individual endpoints.

By computing the shortest path from a compromised standard user node to the Domain Admins or Enterprise Admins group, BloodHound reveals complex, multi-hop privilege escalation paths that are impossible to identify through manual inspection.