Multi-Forest Active Directory Architecture: How Forests, Trusts, DNS, and Tiered Services Actually Work

Series · 3 partsActive Directory Architecture & InternalsPart 1 · You are here

1. 1Multi-Forest Active Directory Architecture: How Forests, Trusts, DNS, and Tiered Services Actually WorkYou are here
2. 2Inside Kerberos Delegation: Why Multi-Tier Windows Apps Need It (and Why It Breaks)
3. 3Active Directory as a Directed Graph: How Security Descriptors and Object ACLs Actually Work

Directory Topology and Forest Security Boundaries

In enterprise environments, Active Directory security assessments frequently fail when operators mistake domain administrative boundaries for security boundaries. A Domain Controller is not an isolated target; it is a node in a replicated directory topology governed by directory partitions, trust attributes, and service locator records. Misconfigurations in Active Directory are rarely software bugs: they are standard Windows architecture features operating across misconfigured trust boundaries:

• AS-REP Roasting and Kerberoasting are standard RFC 4120 ticket exchanges (AS-REP and TGS-REP) encrypted with the target account’s long-term secret key, allowing stateless KDCs to avoid maintaining per-client session state in memory.
• Constrained Delegation (S4U2Self / S4U2Proxy) is a protocol extension allowing multi-tier enterprise applications (such as an IIS web frontend querying a backend MSSQL database) to impersonate authenticated users without handling or storing cleartext passwords.
• Parent-Child ExtraSids Privilege Escalation functions because a child domain is an administrative unit, not a security boundary. Every domain inside an Active Directory forest shares the same Configuration and Schema partitions.
• Directory Graph Enumeration (BloodHound) operates because Windows member servers and domain clients require read access to directory metadata and object security descriptors (nTSecurityDescriptor) under the Authenticated Users identity to apply Group Policies, resolve SIDs, and locate services.

The five-server GOAD (Game of Active Directory) lab provides a complete reference model for evaluating multi-tier architecture. Through read-only LDAP and DNS queries dispatched from a security auditing host (192.168.56.0/24), this analysis details how two distinct forests, three domains, three Domain Controllers, and two member servers interact under Microsoft Windows Server protocols.

---

1. Directory Partitions: Why the Forest Is the Sole Security Boundary

When the first Domain Controller is promoted in an Active Directory forest (Install-ADDSForest), Windows creates an Extensible Storage Engine (ESE) database file at C:\Windows\NTDS\ntds.dit. Within this database, objects are segregated into distinct logical Naming Contexts (Partitions) to govern directory replication scope across Domain Controllers.

Querying CN=Partitions,CN=Configuration,DC=sevenkingdoms,DC=local on DC01 (192.168.56.10) displays the complete partition registration set for Forest 1:

$ ldapsearch -x -H ldap://192.168.56.10 -D "[email protected]" -w "Heartsbane" \
    -b "CN=Partitions,CN=Configuration,DC=sevenkingdoms,DC=local" "(objectClass=crossRef)" \
    cn nCName dnsRoot | grep -E "^(cn|nCName|dnsRoot)"
cn: Enterprise Configuration
nCName: CN=Configuration,DC=sevenkingdoms,DC=local
dnsRoot: sevenkingdoms.local
cn: Enterprise Schema
nCName: CN=Schema,CN=Configuration,DC=sevenkingdoms,DC=local
dnsRoot: sevenkingdoms.local
cn: SEVENKINGDOMS
nCName: DC=sevenkingdoms,DC=local
dnsRoot: sevenkingdoms.local
cn: NORTH
nCName: DC=north,DC=sevenkingdoms,DC=local
dnsRoot: north.sevenkingdoms.local
cn: 3d4b07e3-c44f-4f9e-ab6c-19dbc611d4e3
nCName: DC=DomainDnsZones,DC=sevenkingdoms,DC=local
dnsRoot: DomainDnsZones.sevenkingdoms.local
cn: 7a98ffc5-6322-406d-89c3-4f33b87dd679
nCName: DC=ForestDnsZones,DC=sevenkingdoms,DC=local
dnsRoot: ForestDnsZones.sevenkingdoms.local
cn: a7e87a5b-d212-4656-9be1-dc9505595501
nCName: DC=DomainDnsZones,DC=north,DC=sevenkingdoms,DC=local
dnsRoot: DomainDnsZones.north.sevenkingdoms.local

Partition Classes and Replication Scopes

In corporate architectures, organizations frequently provision child domains (such as north.sevenkingdoms.local) to delegate administrative control to subsidiary teams without standing up separate forests. However, because DC01 (kingslanding) and DC02 (winterfell) share the same forest-wide CN=Configuration and CN=Schema partitions, Microsoft defines the forest, not the domain, as the true security boundary.

