Active Directory design

Design reference

Part I — Design Reference: Active Directory Forest, Domain, and Organizational Unit Design (as of October 2026)

Government and vendor guidance on Active Directory design splits cleanly. Microsoft owns the structural logic (how many forests and domains, how to lay out OUs and Group Policy); CISA/NSA, DISA and NIST own the security overlay (tiered administration, privileged-access isolation, and the controls that keep a forest from falling in one move). The single fact they all agree on is that the forest, not the domain, is the security boundary, so forest and tiering decisions set the blast radius for an identity compromise. The two points of real movement in 2026 are the retirement of the old “Red Forest” (ESAE) design in favor of the Enterprise Access Model, and Windows Server 2025’s delegated Managed Service Accounts, which created a new Tier 0 concern (BadSuccessor / CVE-2025-53779).

This reference parallels the companion DNS, PKI, NTP and DHCP design references: organized by design area, government and vendor guidelines only, ending with where the authorities agree, differ, or conflict.

• Government and vendor guidelines only:Microsoft, NIST, CISA/NSA, DISA, CIS, and (minimally) the IETF for the underlying Kerberos and LDAP protocols. Practitioner research (SpecterOps, Trimarc, Mandiant, Akamai) is included and labeled as non-governmental.
• Removed: other governments' guidance — ANSSI (France), BSI (Germany), NCSC (UK), ASD/ACSC (Australia), CCCS (Canada), ENISA (EU).
• Design spine: forest, domain, and OU, plus the design areas tied to them — trusts, Group Policy, and administrative tiering.

Summary

• Forest: Prefer a single production forest unless a hard isolation or autonomy requirement forces more. Microsoft states the forest is “the security and administrative boundary for all objects that reside within the forest,” and that co-ownership of one forest by two autonomous IT organizations “is not recommended.” A separate administrative (“Red”) forest is no longer the default — ESAE was retired on December 15, 2020 and replaced by the Enterprise Access Model — but tiering itself was not retired.
• Domain: Prefer a single domain per forest. The domain is a replication and administrative boundary, not a security boundary. Add domains only for replication, administrative, or policy reasons, never for security isolation. The AD domain name is a DNS name, so namespace choice is a joint AD/DNS decision (use a registered subdomain or ICANN’s .internal, never .local or a single label).
• OU: Design OUs for exactly two purposes — delegation of administration and Group Policy application — not replication. Delegate with least privilege, redirect the default Users and Computers containers so GPOs reach new objects, and build a Tier 0/1/2 OU structure for administrative separation.
• Group Policy: Keep GPOs few and well-scoped. Understand LSDOU processing, link order, Block Inheritance vs Enforced, security and WMI filtering, and loopback. Deliver security baselines (DISA STIG GPOs, Microsoft security baselines, CIS build kits) through GPOs linked to the right OUs, tested first.
• Administrative tiering: Treat the directory’s control plane as Tier 0 (domain controllers, AD CS, AD FS, Microsoft Entra Connect, and the accounts, groups and workstations that manage them). Use privileged access workstations and the clean- source principle, put privileged accounts in Protected Users with authentication policies/silos, set ms-DS-MachineAccountQuota to 0, and restrict OU write permissions so the dMSA/BadSuccessor path is closed.

Authoritative design-source overview

Status as of October 19, 2026. Access is free unless noted. Reuse: US federal works (NIST, CISA, NSA, DISA) are generally public domain in the US, excluding third-party content and logos; Microsoft Learn/Support is under the Microsoft Terms of Use (Learn text is also on GitHub under CC BY 4.0, verify per page); CIS Controls/Benchmarks are free for non-commercial use under CC BY-NC-SA 4.0 (commercial use and CIS-CAT Pro/build kits need SecureSuite membership); IETF RFCs fall under the IETF Trust Legal Provisions; practitioner papers are author-copyrighted.

1. Forest design

Decision at stake: how many forests to run, how to treat the forest security boundary, how to build the forest root domain, which forest functional level to choose, and whether a separate administrative forest is warranted.

Realistic options: single forest with a single domain (simplest, most common); single forest with multiple domains (one security boundary, several administrative/replication boundaries); multiple forests (account/resource or organizational forests for isolation/autonomy); a dedicated administrative forest (the former ESAE/“Red Forest”, now niche).

What the government and vendor guidelines say:

• Microsoft (structural):
  • “A forest is the security and administrative boundary for all objects that reside within the forest. In contrast, a domain is the administrative boundary for managing objects.” The domain was the security boundary in the Windows NT era; that changed with Active Directory.
  • Determining the number of forests means evaluating isolation and autonomy requirements; “isolation requirements limit your design choices,” and the decision “involves balancing costs against benefits.”
  • All objects in one forest are in the global catalog, so “no synchronization across forests is required.” Co-ownership of a single forest by two autonomous IT organizations “is not recommended.”
  • Collapsing forests later is much harder than adding them, so get the count right at the start.
• Forest functional level: Windows Server 2025 introduces a new domain and forest functional level (the first since 2016); a new forest requires at least the 2016 level. The 2025 level enables the optional 32k database page size and the delegated Managed Service Account (dMSA) feature.
• Forest root domain: either a dedicated/empty root (holding the forest-wide Enterprise Admins and Schema Admins groups, isolating them) or a single regional domain that is also the root.
• Microsoft (security) and practitioners:
  • ESAE (the “Red Forest”) was retired as the default recommendation on December 15, 2020, when Microsoft published the Enterprise Access Model. SpecterOps confirms Microsoft “retired ESAE and took down their old recommendations,” and that the equivalent control is now the Enterprise Access Model plus the administrative tier model.
  • A dedicated administrative forest (and Microsoft’s PAM/MIM pattern) still exists for the highest-assurance or legacy on-prem cases, but most organizations should implement tiering and PAWs within the production forest rather than stand up a separate forest.
• CISA/NSA and NIST: treat the forest as the identity control plane’s outer edge. The Sept 2024 CISA/NSA guidance frames AD compromise as the primary objective for attackers; because the forest is the security boundary, Tier 0 isolation (Section 6) is what limits damage. NIST SP 800-207 reframes identity as the control plane, the conceptual basis for isolating it.
• DISA: forest-level rules live in the AD Forest STIG — SID filtering and selective authentication on trusts (Section 3), restrictions on anonymous access to forest data, and the AD CS rules (V-269098/V-269099).

Trade-offs:

• More forests give real isolation (separate schemas and security boundaries; a compromise in one does not automatically cross), at the cost of synchronization (no shared global catalog; you need Entra Connect / MIM / trusts), duplicated administration, and a worse cross-forest user experience.
• A single forest is cheaper and simpler but concentrates risk: a Tier 0 compromise anywhere in the forest is a whole-forest compromise.
• A dedicated admin forest maximizes credential isolation but is expensive and complex; Microsoft retired it as the default for that reason.

Conflicts: the main one is “when is a separate administrative forest still justified?” Microsoft now answers “rarely — use the Enterprise Access Model in-forest,” while practitioners note the tier model persists and a hardened admin forest remains defensible for specific high-assurance or heavily legacy estates. There is no government mandate for a separate admin forest.

2. Domain design

Decision at stake: how many domains per forest, how to treat the domain boundary, single vs multiple trees/namespaces, whether to use an empty forest-root domain, the domain functional level, and FSMO placement.

Realistic options: single domain (preferred); multiple domains in one tree (contiguous namespace); multiple trees (disjoint namespaces) in one forest; an empty forest-root domain plus one or more child domains.

What the government and vendor guidelines say:

