Within a forest, you can establish parent-child, tree-root, and shortcut trust relationships. All these intraforest trust relationships are two-way and transitive. (Shortcut trusts can be set up one-way, but shortcut trusts don't affect security.) When deciding whether to create a domain within a forest, consider several factors. All domains in a forest trust each other, so the new domain must be able to implement a minimum level of security appropriate for the rest of the forest. Also, by default, all domains are subject to the Administrators group of the forest root domain because of default permissions assigned to the Enterprise Admins group. Is this authority appropriate given the resources in the new domain? Last, although officially, administrators of one domain have no inherent authority in other domains in the forest, Active Directory (AD) has a vulnerability that, if exploited, could potentially result in administrators of one domain gaining administrative authority in another domain. Some companies that have a section of their business (such as classified government work) that needs complete protection from other administrators choose to implement a separate forest for the sensitive area instead of just a separate domain within the same forest.
External trusts, forest trusts, and realm trusts extend trust beyond a forest. External trusts allow you to set up a one- or two-way trust with a domain in another forest or a legacy Windows NT 4.0 domain. External trusts are nontransitive (i.e., limited to the two domains directly linked to each other). External trusts are limited to the NT LAN Manager (NTLM) authentication protocol, which is a relatively weak authentication protocol, but you can improve protection against password sniffing and cracking by using NTLMv2 rather than NTLM to configure domain controllers (DCs) and client computers in the trusted domain and DCs and servers in the trusting domain. Trusting domains are also vulnerable to SID manipulation by administrators of the trusted domain. Unless SID filtering is enabled, a trusted-domain administrator can insert spurious SIDs in an account's SID history property that correspond to group SIDs (such as Administrators, Domain Admins, or Enterprise Admins) from the trusting domain's forest. With SID filtering enabled for the trust relationship, the trusting DC will filter out spurious SIDs it receives in authentication requests from the trusted domain.
Forest trusts are new to Windows Server 2003 forests. A two-way trust created between two Windows 2003 forests extends the implicit trust normally found between all domains in the forest to include all domains in both forests. A one-way forest trust means that all domains in the trusted domain trust all the domains in the trusted forest but not the other way around. Forest trusts support both NTLM and Kerberos, so again the need for implementing NTLMv2 between the two trusting parties arises. Forest trusts are vulnerable to the same SID-manipulation risks as external domains, so SID filtering should be enabled. Forest trusts are a good way to achieve the same level of trust between all domains in two forests without the risk of domain administrators in one domain in a forest stealing administrative authority in another domain of the other, trusted forest.
However, domains joined by a cross-forest trust don't share two AD resources that are shared by all domains in a forest: the Global Catalog (GC) and the schema. Schema changes in one forest won't pass beyond the forest boundary. This isn't a problem in most cases because, if necessary, you can just apply the same schema changes in the other forest. The lack of a single, unified GC, however, isn't so easy to solve. The GC is what makes domain boundaries transparent to users when they try to find other users, distribution groups, servers, or other resources. When your organization is broken into multiple forests, your users must become aware of forest boundaries and which users, departments, and resources reside in which forest. To restore user transparency to a multiforest environment, you can use the free Microsoft Identity Integration Server (MIIS) Feature Pack for Windows Server Active Directory to synchronize objects between forests. For instance, if you have two forests, A and B, you can set up MIIS Feature Pack to publish forest A user accounts as contact objects in forest B and forest B user accounts as contacts in forest A, thus enabling users to find each other and communicate via Microsoft Exchange Server.
