Trusts didn't go away when Windows 2000 (Win2K) came onto the scene—they just changed a lot. Actually, Active Directory (AD) continues to support Windows NT-style trusts, and for good reason.
First, a quick review of the primary type of trust—the one that exists between parent and child domains in the same forest. As Figure 22.1 shows, every child domain has a two-way, automatic, nonconfigurable trust with its parent. This trust is transitive, meaning that, in this example, domains B and C trust one another through their trust with their parent, domain A.
Figure 22.1: Native Win2K AD trusts.
It's important to remember that trusts don't necessarily confer any special privileges to any users; it simply makes it possible for user accounts in one domain to be granted permissions to resources in another domain. The exception is the Enterprise Admins group, which has special, full administrative control over every domain in the forest.
An AD domain, not a forest, can establish a manual, one-way, non-transitive trust with another AD domain, a Kerberos domain, or an NT 4.0 domain. Figure 22.2 shows an example.
Figure 22.2: Foreign AD trusts.
In this example, Domain B trusts Domain D, meaning Domain B can assign permissions on resources to user accounts contained within Domain D. The relationship is not reciprocal; if Domain D wants to utilize accounts from Domain B, a separate, independent D-trusts-B trust will have to be created.
In addition, these trusts are not transitive. Although Domain C trusts Domain E, it does not follow that Domain B also trusts Domain E even though Domain B trusts Domain C. If Domain B wants to utilize user accounts that exist in Domain E, a separate trust will have to be established in which Domain B trusts Domain E.
The trust relationship, especially the ability to obtain security IDs (SIDs) for user accounts in the trusted domain, lies with the domain controller holding the PDC emulator role in AD domains, with the PDC in NT domains, and with an individual Kerberos server for Kerberos realms. The inter-domain communications are critical and are encrypted. The encryption key is a shared secret, or password, which you create when you establish the trust. Actually, as soon as the trust is established, the two domains negotiate a new password, which they then change on a periodic basis. One problem in trust relationships is when the two domains lose sync of the trust password. In that case, you'll have to delete and re-create the trust. Doing so will not generally affect the permissions assigned to users from the trusted domain, provided you repair the trust quickly.
You can use the Netdom command-line tool from the Support Tools to verify, delete, and create trusts in a Win2K domain.
Note that the trust relationship between Domain C and Domain E in this example does not necessarily make Domain E a member of the forest containing Domain A, Domain B, and Domain C. New domain trees can be added to an existing forest, but you make this decision when you install the domain controller. Domain C and Domain E, in this example, do not necessarily share a common AD schema because they are separate forests.
It's possible for a domain in one tree to trust a domain in another tree, as Figure 22.3 illustrates.
Figure 22.3: Two trees with inter-domain trusts.
In this example:
In other words, the normal two-way transitive trusts operate within each tree, and one domain from each tree trusts a foreign domain. The manual trust between Domain C and Domain E is non-transitive and one-way. Again, this configuration has not formed a forest of six domains: there are two forests, with three domains, and one domain tree apiece, and the two forests don't trust one another. Password synchronization occurs between the PDC emulators in Domain C and Domain E.
New in Windows Server 2003, inter-forest trusts allow two forests to trust one another. These trusts are one-way or two-way, and they take advantage of the transitive nature of intra-tree trusts. For example, Figure 22.4 shows two forests, each with three domains in a single domain tree. The root domains in each forest trust one another.
Figure 22.4: Inter-forest trust.
This feature is only available in AD domains in which all domain controllers are running Windows Server 2003 and the forest functional level has been raised to its highest level, Windows Server 2003 Native.
In this example, Domain, West.Domain, and East.Domain all trust Other, West.Other, and East.Other. The trust, then, is transitive. You can also configure a two-way trust, which in this example, would result in all six domains trusting one another. Forest trusts can use SID filtering, which prevents specific SIDs in one domain from being used in another domain.
New in Windows Server 2003: Forest trusts were created to acknowledge the power of the Enterprise Admins group. Prior to forest trusts, Microsoft often stated that domains were the primary security boundary. In fact, as a result of the forest-wide rights of Enterprise Admins, the forest was the only true security boundary. Many enterprises created separate forests to resolve political issues about who controlled which resources; forest trusts give these organizations a way to provide easier crossforest access to their users, while restricting control of the Enterprise Admins group in each forest. SID filtering can be used to ensure that foreign Enterprise Admins have no control in a forest, and they have no rights in a foreign forest by default.
Forest trusts are considered to be an external trust, and as with any other external trust, there's no implicit synchronization of data. For example, the Domain and Other domain trees do not have to share a common AD schema, as they would if both trees belonged to the same forest. There's also no synchronization of address lists or directory objects of any kind, and Global Catalog (GC) servers in each forest maintain independent catalogs. If synchronization of some kind is desired, check out Microsoft Metadirectory Services (MMS), which can be used to synchronize objects across multiple directory services or domains.