• Microsoft:
  • The domain is “the administrative boundary for managing objects,” not a security boundary. “Only one instance of an Active Directory domain should exist at any time.”
  • Microsoft’s long-standing guidance favors the fewest domains possible, and a single domain wherever it meets requirements. Extra domains are justified by replication control, decentralized administration, distinct account/password or policy requirements, or replication scale — not by a desire for security isolation, because domain admins in one domain can reach others through known forest-internal paths.
  • The AD domain name is simultaneously a DNS name (e.g., corp.contoso.com), so domain naming is a joint decision with DNS: use a registered subdomain or ICANN’s reserved .internal, and avoid single-label names and .local (see the DNS design reference).
• Empty forest-root domain: a dedicated root domain that holds the forest-wide groups (Enterprise Admins, Schema Admins) and little else, to protect those groups and decouple the root from any region. It adds domain controllers to build and maintain.
• Domain functional level: governs per-domain features; raising it requires all domain controllers at that OS level or higher.
• FSMO roles: five operations master roles — Schema Master and Domain Naming Master are forest-wide; PDC Emulator, RID Master, and Infrastructure Master are per-domain. Place the PDC Emulator on a reliable, well-connected DC (it is also the default authoritative time source — see the NTP reference); keep the Infrastructure Master off a global catalog server unless every DC is a GC. Seize a role only after unrecoverable failure.
• IETF: Kerberos (RFC 4120) and LDAP (RFC 4511) are the protocols the domain exposes; design choices (trust transitivity, referrals) rest on them.

Trade-offs:

• Single domain: simplest administration, one Group Policy and replication scope, easiest recovery. It offers no internal administrative separation beyond OUs and delegation.
• Multiple domains: administrative and replication separation, but not security isolation, plus more DCs, trusts to manage, and cross-domain Group Policy complexity.
• Empty root: protects forest-wide groups and gives a stable root, at the cost of extra infrastructure; modern guidance leans toward single-domain for most organizations.

Conflicts: single vs multiple domains, and whether an empty root is worth it. Microsoft historically recommended an empty root for large enterprises; current practice leans single- domain. No authority reviewed treats a domain as a security boundary — a common and dangerous misconception the sources explicitly correct.

3. Trust design

Decision at stake: which trust relationships to create, their direction and transitivity, and how to contain the risk they add.

Realistic options:

• Intra-forest trusts — created automatically between all domains in a forest; two-way and transitive; Kerberos.
• External trust — to a single domain in another forest; non-transitive.
• Forest trust — between two forest root domains; transitive across each forest.
• Realm trust — to a non-Windows Kerberos realm (e.g., MIT Kerberos).
• Shortcut trust — to optimize authentication paths within a large forest.

What the government and vendor guidelines say:

• Microsoft:
  • Documents trust types, transitivity and direction, and that SID filtering (quarantine) is enabled by default on external and forest trusts to drop SIDs from outside the trusted domain’s own domain, defeating SID-history injection.
  • Selective authentication can be set on external/forest trusts so that only explicitly allowed users can authenticate to specific resources across the trust.
  • A forest trust is a convenience, not a security guarantee: a compromise in a trusted forest can threaten the trusting forest, so a forest trust should not be treated as a security boundary against a compromised partner.
• DISA (AD Forest STIG): SID filtering must be enabled on inter-forest/external trusts, and selective authentication applied where cross-forest access must be limited.
• CISA/NSA: the Sept 2024 guidance covers trust-account abuse, SID-history injection, and cross-forest Kerberoasting among its techniques; the practical message is that trusts widen the attack surface and must be minimized and filtered.

Trade-offs: trusts enable resource and identity sharing across boundaries, but every trust enlarges the reachable attack surface. SID filtering can break legacy migrations that rely on SID history; selective authentication adds per-resource management overhead.

Conflicts: default SID filtering vs migration needs (filtering must sometimes be relaxed temporarily, which is risky). And the framing of a forest trust: Microsoft and CISA/NSA are clear it is not a security boundary against a compromised trusted forest, even though it is often treated as one in practice.

4. OU design

Decision at stake: how to structure organizational units, how to delegate administration, where to place objects, and how to ensure Group Policy reaches everything.

Legitimate drivers (only two): delegation of administration and Group Policy application. OUs are not a replication or security boundary (that is domains/forests and sites).

Realistic structure models:

• By object type — top-level OUs for Users, Computers, Groups, Service Accounts.
• By function/role — e.g., Servers, Workstations, by business function.
• By geography/location — regional OUs for delegated regional admins.
• Hybrid — top level by function or geography, then subdivided by object type (the most common real-world pattern).
• Tiered-administration OUs — a Tier 0 / Tier 1 / Tier 2 structure overlaid for administrative separation (Section 6).

What the government and vendor guidelines say:

• Microsoft:
  • Build the OU design to delegate administration and to apply Group Policy; structure follows those two needs rather than the org chart.
  • Delegate with the Delegation of Control Wizard or custom ACLs, granting the minimum rights needed and documenting them; review delegated permissions over time.
• Redirect the default containers: the built-in CN=Users and CN=Computers containers cannot have GPOs linked to them. Use redirusr.exe and redircmp.exe to redirect newly created user and computer objects into OUs where GPOs apply. This is a near-universal first step so default- created objects are not left ungoverned.
• Protect OUs from accidental deletion, and avoid unnecessarily deep nesting (it complicates both delegation and Group Policy processing).
• DISA / CIS: both assume a tiering OU layout; Tier 0 objects live in protected OUs with inheritance controlled so lower-tier policy does not weaken them.

Trade-offs:

• By object type is the cleanest for Group Policy targeting; by geography suits delegated regional administration; a hybrid balances both.
• Too many OUs or deep nesting slows and obscures Group Policy processing and makes delegation hard to audit.
• Container redirection is a one-time action but essential; skipping it leaves default-created accounts outside GPO scope.

Conflicts: OU-by-function vs OU-by-geography — both valid, and the right choice depends on who delegates administration and what policy varies. And whether to use Block Inheritance on an OU (see Section 5).

5. Group Policy design (coupled to OU design)

Decision at stake: how to scope and order GPOs, how to handle inheritance and exceptions, how to filter, and how to deliver security baselines.

What the government and vendor guidelines say:

• Microsoft (processing model):
  • GPOs apply in LSDOU order — Local, then Site, then Domain, then OU (deepest OU last) — so a setting applied later wins unless overridden.
  • Link order within a container: the link with the lowest number is processed last and therefore wins among that container’s GPOs.
  • Block Inheritance (set on an OU) stops inherited GPOs; Enforced (set on a link) overrides Block Inheritance and wins. Microsoft discourages routine use of both because they obscure the effective policy.
• Security filtering: since the 2016-era change, the computer or user account needs both Read and Apply Group Policy, and Authenticated Users must retain at least Read for a GPO to process. Scope with security groups carefully.
• WMI filtering applies GPOs conditionally (e.g., by OS); it adds per-refresh evaluation cost.
• Loopback processing (merge or replace) applies user policy based on the computer object, for shared, kiosk, RDS/session-host, and Tier 0 machines.
• Use Starter GPOs, a Central Store for ADMX templates, consistent naming, and the fewest GPOs that do the job.
• Baseline delivery (cross-reference the DISA STIG/GPO reference): deliver security baselines — DISA STIG GPO packages, Microsoft security baselines from the Security Compliance Toolkit, or CIS build kits — as GPOs linked to the appropriate OUs, and test them in a representative OU before wider linking. Tier 0 systems get the strictest baselines, scoped by the tiering OUs.

