article is based on an article in the Microsoft TechNet Library and is presented here to enable those outside of Microsoft who are interested and knowledgeable on this topic to improve it. The original article exists on TechNet as
Applies to Windows 2000 only - does not yet cover Windows Server 2003 forest trusts (please, remove this note if you update the article to cover later versions).
Table of Contents OverviewGeneral Guidelines for TrustsTrust Management Tasks and ProceduresCreating External TrustsCreating External TrustsProcedures for Creating External TrustsCreating Shortcut TrustsProcedures for Creating Shortcut TrustsRemoving Manually Created TrustsProcedure for Removing Manually Created TrustsPreventing Unauthorized Privilege EscalationProcedure for Preventing Unauthorized Privilege Escalation
Trusts require little management. Trust relationships between domains establish a trusted communication path through which a computer in one domain can communicate with a computer in the other domain. Trust relationships allow users in the trusted domain
to access resources in the trusting domain.
For example, where a one-way trust exists:
A user who is logged on to the trusted domain can be authenticated to connect to a resource server in the trusting domain.
A user can use an account in the trusted domain to log on to the trusted domain from a computer in the trusting domain.
A user in the trusting domain can list trusted domain security principals and add them to groups and access control lists (ACLs) on resources in the trusting domain.
When you create a Windows 2000 domain in an existing Windows 2000 forest, a trust relationship is established automatically. These trust relationships are two-way and transitive, and they should not be removed.
However, three types of trusts must be created manually:
Trusts between a Windows 2000 domain and a Windows NT 4.0 domain.
Any trust between domains in different forests, whether both domains are Windows 2000 or one is Windows 2000 and the other Windows NT 4.0.
Shortcut trusts between two domains in the same forest.
Trust relationships between a Windows 2000 domain and a non-Windows Kerberos realm. For more information about trusts between a Windows 2000 domain and a non-Windows Kerberos realm, see the Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability link
on the Web Resources page at
You might also need to manage trusts for the following reasons:
To remove a manually created trust.
To configure security identifier (SID) filtering to deny one domain the right to provide credentials for another domain. You can enable SID filtering for external trusts, that is, trusts between domains in different forests, or between a Windows 2000 and
a Windows NT 4.0 domain.
Table 1.20 shows the tasks and the procedures for managing trusts.
Table 1.20 Trust Management Tasks and Procedures
Create an external trust (between a Windows 2000 domain and a Windows NT 4.0 domain, or between domains in different forests).
Create a One-way Trust (MMC Method).
Create a One-way Trust (Netdom.exe Method).
Create a Two-way Trust (MMC Method).
Create a Two-way Trust (Netdom.exe Method).
Active Directory Domains and Trusts (Windows 2000)-Or-
User Manager for Domains (Windows NT 4.0)
Create a shortcut trust.
Active Directory Domains and Trusts-Or-
Remove a manually created trust.
Prevent unauthorized privilege escalation.
Configure SID filtering.
You create an external trust when you want to establish a trust relationship between Windows 2000 domains that are in different forests, or between a Windows 2000 domain and a Windows NT 4.0 domain. An external trust relationship has the following characteristics:
It is one-way. The trust must be established manually in each direction to create a two-way external trust relationship.
It is nontransitive.
If you upgrade a Windows NT 4.0 domain to a Windows 2000 domain, the existing trust relationships remain in the same state.
Credentials: Domain Admins
You can create the trust when you log on to the domain, or use the Run As command to create the trust for a different domain.
Tools: Active Directory Domains and Trusts or Netdom.exe (Support Tools).
You can create an external trust by using one of the following methods. Procedures are explained in detail in the linked topics.
Create a One-way Trust (MMC Method)
Create a One-way Trust (Netdom.exe Method)
Create a Two-way Trust (MMC Method)
Create a Two-way Trust (Netdom.exe Method)
A shortcut trust relationship is a manually created trust that shortens the trust path to improve the efficiency of users who remotely log on. A trust path is a chain of multiple trusts that enables trust between domains that are not adjacent in the domain
namespace. For example, if users in domain A need to gain access to resources in domain C, you can create a direct link from domain A to domain C through a shortcut trust relationship, bypassing domain B in the trust path.
A shortcut trust relationship has the following characteristics:
It can be established between any two domains in the same forest.
It must be established manually in each direction.
It is transitive.
Tool: Active Directory Domains and Trusts
You can create a shortcut trust by using one of the following methods. Procedures are explained in detail in the linked topics.
Create a Two-way Trust (Netdom.exe Method)
You can remove manually created trusts, but you cannot remove the default two-way transitive trusts between domains in a forest. It is particularly important to verify that you successfully removed the trusts if you are planning to re-create them.
Tool: Active Directory Domains and Trusts or Netdom.exe.
You can remove a manually created trust by using one of the following methods. Procedures are explained in detail in the linked topics.
Remove a manually created trust by using the Active Directory Domains and Trusts snap-in.
Remove a manually created trust by using Netdom.exe.
Security principals in Active Directory have an attribute called SIDHistory to which domain administrators can add users' old SIDs. This is useful during the migration process because users can use their old SIDs to access resources, administrators do not
need to modify ACLs on large numbers of resources. However, under some circumstances it is possible for domain administrators to use the SIDHistory attribute to associate SIDs with new user accounts, thereby granting themselves unauthorized rights.
You can configure SID filtering to prevent this type of attack. You might configure SID filtering under the following circumstances:
You have identified one or more domains in your enterprise where physical security is lax, or where the domain administrators are less well trusted.
You then isolate these less trustworthy domains by moving them to other forests. By definition, all domains within a forest must be trustworthy; if a domain is deemed less trustworthy than the others in the forest, it should not be a forest member. Once
you have moved less trustworthy domains out of the forest, establish external trusts to these domains, and apply access control to protect resources. If you are still concerned about SID spoofing being used for privilege escalation, then apply SID filtering.
Do not apply SID filtering to domains within a forest, as this removes SIDs required for Active Directory replication, and causes authentication to fail for users from domains that are transitively trusted through the isolated domain.
Use the following procedures to configure SID filtering. Procedures are explained in detail in the linked topics.
Remove SID filtering.
very good, thanks