Forest-Wide Authentication on an AD Forest Trust Gives Every Trusted-Forest User Authenticated Users Access

When you create a forest trust, Active Directory Domains and Trusts sets its authentication to Forest-wide Authentication unless you choose otherwise. Microsoft documents this as the default for forest trusts, and it lets any user in the trusted forest authenticate to resources in every domain of your forest. Those users receive your forest’s Authenticated Users SID, so every share, folder or application that grants Authenticated Users is open to them, even though no ACL names the other forest. The fix is to grant the Allowed to Authenticate permission on the specific computer objects partner users need, then switch the outgoing side of the trust to Selective Authentication.

Symptom

Users from a trusted forest can open shares and folders on servers in your forest that nobody ever granted them. A forest trust created for one narrow purpose, such as a partner team reaching a single application server, turns up in an access review as reach into file servers across your domains. The share and NTFS permissions list only your own groups and Authenticated Users, so the access looks impossible until you look at the trust itself.

False Assumption

The assumption is that a trust only creates a path, and that the other forest gets nothing until you add its users or groups to an ACL. That holds for permissions that name specific principals. It does not hold for permissions granted to Authenticated Users, which is a computed group: its SID is added on the server the user authenticates to, and you cannot change its membership. If the trust lets the user authenticate, the user is in it.

Root Cause

The trust’s authentication setting decides whether trusted-forest users are treated as your own authenticated users. Microsoft’s Security Considerations for Trusts reference describes three settings:

• Domain-wide Authentication (external trusts): unrestricted access by any user in the trusted domain to all available shared resources in the trusting domain. It is the default for external trusts.
• Forest-wide Authentication (forest trusts): unrestricted access by any user in the trusted forest to all available shared resources in any domain of the trusting forest. It is the default for forest trusts.
• Selective Authentication (external and forest trusts): only users who have been explicitly given authentication permission on computer objects in the trusting forest can authenticate to them. It must be enabled manually.

Under domain-wide or forest-wide authentication, users authenticated over the trust automatically get the trusting forest’s Authenticated Users SID (S-1-5-11). Microsoft states the consequence directly: after you set up the trust, users from the other forest receive some default rights to all resources in the trusting forest that are accessible to Authenticated Users.

Impact

Every resource that trusts Authenticated Users becomes reachable from an organisation whose accounts, password policy and administrators you do not control. Microsoft describes a trust as a larger attack surface for any malicious user in the trusted forest, and names selective authentication as the setting that reduces it. A compromised partner account needs no permission in your forest to read a share that grants Authenticated Users read access. The same exposure appears in access reviews as unexplained reads, and audit findings are hard to close because no ACL entry points to the cause. SID filtering is a separate control: see how the SID history attribute becomes a post-migration escalation path for that side of trust security.

Diagnosis

These steps are read-only. Run them from a domain controller or an administrative workstation in the forest root domain of the trusting (resource) forest.

1. List the trusted domain objects in the forest with the ActiveDirectory module, and note every forest and external trust:

   Get-ADTrust -Filter *

2. For each outgoing forest or external trust, display its selective authentication state. The netdom trust reference says /selectiveauth without a value displays the current state, and that the setting is valid only on outbound forest and external trusts:

   netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /selectiveauth

3. Confirm in the console: open Active Directory Domains and Trusts, right-click the forest root domain, choose Properties, select the trust on the Trusts tab, choose Properties and read the Authentication tab. This tab shows only the outgoing side. For the other direction of a two-way trust, connect to a domain controller in the other forest’s root domain and read its outgoing trust.
4. Measure exposure on each file server. On the server, list a share’s permissions and look for Authenticated Users:

   Get-SmbShareAccess -Name "<ShareName>"

   Then find files and folders under the share’s path whose DACL explicitly names Authenticated Users. icacls takes a numeric SID with a leading asterisk; /t includes subdirectories and /c continues past errors:

   icacls D:\Shares\Finance\* /findsid *S-1-5-11 /t /c

A forest trust reporting that selective authentication is not enabled, plus shares or folders granting Authenticated Users, confirms the exposure.

Correction

Grant first, then switch the trust to selective authentication, so the partner users who should keep access do not lose it at the cut-over.

Preconditions. Changing the trust needs Domain Admins in the forest root domain or Enterprise Admins. Granting Allowed to Authenticate needs Account Operators, Domain Admins or Enterprise Admins, or at least Modify Permission on the computer objects. Agree with the application owners which servers partner users need, and pick or create a group of those users. Rehearse in a test forest pair first.

State capture. Save the output of the netdom trust … /selectiveauth check and a screenshot of the Authentication tab, and record each computer or service account object you change, with the principal you add.

1. In Active Directory Users and Computers in the trusting domain, enable View > Advanced Features.
2. For each resource computer, open Properties > Security, click Add, enter the partner group and select Allow for Allowed to Authenticate.
3. Where a service runs under a domain service account and clients use Kerberos, grant the permission on that service account instead of the computer. For NTLM, grant it on the computer account even when the service uses a domain account.
4. Enable selective authentication on the outgoing trust, either on the Authentication tab (select Selective authentication, then OK) or from the forest root domain:

   netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /SelectiveAUTH:Yes /userD:<DomainAdministratorAcct> /passwordD:*

Stop condition. If an in-scope partner user cannot reach a server that should be granted, stop changing further trusts. Add the missing grant on that computer or service account, and roll the trust back only if service cannot be restored that way.

Validation

Validation proves that the trust is selective and that only granted computers accept partner users. Re-run netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /selectiveauth and check that it now reports selective authentication as enabled, and that the Authentication tab shows Selective authentication. With a test account from the trusted forest, open a resource on a granted server: it should succeed. Then try a share on a server that was not granted: it should fail, because the domain controller checks Allowed to Authenticate on the computer object and does not issue a service ticket without it.

Rollback

Rollback restores forest-wide authentication and, with it, the original exposure, so treat it as temporary. Run the same command with /SelectiveAUTH:No, or select Forest-wide authentication on the trust’s Authentication tab:

netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /SelectiveAUTH:No /userD:<DomainAdministratorAcct> /passwordD:*

To withdraw a single grant, clear Allow for Allowed to Authenticate on that object’s Security tab, using your state-capture list. Re-run the /selectiveauth check to confirm the state you restored.

Prevention: Keep Forest Trusts Selective and Granted Servers Clean

Selective authentication limits which computers partner users can authenticate to, not what they can do there. Microsoft’s trust reference notes that a member server still adds the Authenticated Users SID for a partner user it authenticates, so on every granted server, Authenticated Users permissions apply to partner users too.

• Choose selective authentication when you create a trust; the New Trust Wizard offers it, and it is far easier than retrofitting.
• Review granted servers’ shares and folders with Get-SmbShareAccess and icacls /findsid, and replace Authenticated Users with named groups where partner access is not intended.
• Do not strip Authenticated Users everywhere as a shortcut. It breaks things that depend on it, as in removing Authenticated Users from a GPO’s security filter.
• Add the trust check to your regular Active Directory review alongside other domain controller hardening, such as requiring LDAP signing on domain controllers.

The selective authentication procedures Microsoft publishes are written for Windows Server 2003 to 2008 R2. The current netdom trust reference, which applies to Windows Server 2016 to 2025, still documents /selectiveauth. Check it against your domain controllers’ version before you change a production trust.