Active Directory / Intermediate / Lesson 12

Trusts and cross-domain access

Describe who accepts whose identities, keep resource permission separate, and review cross-forest boundaries without creating or weakening a trust.

About 5 min readContent reviewed 2026-10-26

On this page

Lesson goals

Explain trusting and trusted sides with an explicit access direction.
Distinguish trust path, authentication eligibility, and resource authorization.
Review transitivity, isolation, and dependencies without operational changes.

Name the account side and resource side

A trust establishes an authentication relationship, not an automatic resource grant. In a one-way example, the resource side trusts the account side so identities from the account side can be considered for access on the resource side, subject to other controls. State that sentence explicitly rather than relying on an ambiguous arrow. The reverse direction does not follow automatically. Within one AD DS forest, domain trust relationships are automatic and transitive according to the forest model. External and forest trusts have their own scope and behavior, so a diagram needs the trust type as well as direction.

Require both the modeled path and a resource grant

The complete Python model defines one direct accepting relationship and one resource allow-list. It returns True only when both conditions are met. The second and third tests show that reversing the direction or using an ungranted identity does not satisfy the model. This is not Windows trust validation, SID filtering, selective authentication, Kerberos referral processing, or effective ACL evaluation. It deliberately models no implicit third-forest path. Real forest trusts do not automatically create arbitrary trust between every forest connected through an intermediate forest. Validate actual trust semantics against the applicable Microsoft design and the specific environment.

python Offline directional trust-and-grant model

accepts = {("resources", "accounts")}
resource_readers = {"reader-17"}
def modeled_access(account_forest, resource_forest, identity):
    return (resource_forest, account_forest) in accepts and identity in resource_readers
print(modeled_access("accounts", "resources", "reader-17"))
print(modeled_access("resources", "accounts", "reader-17"))
print(modeled_access("accounts", "resources", "reader-99"))

Expected output

True
False
False

The outputs are True, False, False. No trust is queried or created and no authentication or resource access is attempted.

A trust also depends on naming, connectivity, and policy

Cross-domain or cross-forest authentication can depend on DNS resolution, time, service identity, supported protocol paths, and appropriate network policy. A resource permission can still deny an authenticated identity. Selective authentication and SID filtering address specific trust risks and must not be disabled as a generic troubleshooting step. A separate forest remains a significant boundary, but establishing a trust creates intentional identity relationships that need security ownership. Microsoft Entra Domain Services has managed-service-specific trust capabilities; do not copy those limits or procedures into ordinary AD DS without checking which product is involved. This course creates neither type of relationship.

Document permission and authority beyond the trust label

The contextual plan identifies account and resource forests, the intended one-way access path, and the separately approved resource action. It is not a trust-creation command, secret exchange, or a configuration import. A real design also needs trust type, name routing, authentication restrictions, resource owners, audit requirements, incident handling, and a removal plan. Do not treat a trust as a shortcut around application authorization. A merger or partner scenario may require a narrow set of resource grants rather than broad administrator equivalence across organizations. State exclusions so reviewers can test that an unrelated identity or reverse request remains denied.

json Non-runnable cross-forest access design

{"account_forest":"accounts.example.test","resource_forest":"resources.example.test","intent":"resource_side_accepts_account_side_identities","resource_action":"read-course-archive","reverse_access":"not_implied","state":"architecture_review"}

The record states one intended direction and a separate resource action. It establishes no trusted-domain object, secret, or permission.

Test allowed, denied, reverse, and removal cases

An authorized isolated trust test needs a valid account, the intended resource, explicit permission, and negative cases outside the agreement. Verify actual authentication and resource decisions separately, including reverse-direction denial and name-routing edge cases. Existing sessions and cached authorization can influence removal timing, so a trust-removal plan needs more than deleting a diagram edge. Preserve approved evidence without collecting passwords or trust secrets. A local Boolean model cannot validate a production trust. When a cross-boundary request fails, identify whether discovery, authentication routing, restrictions, or the resource policy is responsible before changing the relationship.

Common errors and fixes

Trust existence is assumed to grant every resource.

Why it happens: Authentication relationships were confused with authorization.
How to fix it: Review explicit resource permissions and restrictions.
Prevent it next time: Test authenticated-but-denied identities.

A one-way relationship is read in reverse.

Why it happens: The diagram omitted trusting and trusted roles.
How to fix it: Write which side accepts whose identities in words.
Prevent it next time: Include a reverse-direction negative test.

A third forest is assumed reachable through any intermediate trust.

Why it happens: Different transitivity scopes were generalized incorrectly.
How to fix it: Review the exact trust type and allowed paths.
Prevent it next time: Document explicit boundaries and unsupported routes.

Check your understanding

1. Add reader-99 to the model allow-list. Which result changes and which direction remains denied?

Show worked solution

The third result becomes True because the declared direct accepting path already exists and the resource condition is now satisfied. The reverse request remains False because no reverse relationship was modeled. This is only a local logic result; actual authorization, trust restrictions, group/token state, and connectivity remain outside the test.

2. A user authenticates across the intended boundary but receives access denied from the archive. Why is recreating the trust an unsupported first repair?