Domain & Forest Trusts
See every trust between your Active Directory domains and forests, whether it lets an attacker who controls one domain escalate into another, and why.
Requires role: Viewer (trust relationships, the domain's Trusts section, and the escalation panel)
Related: Graph Explorer, Relationship Detail Drill-Down, Identity Graph Data Model and Change Simulation, Critical Junctions, Risk Posture Dashboard
Overview
A trust lets accounts from one Active Directory domain sign in to resources in another. Trusts join the domains of one forest (a forest root and its child domains), and they join separate forests (partners, acquisitions, migrations). Some trusts are safe by default. Others let an attacker who takes over one domain forge credentials that the other domain accepts as its most privileged accounts.
GraphnAI reads every domain's trusts on every sync and draws them between domain nodes in the graph. It marks which trusts only describe how your domains are joined, and which are escalation paths from one domain into another. It also shows whether each read of a domain's trusts worked, so a permission problem on your sync account never looks like "this domain has no trusts".
Two ideas come first:
- The security boundary is the forest. By design, every domain in a forest can present the forest root's most privileged group identifiers. Taking over any domain in a forest amounts to taking over the forest root, unless that trust is deliberately locked down (quarantined). GraphnAI draws every trust inside one forest as an escalation, as Microsoft's own guidance describes it.
- A trust between two forests escalates only when its SID filtering is weak. A security identifier (SID) is the value Windows uses to identify an account or group. Most cross-forest trusts filter SIDs correctly by default and never escalate. GraphnAI flags a cross-forest trust only when filtering is off or relaxed, so a healthy trust never buries a real finding.
Prerequisites
- At least one full sync of each domain you want to inspect. After that, every full and delta sync reads its trusts.
- The Viewer role, to browse trusts, read a domain's Trusts section and open the escalation panel.
- No setup. Every Active Directory sync collects trusts, with nothing to turn on.
- Read access to each domain's System container, where trust objects live, for that domain's sync account. Any authenticated account normally has it. See The trust read fails if yours doesn't.
Where to find trust information
Trusts don't have a page of their own yet. They appear in four places in the Graph Explorer:
- The graph. Trust relationships run between domain nodes, styled so you can tell the three kinds apart. See Reading trust relationships on the graph.
- A domain's detail panel. Select a domain node and open its Trusts section for every direction of every trust the domain takes part in.
- The relationship panel. Select a trust relationship to see its details. For an escalation, the panel explains what it means and what to do.
- The boundary overview. The Graph Explorer's default view shows each forest and tenant as a card. It counts cross-forest escalations apart from ordinary cross-boundary permissions, as "{n} trusts let {domain A} escalate into {domain B}". See Graph Explorer for the boundary map.
Reading trust relationships on the graph
To show or hide each kind, select the funnel icon (Show or hide relationship types) in the graph toolbar:
| Toggle | Where in the menu | What it shows |
|---|---|---|
| Domain trusts | Structural | The trust itself: "{trusting domain} trusts {trusted domain}" |
| Trust accounts | Structural | The account each domain uses to authenticate across the trust |
| Trust escalations | The top list | Whether privileges can cross the trust |
Trust lines use the graph's usual visual language. The color names the relationship type. A solid line is in effect, a dotted line isn't observed yet, and an amber diamond mid-line flags the relationship for review.
| Relationship | Line | Color | Meaning |
|---|---|---|---|
| Domain trust | Solid | Light purple | The trust exists. The arrow points at the trusted domain. On its own, this isn't a finding. Most trusts are healthy. |
| Domain trust, quality not yet observed | Dotted | Light purple | Only the trusted side has been read, so its SID filtering can't be confirmed yet. |
| Domain trust, flagged for review | Solid, amber diamond | Light purple | SID filtering is weakened, or the two sides' copies of the trust disagree. |
| Trust account | Solid | Lavender | The interdomain trust account each domain uses to authenticate the other. It only describes structure. |
| Trust escalation, same forest | Solid | Rose | Privileges can cross this trust, and both domains are in one forest. Expected in most multi-domain forests. Knowing it helps you tier your admins correctly. |
| Trust escalation, across forests | Solid, thicker | Rose | Privileges can cross into a different forest. Look at these first. When the graph can't tell which kind an escalation is, it draws the thicker line. |
Trusts that run both ways. Most trusts inside a forest run both ways. When both directions have the same settings, the graph draws one line with an arrowhead at each end, for the domain trust and the trust escalation alike. Two domains that trust each other are then joined by two lines: one for the trust and one for the escalation. On the boundary map, a two-way trust escalation reads "Trust escalation (1 each way)". If the directions differ in any way, each gets its own line, so a weaker direction never hides behind a healthy one. Differences include one side weakened, one side not yet observed, the two sides disagreeing, or a different kind of escalation.
Understanding the three relationship types
Domain Trust
The fact that one domain trusts another, worded "{trusting domain} trusts {trusted domain}". It holds the trust's settings: its kind (within forest, forest, external, Kerberos realm or cloud Kerberos), its SID filtering, whether selective authentication is on, and whether it's transitive. A domain trust isn't a risk finding on its own. Select it to see these settings. Its panel notes that any escalation across it shows as a separate relationship.
Trust Account
An interdomain trust account backs every trust between two Active Directory domains. It's named after the trusting domain, for example DEV$ in the LAB domain, and the two domains' controllers use it to authenticate each other. This relationship only describes structure. GraphnAI never flags the account as stale, weak-password or unused. It's stored like a user account, but it isn't one.
Trust Escalation
An attacker who controls the domain at the tail of the arrow can present credentials that the domain at the head accepts as coming from its privileged accounts. See When a trust escalates for exactly when GraphnAI draws one.
When a trust escalates
Inside one forest, almost every trust escalates, because a domain isn't a security boundary inside its forest. Whoever controls a child domain can forge a credential that carries the forest root's most privileged group identifiers, including Enterprise Admins. The only exception is a quarantined trust, which filters external-style identifiers even within the forest. Quarantine inside a forest is rare, and it's usually a deliberate hardening step.
Across forests, GraphnAI draws an escalation only when SID filtering is weak in one of three ways:
- An external trust with SID filtering turned off (not quarantined).
- A forest trust with SID history allowed. An administrator relaxed the default filtering, often for a migration.
- A Privileged Identity Management (PIM) trust, an administrative forest trust built to let one forest manage another's privileged accounts.
A default forest trust never escalates, and neither does a quarantined one. Two kinds never escalate, whatever their settings:
- A cloud Kerberos trust to Microsoft Entra ID, where an on-premises domain accepts Kerberos tickets from Entra ID.
- A Kerberos realm trust, a trust to a Kerberos system outside Active Directory.
What crosses the trust sets how bad it is. A within-forest or PIM escalation lets the trusting forest's own most privileged group identifiers cross. GraphnAI treats it as reaching the highest risk tier. A relaxed forest trust or an unfiltered external trust lets through only identifiers with a relative ID (RID, the last part of a SID) of 1000 or higher. Those are ordinary accounts and groups. Built-in administrator groups stay filtered. This difference decides how each escalation is ranked and routed for investigation.
Where the settings come from. GraphnAI reads every trust setting from the trusting domain's own copy of the trust, because that side enforces the filtering. If only the trusted side has reported so far, GraphnAI shows "Trust quality not yet observed". It draws no escalation until the trusting domain's own sync confirms it.
The Domain "Trusts" panel
Select a domain node in the Graph Explorer and open its Trusts section. It's the fullest view of a domain's trusts.
Collection states
The section keeps four situations apart, so a failed read never looks like a domain with no trusts:
| State | What it means | What you see |
|---|---|---|
| Not yet observed | GraphnAI has never read this domain's trusts | "Trusts not yet observed. They appear after the next sync of this domain." |
| No trusts | The last read worked and found none | "This domain has no trusts." |
| Read, relationships pending | The last read found trusts, but the analysis that draws them hasn't run since | For example, "2 trusts were read. The relationships appear after the next analysis." |
| Couldn't read | The last read failed | A "Couldn't read trusts." warning with the reason, and "Showing the last successful read from {time}." when an earlier read worked |
A failed read never removes anything from the graph. If a later read fails, the section keeps showing the last good result under the warning, so a passing access problem never looks like a removed trust.
What each row shows
Each direction of a trust is its own row, worded "{trusting domain} trusts {trusted domain}". Select a domain name that's in the graph to focus that domain. A row shows:
- Kind: Within forest, Forest, External, Realm or Cloud Kerberos. Hover for what it means.
- SID filtering: SID filtering: Enforced, Disabled, Relaxed or not applicable. When only the trusted side has reported, it reads Trust quality not yet observed. Hover for what each value does.
- Selective authentication: on, off, not applicable for kinds without it, or not yet observed.
- Transitivity: Transitive or Not transitive, whether the trust reaches past the two domains shown.
- PIM: a badge on a Privileged Identity Management trust.
- Escalation: on a direction that escalates, the kind of escalation.
sid-history-forest-localmeans the trusting forest's own privileged groups can cross.sid-history-rid1000means only accounts and groups with a RID of 1000 or higher can. Hover for the explanation. - Divergence warning: "The two sides of this trust disagree. Showing the trusting domain's settings." This is expected for a short time after a trust is created or removed, until both domains sync. Look into it only if it stays after both have synced since the change.
The top of the section gives the last successful read, as "Last read {time}". Below the rows, "{n} trusts to domains not collected" lists trust partners that no bridge syncs.
The escalation "why" panel
Select a trust escalation on the graph to open a panel that explains it and says what to do. For a two-way escalation (one line with an arrowhead at each end), the panel explains each direction, then gives the fixes once, because both directions share their settings.
- What this means: an explanation for this kind of escalation. A within-forest escalation reads, for example: "Anyone who controls {domain A} can forge sign-in tickets that carry {domain B}'s most privileged group identifiers, including Enterprise Admins. Inside one forest, a domain isn't a security boundary."
- Conditions met: the kind, SID filtering, selective authentication and divergence that make this trust an escalation.
- What to do: the fix for this situation:
- Within one forest: Treat every domain administrator in the forest as Tier 0 (GraphnAI's highest privilege tier) across the whole forest. If you can't trust a domain's administrators with the rest of the forest, move that domain to its own forest.
- A PIM trust: Confirm it's an intended administrative relationship. If it isn't, disable the trust.
- SID history allowed on a forest trust: Disable SID history on the trust unless a migration still needs it.
- An external trust without filtering: Turn on SID filtering (quarantine the trust).
- Selective authentication off on a forest or external trust: Turn it on to limit which accounts can sign in across the trust. This shrinks the blast radius even while the trust stays weak in other ways.
Every fix is a manual change in Active Directory. GraphnAI has no automatic fix for a trust escalation.
Select the domain trust instead of the escalation to see the trust's own settings (kind, filtering, transitivity). A two-way trust reads "{domain A} and {domain B} trust each other".
Reach and boundary escapes
Once a trust escalation exists, GraphnAI answers two separate questions:
- Inside one forest, an escalation widens what an attacker who controls one domain can reach: every other domain in the forest. It never counts as a boundary escape on its own, because the forest is the boundary and the domain sits inside it.
- Across forests, a weak trust counts as a boundary escape. Its severity depends on what can cross. A trust that lets the trusting forest's own privileged groups cross ranks at the highest severity and reaches the top privilege tier. A trust that lets only ordinary accounts and groups cross (RID 1000 and above) ranks high. Either way, the finding goes to a person to investigate, because GraphnAI can't fix a trust for you.
The boundary overview lists cross-forest trust escalations on their own, as "{n} trusts let {domain A} escalate into {domain B}", apart from ordinary cross-boundary permission counts. See Graph Explorer.
Limits:
- A cross-forest escape's severity reflects what kind of identifier can cross. It doesn't measure how much high-value access sits in the other forest. Two relaxed trusts, one into a nearly empty forest and one into a forest full of privileged accounts, rank the same. Read the ranking as "what could cross", and judge the urgency from what you know of the target forest.
- GraphnAI tracks whether selective authentication is on or off for a trust as a whole. It doesn't model which resources selective authentication lets through.
Operational notes
- Trust escalation relationships refresh in the analysis that runs right after each sync.
- If reach analysis (what identities can reach across the graph) is turned off in your environment, trust relationships stop refreshing. They keep their last values rather than disappearing.
- GraphnAI never reads trust key material. Windows doesn't expose it over the directory protocol GraphnAI uses to collect trusts.
Troubleshooting
The trust read fails
The section shows "Couldn't read trusts." with one of these reasons:
- "The sync account couldn't read this domain's trusts. Give it read access to the System container, then sync again." Check that the domain's sync account can browse
CN=Systemlike any other container. Ordinary read access is normally enough. - "The trust search didn't finish. It runs again at the next sync." The read timed out.
The next sync, full or delta, clears the error once the read works. Until then, the section keeps the last successful result, if there is one.
"Trust quality not yet observed"
GraphnAI has seen only the trusted side's copy of the trust. SID filtering and selective authentication can only be confirmed from the trusting side. Sync the trusting domain, the one named first in "{trusting domain} trusts {trusted domain}".
"{n} trusts to domains not collected"
The domain trusts one or more domains that no bridge syncs. To see one in full, add its domain to a bridge. Until then, GraphnAI shows what the domain you do sync says about the trust. It can't confirm the partner's settings or draw a full relationship to it.
A trust disagrees with what you see in Active Directory
Check the row for the divergence warning. If the two sides disagree, that's expected for a short time after a trust is created, changed or removed, until both domains sync. Wait for both to finish a sync and check again. If they still disagree, the trust is set up differently on each side. Look into it in Active Directory.
There's no Select Fire button on a trust escalation
GraphnAI has no automatic fix for trust escalations yet. Every fix in The escalation "why" panel is a manual change in Active Directory.