[ Team LiB ] |
IntroductionTo the layperson, the title of this chapter may seem like a hodgepodge of unrelated terms. For the seasoned Active Directory administrator, however, these terms represent the most fundamental and, perhaps, most important concepts within Active Directory. In simple terms, a forest is a collection of data partitions and domains; a domain is a hierarchy of objects that is replicated between one or more domain controllers; a trust is an agreement between two domains to allow security principals (i.e., users, groups, and computers) to access resources in either domain. Active Directory domains are named using the Domain Name Service (DNS) namespace. The domains that are part of a common DNS namespace are considered to be in the same domain tree. For example, the amer.rallencorp.com, emea.rallencorp.com, and rallencorp.com domains are part of the rallencorp.com domain tree. A single domain tree is sufficient for most implementations, but one example when multiple domain trees are necessary is with large conglomerate corporations. Conglomerates are made up of multiple individual companies. Each company typically wants to maintain its own identity and, therefore, its own namespace. Describing the conglomerate scenario is a good way to show the relationships between forests, domains, domain trees, and trusts. Assuming each company within the conglomerate wants its Active Directory domain name to be based on its company name, you have two choices for setting up this type of environment. You could either make each company's domain(s) a domain tree within a single forest or you could implement multiple forests. One of the biggest differences between the two options is that all the domains within the forest trust each other, whereas separate forests by default do not trust each other. Without the trust relationships, users from one forest cannot access resources in the domains of the other forest. If you want users to be able to access resources within each company's domains, using separate domain trees is an easier approach than separate forests. Transitive trusts are established between the root domains of each domain tree within a forest. As a result, every domain within a forest, regardless of which domain tree they are in, is trusted. Figure 2-1 illustrates an example with three domain trees in a forest called rallencorp.com. Figure 2-1. Multiple domain trees in a forestIf you implement the alternative approach and create multiple Windows 2000 Active Directory forests, to create the fully trusted model you would have to create individual trusts between the domains in every forest. This can get out of hand pretty quickly if there are numerous domains. Fortunately, with Windows Server 2003 Active Directory, you can use the new trust type called forest trust to create a single transitive trust between two forest root domains. This single trust causes all of the domains in both forests to trust each other. There are many more issues to consider when deciding how many forests, domains and domain trees to implement. For a thorough explanation of Active Directory design considerations, I recommend reading Part II of Active Directory, Second Edition (O'Reilly). In this chapter, I cover the most common tasks that you would need to do with forests, domains, and trusts. First, I'm going to review how each is represented in Active Directory. The Anatomy of a DomainDomains are represented in Active Directory by domainDNS objects. The distinguished name (DN) of a domainDNS object directly corresponds to the fully qualified DNS name of the domain. For example, the amer.rallencorp.com domain would have a DN of dc=amer,dc=rallencorp,dc=com. Table 2-1 contains a list of some of the interesting attributes that are available on domainDNS objects.
In Active Directory, domains are naming contexts (NCs) and are also represented under the Partitions container in the Configuration NC as crossRef objects. In this case, the relative distinguished name (RDN) of the crossRef object is the NetBIOS name of the domain as defined by the netBIOSName attribute of the domain object. In our previous example of amer.rallencorp.com, the corresponding crossRef object for the domain (assuming the forest name was rallencorp.com) would be located at cn=AMER,cn=Partitions,cn=Configuration,dc=rallencorp,dc=com. Table 2-2 contains some interesting attributes of crossRef objects.
The Anatomy of a TrustTrusts are stored as trustedDomain objects within the System container of a domain. Table 2-3 lists some of the important attributes of trustedDomain objects.
A trust also has a corresponding user object in the Users container of a domain. This is where the trust password is stored. The RDN of this user object is the same as the cn attribute for the corresponding trustedDomain object with a $ appended. The Anatomy of a ForestA forest is a logical structure that is a collection of domains, plus the configuration and schema naming contexts, and application partitions. Forests are considered the primary security boundary in Active Directory. By that I mean, if you need to definitively restrict access to a domain such that administrators from other domains do not have access, you need to implement a separate forest (and subsequently a domain in that forest), instead of using a domain within the current forest. This is due to the transitive trust relationship between all domains in a forest and the extensive permissions that members of the Domain Admins group have. Unlike domains and trusts, a forest is not represented by a container or any other type of object in Active Directory. At a minimum, a forest consists of three naming contexts: the forest root domain, the Configuration NC, and the Schema NC. The Partitions container in the Configuration NC contains the complete list of partitions that are associated with a forest. Here is a description of the type of partitions that can be part of a forest:
|
[ Team LiB ] |