Trusts and cross-forest access

Name the account side and the resource side

If domain R trusts A, R accepts authentication from A. Accounts in A can then be considered for access to resources in R. They still need the relevant resource permissions. A trust does not grant those permissions automatically.

Write down which domain trusts which before using the words incoming and outgoing. Those labels depend on which side you’re looking at.

An external trust connects domains. A forest trust provides routing between forests, with additional namespace information. Do not assume that a forest trust makes every other trust of either forest transitively usable.

For example, an account in accounts.example.com accesses \\fs1.resource.contoso.com\Finance. Record the account domain, resource computer domain, service-account domain, and both forest roots. The service account need not live in the computer’s domain. That extra distinction can explain a referral or PAC-validation dependency that a two-box drawing hides.

Follow the referral and the authorization check separately

The account-domain KDC can return a referral TGT for another realm; subsequent KDCs route the client toward the realm that owns the requested SPN. The resource KDC then issues the service ticket. The client carries the ticket to the service. It is not sending its password successively to every KDC on that path.

There are three things to check: can the client reach the right realm, does that realm accept the authentication and authorization data crossing the boundary, and does the accepting server permit the requested operation? A correct trust password doesn’t settle the last two. RFC 4120’s cross-realm model and MS-PAC’s filtering rules describe those different stages.

Collect the trust configuration

From an AD PowerShell session, target an explicit domain controller:

Get-ADTrust -Filter * -Server dc1.contoso.com |
    Select-Object Name, Source, Target, Direction, TrustType,
        ForestTransitive, IntraForest, SelectiveAuthentication,
        SIDFilteringForestAware, SIDFilteringQuarantined

Check each relevant domain; one domain’s results won’t list every trust in the forest. Save the source DC and collection time with the output in case the replicas disagree.

For the underlying non-secret configuration on that replica:

$dc = 'dc1.contoso.com'
$base = (Get-ADRootDSE -Server $dc).defaultNamingContext
Get-ADObject -Server $dc -SearchBase "CN=System,$base" `
    -LDAPFilter '(objectClass=trustedDomain)' `
    -Properties trustPartner, flatName, trustDirection, trustType, trustAttributes |
    Select-Object DistinguishedName, trustPartner, flatName,
        trustDirection, trustType, trustAttributes

This does not retrieve trust passwords. The TDO fields describe the local side; compare them with the intended opposite-side configuration and replication state. Forest trust information is associated with the forest-root trust. The LSA trust-information model maps these conceptual values to AD attributes.

Active validation: after confirming the intended direction, test the trust relationship rather than immediately resetting its password:

netdom trust resource.contoso.com /domain:accounts.example.com /verify

You’ll need suitable rights and connectivity. A successful verification checks that trust path at that time. You still need to test the application and resource ACLs. See the netdom trust reference.

Selective authentication adds a gate

With selective authentication, a foreign principal needs Allowed to authenticate for the target computer or service, as well as permission to use the resource. Successfully adding a user to a share ACL does not satisfy that earlier gate.

The extended right does not add the user to a stored Authenticated Users group membership. It authorizes authentication to that target. For Kerberos TGS processing, the KDC checks the AD account for which the ticket is being requested. When an SPN belongs to a user service account, inspecting only the host computer’s ACL can miss the relevant gate. The KILE TGS access check specifies that target; the extended-right definition lists its applicable object classes. For a multi-hop application, inspect the actual principal and target at each hop.

To inspect the current setting without changing it:

netdom trust resource.contoso.com /domain:accounts.example.com /selectiveauth

Use a deliberately permitted test identity and target to distinguish selective-authentication denial from an application authorization failure.

SID filtering depends on the trust type

SID filtering limits which authorization SIDs are accepted across a trust. It applies to forest trust boundaries as well as external trusts; the policies and allowed SID categories differ.

These are inspection commands. Omitting a yes/no value asks netdom to display the setting:

netdom trust resource.contoso.com /domain:accounts.example.com /quarantine
netdom trust resource.contoso.com /domain:accounts.example.com /enablesidhistory

/quarantine and /enablesidhistory are not interchangeable hardening switches. The latter controls migrated SID history across an outbound forest trust. Confirm trust type and direction before interpreting the result, and use Microsoft’s netdom parameter definitions when planning a change. Do not disable filtering simply to make a failing migration test pass.

Filtering is not a blanket test that every foreign SID is either trusted or discarded. A cross-forest boundary rejects local-forest identities asserted by the remote forest and applies additional SID-category rules. A quarantined external trust is narrower still. Do not assume that a SID appearing in the source directory’s group report must appear in the resource server’s final token. Inspect the actual access context and the applicable PAC boundary rules.

Inbound ticket validation has its own trust path

A service running in a different domain from its host can cause PAC validation to traverse the host domain toward the service-account domain. A failure after service-ticket issuance can therefore involve Netlogon and an intermediate DC. Collect the accepting server’s System events and patch levels along that route, not just the user’s KDC’s Security events.

The KB5037754 Network Ticket Logon changes reached final enforcement with April 2025 updates. The former compatibility registry settings are no longer supported after those updates. Before changing a firewall, check the actual validation path. An older diagram may leave out DC contact after ticket issuance.

Name suffix routing can fail before resource access

Keep the following with the trust inventory: routed UPN/DNS suffixes, exclusions, disabled or conflicting entries, and the SPN the client requested. The directory can contain the correct service account while the account forest’s KDC has no usable route to the resource forest.

Check the trust’s Name Suffix Routing tab in Active Directory Domains and Trusts. Compare the request’s realm referrals with those settings. Do not delete and recreate the trust before recording the suffix configuration.

For an inspection from the resource forest’s root-domain context:

netdom trust resource.contoso.com /namesuffixes:accounts.example.com

Use the actual forest-root trust names. /namesuffixes lists the routing entries; changing a suffix is a separate operation. Entry numbers are display positions and can change, so an old report’s number is not a stable identifier for an eventual approved change.

A suffix can be listed but disabled. The LSA trust-record flags distinguish a newly created but not enabled top-level name, an administrator-disabled name, and a conflicting name. Domain-information records also distinguish SID and NetBIOS-name conflict states. Keep the record type and disabled reason with the results; a nonzero flag doesn’t by itself mean the trust password is broken.

When the failure follows a custom service alias, compare the client’s requested SPN with the actual SPN registration.

SID history can remain useful after a trust is removed

An old SID can still appear on a resource ACL that now lives in the same forest as the migrated account. Removing the old trust does not make that SID history unused. Check the affected ACLs and application dependencies before removing it.

A read-only list of users carrying SID history is:

Get-ADUser -LDAPFilter '(sIDHistory=*)' -Properties sIDHistory |
    Select-Object SamAccountName, SID, sIDHistory

Include groups in a migration review too. A group or user carrying a historical SID may be part of an access path even when the name of the old domain appears nowhere in today’s documentation.