Establishing Secure Collaboration with Other Forests

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

Support for interforest collaboration might become necessary for a variety of reasons, including the following:

  • Organizational mergers and acquisitions

  • Collaboration between isolated forests within an organization

  • Shared applications that are accessed from an application forest

Collaboration between domains in different forests can range from simply sharing e-mail to providing access to data and resources. A number of scenarios, including scenarios in which there is a need for service isolation, can result in an organization or partnership spanning multiple forests. Trust relationships can be used to set up resource sharing between pairs of domains from separate forests or between all domains in two forests. In some cases, plans might call for maintaining separate forests with trust relationships to facilitate collaboration. In other cases, plans might exist to merge forests eventually. In the case of either collaboration or migration, trust relationships that link domains in different forests might be necessary.

Access to applications, data, and other resources that exist in different forests can be enabled through two types of trust relationship:

  • An external trust is a one-way or two-way, nontransitive trust between two domains in separate Windows 2000 or Windows Server 2003 forests. External trusts can also exist between Windows NT 4.0 domains and domains in Windows 2000 or Windows Server 2003 forests. A domain administrator in one forest can create external trust relationships with domains in other forests.

  • A forest trust is a one-way or two-way, transitive trust between all domains in two Windows Server 2003 forests. For generalized resource sharing between all domains in both forests, forest administrators can create forest trusts.

Forest and external trust relationships extend the use of security principals that are created in one domain of a forest to a domain or domains in another forest or forests. However, external and forest trusts introduce potential security risks because they allow security principals to cross security boundaries.

When trust relationships exist between domains in separate forests, security implications include the following:

  • With external trusts, SIDs from untrusted domains can be added to access tokens, and the SIDs can be accepted by domain controllers in a trusting domain. This risk can be mitigated by SID filtering.

  • With forest trusts and external trusts, users from a different forest can be added to administrative groups in the forest root domain or in other domains in the trusting domain. This risk can be mitigated by secure administrative policies and trustworthy high-level administrators.

Avoiding these security risks requires that appropriate administrative policies be in place. In addition, Windows Server 2003 provides default features that mitigate risk from the unauthorized use of SIDs.

SID History and External Trusts

The risks that are associated with external trust relationships relate to the SIDs that are included in a trusted user’s access token when the user’s authentication is accepted by the trusting domain of the external forest.

Because the SID contains the domain affiliation of the user, it is not possible to move the security principal between domains when a user is migrated from one domain to another domain within a forest or between forests. Such a move requires that a new security principal be created in the new domain, with a new user SID that identifies the domain. To ensure that the user does not lose appropriate access to resources, the SIDs that are associated with that user in the source domain are added to the SID history (sIDHistory) attribute of the new user account in the target domain. The sIDHistory attribute is available on security principal objects only in domains that are operating at one of the following:

  • Windows 2000 native mode (Windows 2000 domains)

  • Windows 2000 native domain functional level (Windows Server 2003 domains)

  • Windows Server 2003 domain functional level (Windows Server 2003 domains)

Security Risk Posed by SID History

When a user logs on to a domain, the user's primary SID and the SIDs of groups of which the user is a member are determined by a domain controller in the user's account domain. If the domain of the authenticating domain controller is operating at Windows 2000 native mode or higher, the authenticating domain controller also determines if the user has any values present in the sIDHistory attribute, and it includes those SIDs in the authorization data. From the perspective of access control, these SIDs are no different from other group SIDs.

By design, a domain controller in a trusting domain accepts the authorization data of a trusted domain. When the user is from a different forest, accepting all SIDs in the authorization data exposes the trusting domain to potential security threats. Although the authenticating domain may be trusted, a user’s sIDHistory attribute might contain SIDs that are based on other domains that are not trusted. If a particular SID can be added to a user’s sIDHistory attribute, that user can gain unauthorized access to resources in the trusting domain, including administrative privileges, which constitutes an elevation-of-privilege threat.

Note

Exploiting this vulnerability would be a challenge to an attacker. Only the delete operation can be performed using a low-level operation (for example, an LDAP call or ADSI) to directly access the attribute. To add a value to this attribute, an attacker needs, at a minimum, administrative credentials in the trusted domain and the technical ability to modify low-level operating system functions and data structures. Microsoft is not currently aware of any programming interface that allows an attacker — even one with administrative credentials — to introduce a SID into sIDHistory.

Blocking SIDs from Untrusted Domains