Trade-offs: fewer, well-named, well-scoped GPOs mean faster logon/boot and far easier troubleshooting. Block Inheritance and heavy security/WMI filtering make the effective-policy picture hard to reason about; over-blocking is a common cause of baseline drift.

Conflicts: Block Inheritance (discouraged — it hides policy) vs Enforced (use sparingly for must-apply security settings); and security-group filtering vs OU-based targeting as the primary scoping method.

6. Administrative tiering design

Decision at stake: how to isolate privileged access — the tier model and the Enterprise Access Model, what belongs in Tier 0, how to use privileged access workstations and the clean-source principle, and how to protect privileged accounts and the newest attack primitives.

What the government and vendor guidelines say:

• Microsoft (current tier model page):
  • The AD DS tier model “separates administrative identities, workstations, and managed assets into trust tiers” — Tier 0, Tier 1, Tier 2 — with privileged access workstations (PAWs) enforcing the boundaries.
  • Tier 0 contains everything that directly or indirectly controls the directory: domain controllers; identity services including Microsoft Entra Connect, Microsoft Entra application proxy, AD FS, and AD CS; and Tier 0 administrative accounts and groups, “including built-in Active Directory groups such as Backup Operators and Server Operators.”
  • The tier model fits inside the broader Enterprise Access Model (EAM), which spans on- premises, multiple clouds, user access, and application access via a control plane, management plane, and data/workload plane. The model and deployment guidance are in the microsoft/ActiveDirectoryTierModel repository.
• Clean source principle: administer a tier only from a device of equal or higher trust (manage Tier 0 only from a Tier 0 PAW).
• Protected Users security group hardens privileged accounts (no NTLM, no DES/RC4, no unconstrained delegation, no long-term Kerberos keys, no credential caching). Authentication policies and silos restrict where privileged accounts can authenticate.
• ESAE → EAM: Microsoft retired ESAE/the Red Forest on December 15, 2020 and replaced it with the Enterprise Access Model; the tier model itself was not retired — a frequent point of confusion.
• NIST SP 800-53 Rev 5: AC-2 (account management), AC-5 (separation of duties), AC-6 least privilege with AC-6(2) (non-privileged access for nonsecurity functions) and AC-6(5) (privileged accounts restricted to named personnel), and IA-2(1) (MFA for privileged accounts). SP 800-63B(-4) sets authenticator assurance; SP 800-207 establishes identity as the control plane.
• CISA/NSA (Sept 2024, 17 techniques): Kerberoasting, AS-REP roasting, DCSync, Golden/Silver Ticket, AD CS abuse, unconstrained delegation, SID-history injection, GPO abuse, and more. Mitigations include tiering, PAWs, Protected Users, MFA, least privilege, and setting the machine-account quota to zero. It treats AD CS, AD FS and Entra Connect as Tier 0.
• DISA (AD Domain STIG): CAT I rules restrict membership of Enterprise Admins, Domain Admins and Schema Admins (Enterprise Admins and Schema Admins are typically kept empty except when a specific change requires them); V-243477 requires privileged domain accounts to be in the Protected Users group; and AD remote management must come from a PAW/Tier 0.
• CIS: Controls v8.1 Safeguard 5.4 (dedicated administrative accounts) and the MFA safeguards; the Windows Server benchmarks harden the hosts.
• ms-DS-MachineAccountQuota: the default of 10 lets any authenticated user join 10 computers (machine accounts), which enables several escalation primitives; the common hardening is to set it to 0.
• dMSA / BadSuccessor (CVE- 2025-53779): Windows Server 2025 introduced delegated Managed Service Accounts to migrate legacy service accounts. The BadSuccessor technique (Akamai, Yuval Gordon; disclosed May 21, 2025; patched August 12, 2025) abuses them: in any forest with at least one Windows Server 2025 domain controller and a KDS root key, an attacker who can create a dMSA — or who merely has write permission to any OU, plus the ability to set the dMSA’s migration attributes (e.g., msDS-ManagedAccountPrecededByLink) — can impersonate a privileged account and reach domain, then forest, compromise. Notably the domain does not need to be at the 2025 functional level or using dMSAs. Design implications: apply the patch to all Windows Server 2025 DCs, restrict OU write permissions, and ensure only Tier 0 can create or manage dMSAs and their migration attributes. Akamai notes the patch mitigates much of the risk but the technique “lives on” in some scenarios.

Trade-offs: strict tiering is the single highest-value AD security control, but it is operationally heavy — dedicated accounts per tier, PAWs, and discipline about never signing a Tier 0 credential into a lower-tier host. The cost is hardware and process; the payoff is that a workstation or server compromise no longer yields the directory.

Conflicts:

• Scope of protection: DISA’s CAT I rules target Enterprise Admins / Domain Admins / Schema Admins specifically, while Microsoft’s tier model protects all Tier 0 groups (including Backup Operators, Server Operators, AD CS, AD FS, Entra Connect). DISA compliance alone therefore does not equal full tier isolation.
• Cloud vs platform-neutral: Microsoft’s current guidance pushes cloud-era tooling (the Enterprise Access Model, Microsoft Defender for Identity, Entra PIM), while DISA and NIST remain platform-neutral and on-prem-centric.
• Coverage gap: as of this writing, no government source reviewed addresses dMSA/BadSuccessor directly; the Tier 0 guidance for dMSAs comes from Microsoft’s CVE response and practitioners (SpecterOps, Akamai, Tenable).

Where authorities agree, differ, or conflict

Caveats and items that could not be verified

• Research mode was unavailable for this document, so it was assembled from direct source checks plus the project’s earlier AD/OU research. Verified this session on primary or reported sources: the forest-as-security-boundary wording and forest/domain-count logic (Microsoft TechNet/Learn), the ESAE retirement date (December 15, 2020) and the Enterprise Access Model, the current Microsoft “Tier model for AD DS” page and its Tier 0 contents, and BadSuccessor/CVE-2025-53779 (patched August 12, 2025).
• Legacy Microsoft design pages: “Determining the Number of Forests/Domains,” “Creating a New Forest,” and the AD DS Design Guide are Windows Server 2003/2008- era TechNet archive content. The design logic (isolation/autonomy, boundary definitions, single-domain preference) remains Microsoft’s canonical guidance, but confirm against the current AD DS planning pages for version-specific detail.
• DISA STIG specifics (AD Domain STIG V3 series and its EA/DA/SA CAT I rules, Protected Users rule V-243477, the PAW-for-AD-management rule; AD Forest STIG SID- filtering/selective-authentication and V-269098/V-269099) are drawn from the project’s earlier research and third-party STIG mirrors, not re-fetched from cyber.mil this session. Confirm the current release and rule IDs at public.cyber.mil.
• CIS versions (Controls v8.1 Safeguards 5.4 and the MFA safeguards; the current Windows Server 2025 Benchmark version) were not re-verified this session.
• NIST control text (AC-2, AC-5, AC-6 and enhancements, IA-2(1)) is paraphrased; confirm the SP 800-63B-4 (2025) and SP 800-53 Release 5.2.0 (Aug 27, 2025) details against csrc.nist.gov.
• Windows Server 2025 functional-level details (first new level since 2016; new forests require the 2016 level or higher; the optional 32k database page; dMSA) come from Microsoft’s “what’s new” material and the BadSuccessor coverage; confirm specifics on the current Microsoft Learn page.
• The CISA/NSA “Detecting and Mitigating Active Directory Compromises” guidance (Sept 2024) is an ASD-led Five Eyes product; under this reference’s scope it is treated only as a CISA/NSA source. A 2026 revision may exist and was not confirmed here.
• Group Policy security-filtering behavior (the Authenticated Users Read requirement) reflects the post-2016 change; confirm exact wording on the current Microsoft Learn Group Policy pages.
• Practitioner sources (SpecterOps, Trimarc, Mandiant, Akamai, Tenable) are non- governmental and labeled as such; they are cited for the ESAE/EAM history, tiering practice, and the dMSA/BadSuccessor analysis rather than as authority.
• Licensing statements are general; confirm per-document terms before republishing excerpts.

