When to create an external trust

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

When to create an external trust

You can create an external trust to form a one-way or two-way, nontransitive trust with domains outside of your forest. External trusts are sometimes necessary when users need access to resources located in a Windows NT 4.0 domain or in a domain located within a separate forest that is not joined by a forest trust, as shown in the figure.

When a trust is established between a domain in a particular forest and a domain outside of that forest, security principals from the external domain can access resources in the internal domain. Active Directory creates a foreign security principal object in the internal domain to represent each security principal from the trusted external domain. These foreign security principals can become members of domain local groups in the internal domain. Domain local groups can have members from domains outside of the forest.

Directory objects for foreign security principals are created by Active Directory and should not be manually modified. You can view foreign security principal objects from Active Directory Users and Computers by enabling advanced features. For information about enabling advanced features, see To view advanced features.

In domains with the functional level set to Windows 2000 mixed, it is recommended that you delete external trusts from a domain controller running Windows Server 2003. External trusts to Windows NT 4.0 or 3.51 domains can be deleted by authorized administrators on the domain controllers running Windows NT 4.0 or 3.51. However, only the trusted side of the relationship can be deleted on the domain controllers running Windows NT 4.0 or 3.51. The trusting side of the relationship (created in the Windows Server 2003 domain) is not deleted, and although it will not be operational, the trust will continue to display in Active Directory Domains and Trusts. To remove the trust completely, you will need to delete the trust from a domain controller running Windows Server 2003 in the trusting domain. If an external trust is inadvertently deleted from a domain controller running Windows NT 4.0 or 3.51, you will need to recreate the trust from any domain controller running Windows Server 2003 in the trusting domain.

For more information about how to create an external trust, see Create an external trust.

Securing external trusts

To improve the security of Active Directory forests, domain controllers running Windows Server 2003 and Windows 2000 Service Pack 4 (or higher) enable security identifier (SID) filter quarantining on all new outgoing external trusts by default.

By applying SID filter quarantining to outgoing external trusts, you prevent malicious users who have domain administrator level access in the trusted domain from granting, to themselves or other user accounts in their domain, elevated user rights to the trusting domain.

When a malicious user can grant unauthorized user rights to another user it is known as an elevation of privilege attack. For more information about SID filtering and how to further mitigate an elevation of privilege attack, see MS02-001: Forged SID could result in elevated privileges in Windows 2000 (https://go.microsoft.com/fwlink/?LinkId=102075).

How SID filter quarantining works

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 it 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 created from the trusting domain use SID filter quarantining to verify that incoming authentication requests made from security principals in the trusted domain contain SIDs of security principals from the trusted domain only. This is done by comparing the SIDs of the incoming security principal to the domain SID of the trusted domain. If any of the security principal SIDs include a domain SID other than the one from the trusted domain, the trust removes the offending SID.

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

The SID history attribute can be useful to domain administrators when they migrate user and group accounts from one domain to another. Domain administrators can add SIDs from an old user or group account to the SID history 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 could not use the SID history attribute in this way, they would have to track down and reapply permissions for the new account on each network resource that the old account had access to.

Understanding the threat

If not for SID filtering on outgoing external trusts, a malicious user with administrative credentials residing in the trusted domain could sniff network authentication requests from the trusting domain to obtain the SID information of a user who has full access to resources in the trusting domain, such as a domain administrator.

After obtaining the domain administrators SID from the trusting domain, a malicious user with administrative credentials can add that SID to a user account's SID history attribute in the trusted domain and attempt to gain full access to the trusting domain and the resources within 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 neutralizes the threat of malicious users in the trusted domain from using the SID history attribute to gain elevated privileges.

Impact of SID filter quarantining

SID filter quarantining 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 will be removed from authentication requests made from the trusted domain. This will result in access being denied to resources that have the user's old SID.

• Universal group access control strategy between forests will require changes.

When SID filter quarantining is enabled, 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 filter quarantining will have a major impact on your access control strategy.

Because universal groups must adhere to the same SID filter quarantining guidelines as other security principal objects (that is, the universal group object SID must also contain the domain SID), you should 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 made from members of that universal group will be filtered and discarded.

Therefore, before assigning access to resources in the trusting domain for users in the trusted domain, you should confirm that the universal group containing the trusted domain users was created in the trusted domain.

Disabling SID Filter quarantining

Although it is not recommended, you can disable SID filter quarantining for an external trust by using the Netdom.exe tool. You should consider disabling SID filter quarantining only in the following situations:

• You have the same level of trust for all administrators who have physical access to domain controllers in the trusted domain as the administrators in the trusting domain.

• You have a strict requirement to assign universal groups to resources in the trusting domain that were not created in the trusted domain.

• Users have been migrated to the trusted domain with their SID histories preserved, and you want to grant them access to resources in the trusting domain based on the SID history attribute.

Only domain administrators can disable SID filtering. To disable SID filter quarantining for the trusting domain, type the following syntax at a command-prompt:

Netdom trustTrustingDomainName**/domain:TrustedDomainName/quarantine:**No **/userD:domainadministratorAcct/passwordD:**domainadminpwd

To enable SID filter quarantining, set the /quarantine: command-line option to Yes. For more information about Netdom.exe, see Active Directory support tools.

You can enable or disable SID filter quarantining only from the trusting side of the trust. If the trust is a two-way trust, you can also disable SID filter quarantining in the trusted domain by using the domain administrator's credentials for the trusted domain and reversing the TrustingDomainName and TrustedDomainName values in the command-line syntax.

Notes

• To further secure your forest, you should consider enabling SID filter quarantining on all existing external trusts that were created by domain controllers running Windows 2000 Service Pack 3 (or earlier). You can do this by using Netdom.exe to enable SID filtering on existing external trusts, or by recreating these external trusts from a domain controller running Windows Server 2003 or Windows 2000 Service Pack 4 (or later).

• You cannot turn off the default behavior that enables SID filter quarantining for newly created external trusts.

• External trusts created from domain controllers running Windows 2000 Service Pack 3 (or earlier) do not enforce SID filter quarantining by default.

• Domain controllers running Windows NT Server 4.0 do not take part in the trust creation process when existing domain controllers in the same domain are running Windows 2000 or Windows Server 2003.

• You can enable or disable SID filter quarantining only for trusts that extend beyond forest boundaries such as external and forest trusts. For more information about SID filtering and forest trusts, see Forest trusts.

Allowing SID history to traverse forest trusts

If you are migrating users from one domain to another in different forests, you may want to allow the migrated users to access resources in their original forest by using their migrated (SID history) credentials. The default SID filtering that is applied to forest trusts prevents user-resource-access requests from traversing the trusts with the credentials of the original domain. If you want to make it possible for users to use the credentials that were migrated from their original domain, you can allow SID history to traverse forest trusts by using the netdom command.

Only domain administrators or enterprise administrators can modify SID filtering settings. To allow SID history credentials to traverse a trust relationship between two forests, type a command using the following syntax at a command prompt, and then press ENTER:

Netdom trustTrustingDomainName**/domain:TrustedDomainName/enablesidhistory:**Yes **/usero:domainadministratorAcct/passwordo:**domainadminpwd

To re-enable the default SID filtering setting across forest trusts, set the /enablesidhistory: command-line option to No. For more information about Netdom, see “Domain and Forest Trust Tools and Settings.”