Federation and Trust Guide: AD Trusts and Cross-Tenant Access

Every trust relationship lets identities you do not manage reach resources you do, so a compromise on the trusted side becomes your compromise unless the trust is scoped, filtered and watched. Most organisations carry decades of trust debt: Active Directory domain and forest trusts left over from mergers, federated domains pointing at old identity providers, Entra ID tenants connected for collaboration, cloud roles that trust partner accounts, and workloads that trust external token issuers. This guide covers how each trust type works, the controls that limit it (SID filtering, selective authentication, cross-tenant access settings, external IDs, federated credential matching), how attackers abuse trusts for privilege escalation and persistence, and how to inventory, tighten and monitor them. It is written for directory, identity, cloud platform and detection engineers.

Key takeaways

• The forest is the security boundary, not the domain. Microsoft states that domain owners "cannot prevent a malicious domain owner from controlling their services and accessing their data" inside the same forest.
• Trust and access flow in opposite directions. The trusting side holds the resources and carries the risk, so it is the trusting side that must filter, scope and log.
• Federated domains are tier-zero configuration. An attacker with Global Administrator rights can add a federated domain or signing certificate and then sign in as any user, bypassing MFA.
• Cross-tenant defaults are open for B2B collaboration. All internal users can collaborate with any external Entra tenant by default; tighten defaults and allow partners explicitly.
• Every trust needs an owner, an expiry review and an alert. Trusts outlive the projects that created them, and nobody notices a new or changed trust unless it raises an alert.

The domain trust model

A trust relationship is an authentication path between two security domains. It has a trusting side, which holds resources, and a trusted side, which holds accounts. Microsoft's example: in a one-way trust where Forest 1 is trusted and Forest 2 is trusting, "Members of Forest 1 can access resources located in Forest 2", but not the reverse. A two-way trust is simply two one-way trusts in opposite directions. A transitive trust extends to domains the trusted domain itself trusts; a non-transitive trust stops at the two parties.

Microsoft's archived design guidance is explicit that "the forest is the security boundary for Active Directory" and that forest owners can control services and data in any domain. Read the domain trust model as one forest, one trust zone: business units that must be isolated need separate forests, not separate domains.

How a cross domain trust path works

When a user requests a resource in another domain, the domain controller computes a trust path. For Kerberos, each KDC either refers the client to the target domain if it is trusted directly, refers it to the next domain along a transitive path, or denies the sign-in. NTLM follows the same logic using pass-through authentication through Net Logon. Each trust is stored as a Trusted Domain Object (TDO) in the System container and replicated to the global catalog. Forest trust TDOs record the name suffixes and SID namespaces used to route requests.

• Trust passwords: both sides share a trust password stored in the TDO. The trusting domain's PDC emulator changes it every 30 days, twice for a two-way trust because it is two one-way trusts. A trust account is effectively a non-human identity; its secret matters as much as a service account password.
• Trust relationship persistence: trusts survive reorganisations, failed migrations and divestments.

SID filtering, SID history and selective authentication

• SID history: an attribute that stores the former SIDs of moved users and groups so they keep access to old resources during a migration. It is legitimate during migrations and dangerous afterwards.
• SID history abuse: ATT&CK T1134.005 SID-History Injection. An attacker with Domain Admin rights or equivalent adds privileged SIDs, such as those of Enterprise Admins in another domain, to an account's SID history so they appear in its access token.
• SID filtering: on interforest trusts, the trusting side removes any SID in the incoming authorisation data that does not belong to the trusted domain. Microsoft describes its purpose as preventing administrators in a trusted forest from granting themselves elevated rights in a trusting forest. SID filter quarantining, the strictest form, is enabled by default on new external trusts and cannot be turned off for newly created external trusts. Forest trusts use standard SID filtering instead of quarantining.
• Selective authentication: by default a forest trust uses forest-wide authentication, so every trusted user can attempt to authenticate to every computer. With selective authentication, a trusted user can only obtain a service ticket for a computer whose AD object grants them the "Allowed to Authenticate" permission. It is enabled from the trusting side.

ATT&CK mitigation M1015 for SID-History Injection is to clean up SID history once migrations finish, apply SID filtering to forest and external trusts, keep SID history disabled on forest trusts, and keep quarantining on external trusts. Microsoft warns that users who rely on SID history for access lose it when filtering is enforced, so inventory SID history use before tightening.

Domain trust discovery and the trust relationship exposure window

Attackers map trusts early. ATT&CK T1482 Domain Trust Discovery describes enumeration through Windows APIs such as DSEnumerateDomainTrusts, .NET methods such as GetAllTrustRelationships, and LDAP queries for trust objects, to find paths for SID history injection, pass the ticket and Kerberoasting. Discovery cannot really be prevented; make discovered trusts less useful and detect unusual enumeration from non-administrative hosts.

