Modern Active Directory Architecture: What 25 Years Taught Me

I deployed my first Windows NT domain in the late 1990s. NT 3.51, single domain, flat trust, everyone was a Domain Admin because it was easier. The network had maybe 200 users.

Twenty-five years later, Active Directory is still the identity backbone of most enterprises. And most of them are still running architectures that were designed for Windows Server 2003.

This isn't a deployment guide. It's a collection of patterns and lessons from building, inheriting, and modernizing AD environments across defense, healthcare, energy, and financial services. Some of these cost me sleep. All of them cost someone money.

The problem with inherited AD

Nobody builds Active Directory from scratch anymore. You inherit it. And what you inherit is a decade of decisions made by people who are no longer there, under constraints that no longer exist, documented in SharePoint sites that no longer load.

Common symptoms of inherited AD:

• Flat OU structure -- Everything in one or two OUs. No delegation boundaries. GPOs linked at the domain level affecting every object.
• Domain Admin creep -- Service accounts, helpdesk staff, and that one contractor from 2014 all in Domain Admins. Nobody knows which accounts are still active.
• Single-domain forest with no tiering -- Domain Controllers, member servers, and workstations all administered by the same accounts with the same privileges.
• Legacy trust relationships -- Trusts to domains that were decommissioned years ago. One-way trusts that should be two-way. Trusts with SID filtering disabled "temporarily" in 2016.
• Kerberos misconfigurations -- Unconstrained delegation on service accounts. SPNs registered on the wrong objects. Golden ticket attack surface nobody has assessed.

If any of this sounds familiar, you're in the majority.

Tiered administration: the model that should be everywhere

Microsoft published the Enhanced Security Admin Environment (ESAE) and tiered administration model years ago. The concept is simple: separate administrative privileges into tiers so that compromise of a workstation doesn't give an attacker access to Domain Controllers.

The three tiers

Tier 0 -- Identity infrastructure:

• Domain Controllers
• AD CS (Certificate Services)
• AD FS (Federation Services)
• Azure AD Connect (if hybrid)
• PKI infrastructure
• The AD schema and configuration partition

Tier 0 accounts can only log into Tier 0 systems. They never touch a workstation or member server. Ever.

Tier 1 -- Server infrastructure:

• Member servers (application servers, file servers, database servers)
• Server management tools (SCCM, SCOM, patching systems)
• Hypervisor management (vCenter, Proxmox -- though ideally these are in Tier 0)

Tier 1 accounts manage servers but cannot log into Domain Controllers or workstations.

Tier 2 -- Workstation and user environment:

• End-user workstations
• Helpdesk tools
• User-facing application management

Tier 2 accounts can reset user passwords and manage workstations but have zero access to servers or Domain Controllers.

Why it matters

The attack path that ends most AD environments is lateral movement from a compromised workstation to a Domain Controller. An attacker compromises a user's laptop (phishing, drive-by download, USB), escalates to local admin, dumps credentials from memory, and finds a cached Domain Admin token. Game over.

Tiered administration breaks this chain. Even if the workstation is fully compromised, no Tier 0 credentials exist on it. The attacker has a workstation. They don't have the domain.

Why almost nobody does it

Because it's operationally painful. Your senior sysadmin who's been running everything from one account for 15 years now needs three accounts -- one for each tier. They need separate Privileged Access Workstations (PAWs) for Tier 0 management. They can't RDP to a Domain Controller from their laptop.

The technical implementation is straightforward. Authentication policy silos, GPO-enforced logon restrictions, PAW deployment. The organizational change management is the hard part. People resist losing convenience, even when the alternative is a catastrophic breach.

Trust relationships: less is more

Every trust relationship is an attack path. External trusts, forest trusts, shortcut trusts -- each one extends your security boundary to include another domain's administrators.

Rules for trusts

1. Default to no trust. If two domains don't need to share resources, they don't need a trust. The absence of a trust is the strongest security boundary.

2. One-way over two-way. If Domain A needs to access resources in Domain B, but not vice versa, create a one-way trust. Two-way trusts are convenient but double your attack surface.

3. SID filtering stays on. SID filtering prevents an administrator in a trusted domain from impersonating users in your domain using SID history. Disabling it "temporarily" to fix a migration issue is how you get compromised permanently.

4. Selective authentication over forest-wide. When you create a forest trust, you can choose between forest-wide authentication (any user in the trusted forest can authenticate to any server) and selective authentication (access must be explicitly granted per-server). Always choose selective.

