3.3 Trust relationships: Under the hood

Let’s look at what is behind a “trust relationship” and what happens when you manually set up a one-way trust relationship in Windows Server 2003.

In the example in Figure 3.7, the domain administrator of domain South decides to trust another domain, North. In this case South is the trusting domain and North is the trusted domain. When the administrator sets up the trust, Windows will create a Trusted Domain Object (TDO) for the North domain in the AD domain naming context of domain South (this is on the outgoing side of the trust). This account will be called South. Just as for any other AD account, there will be a security principal password linked to this object. This password is sometimes also referred to as the 3.3 Trust relationships: Under the hood interdomain secret. When you set up a trust relationship manually, the OS will actually prompt you for this password. When the administrator in the South domain or the administrator in the North domain creates the other side of the trust in the North domain (the incoming side), another TDO called South will be created in the AD domain naming context of domain North.

Figure 3.7: Trust relationships: behind the scenes.

You can look at the TDO account objects using the AD Users and Computers MMC snap-in or using AdsiEdit. The TDOs are located in the domain naming context underneath the system container (as illustrated in Figure 3.8). Table 3.2 shows the most important trust-related attributes of an AD TDO object.

Figure 3.8: Checking out TDO objects using ADSI Edit.

Table 3.2: Key AD TDO Object Trust-Related Attributes

TDO Attribute	Meaning/Values
TrustAttributes	Trust properties. Values: 1: trust is nontransitive 2: trust valid only for Windows and later computers 40 0000: trust to a parent domain 80 0000: trust to root domain of another domain tree
TrustDirection	The direction of a trust. Values: 1: incoming trust 2: outgoing trust 3: two-way trust
TrustPartner	The name of the domain with which a trust exists. For Windows 2000 and later this is a DNS name. For Windows NT this is a NetBIOS name.
TrustType	The type of trust. Values: 1: downlevel trust (to a Windows NT domain) 2: Windows 2003 trust (with an AD domain) 3: MIT trust (with MIT Kerberos v5 realm) 4: DCE trust (with DCE realm)
TrustAuthIncoming	Authentication information for the incoming portion of a trust.
TrustAuthOutgoing	Authentication information for the outgoing portion of a trust.

The South TDO account is replicated among the DCs in the North domain using plain AD domain naming context replication. The same is true for the North TDO in the South domain. The TDOs and some of their attributes are also replicated to the global catalog (GC). This makes them available to all entities in a Windows forest. The latter enables the routing of cross-domain and cross-forest authentication requests and object browsing (explained in the following sections).

What are these TDOs and their passwords (the interdomain secrets) used for? One of the things they are used for is the setup of a secure channel between the domains North and South. A secure channel is set up when the first domain controller of domain South boots up and on condition that a domain controller of domain North is available. It is used to secure the authentication traffic between the trusting and the trusted domain. As other domain controllers become available they will set up their proper secure channels.

Windows 2000 introduced the concept of a forest as a logical and administrative grouping of several Windows domains that are linked together using trust relationships. A forest provides ease of use and administration for resources that must be available to the users of different domains. It also facilitates the deployment, administration, and use of enterprise applications such an Exchange-based mail infrastructure.

As the knowledge of the forest concept matured, it became clear that it takes away some of the domain boundaries that are available in earlier Windows versions. In Windows 2000 the domain cannot be considered a true security boundary anymore: The final border is the forest. As a consequence, a certain amount of trust is required between the different domains in a forest and their administrators.

A lot of organizations cannot live with these trust requirements for political, legal, or purely administrative reasons and have deployed multiple Windows forests. Many organizations built multiple forests for reasons of a company merger or a set of company acquisitions. Another example is the requirement to build two forests for perimeter security reasons: one forest for the intranet and another one for the demilitarized zone (DMZ).

A major problem in Windows 2000 is the definition of cross-forest trust. From a security administration point of view, the creation of cross- forest trust is an administrative nightmare that basically puts your Windows 2000 environment back in the NT4 era (remember the spaghetti model of trust). A general shortcoming of Windows 2000 trust relationships is that, just like their predecessors, they can only define trust in a very coarse-grain way, a characteristic that is not particularly useful in a cross-forest environment where you may want to restrict what is exchanged and accessed between forests.

It is clear that Windows 2000 is not made to easily support multiple forests. In Windows Server 2003, Microsoft resolved most of the Windows 2000 multiple forest and cross-forest trust problems and shortcomings through the introduction of a new trust type called “forest” trust.