Every Active Directory trust lets accounts from another domain or forest authenticate into yours, so a compromise on the trusted side becomes a route into the trusting side unless the trust is deliberately narrowed. MITRE D3FEND names the countermeasure Domain Trust Policy (D3-DTP) and defines it as "Restricting inter-domain trust by modifying domain configuration." It sits under the Isolate tactic as a child of Access Policy Administration, next to Local File Permissions, User Account Permissions and User Group Permissions. D3FEND's record is short, so this card adds the practical settings that do the restricting: removing unneeded trusts, one-way rather than two-way direction, SID filtering, selective authentication and trust change monitoring. It is for Active Directory engineers and identity security teams; the wider trust design is in the Active Directory Trusts and SID Filtering Guide.
Key takeaways
- D3FEND's data is thin. D3-DTP has a one-line definition and a single Microsoft reference on forest trusts; it says nothing about specific settings. The settings below are NHI Mgmt Group's interpretation of "restricting inter-domain trust", drawn from Microsoft documentation.
- The ATT&CK link is discovery, not abuse. The D3FEND ontology says D3-DTP restricts Directory Service and Domain Account discovery (T1087.002); the D3FEND site infers System Owner/User Discovery (T1033). The techniques defenders usually associate with trusts, such as T1482 Domain Trust Discovery, T1484.002 Trust Modification and T1134.005 SID-History Injection, are not D3FEND mappings.
- Access flows against the trust. In a one-way trust, users in the trusted domain reach resources in the trusting domain, not the reverse. Getting direction wrong is the most common design error.
- Selective authentication is the strongest restriction short of removal. Users from the other forest cannot get a service ticket for a computer unless they hold the Allowed to Authenticate permission on that computer object.
- Trust changes must alert. Domain controllers record trust creation as event 4706 and trust changes as event 4716 under Audit Authentication Policy Change; an unplanned trust change is an incident.
D3-DTP at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DTP (d3f:DomainTrustPolicy) |
| Tactic | Isolate |
| Parent technique | Access Policy Administration (siblings: Local File Permissions, User Account Permissions, User Group Permissions) |
| Digital artefacts | Directory Service (D3FEND relation: restricts Directory Service); the ontology also states it restricts T1087.002 Domain Account discovery |
| D3FEND reference | Microsoft: How trust relationships work for resource forests in Azure Active Directory Domain Services (now Microsoft Entra Domain Services) |
| Related ATT&CK mitigation | M1015 Active Directory Configuration (D3FEND lists D3-DTP as related) |
| What it changes | Which external domains are trusted, in which direction, which SIDs cross, and which accounts may authenticate to which computers |
| Main limitation | Does not help inside a forest: every domain in a forest has two-way transitive trusts, so the forest is the security boundary |
How it works
Microsoft's documentation, D3FEND's reference, sets out the mechanics. Before authentication can cross a trust, Windows checks whether the requested domain has a trust relationship with the account's domain. With Kerberos, the client's domain controller issues referrals along the trust path until it reaches the domain holding the resource, and denies sign-in if no transitive path exists. With NTLM, the resource's domain controller passes the credentials to the account's domain through pass-through authentication over a direct or transitive trust. Trust passwords are changed every 30 days, initiated by the trusting domain's PDC emulator.
Restricting a trust therefore means narrowing one of four things:
- Existence: a trust that is no longer needed is removed. This is the only restriction that removes the path entirely.
- Direction and transitivity: a one-way trust lets users in the trusted domain reach the trusting domain and not the reverse. A forest trust is transitive between two forests but is not extended to a third; an external trust is non-transitive.
- What identities carry across: SID filtering is set on all trusts by default and removes SIDs that do not come from the trusted domain, which blocks abuse of attributes such as sIDHistory. SID filter quarantining is the stricter form for external trusts. Microsoft's guidance says quarantining should not be applied to forest trusts or intra-forest trusts.
- Who may authenticate where: selective authentication on an external or forest trust tags users from the other organisation with the Other Organization SID, and the resource domain controller issues a service ticket only if the user has the Allowed to Authenticate permission on the target computer object.
The same documentation shows the relevant Netdom trust switches: /quarantine for SID filter quarantining on external trusts, /enablesidhistory for allowing SID history across forest trusts (which weakens security), and /SelectiveAuth for selective authentication, run from the trusting side.
Where identity fits
Trusts are often kept alive for service accounts rather than people: a backup server, a migration tool or an application in one forest that reads resources in another. Those accounts are the reason two-way trusts survive long after a merger. Selective authentication lets you grant Allowed to Authenticate to the specific service account on the specific server instead of keeping the whole trust open. Microsoft's guidance notes that for Kerberos, if the service runs as a domain service account, the permission is granted on that account; for NTLM it is granted on the computer account. Build the inventory first with How to build a service account inventory from Active Directory.
ATT&CK techniques and D3-DTP
Relationship type: one ontology assertion and one inferred relation. The D3FEND ontology file states D3-DTP restricts T1087.002. The D3FEND site (knowledge graph 1.6.0, checked November 2026) shows a single inferred and experimental relation through the Directory Service artefact. Other rows are NHI Mgmt Group's view and are labelled as such.
| ATT&CK ID | Technique | Source | How trust restriction helps |
|---|---|---|---|
| T1087.002 | Domain Account (Account Discovery) | D3FEND ontology: restricts | Selective authentication and removed trusts limit which foreign accounts can query the directory |
| T1033 | System Owner/User Discovery | D3FEND site: inferred via Directory Service | Same effect, weaker link |
| T1482 | Domain Trust Discovery | NHI Mgmt Group view | Fewer trusts means less to discover and fewer paths to map |
| T1134.005 | SID-History Injection | NHI Mgmt Group view | SID filtering strips foreign SIDs at the trust boundary |
| T1484.002 | Trust Modification | NHI Mgmt Group view | Not prevented by policy; detected by events 4706 and 4716 |
| T1078.002 | Domain Accounts | NHI Mgmt Group view | Selective authentication limits where a compromised foreign account can log on |
For the attacker side see MITRE ATT&CK T1482 Domain Trust Discovery, T1087 and T1069 Account and Permission Group Discovery Defensive Guide and the MITRE ATT&CK T1484 Domain or Tenant Policy Modification Guide.
Where it is implemented
| Setting | Applies to | Effect | Trade-off |
|---|---|---|---|
| Remove trust | Any trust | Removes the authentication path | Breaks any remaining cross-domain dependency |
| One-way instead of two-way | External and forest trusts | Access only from trusted to trusting side | Requires knowing which side genuinely needs access |
| SID filtering (default) | All trusts | SIDs not from the trusted domain are removed | Breaks migrations that rely on sIDHistory until they finish |
| SID filter quarantining | External trusts | Only SIDs from the trusted domain cross | Microsoft advises against it on forest and intra-forest trusts |
| Selective authentication | External and forest trusts | Allowed to Authenticate needed per computer object | Administrative effort; every new server needs explicit grants |
| Trust attribute 0x200 (no TGT delegation) | Cross-organisation trusts | Shown in trust events as CROSS_ORGANIZATION_NO_TGT_DELEGATION | Breaks services that rely on unconstrained delegation across the trust |
| Entra Domain Services forest trust | Managed domains | Up to five one-way outbound forest trusts to on-premises forests; two-way trusts shown as preview | Feature status changes; check the current documentation |
The live Active Directory Trusts and SID Filtering Guide covers trust design in depth, and the Active Directory Domain and Forest Migration Security Guide covers sIDHistory during migrations.
Implementation steps
- Inventory every trust. In each forest, list trusts with type, direction, transitivity, attributes and SID filtering state, using Active Directory Domains and Trusts or read-only Netdom and Nltest queries. Record the business owner and the accounts that use each one.
- Measure real use. Collect cross-trust Kerberos and NTLM authentications for 30 to 60 days (an example window, not a standard) to see which accounts and servers depend on each trust.
- Remove what is unused. Disable or delete trusts with no traffic and no owner, after notifying owners.
- Narrow direction. Convert two-way trusts to one-way where access is only needed in one direction.
- Confirm SID filtering. Check that SID filtering is enabled on every trust and that SID history is not allowed across forest trusts unless a migration is active and time-boxed.
- Pilot selective authentication. On one trust, grant Allowed to Authenticate on the computer objects the foreign accounts need, then enable selective authentication from the trusting side. Watch for failures and add missing grants.
- Turn on trust auditing. Enable Audit Authentication Policy Change on domain controllers and alert on 4706, 4707 and 4716.
- Roll back if needed. Selective authentication and direction changes are reversible settings; keep the pre-change trust configuration recorded so it can be restored quickly if a critical dependency breaks.
How to verify it works
- Configuration review: quarterly, compare the live trust list and attributes with the approved register. Any new trust, any two-way trust without justification and any trust with SID filtering disabled is a finding.
- Event check: decode the Trust Attributes field in 4706 and 4716 events (convert the decimal value to hexadecimal) and confirm the flags match the approved design, for example 0x4 QUARANTINED_DOMAIN on external trusts.
- Negative test: from a test account in the trusted forest without Allowed to Authenticate, attempt to access a server in the trusting forest; it must fail.
- Noise filter: 4716 events with the subject ANONYMOUS LOGON reflect automatic trust password resets and are expected, according to Microsoft; exclude them from the change alert rather than suppressing the event.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Trusts with a named owner and documented purpose | 100% | Unowned trusts are never removed |
| Trusts with SID filtering enabled | 100%, with time-boxed migration exceptions | Blocks SID history abuse |
| External and forest trusts using selective authentication | Rising each quarter | Limits foreign accounts to named computers |
| Unplanned 4706 or 4716 events investigated | 100% within one business day | Trust changes are a known persistence and escalation path |
| Two-way trusts without justification | Zero | Direction is the cheapest restriction |
Limits, bypasses and failure patterns
- Treating a domain as a boundary: domains within one forest trust each other two-way and transitively. Trust policy cannot isolate a child domain from a compromised forest; separate forests are needed.
- Migration settings left on: SID history allowed across a forest trust for a migration and never turned off.
- Selective authentication with blanket grants: granting Allowed to Authenticate to Authenticated Users or on every computer object restores the open trust.
- Trusting a weaker forest: a trust's security depends on the trusted side. Domain or enterprise admins in a trusted forest can attack a trusting forest if SID filtering is off.
- No alert on trust change: attackers with high privilege can add or modify trusts (T1484.002). Without 4706 and 4716 alerting, the change is silent. Federated trust abuse in cloud tenants follows the same pattern; see the Golden SAML and Federation Trust Abuse Defence Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 Access Enforcement, AC-20 Use of External Systems | Enforcing which external domains and accounts gain access |
| NIST SP 800-53 Rev 5 | CM-6 Configuration Settings, CM-3 Configuration Change Control | Trust settings as controlled configuration |
| NIST SP 800-53 Rev 5 | AU-12 Audit Record Generation, SI-4 System Monitoring | Trust change events and alerting |
| NIST CSF 2.0 | PR.AA-05, PR.PS-01 | Access permissions managed by policy; configuration management |
| MITRE ATT&CK mitigation | M1015 Active Directory Configuration | See M1015 Active Directory Configuration |
| MITRE D3FEND | Access Policy Administration, D3-DTP | Parent and technique; see the MITRE D3FEND Access Policy Administration Implementation Guide |
Practitioner checklist
- Keep a register of every trust with owner, purpose, direction, attributes and dependent accounts.
- Remove trusts with no traffic and no owner.
- Use one-way trusts wherever access is only needed in one direction.
- Confirm SID filtering on every trust; time-box any SID history exception.
- Use selective authentication on external and forest trusts, granting Allowed to Authenticate per computer or service account.
- Alert on events 4706, 4707 and 4716, excluding automatic trust password resets.
- Treat the forest, not the domain, as the security boundary.
Standards and references
- MITRE D3FEND: Domain Trust Policy (D3-DTP)
- Microsoft Learn: How trust relationships work for forests in Active Directory
- Microsoft Learn: Security considerations for trusts
- Microsoft Learn: Event 4706, a new trust was created to a domain
- Microsoft Learn: Event 4716, trusted domain information was modified
- MITRE ATT&CK: T1482 Domain Trust Discovery
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: D3-LFP Local File Permissions · Active Directory Trusts and SID Filtering Guide · Active Directory and Entra ID Hardening Guide · MITRE ATT&CK T1482 Domain Trust Discovery · MITRE D3FEND Access Policy Administration Implementation Guide · MITRE D3FEND Guide