How to Configure and Secure Active Directory Trusts

What Are Active Directory Trusts

Active Directory trusts let a domain controller in one domain vouch for the identity of an account authenticated in a different domain or forest. Internally, each trust is stored as a Trusted Domain Object (TDO) that records the trusted domain's name, direction, transitivity, and a shared secret — the trust password — used to protect authentication traffic that crosses it. Active Directory trusts are what make a multi-domain forest usable: without them, every domain would be an isolated authentication island with no way to reference users or groups from anywhere else.

A trust by itself grants no access. It only extends the authentication path — whatever the requesting account can actually reach on the other side is still governed by ACLs, group membership, and delegation settings. That said, a badly configured trust widens the blast radius of a compromise on either side, which is why trust configuration deserves the same discipline as any other Tier 0 change.

Trust Types and Transitivity

Not every trust behaves the same way. Two properties decide how far a trust actually reaches: direction (which side's users can authenticate to the other) and transitivity (whether the trust extends implicitly to domains the trusted side itself trusts).

Two consequences matter for hardening:

• Transitivity chains. A transitive forest trust does not stop at the forest root — it extends to every domain inside that forest. Trusting one forest means trusting every domain administrator in it, not just the team that requested the integration.
• Direction limits exposure. A one-way trust where domain A trusts domain B lets B's users authenticate into A, but not the reverse. Wherever the business need is one-directional, configuring a two-way trust "to be safe" only adds an authentication path nobody asked for. TRUST_BIDIRECTIONAL in the EtcSec catalogue flags every two-way external, forest, or cross-tree trust (parent-child trusts are excluded, since those are bidirectional by design) — a configuration signal to review, not a determination that traffic only flows one way in practice.

How to Configure a Secure Trust Step by Step

The steps below focus on external and forest trusts — the cases that need deliberate hardening. Parent-child and tree-root trusts are created automatically by the domain and forest promotion process and inherit forest-wide defaults; SID filtering does not apply to them by design, because SID history between domains in the same forest is expected.

Step 1 — Plan the Trust Before You Create It

Write down, before opening any console: which side initiates authentication, whether it needs to be one-way or two-way, which resources the trusted side actually needs to reach, who owns the relationship, and a review date. A trust with no owner and no review date is the one still open five years after the project that requested it ended.

Step 2 — Create the Trust

Create the trust from the Active Directory Domains and Trusts console (New Trust Wizard), or non-interactively with netdom:

netdom trust TrustingDomain /domain:TrustedDomain /add /twoway /userD:AdminAccount /passwordD:*

Drop /twoway for a one-way trust — match it to what Step 1 actually requires, not to what's fastest to click through.

Step 3 — Restrict Trust Encryption to AES

New trusts should never be left on the encryption default. Check the interdomain trust account's msDS-SupportedEncryptionTypes attribute and set it to AES-only (0x18) once every system authenticating across the trust supports AES:

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Set-ADObject $trustDN -Replace @{'msDS-SupportedEncryptionTypes' = 24}

An undefined attribute is not a safe default to assume either way — Microsoft's own guidance notes that AES is supported by default for domain controllers, read-only domain controllers, and trusts only once the deploying DC is patched for the 2022 Kerberos RC4 changes, and a downlevel or never-touched trust can still negotiate RC4. TRUST_AES_DISABLED fires whenever the attribute doesn't report AES support, including when it is simply unset. TRUST_RC4_ONLY is narrower: it only fires when the trust explicitly reports RC4 support without AES, so an attribute that is merely undefined will not trip it.

Step 4 — Enable SID Filtering (Quarantine)

SID filtering is on by default for new external and forest trusts, but it is routinely turned off during migrations that depend on sIDHistory and then never turned back on. Confirm it explicitly:

netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

TRUST_SID_FILTERING_DISABLED flags any external or forest trust where this is off. Do not toggle it blindly — if a migration currently depends on SID history to preserve access, quarantine will break that access until the migration completes.

Step 5 — Scope Selective Authentication

Selective authentication turns "every authenticated user on the trusted side can attempt to reach anything on this side" into a named allow list. Enable it on the outgoing side of the trust, then grant the Allowed to Authenticate extended right only on the specific computer objects the trusted-side accounts genuinely need:

Get-ADTrust -Filter * | Select-Object Name, Direction, SelectiveAuthentication

TRUST_EXTERNAL_NO_SELECTIVE_AUTH fires when an external trust has no selective authentication configured — the single most common gap on trusts set up for a one-off partner integration.

Step 6 — Validate the Trust

Confirm the trust behaves the way Step 1 intended before calling the change done:

Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

Then force a real authentication attempt across the trust and read back the negotiated encryption type with klist. Configuration state and what actually negotiates on the wire can diverge if a downstream GPO or a legacy member overrides the trust's own setting.

Detection

Trust creation and modification are logged events, not silent changes — if trust drift is only showing up in a periodic audit instead of an alert, the logging pipeline is the gap, not the visibility.

A single event proves very little on its own — a 4716 that flips SidFilteringEnabled off is routine during a planned migration and alarming everywhere else. Alert on the event, then check it against the change ticket.

Remediation and Hardening Checklist

1. Inventory every trust with Get-ADTrust -Filter * and record an owner, business justification, and review date for each.
2. Match direction to actual need — do not run a two-way trust where authentication only ever flows one direction.
3. Enable SID filtering on every external and forest trust that is not actively mid-migration.
4. Scope selective authentication to the specific systems the trusted side needs, not the whole domain.
5. Move to AES-only encryption once every authenticating system supports it.
6. Remove trusts with no current owner or business need rather than leaving them "documented" indefinitely.

For the full checklist with PowerShell for every check and the compliance mapping, see Active Directory Trust SID Filtering Selective Authentication Audit. For the attack narrative these controls defend against, see Active Directory Trust Attacks: From Child Domain to Forest Root.

Trust Lifecycle: Bidirectional, Transitive, and Inactive Trusts

Trusts are easy to create and easy to forget. Three catalogue findings target exactly that lifecycle gap:

• TRUST_BIDIRECTIONAL — flags every two-way trust outside of parent-child by configuration, regardless of observed usage. If the business need is one-directional, narrowing it to one-way removes an authentication path with no loss of function.
• TRUST_FOREST_TRANSITIVE — a forest trust inherits every domain inside the trusted forest, not just the domain that requested the integration. Before approving a forest trust, review the trusted forest's own domain list and administrative hygiene, not just the resource the requester needs.
• TRUST_INACTIVE — a trust whose inter-domain password hasn't rotated in over 180 days. Windows auto-rotates a live trust's password roughly every 30 days, so a stale pwdLastSet is a proxy for an abandoned trust nobody maintains rather than a direct measure of authentication traffic. An inactive trust that nobody uses is still a live authentication path that nobody is watching. If the business need ended, remove the trust through the normal change process rather than leaving it "just in case."

None of these three require a compromise to matter — they are configuration and lifecycle hygiene issues that shrink the attack surface before an incident, not after one.

How EtcSec Detects This

EtcSec reads each Trusted Domain Object's trustAttributes bitmask and the interdomain trust account's msDS-SupportedEncryptionTypes directly — the same properties Get-ADTrust and Get-ADObject expose above. It flags TRUST_SID_FILTERING_DISABLED, TRUST_EXTERNAL_NO_SELECTIVE_AUTH, TRUST_BIDIRECTIONAL, TRUST_FOREST_TRANSITIVE, TRUST_INACTIVE, TRUST_RC4_ONLY, and TRUST_AES_DISABLED against every trust in the environment, with findings linked to the specific trust object so remediation targets the exact command needed.

Related Reading

For the attack chain these controls defend against, see Active Directory Trust Attacks: From Child Domain to Forest Root. For the deep-dive audit checklist on SID filtering, selective authentication, and encryption, see Active Directory Trust SID Filtering Selective Authentication Audit. Trust password rotation is covered in krbtgt Password Rotation, Trust Account, Domain Controller Machine Password, and delegation risk that often rides across a trust boundary is covered in Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse. For where trust review fits into a full environment audit, see Audit Active Directory Security: What to Review First and How to Prove Remediation.

Primary References

• Forest Design Models
• netdom trust command
• MS-PAC: SID Filtering and Claims Transformation
• Event ID 4706 — A new trust was created
• Event ID 4716 — Trusted domain information was modified
• Event ID 4769 — A Kerberos service ticket was requested
• Detecting and remediating RC4 usage for Kerberos
• Securing domain controllers against attack