Advanced AD DS Trust Settings

SID Filtering

By default, when you establish a forest or domain trust, you enable a domain quarantine, which is also known as SID filtering. When a user authenticates in a trusted domain, the user presents authorization data that includes the SIDs of all of the groups to which the user belongs. Additionally, the user’s authorization data includes SIDs from other attributes of the user and the user’s groups.

AD DS sets SID filtering by default to prevent users who have access at the domain or enterprise administrator level in a trusted forest or domain, from granting (to themselves or to other user accounts in their forest or domain) elevated user rights to a trusting forest or domain. SID filtering prevents misuse of the attributes that contain SIDs on security principals in the trusted forest or domain.

One common example of an attribute that contains a SID is the SID-History attribute (SIDHistory) on a user account object. Domain administrators typically use the SID-History attribute to migrate the user and group accounts that are held by a security principal from one domain to another.

In a trusted domain scenario, it is possible that an administrator could use administrative credentials in the trusted domain to load SIDs that are the same as SIDs of privileged accounts in your domain into the SIDHistory attribute of a user. That user would then have inappropriate levels of access to resources in your domain. SID filtering prevents this by enabling the trusting domain to filter out SIDs from the trusted domain that are not the primary SIDs of security principals. Each SID includes the SID of the originating domain, so when a user from a trusted domain presents the list of the user’s SIDs and the SIDs of the user’s groups, SID filtering instructs the trusting domain to discard all SIDs without the domain SID of the trusted domain. SID filtering is enabled by default for all outgoing trusts to external domains and forests.

 

 

Selective Authentication

When you create an external trust or a forest trust, you can manage the scope of authentication of trusted security principals. There are two modes of authentication for an external or forest trust:

Domain-wide authentication (for an external trust) or forest-wide authentication (for a forest trust)

Selective authentication

If you choose domain-wide or forest-wide authentication, this enables all trusted users to authenticate for services and access on all computers in the trusting domain. Therefore, trusted users can be given permission to access resources anywhere in the trusting domain. If you use this authentication mode, all users from a trusted domain or forest are considered Authenticated Users in the trusting domain. Thus if you choose domain-wide or forest-wide authentication, any resource that has permissions granted to Authenticated Users is accessible immediately to trusted domain users.

If, however, you choose selective authentication, all users in the trusted domain are trusted identities. However, they are allowed to authenticate only for services on computers that you specify. For example, imagine that you have an external trust with a partner organization’s domain. You want to ensure that only users from the partner organization’s marketing group can access shared folders on only one of your many file servers. You can configure selective authentication for the trust relationship, and then give the trusted users the right to authenticate only for that one file server.

 

Name Suffix Routing

Name suffix routing is a mechanism for managing how authentication requests are routed across forests running Windows Server 2003 or newer forests that are joined by forest trusts. To simplify the administration of authentication requests, when you create a forest trust, AD DS routes all unique name suffixes by default. A unique name suffix is a name suffix within a forest—such as a UPN suffix, SPN suffix, or DNS forest or domain tree name—that is not subordinate to any other name suffix. For example, the DNS forest name fabrikam.com is a unique name suffix within the fabrikam.com forest.

AD DS routes all names that are subordinate to unique name suffixes implicitly. For example, if your forest uses fabrikam.com as a unique name suffix, authentication requests for all child domains of fabrikam.com (childdomain.fabrikam.com) are routed, because the child domains are part of the fabrikam.com name suffix. Child names appear in the Active Directory Domains and Trusts snap-in. If you want to exclude members of a child domain from authenticating in the specified forest, you can disable name suffix routing for that name. You also can disable routing for the forest name itself

https://www.youtube.com/watch?v=MB4iiqEyr5A

 

Trust Properties - Name Suffix Routing Tab

Updated: March 1, 2012

Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

 

Item

Details

Name suffixes in the <DNS name> forest:

  • Suffix : A list of name suffixes in the local forest.
  • Routing : Specifies the routing status of the corresponding name suffix.
  • Status : Specifies the status (conflicts, whether the name suffix is newly created, and so on) of the corresponding name suffix.

Enable

Click to set the routing status of the selected name suffix to Enabled.

Disable

Click to set the routing status of the selected name suffix to Disabled.

Refresh

Click to refresh the list of name suffixes in the local forest.

Edit

Click to exclude name suffixes from routing to the local forest.