5.3 Understand and Support Internetwork Trust Architectures
Key Takeaways
- In a one-way trust, the resource domain trusts the account domain: users from the trusted (account) side can be granted access to resources on the trusting (resource) side, not the reverse.
- Two-way trusts are mutual; transitive trusts extend authentication along the path (Active Directory forest trusts are transitive by default); zero trust grants no standing trust from network or domain membership.
- Internet, intranet, extranet, and demilitarized zone (DMZ) are trust zones: the DMZ is a screened subnet for services that must face an untrusted network without sitting beside directory servers.
- Third-party application programming interfaces (APIs), app extensions, and middleware are trust relationships: authenticate the caller, constrain scopes, log, and revoke.
- A transitive Active Directory forest trust is a poor substitute for zero trust because it extends implicit authentication trust across domains unless selective authentication and tight access control lists constrain it.
Trust is a configuration, not a feeling
Knowledge area 2.2 — Understand and support internetwork trust architectures — asks how networks and identity systems decide to believe each other. The Systems Security Certified Practitioner (SSCP) outline names trust relationships (1-way, 2-way, transitive, zero); the internet, intranet, extranet, and demilitarized zone (DMZ); and third-party connections such as application programming interfaces (APIs), app extensions, and middleware.
On an SSCP shift this is Active Directory (AD) forest trusts, site-to-site virtual private networks (VPNs), partner extranets, screened subnets for web farms, and the API key a vendor left in a mobile app. Mis-set trust is how an attacker in a test domain becomes Domain Admin in production, or how a marketing WordPress plugin becomes a beachhead on the directory. Domain 2 is 15% of the exam under the outline effective 1 October 2025; 2.2 is the part that fails in change tickets, not in password policy posters.
Trust relationships: one-way, two-way, transitive, zero
In directory and Kerberos language, "A trusts B" means A will accept authentication assertions from B. Users and groups from the trusted domain can be granted access to resources in the trusting domain. The arrow direction is the exam trap. If scada.example trusts corp.example, plant systems (resource) accept corp identities (account). It does not mean plant admins can log on to headquarters.
| Type | Meaning | Typical use | Risk if mis-set |
|---|---|---|---|
| One-way (1-way) | Resource domain A trusts account domain B. B does not trust A. | Headquarters users access a lab, plant, or partner resource domain | Reverse the arrow and lab admins authenticate into headquarters |
| Two-way (2-way) | Mutual trust | Merged companies that need both directories to consume each other's identities | Doubles the authentication blast radius |
| Transitive | If A trusts B and B trusts C, A trusts C | AD forest trusts are transitive by default inside a forest | A compromised child domain or trusted forest becomes a path into every domain that inherits the trust |
| Nontransitive | Trust does not flow to a third domain | External domain trusts; many realm trusts | Safer default for partners |
| Zero | No implicit trust based on location or domain membership | Zero-trust architecture: authenticate and authorize every request | Requires identity, device, and context on each session — not a missing firewall rule |
Selective authentication on an AD trust (versus forest-wide authentication) is how you keep "A trusts B" from meaning "every B user can enumerate A." Always ask three questions: who is the account domain, who is the resource domain, and does trust transit to domains you never intended?
Kerberos, Lightweight Directory Access Protocol (LDAP), and the secure channel that AD uses to refresh a trust password all have to reach each other for a trust to stay healthy. A trust is not a diagram in Visio; it is ports, time sync, and a secret that rotates. When those fail, users do not "lose permissions" in the access-control list — they fail to authenticate across the trust at all.
Scenario: a broken one-way trust
You support two AD domains: corp.example (accounts, people, multi-factor authentication) and scada.example (plant historians, no internet). Architecture is a one-way trust so scada (resource) trusts corp (account). Plant technicians with corp accounts access historians. A compromised historian must not be able to authenticate as a corp user.
Monday morning those technicians cannot log on to the historian. Event logs on scada domain controllers show trust-relationship failures. nltest and netdom report that the secure channel is broken. Causes you actually see: the trust password (the secret AD rotates on the trust object) expired or was reset from the wrong side; a five-minute time skew broke Kerberos; a firewall change blocked TCP/UDP 88, 389, 445, or 135 between the domains; or someone "cleaned up" and deleted the incoming trust on scada.
Your job is not to make it two-way "so it is more reliable." You restore the intended one-way trust: fix time, restore the ports on the management path, reset the trust password from the correct side, and verify that corp still does not trust scada. Then you document the dependency so the next firewall change request lists the trust ports. Flattening the design into a two-way transitive forest trust so this never happens would let ransomware on a historian chase corp credentials — the opposite of the architecture.
The same pattern appears after mergers. An acquisition domain that was supposed to be a one-way resource trust gets joined as a two-way forest trust because "file shares were easier." Six months later that acquisition's neglected backup server is the beachhead. Direction and transitivity are security controls, not convenience settings.
Internet, intranet, extranet, and DMZ
These are trust zones, not marketing terms.
| Zone | Who uses it | Trust posture | What belongs there |
|---|---|---|---|
| Internet | The public, untrusted | No identity assumed; anything can be hostile | Public Domain Name System, marketing site via a content delivery network; not domain controllers |
| Intranet | Workforce on organizational networks | Historically higher implicit trust; SSCP should still authenticate | File servers, directory, internal apps, print |
| Extranet | Named partners, suppliers, customers | Authenticated third parties with limited reach | Partner portals, dedicated APIs, vendor-managed devices in a constrained cage |
| DMZ (screened subnet) | Services that must face an untrusted network | Compromise expected; east-west tightly limited | Reverse proxies, web front ends, email edge, VPN concentrators, API gateways |
A DMZ is not "the Wi-Fi in the lobby" and not "a firewall." It is a network segment with controlled interfaces: untrusted network ↔ screening device ↔ DMZ hosts ↔ screening device ↔ intranet. Hosts in the DMZ should not use intranet directory credentials in a way that a DMZ breach dumps the hash store. Prefer a dedicated directory or replica with no privileged intranet secrets, jump hosts for administration, and no Server Message Block from the DMZ to domain controllers.
An extranet is about who (partners). A DMZ is about where (screened placement). Partner traffic often lands on a DMZ-hosted portal that then calls internal systems through a broker. Do not put partner laptops on the same virtual local area network (VLAN) as payroll. Do not call a flat "guest" SSID a DMZ because the marketing site shares its switch.
Placement questions on the exam are usually this direct: a partner-facing API gateway that must be reachable from the internet does not sit next to domain controllers on the intranet, and it does not sit on an unfiltered internet connection. It sits in a screened subnet with tightly controlled paths inward — application traffic to a broker, not interactive remote desktop to the directory.
Third-party connections: APIs, app extensions, middleware
Modern trusts are not only forest trusts. They are connections you enable on purpose.
APIs. A SaaS billing system calls your identity API; a mobile app calls a payment API. Authenticate the caller — OAuth2 client credentials, mutual Transport Layer Security, signed requests — authorize scopes, rate-limit, and log. An API key committed to a public repository is a two-way trust with the entire internet. Rotate keys, bind them to source addresses or certificates where you can, and treat a new API consumer as a change with security impact analysis.
App extensions. Browser add-ons, SaaS plugins, low-code connectors, and copilot-style extensions that inherit the user's session. An extension with mail.readwrite is a privileged client. Allowlist publishers, review scopes, and do not grant tenant-wide Directory.ReadWrite.All to a weekend integration. Extensions are transitive in spirit: they ride the user's authentication into every object that user can touch unless you constrain them.
Middleware. Enterprise service buses, API gateways, identity-aware proxies, and integration-platform tools that sit between apps and data. Middleware that decrypts Transport Layer Security to inspect traffic becomes a trust anchor. Harden it, limit who can add routes, and treat a new connector the way you would treat a new forest trust: who authenticates whom, what can transit, and how you revoke it.
Each of these is a trust relationship. Ask the same questions you ask of an AD trust. Which side accepts authentication from the other? Is it transitive — can the plugin reach every API the user can? What happens Friday afternoon when you disable the client?
Zero trust versus transitive AD forest trusts
Zero trust is the opposite of "inside the forest means trusted." It assumes breach, authenticates every request, authorizes on identity, device health, and context, and grants the least privilege for that session. Network location — intranet, VPN, VLAN — is a signal, not a permit. A user who passed MFA last week does not get a standing pass to every share this week.
A transitive AD forest trust says the opposite: once you are authenticated in a domain the forest trusts, Kerberos will help you into resources across that trust path unless administrators used selective authentication and tight access control lists — and many do not. Forest-wide authentication plus Domain Users on a share is implicit standing trust. That is convenient. It is also how a neglected child domain becomes every other domain's incident.
You can use AD inside a zero-trust program. You do not equate them. Tighten trusts (prefer one-way, nontransitive, selective authentication), put partner and internet-facing systems in a DMZ, authenticate APIs and plugins as first-class identities, and still verify user plus device on each sensitive request. A one-way trust that broke on Monday is painful. A transitive two-way forest trust to a neglected acquisition domain is how Monday becomes a multi-domain incident.
When a stem shows a partner, an API, or a second forest, name the zone, name the trust direction, and refuse "just join them to the intranet" as the architecture. Support the trust you meant to build — including the unglamorous work of ports, time, certificate or trust-password rotation, and a revocation path — and do not widen it into transitivity because troubleshooting was hard.
In a one-way Active Directory trust, Domain A (resource) trusts Domain B (account). What can users in Domain B do?
Where should an organization typically place a partner-facing application programming interface gateway that must be reachable from the internet but must not sit on the same segment as internal directory servers?
Why is a transitive Active Directory forest trust a poor substitute for a zero-trust architecture?