Trust Relationships

Active Directory provides security across multiple domains through interdomain trust relationships. When there are trust relationships between domains, the authentication mechanism for each domain trusts the authentication mechanism for all other trusted domains. If a user or application is authenticated by one domain, its authentication is accepted by all other domains that trust the authenticating domain. Users in a trusted domain have access to resources in the trusting domain, subject to the access controls that are applied in the trusting domain.

Note

"Access to resources" in any discussion of trust relationships always assumes the limitations of access control. Trust relationships allow users and computers to be authenticated (to have their identity verified) by an authentication authority. Access control allows authenticated users to use the resources (files, folders, and virtual containers) that they are authorized to use and prohibits them from using (or even seeing) resources that they are not authorized to use. For more information about resource authorization, see "Access Control" in this book.

Transitive and Nontransitive Trust

In Windows NT 3.51 and Windows NT 4.0, trust relationships must be created explicitly in one direction. A two-way trust relationship is established by creating two one-way trust relationships. Domains can be connected by explicit one-way or two-way trust relationships for the purpose of enabling access to resources, but they are not necessarily related in any other way.

In Windows 2000, domains can be joined to a domain tree or forest, and each child domain has an automatic two-way trust relationship with the parent domain. This trust relationship is also transitive. Transitive trust means that the trust relationship extended to one domain is extended automatically to any other domain that is trusted by that domain. Transitive trust is applied automatically for all domains that are members of the domain tree or forest. Therefore, when a grandchild domain is created, the trust relationship between the parent and child domains is accepted by the grandchild domain, and vice versa. For example, if a user account is authenticated by the parent domain, the user has access to resources in the grandchild domain. Similarly, if the user is authenticated by a child domain, the user has access to resources in the parent domain, as well as in the grandparent domain.

The effect of transitive trust in Windows 2000 domains is that there is complete trust between all domains in an Active Directory forest — every domain has a transitive trust relationship with its parent domain, and every tree root domain has a transitive trust relationship with the forest root domain.

Note

In Windows 2000, transitive trust relationships are always two-way trust relationships.

A nontransitive trust relationship can be created between Windows 2000 domains when a transitive trust relationship is not appropriate, but this trust relationship must be created explicitly. It can be created, for example, between two Windows 2000 domains that are not in the same forest.

A trust relationship between a Windows 2000 domain and a Windows NT 4.0 domain is always a nontransitive trust relationship. If one of these domains is an account domain and the other is a resource domain, the trust relationship is usually created as a one-way trust relationship. If there are user accounts in both domains, two one-way trust relationships can be created between them.

The trust relationship between two domains — whether one-way or two-way, transitive or nontransitive — is stored as an interdomain trust account object in Active Directory.

For more information about the nature and management of interdomain trust objects, see "Authentication" in this book. For more information about mixed-mode trust relationships, see "Determining Domain Migration Strategies" in the Deployment Planning Guide.

Direction of Trust

In describing trust relationships, arrows illustrate the direction of trust between domains as follows:

• If B is the trusting domain and A is the trusted domain, B-->A indicates that domain B trusts domain A. (The same trust relationship can be illustrated as A<--B, that is, A is trusted by B.)
• When domain B trusts domain A (B-->A), users with accounts in domain A can be authenticated for access to resources in domain B. However, users with accounts in domain B are not trusted to be authenticated for access to resources in domain A.

A hierarchy of Windows 2000 domains is implemented by trust relationships between domains. The direction of the trust relationship between a parent domain and its child domain in Active Directory is two-way (A<---->B), but it has the following restrictions:

• The parent-child relationship between two domains in a domain tree is defined by a subordinate name relationship. For example, noam.reskit.com is a child of reskit.com, but noam.com is not a child of reskit.com. A parent-child trust relationship requires both a parent-child relationship and a direction of trust, as follows: Domain A can be specified as the parent of domain B only if B-->A and B is a subordinate name of A.
• When a new domain joins a domain tree as a child, a parent-child trust relationship is defined automatically that establishes a two-way, transitive trust relationship.

Note

Automatic configuration of replication topology requires that all parent-child trust relationships within the forest are bidirectional and transitive.

The use of two-way, transitive trust relationships reduces management time because it decreases by more than half the number of trust relationships that must be managed, as the diagram in Figure 1.8 illustrates.

Enlarge figure

Figure 1.8 Comparison of Two-way Trust Relationships in Windows NT 4.0 and Windows 2000

Authentication Protocols