Within a forest, parent-child trusts do not enforce SID filtering. Consequently, compromising a child Domain Controller (DC02) yields the domain’s krbtgt hash, allowing the generation of a Kerberos ticket containing the parent forest root’s Enterprise Admins SID (S-1-5-21-3291916993-3717649449-3745629854-519) in the ExtraSids (sIDHistory) attribute, compromising the entire forest.

---

2. Multi-Forest DNS and _msdcs Service Resolution

Windows Active Directory depends entirely on DNS for service discovery. Prior to initiating LDAP binds, Kerberos ticket requests, or Group Policy updates, Windows clients issue RFC 2782 SRV queries to resolve the IP addresses and port numbers of directory services.

Each Domain Controller in GOAD hosts the Windows DNS Server role for its authoritative zone (.10 for sevenkingdoms.local, .11 for north.sevenkingdoms.local, and .12 for essos.local). Querying the core _msdcs records demonstrates this locator process:

$ dig @192.168.56.10 _ldap._tcp.dc._msdcs.sevenkingdoms.local SRV +short
0 100 389 kingslanding.sevenkingdoms.local.

$ dig @192.168.56.10 _kerberos._tcp.dc._msdcs.sevenkingdoms.local SRV +short
0 100 88 kingslanding.sevenkingdoms.local.

$ dig @192.168.56.10 _ldap._tcp.pdc._msdcs.sevenkingdoms.local SRV +short
0 100 389 kingslanding.sevenkingdoms.local.

$ dig @192.168.56.10 _ldap._tcp.gc._msdcs.sevenkingdoms.local SRV +short
0 100 3268 kingslanding.sevenkingdoms.local.
0 100 3268 winterfell.north.sevenkingdoms.local.

The Global Catalog query (_ldap._tcp.gc._msdcs.sevenkingdoms.local) returns both kingslanding (.10) and winterfell (.11) on port 3268. Because the Global Catalog indexes all objects forest-wide, any client in sevenkingdoms.local can query winterfell over port 3268 to resolve universal group memberships or cross-domain UPNs.

Cross-Forest Resolution via Conditional Forwarders

Because sevenkingdoms.local and essos.local occupy separate forests without a shared Global Catalog, cross-forest resolution requires DNS Conditional Forwarders configured on DC01 and DC03:

Add-DnsServerConditionalForwarderZone -Name "essos.local" -MasterServers 192.168.56.12

When a host in north.sevenkingdoms.local queries braavos.essos.local, the local DNS server forwards the query directly to 192.168.56.12 (meereen.essos.local).

From an auditing perspective, conditional forwarders expose cross-forest trust relationships to unauthenticated DNS recon. Furthermore, because Active Directory-Integrated DNS (DC=DomainDnsZones and DC=ForestDnsZones) permits Authenticated Users to create new records by default, compromised accounts can inject wildcard or target records to poison name resolution when SMB signing is not enforced.

---

3. Trust Architecture: Trusted Domain Objects and Kerberos Referrals

While DNS enables cross-forest hostname resolution, cross-domain authentication requires a Trusted Domain Object (trustedDomain) residing in CN=System,DC=<domain>,DC=<tld>.

Querying the trustedDomain entries on DC01 (sevenkingdoms.local) and DC03 (essos.local) reveals the routing flags:

$ ldapsearch -x -H ldap://192.168.56.10 -D "[email protected]" -w "Heartsbane" \
    -b "CN=System,DC=sevenkingdoms,DC=local" "(objectClass=trustedDomain)" \
    cn flatName trustDirection trustType trustAttributes | grep -E "^(cn|flatName|trust)"
cn: north.sevenkingdoms.local
trustDirection: 3
trustType: 2
trustAttributes: 32
flatName: NORTH
cn: essos.local
trustDirection: 3
trustType: 2
trustAttributes: 72
flatName: ESSOS

$ ldapsearch -x -H ldap://192.168.56.12 -D "[email protected]" -w "fr3edom" \
    -b "CN=System,DC=essos,DC=local" "(objectClass=trustedDomain)" \
    cn flatName trustDirection trustType trustAttributes | grep -E "^(cn|flatName|trust)"
cn: sevenkingdoms.local
trustDirection: 3
trustType: 2
trustAttributes: 8
flatName: SEVENKINGDOMS

trustAttributes Bitmask Reference [MS-ADTS §6.1.6.7.9]

SID Filtering Protocol Mechanics

When a referral TGT traverses an inter-forest trust (0x08 or 0x04), the receiving KDC evaluates the Privilege Attribute Certificate (PAC) according to [MS-PAC] §4.1.2.2:

1. The KDC inspects the ExtraSids field within the user’s PAC.
2. If TRUST_ATTRIBUTE_WITHIN_FOREST (32) is set, no filtering occurs. Foreign administrative SIDs (such as Enterprise Admins) are retained in the PAC, allowing direct domain-to-forest escalation.
3. If TRUST_ATTRIBUTE_FOREST_TRANSITIVE (8) is set, the receiving KDC invokes FilterSids(). All SIDs with well-known administrative RIDs (RID < 1000, including 500 Administrator, 512 Domain Admins, 519 Enterprise Admins) and any SIDs not matching the trusted domain’s base SID are permanently stripped from the authorization context.

---

4. Member Server Architecture and Service Identities

Workloads in GOAD execute on two member servers: SRV02 (castelblack at .22 in north.sevenkingdoms.local) and SRV03 (braavos at .23 in essos.local). Auditing service accounts via LDAP reveals their operational parameters:

$ ldapsearch -x -H ldap://192.168.56.11 -D "[email protected]" -w "Heartsbane" \
    -b "DC=north,DC=sevenkingdoms,DC=local" "(|(sAMAccountName=jon.snow)(sAMAccountName=sql_svc)(sAMAccountName=CASTELBLACK$))" \
    sAMAccountName servicePrincipalName msDS-AllowedToDelegateTo userAccountControl | grep -E "^(sAMAccountName|servicePrincipalName|msDS-Allowed|userAccountControl)"
sAMAccountName: CASTELBLACK$
userAccountControl: 4096
servicePrincipalName: HOST/castelblack.north.sevenkingdoms.local
msDS-AllowedToDelegateTo: HTTP/winterfell.north.sevenkingdoms.local
msDS-AllowedToDelegateTo: HTTP/winterfell
sAMAccountName: jon.snow
userAccountControl: 16842752
servicePrincipalName: HTTP/thewall.north.sevenkingdoms.local
servicePrincipalName: CIFS/thewall.north.sevenkingdoms.local
msDS-AllowedToDelegateTo: CIFS/winterfell.north.sevenkingdoms.local
msDS-AllowedToDelegateTo: CIFS/winterfell
sAMAccountName: sql_svc
userAccountControl: 66048
servicePrincipalName: MSSQLSvc/castelblack.north.sevenkingdoms.local:1433
servicePrincipalName: MSSQLSvc/castelblack.north.sevenkingdoms.local

Identity Models on Member Servers

1. Service Principal Names (SPNs): When a client accesses castelblack.north.sevenkingdoms.local:1433, it requests a Kerberos service ticket (TGS-REQ) for MSSQLSvc/castelblack.north.sevenkingdoms.local:1433. The KDC locates the account holding that SPN (sql_svc) and encrypts the ticket using that account’s NTLM/AES secret key. Standard domain users assigned SPNs (jon.snow, sql_svc) are exposed to offline Kerberoasting attacks.
2. Constrained Delegation (msDS-AllowedToDelegateTo): Account jon.snow carries userAccountControl value 16842752 (0x1010000 = DONT_EXPIRE_PASSWORD | TRUSTED_TO_AUTH_FOR_DELEGATION). This grants protocol transition (S4U2Self and S4U2Proxy), permitting jon.snow to request tickets for CIFS/winterfell.north.sevenkingdoms.local impersonating arbitrary users, including Administrator.
3. Managed Service Accounts (gMSA) and LAPS: In essos.local, modern controls mitigate credential theft: a group Managed Service Account (gmsaDragon$) features a 240-byte password automatically rotated by the KDC, accessible only by authorized hosts via msDS-GroupMSAMembership. Concurrently, LAPS stores SRV03’s local administrator password in ms-Mcs-AdmPwd. These controls eliminate offline hash cracking but transfer attack surfaces to LDAP ACLs: any principal granted ReadLAPSPassword (jorah.mormont) or ReadGMSAPassword can retrieve these credentials in cleartext over LDAP.

---

5. Enterprise PKI: Active Directory Certificate Services (AD CS)

AD CS configuration data is stored within CN=Public Key Services,CN=Services,CN=Configuration,DC=<forest>,DC=<tld>. GOAD features two Enterprise Certificate Authorities located on different architectural tiers:

$ ldapsearch -x -H ldap://192.168.56.10 -D "[email protected]" -w "Heartsbane" \
    -b "CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=sevenkingdoms,DC=local" \
    "(objectClass=pKIEnrollmentService)" cn dNSHostName | grep -E "^(cn|dNSHostName)"
cn: SEVENKINGDOMS-CA
dNSHostName: kingslanding.sevenkingdoms.local

$ ldapsearch -x -H ldap://192.168.56.12 -D "[email protected]" -w "fr3edom" \
    -b "CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=essos,DC=local" \
    "(objectClass=pKIEnrollmentService)" cn dNSHostName certificateTemplates | grep -E "^(cn|dNSHostName|certificateTemplates: ESC)"