Annotated source catalog

Reference Collection: Active Directory Design, OU Structure, and Tiered Administration (as of October 2026)

The guidance baseline treats Active Directory administration the same way across all authorities checked: Microsoft’s current tier model, Microsoft’s tooling, DISA STIGs, CIS, and the CISA/NSA joint guidance all require separating privileged identities by tier. That means dedicated admin accounts, privileged access workstations (PAWs), and rules that block higher- tier credentials from lower-tier systems. Only the separate “Red Forest” (ESAE) admin-forest architecture was retired, in December 2020. Tiering itself was not. NIST supplies the control language (AC-2, AC-5, AC-6(5), IA-2) without naming AD. DISA turns the model into mandatory, auditable rules. IETF RFCs supply only protocol background.

TL;DR

• Microsoft’s current baseline is the Learn page “Tier model for Active Directory Domain Services” (ms.date 2026-05-21; last updated 2026-07-01).
  • It has three tiers. Tier 0 is the identity control plane: DCs, AD FS, AD CS, Entra Connect, and the systems and agents that manage them. Tier 1 is servers and applications. Tier 2 is end-user devices and help desk.
  • Each tier requires its own PAW.
  • It lists five anti-patterns.
  • It points to the MIT-licensed microsoft/ActiveDirectoryTierModel repo for deployment (latest release seen: v1.3.1).
  • ESAE/Red Forest was retired as the default recommendation, but Microsoft says PAWs, MFA for admins, and least-privilege tiering remain “good cyber hygiene.”
• Government guidance agrees in substance but differs in form.
  • NIST SP 800-53 Rev. 5 (current catalog Release 5.2.0, August 27, 2025) gives framework-neutral controls.
  • The CISA/NSA joint “Detecting and Mitigating Active Directory Compromises” (September 2024, co-authored with five foreign agencies) catalogs 17 attack techniques plus mitigations.
  • DISA’s Active Directory Domain STIG (Ver 3, Rel 8, in the October 6, 2026 quarterly release) and AD Forest STIG (V3R2) make tiering-related controls mandatory for DoD. Examples: CAT I rules restricting Enterprise/Domain Admins membership, and a CAT I rule requiring that AD CS be managed from a “PAW tier 0.”
• CIS adds hardening benchmarks and safeguards.
  • The CIS Windows Server 2025 Benchmark v2.1.0 (September 2026) has Domain Controller profiles.
  • CIS Controls v8.1 Safeguard 5.4 requires dedicated admin accounts; 6.5 requires MFA for admin access.
  • IETF RFC 4120 (Kerberos) and RFC 4511 (LDAP) are protocol background only. AD-specific extensions such as the PAC are Microsoft Open Specifications, not IETF standards.

1. Guidance landscape overview

2. Section A — Official Microsoft guidance

A1. AD DS design and planning (forest, domain, OU design)

Creating an Organizational Unit Design

• Publisher / URL: Microsoft Learn, https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/creating-an- organizational-unit-design
• Status: Maintained Learn page whose content descends from the Windows Server 2003 deployment kit. It still points to a 2003 “Job Aids” worksheet, so treat it as legacy in origin but still published.
• Access: Free.
• Licence: Microsoft copyright under Learn Terms of Use. The public MicrosoftDocs GitHub source repos generally publish docs under CC BY 4.0 and code under MIT; check the specific repo’s LICENSE before reuse.
• Scope: Who designs OUs and what kinds of OUs to create.
• Key points:
  • Forest owners are responsible for OU designs in their domains. The design covers OU structure, assigning the OU owner role, and creating account and resource OUs.
  • The structure should first be designed to “enable delegation of administration.” Additional OU structures for Group Policy application and for limiting object visibility come afterward.
  • Account OUs contain user, group, and computer objects. Resource OUs contain resources and the accounts that manage them.
  • The OU design should be documented.

Reviewing OU Design Concepts / Designing OUs for Delegation of Administration / Delegating Administration of Account and Resource OUs

• Publisher: Microsoft Learn (previous-versions library: Windows Server 2003/2008 R2).
• Status: Legacy/archived but still the most detailed Microsoft OU-design text.
• Key points:
  • The OU hierarchy “does not need to reflect the departmental hierarchy.”
  • OUs exist for delegation of administration, Group Policy application, or limiting object visibility.
  • OUs are administrative boundaries.
  • Owners of resource OUs may not create OUs.
  • Placing a computer account in a resource OU gives control over the object, not administrator rights on the computer.

Forest and domain design. Microsoft’s AD DS design guide (the same Learn “plan” section) covers forest models (organizational, resource, restricted-access), single- vs. multi-domain models, and the forest as the security boundary. These were not individually re-fetched for this collection (see Caveats). DISA’s AD Domain STIG separately sets rules for trusts, for example documenting every trust and enabling Selective Authentication on outbound forest trusts.

A2. Delegation of administration

• What Microsoft says: Delegation is done by granting permissions on OUs, typically with the Delegation of Control Wizard in Active Directory Users and Computers, to groups rather than individuals.
• The constraint: The AdminSDHolder/SDProp mechanism (A7) overrides delegated permissions on protected accounts and groups. Delegated OU permissions therefore do not reach Tier 0 principals.
• The tier-model page: It adds that delegated rights must stay inside a tier, and that “Tier 1 migration” is “not just moving objects between OUs.”
• Repo implementation: The microsoft/ActiveDirectoryTierModel repo implements delegation as code (A4).

A3. The tier model (current Microsoft page)

Tier model for Active Directory Domain Services

• URL: https://learn.microsoft.com/en- us/windows-server/identity/ad-ds/tier-model
• Author / date: robinharwood (Microsoft); ms.date 2026-05-21; last updated 2026-07-01.
• Applies to: Windows Server 2016–2025. Page metadata marks it “ai-assisted.”
• Status: Current. Free.
• Scope and lineage: The model separates identities, workstations, and assets into trust tiers based on identity privilege rather than network segmentation. Microsoft calls the two “complementary.” The page cites the Biba integrity model and the Mitigating Pass-the-Hash white papers (v1/v2) as lineage. It places the tier model as a component of the Enterprise Access Model.

Tier contents:

Design principles:

• Least privilege within each tier.
• No shared credentials across tiers.
• No line-of-business (LOB) workloads in Tier 0.
• Separation of duties among operators, approvers, and auditors.
• Containment, not perimeter, is the boundary: “The credential and the keyboard define the tier, not the IP address.”

Listed anti-patterns: 1. Collapsing everything into Tier 0. 2. Daily work with Domain Admins. 3. Monitoring, backup, or EDR agents with Domain Admins rights. 4. Shared service accounts across tiers. 5. Treating jump servers as a separate tier. A jump server used to reach DCs is a Tier 0 asset.

PAW requirement:

• The model “only works” when sessions start from a PAW matching the target tier.
• PAWs must be hardened and dedicated to admin work, with no email or web browsing, verified supply-chain provenance, and physical security.
• For cloud management, Microsoft names a “PAWCSM.”
• The “reach-back model” and six supported access paths (physical PAW, jump server, vault, cloud PAW to virtual PAW) all keep any intermediary in the same tier as the target.