Windows 2000 authenticates users and applications by using one of two protocols: the Kerberos v5 authentication protocol or the NTLM authentication protocol. The protocol to be used is determined by the capabilities of the client and the server. If the client does not recognize the Kerberos protocol (for example, a computer that is running Windows NT 3.51 or Windows NT 4.0), authentication occurs by using the NTLM challenge-response protocol. Conversely, if the resource server does not support Kerberos authentication, the client uses NTLM to authenticate to the server.

The Kerberos v5 protocol is the default protocol for network authentication on computers that are running Windows 2000. The NTLM protocol is the default for network authentication in Windows NT 4.0 and for Windows 95–based and Windows 98–based computers that are running Distributed Systems Client. It is retained in Windows 2000 for compatibility with previous versions of Windows-based clients and servers. But the protocol of choice in Windows 2000, when there is a choice, is the Kerberos protocol.

In Windows 2000 domains, the Kerberos v5 authentication protocol is used to authenticate logons when all of the following conditions are true:

• The user who is logging on uses a security account in a Windows 2000 domain.
• The computer that is being logged on to is a Windows 2000–based computer.
• The computer that is being logged on to is joined to a Windows 2000 domain.
• The computer account and the user account are in the same forest.

For any other combination of conditions, such as a computer that is running Windows NT 3.51 or Windows NT 4.0, a user who has an account in a Windows NT 3.51 or Windows NT 4.0 domain, or a domain that is a Windows NT 3.51 or Windows NT 4.0 domain, the NTLM protocol is used to authenticate logons.

The essential differences between the two protocols are these:

• When the NTLM protocol is used, the server must contact a domain authentication service on a domain controller to verify the client credentials. A server authenticates a client by forwarding the client credentials to a domain controller in the client account domain.
• When the Kerberos protocol is used, the server does not have to contact the domain controller. A client gets a ticket for a server by requesting one from a domain controller in the server account domain; the server validates the ticket without consulting any other authority.

For more information about the Kerberos v5 and NTLM authentication protocols, see "Authentication" in this book.

Trust Path

A trust path is defined by a series of trust links from one domain to another domain for passing authentication requests. For example, when a user makes a request for information from a server in a domain other than the domain in which the user is currently logged on, the server must be able to authenticate the user. Before authentication can occur, Windows security must determine whether the domain that is requested (the domain in which the contacted server is located) has a trust relationship with the logon domain of the user account. To make this determination, the Windows 2000 security system computes a trust path between the domain controller for the server that receives the request and a domain controller in the requesting user's account domain.

In the Windows 2000 distributed security model, every workstation and server has a direct trust path to a domain controller in the domain in which it is located. The trust path is implemented by the Net Logon service through an authenticated remote procedure call (RPC) connection to the trusted domain authority — namely, the domain controller. In addition, a secure channel extends to other Windows 2000 domains through interdomain trust relationships. The secure channel is used to obtain and verify security information, including security identifiers (SIDs) for users and groups.

Every Windows 2000 domain has knowledge of all other domains in the forest, as well as of all external domains that it directly trusts or that trust it. By using this information, a domain controller builds the shortest path for authentication. When building the trust path, each domain is first checked to see whether it is the requested domain and then checked for any shortcut trust relationships to the requested domain. If none of these conditions exists, the request is passed ("referred") to the parent domain (because by definition, the child domain trusts the parent domain). However, if there is no transitive trust relationship, the request is denied. If the request is passed all the way to the root domain, it can be referred to a different domain tree root in the forest or, if an external trust relationship exists, to a domain in a different forest.

Note

A shortcut trust relationship is a trust relationship that is created explicitly to shorten the trust path between domains that are in the same forest.

If the authentication request is referred, a path is computed for either NTLM pass-through authentication or for a Kerberos referral by using the information about the tree and current shortcut trust relationships to find the path to the destination domain. In this computation, shortcut trust relationships play the role of circumventing the higher domains in the hierarchy. At each level of the tree, a check is made of the shortcut trust relationships that might exist. If one is found to the destination domain, the next domain in the tree does not have to be checked.

Processing Authentication Referrals

When a request for authentication is referred, trust relationships must be taken into account with respect to their direction and whether they are transitive or nontransitive. The two Windows authentication protocols process referrals differently.

Kerberos v5 Authentication Protocol

If the client uses the Kerberos v5 protocol, the client requests a ticket to the server in the target domain from a domain controller in its account domain. The Kerberos Key Distribution Center (KDC) is a service that acts as a trusted intermediary between a client and server; it provides a session key that enables the two parties to authenticate each other. If the target domain is different from the current domain, the KDC uses the following logic to determine whether an authentication request can be referred:

• Is the current domain trusted directly by the domain of the server that is being requested?
  • If yes, send the client a referral to the requested domain.
  • If no, go to the next step.
• Is there a transitive trust relationship between the current domain and the next domain on the trust path?
  • If yes, send the client a referral to the next domain on the trust path.
  • If no, send the client a logon-denied message.

NTLM Authentication Protocol

If the client uses the NTLM authentication protocol, the initial request for authentication goes directly from the client to the resource server in the target domain. This server sends the user's security credentials to a domain controller in its computer account domain. This domain controller checks the user account against its security accounts database. If the account does not exist, the domain controller uses the following logic to perform pass-through authentication, forward the request, or deny the request:

• Does the current domain have a direct trust relationship with the user's domain?
  • If yes, the domain controller sends the credentials of the client to a domain controller in the user's domain for pass-through authentication.
  • If no, go to the next step.
• Does the current domain have a transitive trust relationship with the user's domain?
  • If yes, pass the authentication request on to the next domain in the trust path. This domain controller begins the process again by checking the user's credentials against its security accounts database.
  • If no, send the client a logon-denied message.

For more information about NTLM authentication and Kerberos v5 authentication mechanisms, see "Authentication" in this book. For more information about cross-reference objects in the Configuration container, see "Name Resolution in Active Directory" in this book.

Types of Trust Relationships

The following types of trust relationships can be established with Windows 2000 domains:

Tree-Root Trust Relationship. A tree-root trust relationship is the trust relationship that is established when you add a new tree to a forest. The Active Directory installation process automatically creates a trust relationship between the domain you are creating (the new tree root) and the forest root domain. A tree-root trust relationship has the following restrictions:

• It can be set up only between the roots of two trees in the same forest.
• It must be transitive and two-way.

Parent-Child Trust Relationship. A parent-child trust relationship is the trust relationship that is established when you create a new domain in a tree. The Active Directory installation process automatically creates a trust relationship between the new domain and the domain that immediately precedes it in the namespace hierarchy (for example, noam.reskit.com is created as the child of reskit.com). The parent-child trust relationship has the following characteristics:

• It can exist only between two domains in the same tree and namespace.
• The parent domain is always trusted by the child domain.
• It must be transitive and two-way in Windows 2000. The bidirectional nature of transitive trust relationships allows the global directory information in Windows 2000 to replicate throughout the hierarchy.

Shortcut Trust Relationship. A shortcut trust relationship (also called a cross-link trust relationship) is a manually created trust relationship that improves the efficiency of remote logons by shortening the trust path. If users in domain A often need to gain access to resources in domain C, you might want to create a direct link through a shortcut trust relationship so that domain B can be bypassed 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 set up manually in each direction.
• It must be transitive.

External Trust Relationship. An external trust relationship is a manually created trust relationship between Windows 2000 domains that are in different forests or between a Windows 2000 domain and a domain whose domain controller is running Windows NT 4.0 or earlier. An external trust relationship has the following characteristics:

• It is one-way.
• It must be set up manually in each direction to establish a two-way external trust relationship.
• It is nontransitive.

Non-Windows Kerberos Realm Trust Relationship. A trust relationship that can be established between a non-Windows Kerberos realm and a Windows 2000 domain. This trust relationship allows cross-platform interoperability with security services based on other Kerberos v5 implementations. (For more information about non-Windows Kerberos interoperability and setting up trust relationships between Windows 2000 domains and non-Windows Kerberos realms, see the Microsoft Windows 2000 Server link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Follow the links to Deployment and then Security Services.)

The non-Windows Kerberos realm trust relationship has the following characteristics:

• It is used only by the Kerberos v5 authentication protocol, not by NTLM or other authentication protocols.
• It is one-way by default. To establish a two-way trust relationship, a one-way trust relationship in each direction must be set up manually.
• It is nontransitive by default.
• When the direction of trust is from a non-Windows Kerberos realm to a Windows 2000 domain, the non-Windows Kerberos realm trusts all security principals in the Windows 2000 domain.
• When the direction of trust is from a Windows 2000 domain to a non-Windows Kerberos realm, account mappings in Active Directory are used to map a foreign Kerberos identity in a trusted non-Windows Kerberos realm to a local account identity in a Windows 2000 domain. The Windows 2000 domain uses only the account to which the non-Windows principal is mapped to evaluate access to domain objects that have security descriptors. This identity is required because non-Windows Kerberos tickets do not contain all of the authorization data that is needed for Windows 2000. All such Windows 2000 proxy accounts can be used in groups and on access control lists (ACLs) to control access on behalf of the non-Windows security principal.

  MIT account mappings are managed by using Active Directory Users and Computers. (For more information about MIT Kerberos interoperability and managing foreign Kerberos identities, see the Microsoft Windows 2000 Server link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Follow the links to Deployment and then Security Services.)

