Learn Active Directory - Active Directory at Scale

#Introduction

In episode 26 we made sure the infrastructure could survive a disaster. Now imagine a different scale: not one office with 300 employees, but 40,000 users spread across 60 countries, 8,000 branches, and 12 data centers. Every design decision that looks trivial in the lab — one DC per site, one GC, one site link — becomes an expensive decision that's hard to change once running.

This is an episode about design, not just configuration. At scale, design errors don't appear today; they appear a year later as stuttering replication, slow logons in remote branches, and ballooning operational costs. Let's dissect the principles that keep AD healthy as it grows to millions of objects.

#Design for the Enterprise: Multi-Domain and Multi-Forest

Many administrators assume scale means many domains. In reality, a single modern domain can hold millions of objects. New domains should be created for design reasons, not fear:

• A domain is a boundary of administration, replication, and security policy. Split a domain when you need clear policy isolation or firm delegation.
• A forest is a security boundary and a schema boundary. Multi-forest is only for extreme isolation: not-yet-integrated acquisitions, compliance separation, or air-gap requirements.

The most common pattern in large enterprises: one forest, several domains, or even one forest and one domain with neatly organized OUs. Every additional domain means GC replication, RID pools, and administrative complexity that must be paid for daily.

#Global Catalog at Scale

At scale, the GC is no longer "nice to have" — it's part of the logon path. When a user logs on, the domain controller queries the GC to determine universal group membership. Without a GC, logon waits, delays, or fails.

GC placement principles:

• At minimum one GC per site, more if cross-domain search load is high.
• Applications searching cross-domain (Exchange GAL, directory tools) use the GC — measure their load when planning the number of GCs per hub.
• For small sites without a GC, enable universal group caching as a compromise: membership keys are stored locally and refreshed periodically, saving bandwidth with a small freshness trade-off.

In a multi-domain forest, every GC holds a partial copy of all domains' attributes. More domains mean more data replicated to every GC — one reason "one forest, one domain" is so attractive.

#Site Design at Scale

Sites are AD's physical network map: subnets are grouped into sites, then connected by site links with cost and schedule. At scale, mistakes here burden replication for years.

• Site link cost determines the best replication path between sites. Give low cost to fast, expensive links and high cost to slow, cheap ones — the KCC will pick the most efficient route.
• Schedule and replication frequency prevent replication from fighting for WAN bandwidth during working hours.
• Preferred bridgehead servers designate certain DCs as the gateway for inter-site traffic, easing monitoring and protection.
• Don't create a site for every building or floor — a site is a collection of subnets with uniform latency, not every physical point.

Set site links with PowerShell:

Set-ADReplicationSiteLink "DEFAULTIPSITELINK" -Cost 100 -ReplicationFrequencyInMinutes 30

#RODCs for Branches

Small branches — stores, warehouses, representative offices — usually don't have a secure server room. This is where the Read-Only Domain Controller (RODC) (episode 19) comes in:

• Read-only AD database; no direct writes, so an attack on a branch can't modify the directory.
• The Password Replication Policy determines whose credentials may be cached at the branch. Privileged accounts are in the denied list by default — a stolen branch RODC doesn't leak Domain Admin credentials.
• Branch admins can be given local RODC administrative rights without getting domain rights (administrator role separation).

Rule of thumb: keep RODCs only at branches that need reliable local authentication but aren't suitable for a writable DC. Beyond one RODC per branch, reevaluate — don't pile up DCs in small locations.

#KCC: Let It Work, But Watch It

The Knowledge Consistency Checker (KCC) (episode 16) builds the replication topology automatically. At scale, the biggest temptation is "helping" the KCC by creating manual connection objects. Don't — manual connections can make the topology messy and unpredictable.

The KCC is "tuned" through correct configuration, not intervention:

• Set site links (cost, schedule) correctly — the KCC follows those cues.
• Use the default site link bridging; disable automatic bridging only if the topology is very complex and you understand the consequences.
• Monitor topology health on a schedule, not by waiting for complaints:

repadmin /replsummary /bysrc | Out-File "C:\Data\replsummary.txt"
repadmin /showrepl * /csv | Out-File "C:\Data\repl.csv"

A repadmin /replsummary script run by a scheduled task every morning is an early warning: replication errors left for a week at scale can mean tens of thousands of out-of-sync objects.

#Delegation and Automation at Scale

Administration can't stay centralized in a handful of people as scale grows. Use three weapons:

1. OU-based delegation. Helpdesk is given password reset rights only on their own division's OUs (episodes 7 and 12). Every delegation must follow least privilege.
2. Service restriction. Service accounts at scale are managed via gMSA — passwords rotate automatically, with no admin holding secrets in their head.
3. Automation. Identity flows — onboarding when employees join, offboarding when they leave — run via PowerShell and scheduled tasks, or an identity lifecycle system provisioning through APIs.

#Best Practices for Many DCs

• Don't pile up DCs. Two writable DCs per hub site is usually enough; add more only for authentication load or availability, not habit.
• Patch gradually. Don't patch all DCs at once. Test one DC first, then roll the rest — making sure AD keeps serving during the update.
• Time synchronization. The PDC Emulator takes time from an external NTP source; all other DCs follow the PDC Emulator. Drifting clocks = broken Kerberos (episode 13).
• Don't clone DCs. Snapshotting or cloning a virtual DC risks USN rollback (episode 26). A new DC must be promoted, not cloned.
• One extra DC isn't the answer to every problem. Slow branch logons are usually DNS and site design, not a shortage of DCs.

#Conclusion

In episode 27 you understood AD at enterprise scale: when multi-domain and multi-forest are truly needed, the Global Catalog's role in the logon path and universal group caching, site design through site link cost and bridgeheads, RODCs as the answer for branches, the KCC principle tuned through configuration not intervention, delegation and automation as survival requirements, and best practices for many DCs.

Key points:

• A single modern domain can hold millions of objects; a new domain needs a design reason.
• One GC per site is the standard; universal group caching for small branches.
• Don't fight the KCC — give it correct site links.
• RODCs for insecure branches, not for every location.
• Automation is the only way to manage scale without adding errors.

After the large infrastructure comes a question big companies can't avoid: how do we prove its control? In episode 28 we dissect Active Directory Compliance & Auditing: regulations like SOX, HIPAA, PCI-DSS, and GDPR, audit policies, access reporting, up to change management. See you there!