Keeping Tier 0 small:

• A “common target” is fewer than five humans with Domain Admins- equivalent access.
• No Domain Admins service accounts.

Adoption steps: 1. Scope and sponsorship. 2. Inventory and classify. 3. Operating model. 4. Implement OUs, groups, GPOs, and restrictions. 5. Phased pilot (Tier 0 → 1 → 2). 6. Continuous validation and drift detection.

Post-deployment hardening includes Security Hardening Framework (SHF) baselines, legacy GPO cleanup, PAW deployment, and DC OS hardening.

A4. microsoft/ActiveDirectoryTierModel (GitHub)

• URL: https://github.com/microsoft/ActiveDirectoryTierModel
• Docs site: microsoft.github.io/ActiveDirectoryTierModel
• Licence: MIT. The README’s “License: MIT” was confirmed via a fork’s metadata; confirm against the LICENSE file before redistribution.
• Releases: v1.0.0 (May 6) through v1.3.1 (August 18, marked “Latest”). The releases page did not show the year; the context suggests 2026.
• What it is: A “declarative PowerShell framework to deploy and audit an Active Directory Tier Model” from one version-controlled JSON configuration file.
• What it creates and audits: OUs, groups, users, ACL delegations, GPOs, ADMX templates, MSA/gMSA/dMSA permissions, and Windows LAPS permissions.
• Features:
  • WhatIf planning and idempotent re-runs.
  • Drift detection with hash provenance.
  • Pester tests.
  • Entry scripts Deploy-TierModel.ps1 and Audit-TierModel.ps1.
  • An optional Microsoft Sentinel monitoring solution (KQL analytics rules and a workbook) maintained in the Azure/Azure-Sentinel repo.
• Note: The Learn tier-model page links to this repo as the deployment reference. Microsoft’s warning applies here: enforcement GPOs linked in the wrong order can lock administrators out, so test outside production.

A5. Enterprise Access Model (EAM)

• URL: https://learn.microsoft.com/en-us/security/privileged-access-workstations/ privileged-access-access-model
• Status: Current; free.
• Planes:
  • Control plane: centralized identity and access control, supplemented by network access control for older systems such as OT.
  • Management plane: enterprise-wide IT management.
  • Data/workload plane: per-workload management, where business value lives.
• Mapping from legacy tiers:
  • Tier 0 “expands to become the control plane” and covers all aspects of access control, including networking where it is the only access control option.
  • Tier 1 splits into the management plane and the data/workload plane.
  • Tier 2 becomes user access and app access.
• Related current pages:
  • “Design an enterprise access architecture” (Zero Trust adoption guidance) restates the mapping.
  • The Entra “privileged roles and permissions” page says privileged intermediaries (PAM, jump hosts, automation runbooks) are control-plane (Tier 0) assets.
• Relationship to the tier model: The AD DS tier model remains the AD-specific implementation within the EAM.

A6. ESAE / Red Forest retirement

• URL: https://learn.microsoft.com/en-us/security/privileged-access-workstations/ esae-retirement
• Dates: ms.date 2023-02-14; last updated 2024-01-29. The retirement was announced in December 2020, alongside the December 15, 2020 republication of the privileged-access guidance.
• What was retired: ESAE, “often referred to as red forest, admin forest, or hardened forest.” This is a dedicated hardened administrative forest for AD admin identities. It is no longer the default recommendation and is now “a custom configuration suitable only for exception cases.” The replacement is the modern privileged access strategy and RaMP, toward Zero Trust.
• Why:
  • ESAE was designed more than 10 years earlier for on-premises AD.
  • It relies on macro-segmentation and does not adequately cover hybrid or cloud environments.
  • It protects only on-premises AD admins.
  • Cloud-based solutions deploy faster, cover more roles, and are less complex and costly.
• Continued-use cases:
  • Isolated or disconnected environments such as critical infrastructure or OT, though “air-gapped ICS/SCADA segments … don’t typically utilize their own Active Directory.”
  • Microsoft itself still runs a similar architecture internally.
  • Existing ESAE deployments: “no urgency to retire” if operated as designed.
• What remains good hygiene:
  • PAWs for all admin activity.
  • Token-based or MFA authentication for admin credentials.
  • Least-privilege administration with regular membership review.
• On-premises AD best practices listed:
  • A tiered least-privilege model, time-based privileged roles, and full auditing of privileged identities.
  • PAW hygiene: don’t administer a PAW from a less-trusted host, use MFA, maintain physical security, run a supported OS.
  • Eliminating password reuse.
  • Reducing applications on DCs.
  • Immutable AD backups.
  • An annual AD security assessment.
  • Microsoft Defender for Identity as a supplement.

A7. Securing privileged access, RaMP, PAWs, intermediaries

• Pages: Privileged access strategy, the Security Rapid Modernization Plan (RaMP), privileged access devices/PAW overview, and intermediaries, all in the “privileged- access-workstations” Learn section linked from the ESAE page.
• What they cover:
  • RaMP is the prioritized rollout plan that replaced ESAE as the default approach.
  • The device pages define security levels for enterprise, specialized, and privileged devices.
  • The intermediaries guidance treats VPNs, jump servers, and PAM/PIM systems as part of the privileged path that must be secured at the level of what they reach.
• Verification: These pages are named and linked from verified pages but were not individually fetched (see Caveats).

A8. Credential protection features

Protected Users security group

• URL: https://learn.microsoft.com/en-us/windows- server/security/credentials-protection-and-management/protected-users-security-group
• Restrictions on members:
  • No NTLM, Digest, or CredSSP default credential delegation.
  • Kerberos with AES only; no DES or RC4.
  • No delegation.
  • Kerberos TGT lifetime hard-set to 240 minutes (4 hours).
• Warnings:
  • Never add service or computer accounts; authentication will fail.
  • Restrictions cannot be bypassed even for highly privileged users.
• Exception: The built- in domain Administrator (RID 500) is always exempt from authentication policies.

Authentication Policies and Authentication Policy Silos

• URLs:
  • https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and- management/authentication-policies-and-authentication-policy-silos
  • https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/how-to- configure-protected-accounts
• Requirements: Windows Server 2012 R2 domain functional level or higher.
• What they do:
  • Policies set TGT lifetime and access-control conditions restricting which hosts an account can sign in from.
  • They apply to user, computer, and service accounts.
  • Silos (objectClass msDS-AuthNPolicySilos) group accounts and restrict a group of admins to a defined set of hosts, which enforces tier isolation at the KDC.
  • They “complement” Protected Users.

Windows LAPS

• Microsoft’s current local administrator password solution is built into Windows and Windows Server.
• It can store passwords in AD (encrypted) or Entra ID.
• It is the recommended way to avoid shared local admin passwords across tiers.
• The tier-model repo configures Windows LAPS permissions per tier.
• The Learn pages were not re-fetched for this collection (see Caveats).

Service accounts: sMSA, gMSA, dMSA

• URLs:
  • https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand- service-accounts
  • …/delegated-managed-service-accounts/delegated-managed-service- accounts-overview
• gMSA: Windows generates and rotates the password; usable across multiple servers.
• dMSA: New in Windows Server 2025.
• It migrates a traditional service account to a machine-bound account with “managed and fully randomized keys” and disables the original account’s password.
• Authentication is tied to device identity.
• Microsoft says it helps prevent Kerberoasting.
• It requires a Windows Server 2025 DC and a KDS root key.
• You can’t migrate from an MSA or gMSA to a dMSA.
• Tiering rule: Per the tier model, a service account must live in one tier only.