cn: ESSOS-CA
dNSHostName: braavos.essos.local
certificateTemplates: ESC13
certificateTemplates: ESC9
certificateTemplates: ESC4
certificateTemplates: ESC3-CRA
certificateTemplates: ESC3
certificateTemplates: ESC2
certificateTemplates: ESC1

Enterprise CA Tiering Implications

When a client enrolls in a certificate template (pKICertificateTemplate), the CA verifies the caller’s SID against the template’s DACL (Enroll / Autoenroll). If authorized, the CA issues a signed X.509 certificate containing client authentication EKUs (1.3.6.1.5.5.7.3.2) and an identity mapping field (Subject Alternative Name or szOID_NTDS_CA_SECURITY_EXT). The client can present this certificate over PKINIT (AS-REQ pre-auth type 16) to obtain a Kerberos TGT.

• In sevenkingdoms.local, SEVENKINGDOMS-CA resides directly on Forest Root DC DC01 (kingslanding, .10), exposing HTTP Web Enrollment (/certsrv/) on port 80.
• In essos.local, ESSOS-CA is hosted on member server braavos.essos.local (.23), while DC03 (meereen, .12) serves as the Domain Controller.

Because an Enterprise CA is published to the forest’s NTAuthCertificates container, it is trusted to issue identity certificates for any domain account across the entire forest. Consequently, an Enterprise CA is inherently a Tier-0 asset, even when hosted on a Tier-1 member server like BRAAVOS. Compromising BRAAVOS grants complete forest root takeover.

---

6. Security Descriptors and Directed Graph Attack Paths

Active Directory stores security descriptors in the nTSecurityDescriptor binary attribute on every LDAP object. It contains an Owner SID, Group SID, Discretionary Access Control List (DACL), and System Access Control List (SACL).

By default, the schema (defaultSecurityDescriptor) grants Authenticated Users (S-1-5-11) the READ_CONTROL (0x00020000) right across Domain and Configuration partitions. This read access is mandatory for Windows operating system functionality: clients must inspect DACLs to evaluate Group Policy application, verify certificate template enrollment rights, and resolve nested group memberships.

As a consequence of open READ_CONTROL, any authenticated domain identity can ingest and map the complete authorization graph of the entire forest. Custom ACE additions (such as GenericAll, WriteDacl, or extended rights like User-Force-Change-Password) form unbroken directed attack paths leading directly to Tier-0 dominance.

---

Telemetry and Detection Engineering

Cross-Forest Authentication Telemetry

// KQL: Detect Anomalous Cross-Realm Kerberos Ticket Requests
SecurityEvent
| where EventID == 4769
| where ServiceName startswith "krbtgt/" and ServiceName !endswith TargetDomainName
| project TimeGenerated, Computer, TargetUserName, ServiceName, TicketOptions, TicketEncryptionType, IpAddress

---

Architectural Summary

---

Evidence and limits

The topology, naming contexts, trust objects, service placement, and ACL examples are tied to the GOAD instance used throughout this series. LDAP and Kerberos outputs in the article were checked against that running lab; protocol behavior and field meanings are cross-referenced to Microsoft Open Specifications. This is why the post separates what the lab exposed from what the protocols guarantee.

GOAD is intentionally compact and vulnerable. Its two forests and three domains are useful for observing boundaries, but they are not a reference enterprise design. The diagrams omit replication sites, hybrid identity, endpoint management, and many production PKI controls. Treat the addresses, trust flags, and service identities as this lab’s inventory, not defaults for every Active Directory deployment.

References

• Orange Cyberdefense, GOAD Architecture & Inventory: orange-cyberdefense.github.io/GOAD
• Microsoft Open Specifications, [MS-ADTS] Active Directory Technical Specification: learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts
• Microsoft Open Specifications, [MS-PAC] Privilege Attribute Certificate Data Structure: learn.microsoft.com
• Microsoft, Best Practices for Securing Active Directory: learn.microsoft.com
• RFC 4120, The Kerberos Network Authentication Service (V5): datatracker.ietf.org/doc/html/rfc4120
• RFC 2782, A DNS RR for Specifying the Location of Services (DNS SRV): datatracker.ietf.org/doc/html/rfc2782

Sources & freshness

How current is this note?

Sources checkedNovember 2, 2026

The latest source-review, content-update, or publication date is shown.

ReviewPublic sources reviewed

Primary public records were checked. Environment-specific behavior remains outside the claim unless separately reproduced.

Primary references

• orange-cyberdefense.github.io · GOAD ↗
• learn.microsoft.com · ms-adts ↗
• learn.microsoft.com · best-practic…tive-directory ↗
• datatracker.ietf.org · rfc4120 ↗
• datatracker.ietf.org · rfc2782 ↗
• github.com · GOAD ↗