The trust relationship exposure window is the period during which a trust grants more than its current business purpose needs. It starts when a project ends but the trust stays, or when a partner's security posture changes and yours does not. Shorten it by giving each trust an owner, a stated purpose, a review date and a decommissioning trigger such as migration completion or contract end. ATT&CK mitigation M1047 sums it up: "Map the trusts within existing domains/forests and keep trust relationships to a minimum." See the Lateral Movement Guide.

Federated trust and the federated domain backdoor

A federated trust lets one identity system accept assertions signed by another. In Entra ID, a federated domain sends users of that DNS domain to an external IdP, such as AD FS, and accepts the SAML or WS-Federation tokens it signs. The federated trust chain is every party whose key or configuration can mint a token that your applications accept; the federated trust path is the route a token takes from issuer to application.

• Malicious federated domain: ATT&CK T1484.002 Trust Modification covers adding a federated domain, switching a domain from managed to federated, or adding an attacker's signing certificate to an existing federated trust domain. In ATT&CK v20 it sits under Defense Impairment and Privilege Escalation.
• The backdoor in practice: Microsoft reported that Storm-0501 used Global Administrator access to create "a persistent backdoor access for later use by creating a new federated domain in the tenant", converting a managed domain or adding its own certificate, so it could issue SAML tokens to "impersonate any user in the organization and bypass MFA". The SolarWinds compromise showed the same pattern with changed federation trust settings.
• Federated IdP added to an SSO tenant: MITRE records Scattered Spider adding a federated identity provider to a victim's SSO tenant and enabling automatic account linking.

Controls for federated domains:

• Restrict token validation: Microsoft recommends setting the validatingDomains property of federatedTokenValidationPolicy to all, which blocks SAML sign-in attempts against non-federated domains such as the tenant's onmicrosoft.com domain.
• Do not trust federated MFA claims by default: set federatedIdpMfaBehavior to rejectMfaByFederatedIdp unless a third-party MFA provider genuinely performs MFA.
• Reduce Global Administrators: domain federation changes need high privilege, so privileged identity management, phishing-resistant MFA and protected actions directly shrink this risk. See the Active Directory and Entra ID Hardening Guide.
• Retire federation you do not need: converting federated domains to managed authentication removes an entire class of signing key risk.

Entra ID cross-tenant access

Cross tenant access settings control how your Entra tenant collaborates with other Entra tenants. Outbound settings govern your users' access to other organisations; inbound settings govern external users' access to yours. Organisational settings for a named partner override the defaults.

Choosing between them

• Use B2B collaboration for most partner access, because you get a user object you can put through access reviews and Conditional Access. See the Third-Party Access Guide.
• Use B2B direct connect only for named partners who need Teams shared channels, scoped to specific users and groups. Activity in an external shared channel leaves no audit log in the user's home tenant, so the resource tenant owns monitoring.
• Use cross tenant synchronisation only between tenants your organisation controls. Microsoft says it is "intended for use within an organization", runs on a 40-minute cycle, and leaves previously synced users in place if the relationship is severed, so clean-up is a separate step.
• Trust settings: accept MFA and compliant-device claims only from partners whose controls you have assessed; trusting MFA means a user who completed MFA at home is not challenged again in your tenant.

Leakage, exposure and blast radius

Cross tenant leakage runs outbound: staff signing in to an unknown external tenant and moving data there. Tenant restrictions control which external tenants users can sign in to from managed devices, and Microsoft notes they are independent of other cross-tenant settings. Cross tenant exposure runs inbound: external identities with standing access to your resources. The cross tenant blast radius is everything an attacker can reach in other tenants after compromising one; the Midnight Blizzard breach began in a forgotten test tenant whose OAuth application held access to the corporate environment. Cross tenant account takeover can also come from platform flaws, as the Entra ID actor token flaw showed.

Cloud, cross-cloud and third-party trust relationships

• IAM role trust relationship: in AWS, a role's trust policy names the principals that may assume it. A role that trusts another account without conditions lets anyone who controls that account assume it. AWS notes that a role ARN "isn't a secret", so roles trusted by a vendor should require an sts:ExternalId that is unique per customer and controlled by the vendor, which prevents the confused deputy problem. For AWS service principals, use aws:SourceArn, aws:SourceAccount, aws:SourceOrgID or aws:SourceOrgPaths conditions.
• Finding external trust in AWS: IAM Access Analyzer external access findings report IAM roles and other resources shared outside the zone of trust (your account or organisation), and policy changes are analysed within about 30 minutes. MITRE also suggests service control policies that restrict who can call CreateSAMLProvider or CreateOpenIDConnectProvider, since a new identity provider in an AWS Organization can federate into member accounts.
• Cross cloud trust relationship: workload identity federation lets an Entra app or managed identity trust tokens from GitHub Actions, Kubernetes, Google Cloud, AWS and other issuers. The issuer, subject and audience must case-sensitively match; an over-broad subject (for example any branch of any repository) trusts far more workloads than intended. See the Cloud Workload Identity Guide.
• Third party trust relationship: ATT&CK T1199 Trusted Relationship covers attackers arriving through providers with existing access, including partners with delegated administrator permissions that can give "administrative control over the victim tenant". Mitigations include MFA for every delegated administrator (M1032) and regular review of partner relationships (M1018).