AdminSDHolder and protected groups (Appendix C)

• URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best- practices/appendix-c–protected-accounts-and-groups-in-active-directory
• How it works:
  • AdminSDHolder, in the System container of every domain, provides “template” permissions.
  • SDProp periodically resets the ACLs of protected accounts and groups to match it.
  • Inheritance is disabled on protected objects.
  • AdminSDHolder is owned by Domain Admins.
• Related appendices:
  • Appendix I explains granting designated management accounts membership- management rights via AdminSDHolder.
  • The “Active Directory security groups” page lists which built-in groups are protected (e.g., Account Operators: “Protected by AdminSDHolder? Yes”) and which are not safe to delegate.
  • DISA’s Protected Users rule (V-243477) applies to the same group set.

A9. “Deny log on” user rights for tier isolation

• Microsoft’s approach: Tier isolation is implemented with GPO User Rights Assignment. Higher-tier admin groups are added to “Deny access to this computer from the network,” “Deny log on locally,” “Deny log on as a batch job,” “Deny log on as a service,” and “Deny log on through Remote Desktop Services” on lower-tier computers.
• Where this appears: The tier-model page names “access restrictions” via group policies as step 4 of adoption; the repo ships these GPOs.
• DISA and CIS: Both prescribe concrete Deny-right memberships (Section B).
• Caution: Microsoft warns that misordered GPO links can lock out domain admins everywhere, including on DCs.

A10. Best Practices for Securing Active Directory and appendices

• URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ security-best-practices/best-practices-for-securing-active-directory
• Status: Still maintained and linked from the tier-model page as related content. The content originated in 2013–2014, so some tooling references are dated.
• Contents:
  • Reducing the AD attack surface, including privileged groups and AdminSDHolder ownership.
  • Monitoring for signs of compromise.
  • Planning for compromise.
• Appendices:
  • B: privileged accounts and groups.
  • C: protected accounts and groups.
  • D: securing built-in Administrator.
  • E: securing Enterprise Admins.
  • F: securing Domain Admins.
  • G: securing Administrators.
  • H: local Administrator accounts.
  • I: management accounts for protected groups.
• Key prescriptions: Keep EA/DA groups empty or minimal except during build or recovery. Use GPOs to deny privileged groups logon to member servers and workstations.

A11. Microsoft Security Baselines (Security Compliance Toolkit)

• What it is: The Security Compliance Toolkit (SCT) publishes Microsoft-recommended GPO baselines per Windows/Windows Server release, including a Domain Controller baseline and a Member Server baseline, plus tools such as Policy Analyzer and LGPO.
• Access: Free download from the Microsoft Download Center.
• Relevance to tiering: The baselines harden DCs but do not implement tier-specific Deny-logon assignments, which depend on the environment. The tier-model page lists baseline hardening (SHF baselines) as a post-deployment activity.
• Verification: The Windows Server 2025 baseline version and date were not verified in this collection (see Caveats).

A12. Microsoft Defender for Identity (MDI)

• Type: Paid, cloud-connected service, licensed as part of Microsoft 365 E5/Defender suites.
• What it does: Uses on-premises AD and Entra ID signals to detect identity threats and to visualize lateral-movement paths.
• Microsoft’s positioning: The ESAE page lists it as a supplemental capability and notes it “does require a cloud-based connection.”

A13. CVEs and advisories

CVE-2025-53779 “BadSuccessor”

• Classification: Windows Kerberos elevation of privilege; CVSS 7.2; CWE-23 relative path traversal.
• Timeline: Disclosed by Akamai researcher Yuval Gordon on May 21, 2025; patched August 12, 2025 (Patch Tuesday).
• What it abused: The Windows Server 2025 dMSA feature. A principal with rights to create or modify a dMSA could set msDS-ManagedAccountPrecededByLink and inherit a high-privilege account’s privileges.
• Prerequisite: At least one Windows Server 2025 DC.
• Lesson for OU delegation: Broad “create child object” rights on OUs became a Tier 0 path.
• After the patch: In the Akamai blog “BadSuccessor Is Dead, Long Live BadSuccessor(?)”, Yuval Gordon wrote that the patch was “effective in mitigating a significant part of the risk … the technique lives on and remains relevant in certain scenarios.”
• Sources: The Akamai research is the primary source. Help Net Security (Aug 13, 2025) quotes Tenable’s Satnam Narang that “only 0.7% of AD domains had met the prerequisite at the time of disclosure.” The MSRC entry is https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53779.

KB5014754: certificate-based authentication on DCs (strong certificate mapping)

• Origin: May 10, 2022 update (CVE-2022-26923/34691/34692) changed KDC certificate validation.
• Timeline:
  • Full Enforcement became the default with the February 11, 2025 update; rollback to Compatibility was allowed until September 2025.
  • The KB was revised 9/10/2025, correcting the date to September 9, 2025.
  • In Full Enforcement, certificates that cannot be strongly mapped are denied.
• Relevance: This matters for AD CS–based authentication abuse such as ESC-style attacks, which CISA/NSA and DISA both treat as Tier 0.

Other relevant Microsoft advisories

• ADV190023 (LDAP channel binding and LDAP signing).
• CIS and DISA now include DC settings for “LDAP server channel binding token requirements” and “LDAP server signing requirements Enforcement” (CIS WS2025 benchmark sections 2.3.5.3–2.3.5.4).

A14. Windows Server 2025 AD DS changes relevant to tiering

• dMSA: See above. Note the BadSuccessor lesson that dMSA creation rights must be treated as privileged.
• DISA Windows Server 2025 STIG: Exists (V1R3, released August 10, 2026). Its DC Deny- logon rules are V-278168, V-278171, and V-278174.
• CIS: Publishes WS2025 DC profiles.
• Other Windows Server 2025 AD changes (e.g., new functional level, LDAP and Kerberos defaults) were not verified here.

A15. Practitioner (non-governmental) material, labeled as such

• SpecterOps, “Certified Pre-Owned” (2021, Schroeder and Christensen): The AD CS abuse taxonomy (ESC1…). This is the basis for treating AD CS as Tier 0.
• SpecterOps BloodHound “Tier Zero” table: A public, maintained list of AD and Entra assets considered Tier Zero.
• Status: Neither is government or standards guidance. Both are widely cited, including by the CISA/NSA joint document’s AD CS section.

3. Section B — Government and standards guidance

B1. NIST

SP 800-53 Rev. 5, Security and Privacy Controls

• URL: csrc.nist.gov (CPRT).
• Version: Release 5.2.0, August 27, 2025, adding software-update and integrity controls. Earlier patch 5.1.1 (November 2023) added IA-13.
• Status: Current.
• Access and licence: Free; US government work, not subject to US copyright.
• Relevant controls (paraphrased):
• AC-2 Account Management: define account types, approvals, monitoring, and disabling.
• AC-5 Separation of Duties: divide duties to prevent malevolent activity without collusion. Maps to Microsoft’s “operators, approvers, auditors.”
• AC-6 Least Privilege:
  • AC-6(1) authorize access to security functions.
  • AC-6(2) non-privileged accounts for nonsecurity functions. Maps to separate admin accounts.
  • AC-6(5) restrict privileged accounts to designated personnel.
  • AC-6(7) review privileges.
  • AC-6(9)/(10) log and prohibit privileged-function misuse.
