SID Filtering Dialog Box - Securing External Trusts

When SID filtering is not enabled on outgoing external trusts, a malicious user with administrative credentials in the trusted domain may be able to "sniff" network authentication requests from the trusting domain to obtain the SID information of a user, such as a domain administrator, who has full access to resources in the trusting domain.

After obtaining the domain administrator's SID from the trusting domain, a malicious user with administrative credentials can add that SID to a user account's SIDHistory attribute in the trusted domain and attempt to gain full access to the trusting domain and the resources in that domain. In this scenario, a malicious user who has domain administrator credentials in the trusted domain is a threat to the entire trusting forest.

SID filtering helps neutralize the threat of malicious users in the trusted domain using the SIDHistory attribute to gain elevated privileges.

When security principals are created in a domain, the domain SID is included in the security principal's SID to identify the domain in which the security principal was created. The domain SID is an important characteristic of a security principal because the Windows security subsystem uses it to verify the security principal's authenticity.

In a similar fashion, outgoing external trusts that are created from the trusting domain use SID filtering to verify that incoming authentication requests from security principals in the trusted domain contain only the SIDs of security principals in the trusted domain. This is accomplished through a comparison of the SIDs of the incoming security principal to the domain SID of the trusted domain. If any of the security principal SIDs includes a domain SID other than the SID from the trusted domain, the trust removes the offending SID.

SID filtering helps ensure that any misuse of the SIDHistory attribute on security principals (including inetOrgPerson) in the trusted forest cannot pose a threat to the integrity of the trusting forest.

The SIDHistory attribute can be useful to domain administrators when they migrate user accounts and group accounts from one domain to another. Domain administrators can add SIDs from an old user account or group account to the SIDHistory attribute of the new, migrated account. By doing this, domain administrators give the new account the same level of access to resources as the old account.

If domain administrators cannot use the SIDHistory attribute in this way, they have to track down and reapply permissions for the new account on each network resource that the old account had access to.

SID filtering on external trusts can affect your existing Active Directory infrastructure in the following two areas:

• SID history data that contains SIDs from any domain other than the trusted domain is removed from authentication requests that are made from the trusted domain. This results in access being denied to resources that have the user's old SID.
  
  
• Your strategy for universal group access control between forests will require changes.
  
  

When you enable SID filtering, users who use SID history data for authorization to resources in the trusting domain no longer have access to those resources.

If you typically assign universal groups from a trusted forest to access control lists (ACLs) on shared resources in the trusting domain, SID filtering has a major impact on your access control strategy. Because universal groups must adhere to the same SID filtering guidelines as other security principal objects (that is, the universal group object SID must also contain the domain SID), verify that any universal groups that are assigned to shared resources in the trusting domain were created in the trusted domain. If the universal group in the trusted forest was not created in the trusted domain—even though it may contain users from the trusted domain as members—authentication requests from members of that universal group will be filtered and discarded. Therefore, before you assign access to resources in the trusting domain for users in the trusted domain, confirm that the universal group that contains the trusted domain users was created in the trusted domain.

• User Interface: Active Directory Domains and Trusts