Rolling out a trust review programme

1. Inventory every trust: AD domain and forest trusts with direction, transitivity, SID filtering and authentication scope; federated domains and their signing certificates; external identity providers in each IdP; cross-tenant organisational settings and synchronisation jobs; cloud roles trusting external accounts; federated credentials on apps and managed identities.
2. Assign ownership and purpose: each trust gets a named owner, the business process it supports and a review date.
3. Measure use before changing anything: review sign-in logs and authentication traffic across each trust. Entra cross-tenant sign-in data may only be retained for 30 days, so export it first.
4. Tighten in rings: start with the lowest-risk trusts. For AD, enable selective authentication with Allowed to Authenticate granted to known resource servers, then expand; for Entra, block default inbound or outbound access only after allowing the partners seen in logs. Microsoft warns that changing defaults to block "could block existing business-critical access".
5. Keep a rollback: record each prior setting so a trust can be restored within minutes.
6. Remove and monitor: remove trusts that showed no use, clean SID history from migrated accounts, and put every remaining trust under the alerts below.

Small and large organisations: a single-forest, single-tenant organisation should focus on federation configuration, B2B defaults and vendor role trusts. Organisations with several forests and tenants after acquisitions should prioritise consolidation; every forest or tenant removed is a trust boundary that no longer needs defending.

Detection and measurement

Treat any trust or federation change outside an approved change as a priority incident. See the ITDR Guide.

Metrics

• Owned trusts: percentage of AD trusts, federated domains, cross-tenant partners and external role trusts with a named owner and a review in the last 12 months.
• Scoped forest trusts: percentage of interforest trusts using selective authentication with SID history disabled.
• Residual SID history: number of accounts still carrying SID history after their migration closed (target zero).
• Explicit cross-tenant posture: whether default inbound and outbound settings are restricted, and the number of partners with organisational settings.
• Unexplained external trust: open IAM Access Analyzer external access findings on roles, and federated credentials with wildcard-like subjects.
• Time to review: median time from a trust or federation change event to human review.

Framework mapping

Common failure patterns

• Domains used as security boundaries: a less-trusted business unit placed in a child domain, on the assumption it is isolated, when any domain compromise reaches the forest.
• Migration leftovers: SID history and two-way trusts kept long after a merger completed.
• Unmonitored federation configuration: no alert on new federated domains or signing certificates, the persistence route used by Storm-0501.
• Open cross-tenant defaults: B2B collaboration left open to every tenant and MFA claims trusted from partners nobody assessed.
• Forgotten tenants: test or acquired tenants with apps or synchronisation into production, as in the Midnight Blizzard breach.
• Unconditional vendor role trust: AWS roles trusting a vendor account without an external ID, open to confused deputy abuse.

Practitioner checklist

• Inventory every AD trust, federated domain, external IdP, cross-tenant setting, external role trust and federated credential, each with an owner and review date.
• Treat each AD forest as one security boundary; isolate business units with separate forests, not domains.
• Keep SID filtering on all interforest trusts, keep SID history disabled on forest trusts and clean SID history after migrations.
• Use selective authentication on forest and external trusts with partners or acquired organisations; prefer one-way trusts.
• Set federatedTokenValidationPolicy validatingDomains to all and federatedIdpMfaBehavior to rejectMfaByFederatedIdp where federation remains.
• Restrict default cross-tenant inbound and outbound access after reviewing logs, and allow partners explicitly.
• Limit cross-tenant synchronisation to tenants your organisation owns, and scope B2B direct connect to named users and groups.
• Require sts:ExternalId on roles trusted by vendors and act on IAM Access Analyzer external access findings.
• Alert on events 4706, 4707, 4716 and 4765, Entra federation and CrossTenantAccessSettings changes, and new identity providers in cloud accounts.

Standards and references

• Microsoft Learn: How trust relationships work for forests in Active Directory
• Microsoft Learn: Security Considerations for Trusts
• Microsoft Learn: Cross-tenant access overview
• Microsoft Learn: What is cross-tenant synchronization?
• MITRE ATT&CK: T1484.002 Domain or Tenant Policy Modification: Trust Modification
• MITRE ATT&CK: T1134.005 Access Token Manipulation: SID-History Injection
• AWS: The confused deputy problem
• Microsoft Security Blog: Storm-0501 ransomware attacks expanding to hybrid cloud environments

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Identity Provider and SSO Security Guide · Third-Party Access Guide · Cloud Workload Identity Guide · Lateral Movement Guide