• IA-2 Identification and Authentication (Organizational Users): IA-2(1) MFA for privileged accounts.
• IA-5 Authenticator Management.
• Limits: NIST does not name AD, tiers, or PAWs. DISA STIG rules map back to these controls via CCIs (e.g., the AD Forest schema rule V-243506 maps to AC- 6).

SP 800-63B (Digital Identity Guidelines: Authentication)

• NIST SP 800-63B-4, “Digital Identity Guidelines: Authentication and Authenticator Management” (author Justin Richer), was published July 31, 2025 (DOI 10.6028/NIST.SP.800-63b-4). Its CSRC page says it “defines technical requirements for each of the three authenticator assurance levels” and “supersedes NIST Special Publication (SP) 800-63B.”
• It defines authenticator assurance levels (AAL1–3) and phishing-resistant authenticators.
• It is not AD-specific. It is relevant to choosing MFA strength for administrative access, which CISA/NSA and CIS 6.5 require.

SP 800-207 Zero Trust Architecture (August 2020)

• Treats identity and per-request policy decisions as core, with no implicit trust based on network location.
• Consistent with Microsoft’s “credential and keyboard, not the IP address” principle. 800-207 does not prescribe AD tiering.

NIST and privileged access management (PAM): No dedicated NIST SP on AD PAM was identified. The NCCoE’s draft SP 1800-18, “Privileged Account Management for the Financial Services Sector” (initial public draft September 28, 2018; author Devin Wynne, MITRE), is now listed on CSRC as “Withdrawn,” with the planning note “NIST has ceased further development of this draft publication” (07/22/2022).

B2. CISA / NSA

Detecting and Mitigating Active Directory Compromises

• Authors: ASD’s ACSC (lead), CISA, NSA, CCCS, NCSC-NZ, NCSC-UK. Treated here as a CISA/NSA source with joint authorship noted.
• URLs:
  • US-hosted PDF: https://media.defense.gov/2024/Sep/25/2003553985/-1/-1/0/CTR-DETECTING-AND- MITIGATING-AD-COMPROMISES.PDF
  • CISA alert of September 26, 2024: https://www.cisa.gov/news-events/alerts/2024/09/26/asds-acsc-cisa-and-us-and- international-partners-release-guidance-detecting-and-mitigating-active
  • NSA announcement: October 1, 2024.
• Status: “First published: September 2024.” A co-author’s (non-US) site lists an August 2026 revision; no US-hosted revision was verified.
• Access and licence: Free; TLP:CLEAR. US agency content is US government work, but the multi-national co-authorship means foreign Crown copyright may apply to portions, so verify before verbatim reuse.
• Scope: 17 techniques against AD DS, AD FS, and AD CS, each with an explanation, mitigations, and detection (Windows event IDs): 1. Kerberoasting 2. AS-REP roasting 3. Password spraying 4. MachineAccountQuota compromise 5. Unconstrained delegation 6. GPP password compromise 7. AD CS compromise 8. Golden Certificate 9. DCSync 10. Dumping ntds.dit 11. Golden Ticket 12. Silver Ticket 13. Golden SAML 14. Microsoft Entra Connect compromise 15. One-way domain trust bypass 16. SID History compromise 17. Skeleton Key
• Key recommendations (paraphrased):
  • Limit privileged-account use and apply a tiered administrative model with PAWs.
  • Use gMSAs, AES-only Kerberos, and Protected Users.
  • Treat AD CS, AD FS, and Entra Connect servers as Tier 0.
  • Reset KRBTGT, and reset trust (TDO) passwords after a suspected compromise.
  • Use canary objects for detection. This is noted as effective against Kerberoasting, AS-REP roasting, and DCSync, because most compromises begin with enumeration tools such as SharpHound.
• Appendices: Consolidated AD security controls (Appendix A) plus detection and event tables.
• Caveat: The PDF body was not fully retrieved for this collection (bot- blocked). Technique list and themes are from the CISA, NSA, and press summaries plus known document structure.

CISA/NSA “Top Ten Cybersecurity Misconfigurations” (AA23-278A, October 2023)

• Verified on CISA’s AA23-278A page. The non-prioritized list of 10 puts “Improper separation of user/administrator privilege” second.
• The page notes “Many of the assessments were of Microsoft® Windows® and Active Directory® environments” and recommends: “Reduce, restrict, audit, and monitor administrative accounts and privileges.”

NSA “Defend Privileges and Accounts” (Top Ten Mitigation Strategies series): an older NSA fact sheet. Its current availability and status were not verified.

B3. DISA (DoD Cyber Exchange; public STIGs are unclassified and free to download)

Active Directory Domain STIG

• Current release: Ver 3, Rel 8, listed in DISA’s October 2026 Quarterly Release announcement (October 6, 2026).
• Prior releases: V3R7 (February 11, 2026) and V3R5 (September 13, 2024) each had 36 rules: 5 CAT I, 27 CAT II, 4 CAT III. The V3R8 count and changes were not verified.
• Key rules (titles from V3R5/V3R7):
• V-243466 (CAT I): Enterprise Admins membership restricted to accounts used only to manage the forest.
• V- 243467 (CAT I): Domain Admins membership restricted to accounts used only to manage the domain and DCs.
• V-243468 / V-243469 (CAT II): Separate admin accounts specifically for managing member servers and workstations. This is DISA’s codification of Tier 1/Tier 2 account separation.
• V-243470 (CAT I): Delegation of privileged accounts prohibited.
• V-243472: Separate smart cards for EA/DA accounts.
• V-243473: Separate accounts for public-facing servers.
• V-243475: DCs blocked from internet access.
• V-243477 (CAT II): Domain-level admin accounts must be members of Protected Users. This covers EA, DA, Schema Admins, Administrators, Account Operators, and Backup Operators; one account may be excluded for availability.
• Trust rules: Documentation of trusts, Selective Authentication on outbound forest trusts, and SID filtering.
• V-269097 (added in V3R5): Kerberos logging on DCs with AD CS.
• PAW rule: “Only systems dedicated for the sole purpose of managing Active Directory must be used to manage Active Directory remotely” (legacy ID AD.MP.0001; current V-ID not verified).
• OU ACLs: OU and Domain Controllers OU permission requirements appear in the Windows Server DC STIGs (e.g., WN12-AD-000004-DC / -000005-DC historically; WS2025 has “Active Directory Domain Controllers Organizational Unit (OU) object must have the proper access control permissions”). Current V-IDs were not verified.

Active Directory Forest STIG

• Release: Ver 3, Rel 2 (released July 2, 2025; NCP lists a publication date of September 14, 2026 for the checklist entry, so dates conflict).
• Rules: 7 in total, 3 CAT I.
• V-243502: Schema Admins membership limited.
• V-243503: anonymous access above rootDSE disabled.
• V-243504: forest-root PDC Emulator uses an external time source.
• V- 243505: schema changes go through configuration management.
• V-243506 (CAT I, AC-6):

Schema update access restricted.

• V-269098 (CAT I): AD CS must enforce CA certificate- manager approval for certificate requests.
• V-269099 (CAT I): AD CS “must be managed by a PAW tier 0.” The check is that one or more PAWs are set aside for remote management of AD CS.

Windows Server 2022 / 2025 STIGs (DC hardening and user rights)

• Versions: WS2022 STIG V2R10 (August 10, 2026; 278 rules: 31 CAT I, 235 CAT II, 12 CAT III). WS2025 STIG V1R3 (August 10, 2026; 291 rules). A V1R4 may now be current (see Caveats).
• Deny-logon rules:
  • On DCs they require only Guests/unauthenticated access. WS2025: V-278168 (network), V- 278171 (locally), V-278174 (RDS). WS2022: V-254421, V-254424.
  • On domain-joined member servers they require Enterprise Admins, Domain Admins, and Guests (plus “Local account” for network and RDS). WS2025: V-278187 (locally). WS2022: V-254435 (network).
  • PAWs dedicated to AD management are exempt from denying EA/DA.
  • Workstation STIGs (e.g., Windows 11) apply the same EA/DA Deny rights.
