After a merger adds a forest trust, why does the privilege graph change with no membership edits?

## Trusts are edges in the same graph A trust relationship is stored as a directory object and it changes the graph in a way no membership report shows. The mechanism is straightforward: authentication flows across the trust, and once a principal from the trusted forest has authenticated on your side, it is an authenticated principal in your forest. That means two things at once — it obtains the same default read over your directory that any of your own accounts has, and it becomes eligible to be named in your access control entries and added to your domain local groups. Direction matters and is routinely stated backwards. Access flows opposite the trust direction: if your forest trusts theirs, their principals can be granted access to your resources. A one-way trust in that direction is not a shield. ## What the acquisition actually merged Two months after an acquisition the technical work looks small — a trust object, some name resolution, a few groups for shared applications. The graph work is enormous: - Every domain local group in your forest that now contains a foreign principal is a cross-forest edge. - Every permission entry that names a foreign principal is a cross-forest edge, including entries someone added during migration to make an application work. - The acquired forest carries its own decades of inherited organisational-unit delegation, forgotten object owners and convenience nesting — all of which nobody on your side has read. - Their weakest account is now a starting node for a route that ends in your estate, if any of the above edges exist. The ranked shortest paths that come out of the merged graph frequently start in the forest you do not administer. That is the finding to produce before anything is touched. ## The forest is the security boundary, not the domain This is the fact interviewers most want to hear stated correctly. Inside a single forest, security identifiers are not filtered between domains, the schema and configuration are shared, and privileged groups at the forest root have reach across it. So compromising any domain in a forest is, in the general case, compromising the forest. Separate forests joined by a trust are a genuine boundary because filtering applies there by default: identifiers that do not belong to the trusted forest are stripped from what it asserts, which is what stops a foreign forest from simply claiming to hold your administrative group. Be careful not to overclaim on that. Filtering blocks smuggled identifiers. It does nothing about rights you granted deliberately — a foreign group placed in your domain local group, or a permission entry naming a foreign account, is legitimate and is honoured. ## Narrowing a trust without removing it The business reason for the trust — payroll, mail, a shared application — usually means it cannot be deleted on the security team's say-so. The lever that exists is selective authentication: instead of letting the trusted forest's principals authenticate anywhere, they must be granted an explicit right to authenticate on each target computer. That converts a forest-wide edge into a per-resource one and dramatically thins the graph, at the price of having to enumerate and grant for every legitimate integration. The other levers are the same ones that work inside one forest: remove cross-forest entries that no longer have an owner, keep foreign principals out of anything privileged, and refuse to place administrative accounts anywhere a foreign principal can reach. ## The wrong answers - *We edited no groups, so nothing changed.* The set of principals eligible to hold rights changed, which is a change to the graph. - *Each domain is its own security boundary.* It is not; the forest is. - *Filtering makes a forest trust safe.* It stops asserted foreign identifiers, not granted rights. - *A one-way trust protects us.* Access flows opposite the trust direction, so trusting them is exactly the direction that exposes you.