Note

If you create a non-Windows Kerberos realm trust relationship by using Active Directory Domains and Trusts, the trust is one-way and nontransitive. You can use the Netdom tool (Netdom.exe) to establish two-way, transitive, non-Windows Kerberos realm trust relationships. You also can use Netdom to modify a non-Windows Kerberos realm trust relationship that you created in Active Directory Domains and Trusts; you can change the trust relationship from non-transitive to transitive by using the /Transitive:yes option in Netdom. (To use Netdom, install the Support Tools that are located in the Support\Tools folder on the Windows 2000 Server operating system CD. To install the tools, double-click the Setup icon in that folder.) For more information about using Netdom to create non-Windows Kerberos realm trust relationships, see Windows® 2000 Support Tools Help.

Use Active Directory Domains and Trusts to manage trust relationships by using the properties of a domain object. The Properties page shows two lists; one shows the trusted domains (Domains trusted by this domain), and the other shows the trusting domains (Domains that trust this domain) for the current domain.

For more information about establishing trust relationships by using Active Directory Domains and Trusts, see Windows 2000 Server Help. For more information about planning trust relationships, see "Determining Domain Migration Strategies" in the Deployment Planning Guide.

Trust Relationships Between Windows 2000 and Windows NT 4.0 Domains

Windows 2000 and Windows NT 4.0 domains can trust each other so that users from either domain can authenticate in the other domain to gain access to resources, but users can do so only if explicit, one-way trust relationships have been created between the domains.

The following examples illustrate the effect of the direction of trust between a Windows 2000 domain and a Windows NT 4.0 domain.

• A (Windows 2000 domain) --> B (Windows NT 4.0 domain). This trust relationship indicates that users in domain B have access to resources in domain A but do not have access to resources in any other domain within the tree.
• B (Windows NT 4.0 domain) --> A (Windows 2000 domain). This trust indicates that only users in domain A (not users in other domains within the tree) have access to resources in domain B.

When a client views Windows 2000 trust relationships from a Windows NT 4.0–based computer, the list of trust relationships that is displayed depends on the type of domain to which the computer belongs:

• In a native-mode domain, the client sees a complete list of the domains in the forest.
• In a mixed-mode domain, the client sees only those domains that are trusted directly by the domain to which the client belongs. In a mixed-mode domain, the client can be using a Windows NT 4.0–based backup domain controller. To ensure consistent results, whether it uses a Windows NT 4.0–based domain controller or a Windows 2000–based domain controller, the same limited list of domains is presented to the client in both cases.

Mixed-Environment Scenario

Figure 1.9 illustrates a mixed environment of two Windows 2000 forests and a Windows NT 4.0 domain. In all, four separate namespaces are implemented: A.com, D.com, G.com, and F.

Enlarge figure

Figure 1.9 Mixed Environment of Two Forests and a Windows NT 4.0 Domain

The following conditions are represented in Figure 1.9:

• A.com and D.com are the roots of separate trees in forest 1. The two-way, transitive, tree-root trust between them provides complete trust between all domains in the two trees of forest 1.
• E.D.com uses resources in C.A.com for everyday business operations. To shorten the trust path between the two domains, C.A.com trusts E.D.com directly. This trust relationship serves only the purpose of shortening the trust path for authenticating E.D.com users to use resources in C.A.com. The path is shortened by cutting the number of hops required for authentication from three (E.D.com to D.com, D.com to A.com, and A.com to C.A.com) to one (E.D.com to C.A.com), which increases the speed of authentication.
• G.com is the root of a single tree that makes up forest 2. The two-way, transitive trust relationship between G.com and H.G.com allows both domains to use each others' resources.
• Domain G.com in forest 2 implements an explicit one-way external trust relationship with domain D.com in forest 1; users in domain D.com are trusted to use resources in domain G.com. Because the trust relationship is nontransitive, no other domains in forest 1 have access to resources in G.com, and D.com does not have access to resources in H.G.com.
• Domain F is a Windows NT 4.0 domain that provides support services to the users in E.D.com. This one-way nontransitive trust relationship does not extend to any other domains in forest 1.

© 1985-2000 Microsoft Corporation. All rights reserved.