• Other DC rules: AD data file, SYSVOL, and GPO permissions; anonymous-access restrictions; Directory Service Access auditing.

Windows Privileged Access Workstation STIG (V3R2)

• Administrative accounts of high- value resources must be assigned to a specific administrative tier (WPAW-00-000400).
• The domain must restrict privileged admin accounts from logging on to lower-tier hosts (WPAW- 00-001200).
• A PAW that manages DCs must not manage other high-value resources (WPAW- 00-001300).
• PAWs must enforce two-factor authentication.

B4. CIS (Center for Internet Security, nonprofit)

CIS Microsoft Windows Server 2025 Benchmark

• Versions: v2.1.0 (announced in CIS’s September 2026 update); v2.0.0 dated February 24, 2026.
• Profiles: Level 1 and Level 2 Domain Controller, Level 1 and Level 2 Member Server, and an optional “Next Generation Windows Security” DC/MS profile.
• Access and licence: Free PDF registration for non-commercial use under CIS terms (Creative Commons BY-NC-SA for Benchmarks). Build kits and CIS-CAT Pro require SecureSuite membership.
• Relevant content:
  • DC-only settings such as LDAP server channel binding and signing enforcement, Netlogon secure channel, and “Allow server operators to schedule tasks.”
  • User Rights Assignment with “(DC only)” and “(MS only)” variants, including Deny rights that exclude Domain/Enterprise Admins from member servers.
• Limits: CIS does not define tiers.

CIS Controls v8.1 (guide v8.1.2, March 2025; licence CC BY-NC-ND 4.0)

• Safeguard 5.4 (IG1): Restrict admin privileges to dedicated admin accounts. Use the primary non-privileged account for browsing, email, and productivity. Maps to NIST AC-6(2) and AC-6(5).
• 5.5: Inventory of service accounts.
• 5.6: Centralize account management through a directory service.
• 6.5 (IG1): Require MFA for administrative access.
• 6.7: Centralize access control.
• 6.8: Define and maintain role-based access control.
• Control 8: Audit logs (e.g., 8.9 centralize).

B5. IETF (background only)

• RFC 4120, Kerberos V5 (July 2005): Core protocol for AD authentication. AD extends it with the PAC, defined in Microsoft’s [MS-PAC] and [MS-KILE] Open Specifications, not IETF.
• RFC 3961 / 3962 (February 2005): Kerberos encryption/checksum framework and AES for Kerberos. This is the basis for “AES-only” requirements in Protected Users and the CISA/NSA guidance.
• RFC 4511 (June 2006), LDAP protocol (part of the RFC 4510 series).
• RFC 5929 (July 2010), TLS channel bindings: The basis for LDAP channel binding, which Microsoft implements per ADV190023.
• Licence: IETF Trust Legal Provisions. RFCs are freely available; reuse of text is permitted with conditions.

4. Topic crosswalk

5. Where authorities agree, differ, or conflict

• ESAE retired, tiering retained. Microsoft retired the separate admin forest, not the tier concept. Its 2026 tier-model page and the GitHub framework expand tiering. DISA (PAW STIG “administrative tier,” V-269099 “PAW tier 0”) and CISA/NSA still use tier language. Training content should not present “Red Forest” as current Microsoft guidance, nor present tiering as deprecated.
• NIST maps onto the tier model without naming it.
  • AC-5 corresponds to Microsoft’s “operators, approvers, auditors.”
  • AC-6(2) and AC-6(5) correspond to dedicated, tier-scoped admin accounts.
  • IA-2(1) corresponds to MFA for admins.
  • NIST is outcome-based; Microsoft and DISA supply the AD mechanisms.
• DISA is prescriptive; Microsoft provides a framework.
  • DISA fixes group names (EA/DA) in Deny rights and requires Protected Users membership. These are binary, auditable checks.
  • Microsoft frames tiers by control scope and accepts organizational variation, such as Tier 0 membership beyond DA and the “common target” of fewer than five admins.
  • DISA’s Deny rights target EA/DA specifically. Microsoft’s model applies to any Tier 0 or Tier 1 group, so DISA compliance alone does not achieve full tier isolation.
• Tier 0 scope. Microsoft explicitly includes backup, monitoring, patching, hypervisor, and EDR systems that manage Tier 0. DISA codifies only parts (AD CS via PAW). CISA/NSA emphasize AD CS, AD FS, and Entra Connect. These positions are compatible, but Microsoft’s is the broadest.
• Cloud emphasis. Microsoft’s ESAE rationale and EAM push toward cloud-based controls (MDI, PIM, cloud PAWs). DISA and NIST are platform-neutral; DoD environments may be disconnected, which is one of Microsoft’s own ESAE exception cases.
• Service accounts. Microsoft promotes dMSA, but BadSuccessor (CVE-2025-53779) showed that dMSA object rights become a Tier 0 path. CISA/NSA’s gMSA advice predates dMSA. No government source verified here addresses dMSA directly.

6. Caveats and items not verified

• Pages not fetched directly. The following were identified via search snippets or links from verified pages but not opened in full:
  • Microsoft Learn: forest/domain design, Delegation of Control Wizard, AD DS permissions, RaMP, PAW overview, intermediaries, Windows LAPS, gMSA overview, Security Compliance Toolkit (WS2025 baseline version/date), MDI.
  • Fully fetched: the tier-model and ESAE pages. The Enterprise Access Model, OU design, Appendix C, Protected Users, Authentication Policies, dMSA, and KB5014754 were verified from search-result extracts of the official pages.
• CISA/NSA joint guide. The PDF body was bot-blocked. The 17-technique list and appendix structure come from official CISA/NSA announcements, the PDF snippet, and known document structure. An “August 2026” revision appears on the Australian co- author’s site (an excluded source); its existence on a US host was not confirmed.
• DISA AD Domain STIG V3R8. The release is confirmed. Its date, rule count, and changes are not; the details above come from V3R5–V3R7. The OU-ACL rule V-ID and the current PAW-rule V-ID were not verified. The AD Forest STIG V3R2 date conflicts between sources (July 2, 2025 vs. NCP’s September 14, 2026). Whether WS2025 V1R3 or V1R4 is current is unconfirmed. Several Deny-logon V-IDs (WS2022 DC RDS, member- server locally/RDS; WS2025 member-server network/RDS) were not verified.
• Rule-detail sources. STIG rule details come from third-party STIG viewers (cyber.trackr.live, stigviewer, Tenable audit listings) mirroring DISA content, because cyber.mil pages did not render. Verify against the official ZIP before publishing rule text.
• Not re-verified this session: NSA “Defend Privileges and Accounts” status and Windows Server 2025 AD changes beyond dMSA.
• GitHub repo. The release year (May–August) was inferred, and the MIT licence was confirmed only via fork metadata and the README.
• BadSuccessor technical details come from Akamai’s own research blog plus security- vendor and press reporting (Tenable, Help Net Security). The MSRC entry itself was not fetched.
• Licensing. Microsoft Learn text is Microsoft-copyrighted; GitHub source repos may carry CC BY 4.0 (docs) and MIT (code). The CIS licence terms are as commonly published. Confirm each before reusing text in commercial training.