Domain and forest trusts: SID filtering, selective authentication and forgotten links
A trust extends your security perimeter to a directory you do not control. Mergers, acquisitions and migration projects often leave behind trusts whose purpose nobody remembers. Here are the settings to review.
Direction and transitivity
The terminology is confusing: access flows in the opposite direction to the trust. If domain A trusts domain B, users from B can access resources in A. A two-way trust therefore opens both directions.
- Parent-child and tree-root trusts, inside a forest, are two-way and transitive.
- Forest trusts are transitive between the domains of the two forests involved, but not beyond.
- External trusts, between two specific domains, are non-transitive.
The forest is the security boundary
Within a forest there is no SID filtering between domains. An administrator of a child domain can, by design, reach the forest root domain. That is why Microsoft considers the forest, not the domain, to be the real security boundary. A child domain "isolated" for a partner protects nothing.
SID filtering and SID history
The sIDHistory attribute is used during migrations to keep access to resources in the old domain. But a SID in that history is treated as a real membership: if an attacker controls the trusted domain, they can place the SID of a privileged group from the trusting domain there.
SID filtering prevents this by stripping, at the trust boundary, SIDs that do not belong to the trusted domain or forest. It is enabled by default on external trusts ("quarantine") and forest trusts. We still find it disabled, usually for a migration that finished long ago.
Get-ADTrust -Filter * |
Select-Object Name, Direction, ForestTransitive,
SIDFilteringQuarantined, SIDFilteringForestAware,
SelectiveAuthentication, WhenChanged
The options can also be checked with netdom trust. A forest trust on which SID history has been allowed should be justified by an ongoing migration.
Rule of thumb. Once a migration is complete, clear sIDHistory from migrated accounts and restore full SID filtering. SID history without an ongoing migration is an anomaly.
Selective authentication
By default, a trust lets every user of the trusted domain authenticate to every machine in the trusting domain, with ACLs doing the rest. Selective authentication reverses this: an external user can only authenticate to a computer if they have been explicitly granted the "Allowed to Authenticate" right on that computer object. It is the right setting for a partner relationship that only needs a few servers.
Forgotten trusts
A trust to a vanished partner, a decommissioned domain or a divested subsidiary remains a risk as long as it exists: the remote domain can be taken over, rebuilt or compromised without your knowledge. Every trust should have an owner, a documented purpose and a review date.
What an audit checks
- The inventory of trusts, with direction, type and transitivity.
- SID filtering status and whether SID history is allowed.
- Accounts with a non-empty
sIDHistory. - Use of selective authentication for external partners.
- Trusts with no identified purpose.