Consolidating Active Directory forests and domains: approaches, SID history risks and trust clean-up

Why these designs persist

In the early 2000s it was common to recommend an empty root domain with child domains per region or entity, in the name of administrative isolation. Acquisitions then added entire forests, linked by "temporary" trusts that never went away. These designs survive because nobody wants to touch something that works, and because business applications have built up dependencies on them.

The original premise is wrong, however: the domain is not a security boundary, the forest is. An administrator of a child domain can, using well-known techniques, gain privileges across the whole forest. Several domains in one forest therefore multiply the accounts and controllers to protect without providing any real isolation.

Choosing the target

The sensible target is usually one forest, one domain. Multiple forests are only justified for genuine separation, such as a dedicated admin forest or an entity that will be divested. There are three ways to get there:

• inter-forest restructuring: migrating accounts, groups, computers and servers to an existing or new target forest;
• intra-forest restructuring: merging the domains of one forest into a surviving domain;
• rebuild: building a new, clean forest and migrating into it gradually, which avoids inheriting the old one's configuration mistakes.

Microsoft's historical tools for these migrations are no longer actively developed; many organisations use third-party tools. Check the support status of the tools you are considering before committing.

SID history: essential during, dangerous after

During a migration, the sIDHistory attribute lets a migrated account keep access to resources still secured with its old identifier. That is what makes the transition invisible to users. It is also a powerful mechanism: a SID placed in the history is treated as if it belonged to the account.

The end of the migration must therefore include an explicit step: translating permissions on resources (file ACLs, shares, applications) to the new SIDs, then cleaning up the history.

Trusts: reduce and harden

Every trust is a potential path. Points to review:

1. SID filtering: it must stay enabled on external and forest trusts. Disabling it to ease a migration opens the door to SID history injection from the trusted forest.
2. Selective authentication: it limits accounts from the trusted forest to explicitly authorised resources.
3. Kerberos delegation across trusts: it should remain disabled unless a need is demonstrated.
4. Direction and transitivity: a two-way trust is often only needed one way.

A trust to a less well-protected forest effectively imports its level of risk. We regularly find trusts to forests whose administrators nobody can name any more.

Decommissioning properly

A migrated domain is not secure as long as it exists. Decommissioning includes removing the trusts, demoting the domain controllers, cleaning up DNS and leftover objects, and checking that no application still authenticates against the old domain. Keeping an empty domain "just in case", with unmaintained controllers, is one of the worst compromises there is.

What an audit checks

• The map of forests, domains and trusts, with their justification.
• The status of SID filtering and selective authentication on each trust.
• Accounts carrying SID history, particularly privileged SIDs.
• Residual, unmaintained domains or forests.
• Privileged accounts and groups in every domain, including the root domain.