We are mid-flight on an Active Directory forest consolidation for a government client: seven forests, eleven domains, accumulated over fifteen years of agencies merging, splitting, and hiring integrators who each brought their own naming religion. The target is one enterprise forest. The tool is ADMT and a great deal of patience. This post is about the design phase — the target forest decisions that determine whether the ADMT migration phases later go smoothly or become a two-year hostage situation.
Forest consolidation is the least glamorous work we do and the highest-leverage. Every other program this client wants — Office 365 with a single tenant, Exchange hybrid, a rationalized GPO estate, eventually a single SCCM hierarchy — is gated on identity. You cannot federate seven forests into one tenant elegantly. You can barely do it inelegantly.
Here is how we approached the design, and the arguments we had along the way.
Discovery first, and discovery means everything
Before drawing the target, we inventoried the sources. Not "how many users" — that number is in every slide deck and it is always wrong. The real inventory:
- Trusts. We mapped 23 trusts, of which 9 were external trusts to forests nobody could identify an owner for. Two were still using SID filtering disabled "temporarily" since 2011.
netdom trustand a lot of interviews. - Service accounts and SPNs.
setspn -Qsweeps across every domain, cross-referenced with services running as domain accounts (SCOM helped here — we already monitor most of this estate). We found 340 service accounts; owners were identifiable for about 210 of them. The other 130 are why you keep source domains readable long after users move. - Applications binding to LDAP by hardcoded domain. The silent killers. Anything with a connection string containing a specific DC name or a
DC=agency,DC=localbase DN will break at cutover unless found first. We scraped configuration files where we could and put network captures on domain controllers where we could not — watching who binds tells you who lies about not using AD. - UPN and sAMAccountName collisions. Eleven domains means eleven chances for two different humans named jsmith. We found 412 sAMAccountName collisions and 96 UPN collisions. Collision resolution policy is a design artifact, not a migration-day improvisation.
The discovery deck ran 70 pages. It was worth more than the migration itself, and we have said the same thing about Office 365 assessments. The pattern holds: the assessment is the project.
One forest, one domain — and the fights about it
The target design question everyone expects to be hard: how many domains in the new forest? Our answer is almost always the same. One forest, one domain, done.
The historical reasons for multiple domains are mostly dead in 2017. Domains are not security boundaries — forests are, and have been since Microsoft said so circa 2002. Password policy per domain stopped being a reason when fine-grained password policies arrived in 2008. Replication traffic stopped being a reason when links stopped being 128k frame relay. What remains is political: agencies want "their own domain" the way departments want their own filing cabinets.
We held the line with two arguments. First, cost: every additional domain is two more domain controllers minimum (we build DCs in pairs, always), plus separate DNS zones, plus another place for GPO drift. Second, the delegation model: OUs plus delegated permissions give each agency everything a child domain gave them, minus the infrastructure. Each agency gets a top-level OU, delegated admin groups scoped to it, and no ability to touch anyone else's. We demonstrated the delegation in a lab with their own admins driving. That demo ended the argument better than any slide.
We did keep one deliberate exception in the design: a separate forest — not domain — for a classified enclave with a legal isolation requirement. A one-way trust from the enclave to the enterprise forest, SID filtering on, selective authentication on. If the requirement is genuine isolation, a domain was never the right answer anyway.
Naming: the new forest got a routable DNS name (a subdomain of the organization's public domain), because .local names are a slow-motion regret — certificate authorities stopped issuing for them years ago and split-brain DNS is misery. UPN suffixes were standardized to match primary SMTP addresses, which the future Office 365 program will thank us for.
Trust topology during the long middle
The consolidation will run 14 months. For that entire window, old forests and the new one coexist, and users in mid-migration need access to resources on both sides. The interim trust topology is therefore not scaffolding — it is a production system that must be designed like one.
We built two-way forest trusts from each source forest to the target, with SID filtering disabled on those specific trusts for the migration window. That sentence should make you flinch; it made us flinch. Disabling SID filtering is what allows SID history to work across the trust — a migrated user carrying their old SID in sIDHistory can still access an ACL on a source file server that only knows the old SID. Without it, you must re-ACL everything before anyone moves, which turns a 14-month program into a 3-year one.
The mitigations, since we are accepting real risk: the trusts are monitored (SCOM alerts on SID history injection patterns and on any new trust creation), the window is bounded and written into the security plan with an expiry date, and quarantine (SID filtering) is re-enabled per-trust the day the last resource dependency for that source forest is cleared. Selective authentication stays on for the two external trusts we could not eliminate yet. The 9 orphan trusts from discovery were simply deleted — six weeks of "does anything break?" silence confirmed what we suspected.
ADMT phases: users last, not first
ADMT 3.2 remains the tool, unfashionable as it is. The phase order matters more than the tool:
- Global groups and universal groups, migrated with SID history, membership recalculated post-move. Groups move before users because a user migrated before their groups arrives in the target naked.
- Service accounts and computers for pilot workloads. Computer migration includes the security translation pass — ADMT re-ACLs local profiles and local group membership so the machine trusts both identities during transition.
- Users, in waves aligned to agency and to file-server dependency clusters — we group users by the resources they share, not by alphabet, so a wave's SID history dependencies retire together.
- Resource servers last. File servers, print servers, application servers migrate (or get re-ACLed in place) only after their user population is fully across. Then that source domain's SID history is dead weight and quarantine goes back on.
Password migration uses the ADMT Password Export Server on a dedicated, hardened box in each source domain — users keep their passwords, which cuts the helpdesk load enormously. Wave size settled at 250–400 users after the pilot; larger waves outran our ability to triage the morning-after ticket queue.
# The post-wave health check we run before declaring any wave done
Get-ADUser -Server target.example.gov -Filter 'sIDHistory -like "*"' `
-Properties sIDHistory, userPrincipalName |
Measure-Object
# ...compared against the wave manifest count. Off by even one, we investigate.
What we flatten, what we keep
Consolidation is the once-a-decade chance to delete things, and we take it seriously. Flattened: the eleven-domain structure, obviously; some 900 GPOs (target is around 200 — that rationalization is its own war story for another post); six different admin-tiering conventions replaced with one; per-agency DNS conventions replaced with a single zone and standardized aliases.
Kept, deliberately: agency identity in the OU structure and in group naming, because delegation and politics both need it; existing email addresses and UPNs where they already matched the standard; and — this surprises people — several hundred legacy security groups whose purpose nobody could state but whose membership patterns suggested application dependencies. Deleting a mystery group costs nothing today and a production outage in August. They go into a _Legacy OU, get documented as unowned, and get reviewed for deletion twelve months post-migration when the SIEM says nobody tokenized them.
The design principle underneath all of it: the target forest should look like it was built on purpose by one team in one year. Every place we compromised on that, we wrote down why, with an expiry date. Undated exceptions are how the next consolidation project gets born.
If you're facing this
Multi-forest consolidation is long, political, and unforgiving of design shortcuts — and it unlocks everything else in a modernization program. We have designed and run these at agency scale, ADMT scars and all. If you are staring at a forest diagram that looks like an org chart's crime scene, get in touch; we are happy to compare it to ours.