By default, all new external trusts that are created from domain controllers running Windows Server 2003 or Windows 2000 Service Pack 4 (SP4) enforce SID filtering, which prevents attacks by malicious users who might try to grant elevated user rights to another user account. SID filtering removes any SIDs that are not related to the user’s account domain. The trusted domain in this case is said to be quarantined. Quarantining is performed from the trusting domain on a per-domain (and, therefore, per–external trust) basis, and only on domains residing in a different forest.

Important

Do not attempt to use the SID filtering feature to create a "restricted-access" domain within a forest. Enabling SID filtering between domains in the same forest disrupts the default trust and authentication behavior of a forest. Using SID filtering in this way is likely to lead to problems with programs and with the Active Directory service itself that are difficult to troubleshoot.

To mitigate the threat posed by sIDHistory, all domain controllers in the trusting domain should either be upgraded to Windows Server 2003 or be running at least Windows 2000 SP4 or later before the external trust is created.

To further secure your forest, consider enabling SID filtering on all existing external trusts that are created by domain controllers running Windows 2000 Service Pack 3 (SP3) or earlier. If an external trust was created before you upgraded your Windows 2000 domain to Windows Server 2003, you must either enable SID filtering for that trust or delete the existing trust and create a new one. You can use Netdom.exe (Windows Support Tools) to enable SID filtering on existing external trusts, or you can recreate the external trusts from a domain controller running Windows Server 2003 or Windows 2000 SP 4 or later.

For more information about enabling SID filtering, see Enabling SID Filtering in the Appendix: Procedures section.

For more information about applying SID filtering, see the following articles in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=4441:

  • 289243, “Forged SID Could Result in Elevated Privileges in Windows 2000”

  • 289246, “Forged SID Could Result in Elevated Privileges in Windows NT 4.0”

Impact of SID Filtering on External Trusts

SID filtering neutralizes the threat of malicious users in the trusted domain using the sIDHistory attribute to gain elevated privileges in the trusting domain. SID filtering on external trusts can affect your existing Active Directory infrastructure in the following areas:

  • SID history data that contains SIDs from any domain other than the trusted domain will be removed from authentication requests that are made from the trusted domain. Removal of these SIDs will result in access being denied to resources that have the user's old SID, as follows:

    • Users that were migrated to the trusted domain lose access to resources in their source domain (if it still exists).

    • Users in the trusted domain who use SID history data for authorization to resources in the trusting domain no longer have access to those resources.

  • Your strategy for universal group access control between forests will require changes. If you typically add universal groups from a trusted forest to permissions on shared resources in the trusting domain, SID filtering will have a significant impact on your access control strategy.

For effective SID filtering, follow these guidelines:

  • Verify that any universal groups that are assigned to shared resources in the trusting domain were created in the trusted domain. 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.

  • Before assigning 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. If the universal group in the forest of the trusted domain was not created in the trusted domain, authentication requests that are made from members of that universal group will be filtered and discarded, even though it might contain users from the trusted domain as members.

Security Risks Associated with Forest Trusts

When a forest trust is in place, the risk to security comes from high-level administrators in the trusted forest who might have malicious goals. When all domains in one forest are trusted by all domains in another forest, it is possible to add users from the trusted forest to domain local security groups in the trusting forest. Some default administrative security groups have the domain local group type. Adding users from one forest to administrative groups in the forest root domain of another forest compromises the isolation of the forests. The same risk applies for domain-level administrative groups in regional domains within the forests.

By default, forest trusts enforce SID filtering. SID filtering on forest trusts does not prevent migrations to domains within the same forest from using SID history, and it does not affect your strategy for universal group access control within the forest.

Security Considerations for Resource Access Across Forests

Even when you create multiple forests for data isolation, service isolation, or both, you might need trust relationships with other forests, or with individual domains in other forests, so that some users can be granted access to resources in a different forest. However, do not include users from other forests in any of the following groups:

  • Groups that are responsible for service management or that can manage the membership of service administrator groups

  • Groups with administrative control over computers that store protected data

  • Groups that have access to protected data or groups that are responsible for the management of user or group objects that have access to protected data

Including users in such groups violates the data and service isolation requirements that created the need for separate forests and exposes the trusting forest to potential data disclosure or service interruption threats.

For information about these administrative groups, see “Designing the Active Directory Logical Structure” in Designing and Deploying Directory and Security Services of the Windows Server 2003 Deployment Kit (or see “Designing the Active Directory Logical Structure” on the Web at https://go.microsoft.com/fwlink/?LinkId=4723).