5. Audit quarterly. Run netdom trust /domain:yourdomain.com /enumerate and review every trust. If you can't explain why a trust exists, it shouldn't.

Group Policy: the silent complexity bomb

GPOs are the most powerful and most abused feature in Active Directory. A typical enterprise has 200-500 GPOs. In large environments, I've seen over 1,000. Most of them conflict with each other, and nobody can explain the net result for a given machine.

GPO hygiene

Link GPOs at the OU level, not the domain level. Domain-level GPOs affect every object. That includes Domain Controllers, servers, and workstations. Unless a policy truly applies to everything (and very few do), link it to a specific OU.

Name GPOs descriptively. SEC-Tier0-DC-AuditPolicy tells you what it does. New Group Policy Object (3) tells you nothing. This seems obvious, but I've inherited environments with 50+ GPOs named GPO-Copy and Test Policy - DO NOT DELETE.

One GPO, one purpose. Don't create monolithic GPOs that configure 40 settings across security, software installation, and drive mapping. When something breaks, you need to know which GPO caused it. A GPO with a single purpose is easy to disable and test.

Use WMI filters sparingly. WMI filters add processing time to every Group Policy refresh cycle. On a domain with 10,000 machines refreshing every 90 minutes, a slow WMI filter generates measurable load on domain controllers.

RSoP before you deploy. Resultant Set of Policy (gpresult /H report.html) shows the effective policy for a specific machine. Run it before and after changes. The delta is your change documentation.

Service accounts: the forgotten attack surface

Service accounts in AD are the credentials most likely to be misconfigured and least likely to be audited.

Common problems:

• Password never expires -- The default for service accounts. That password set in 2012 is still valid. If it was weak then, it's crackable now.
• Interactive logon allowed -- Service accounts that can log into workstations interactively. Why? Nobody knows.
• Unconstrained delegation -- Any service with unconstrained delegation can impersonate any user to any service. This is a Kerberos nuclear weapon. It should almost never be used.
• Over-privileged -- Service accounts in Domain Admins because the application "needed it to work." It didn't. It needed a specific permission on a specific OU, but Domain Admins was faster to troubleshoot.

Group Managed Service Accounts (gMSAs)

gMSAs solve the password rotation problem. AD manages the password automatically -- 240-character random passwords rotated every 30 days. The service account can only be used by specified computers. No human ever knows the password.

If your application supports gMSAs (and most modern applications do), there's no reason to use traditional service accounts. SQL Server, IIS, SCCM, SCOM, and most .NET services support them natively.

For applications that can't use gMSAs, implement LAPS (Local Administrator Password Solution) concepts for service accounts: rotate passwords on a schedule, store them in a vault (CyberArk, HashiCorp Vault, or even an encrypted attribute in AD), and audit access to the vault.

Hybrid identity: the new normal

Most organizations are hybrid now -- on-premises AD synchronized to Entra ID (Azure AD) via Azure AD Connect. This creates a new set of architectural decisions:

Password Hash Sync (PHS) vs Pass-Through Authentication (PTA) vs Federation (AD FS):

• PHS is the simplest. Password hashes sync to Entra ID. Authentication to cloud services happens in the cloud. If on-premises AD is down, cloud authentication still works.
• PTA keeps authentication on-premises. Cloud requests are proxied to your DCs. If your network is down, cloud auth fails.
• AD FS gives the most control but adds infrastructure (federation servers, WAP proxies) and operational complexity.

For most organizations: PHS with Seamless SSO. It's the least complex, most resilient, and Microsoft's recommended approach. AD FS is only justified when you need claims-based transformations that PHS can't handle.

Hybrid identity gotcha: Azure AD Connect syncs everything by default. That includes your Tier 0 accounts. An attacker who compromises Entra ID (cloud) may be able to leverage synced Tier 0 account hashes to move on-premises. Filter Tier 0 accounts from sync. They have no business being in the cloud.

The long game

Active Directory isn't going away. Entra ID is growing, but on-premises AD will exist in enterprises for another decade at minimum. The organizations that invest in proper tiering, trust hygiene, and service account management now will be the ones that survive the inevitable breach attempt without losing their domain.

The ones still running flat architectures with Domain Admin on every workstation will learn these lessons the hard way.

Twenty-five years in, the technology has changed dramatically. The mistakes haven't.