Overview (Synopsis)

Active Directory domains rarely exist in isolation. Many Active Directory deployments in customer sites consist of two or more domains that represent boundaries between different geographical, managerial, organizational, or administrative layouts. For example, when company "A" acquires company "B," it quickly becomes necessary for preexisting domains to start trusting each other. Alternately, in some deployments, servers that have a specific role (such as a mail server) can be members of a "resource domain", easing the management burden by combining like roles under one administrative domain.

Enabling communication between disparate domains, especially secure communication involving authentication and authorization, requires that some stateful knowledge be shared between the peer domains in order for them to trust one another. Some of this knowledge is sensitive, forming the cryptographic basis of trust mechanisms used in protocols such as Kerberos and Netlogon RPC. Other state is public knowledge, such as the NetBIOS name of a peer domain, or which security identifiers are owned by the peer domain. Information like this plays a crucial role when performing name lookups, which are essential for authorization, locating user accounts, or simply displaying information in some type of user interface.

Active Directory stores trust information in trusted domain objects (TDOs) and, depending on the kind of trust established, in associated user accounts (interdomain trust accounts) for the trusted domain. This section of the document details the contents of these objects, focusing on analysis of the properties that are specific to TDOs and interdomain trust accounts, and that are essential for proper interdomain functionality.