Here's the story in a nutshell: To begin understanding Active Directory, you need to understand five of its key components: namespaces, forests, trees, domains, and objects.
Every instance of Active Directory is a namespace.
•
An Active Directory namespace encompasses one and only one forest.
•
A forest consists of one or more trees.
•
Trees include one or more domains.
•
Each domain lives on its own server or set of servers.
•
How you use forests, trees, and domains depends at least in part on how your organization is structured. All the resources in an Active Directory namespace−forests, trees, domains, users, printers, files, and so on−are objects. Objects are often containers that can hold other objects. For example, a domain is a container that can hold, among other things, subdomains.
In practical terms, if you use a Microsoft Management Console Active Directory snap−in to manage a specific Active Directory, you will see all the domains and subobjects in the forest that are supported by that Active Directory, no matter which specific computer or set of computers any particular domain resides on. Figure 2.2, back in Chapter 2, 'Windows Server 2003 and Exchange Server 2003,' shows the major Active Directory snap−ins in action.
Let's look at each of Active Directory's components in more detail.
Namespaces
Like all directories, Active Directory is at heart a namespace with subnamespaces and subsubnamespaces and subsubsubWell, you get the point. A directory namespace is the place that holds the names of objects. You look in a namespace to find an object and whatever other information you need to use an object. Namespaces are hierarchical in nature. As noted previously, the Microsoft Management Console snap−ins that we explored in Chapter 2 graphically present a variety of views of the Windows Server 2003 Active Directory namespace. It's important to note that, in a very real sense, namespaces are concepts, not visible entities. What you see in Microsoft Management Console are the various objects that exist in the Active Directory namespace. You really don't see the namespace, per se; you see a very nice representation of Active Directory itself, which is the container for all the objects in the Active Directory namespace. Of course, all of this doesn't mean that understanding the concept of namespaces isn't important to understanding Windows Server 2003's Active Directory. Au contraire. Without a clear understanding of namespaces, you'll never master Active Directory. (Also, all of this doesn't mean that I and others won't slip occasionally and refer to the Active Directory namespace as though it were a real container for names.)
Let's start with an example of a namespace. The Internet Domain Name System (DNS) is a namespace. Its major function is to tie natural−language names to IP addresses because the TCP/IP protocol uses IP
addresses for intercomputer communication, not the natural−language names that we're all more comfortable with.
At the top of the DNS hierarchy is a large container that holds all the top−level Internet names, including com, edu, and mil. This container is often represented by a dot. Within each of these top− level Internet
subnamespaces are the subdomains or subsubnamespaces that are for a specific organization, such as microsoft or bgerber. The DNS namespace nests increasingly lower until a specific computer or cluster of computers is identified. Sometimes a specific computer will actually be included in the namespace−as in web1.bgerber.com, for example. Sometimes no computer is named, as is often the case with websites. See Figure 3.1 for a glimpse at a very small piece of the DNS namespace−my own website, bgerber.com.
Figure 3.1: A small piece of the Domain Name System hierarchy
When a program such as a web browser goes hunting for a specific website, it asks an Internet domain name server for a specific domain object, such as www.bgerber.com. The domain name server looks up the requested name in its table. If it finds a match, it then looks up the IP address of that name, such as
216.132.83.21, and sends the IP address back to the browser. This is called resolving the domain name into an IP address. The web browser then uses the IP address to find and talk to the web server. The IP address belongs to the web server computer or possibly to a cluster of computers.
I should point out that www.bgerber.com is a distinguished name. I'm not saying that www.bgerber.com is distinguished in the way that a gray−haired gentleman of 60 years might be distinguished. I'm using the term in its namespace sense to indicate that www.bgerber.com identifies a unique object in the DNS namespace. An object in a directory must have a distinguished name, or it is useless.
Active Directory's namespace functions in a manner quite similar to the DNS namespace. In fact, when some names are resolved in a Windows Server 2003 network−for example, the names of internal computers running the Windows 2003 operating system−DNS is used exactly as it is used on the Internet.
Like DNS, the Active Directory namespace has a structure and specific ways of identifying objects. As noted in Chapter 2, four different naming conventions are used in Active Directory: Lightweight Directory Access Protocol (LDAP), Internet RFC 822 (DNS), Hypertext Transfer Protocol (HTTP) URLs, and Microsoft's Universal Naming Convention (UNC). Also, like DNS, clients query Active Directory for whatever lower−level identifiers are required to access a specific network resource, such as a computer, a printer, a user, a user mailbox, a security policy, a domain, and so on.
Forests, Trees, Domains, and Objects
As mentioned earlier, Windows Server 2003 domains are contained in trees, which are contained in forests. A forest can contain one or more trees. Any given Active Directory namespace covers only one forest. In other words, a forest and a specific Active Directory namespace have contiguous boundaries.
Figure 3.2 shows an Active Directory structure based on a namespace with a forest that contains a single tree. The correct name for such a structure is a single contiguous namespace. Everything in my organization is a subentity of the top−level or root−level Windows Server 2003 domain, bgerber.com. The domains below bgerber.com are called child domains. Single contiguous namespace Active Directory structures model organizations that can be represented as a single hierarchical entity. These entities can be small, such as bgerber.com, or quite large, such as microsoft.com or us.gov. All the domains in Figure 3.2 make up the single tree in the Active Directory namespace.
Figure 3.2: An Active Directory structure based on a single root tree or single contiguous namespace model Active Directory Helps Make Windows Server 2003 Industrial Strength
For the record, all the stuff in your Active Directory is represented in what is called the schema. The stuff is officially called objects. Objects represent everything from Windows 2003 user accounts to Exchange 2003 mailboxes. You can look at the schema and, if you know what you're doing, edit it.
One of the problems with Windows NT server is its somewhat limited capability to support extensive numbers of users and other resources in a domain. One NT domain allows for about 40,000 resource objects, about 20,000 of which can be users. That might seem like a lot until your organization starts growing and you've got lots of users, files, printers, and workstations to support. Then you want much more. With NT Server, the solution is to create multiple domains to handle many resources.
Active Directory supports up to 1 million objects. That's a lot! The main thing is that you no longer need to think multiple domains when structuring your Windows Server 2003 networking environment. For this and other reasons, Microsoft encourages you to think small when it comes to the number of Windows 2003 root−level domains that you create. In fact, in most cases, Microsoft's favorite number for root domains is 1. I'll talk more about this in Chapter 5, 'Designing a New Exchange 2003 System'; Chapter 6, 'Upgrading to Windows Server 2003 and Exchange Server 2003'; and Chapter 7, 'Installing Windows Server 2003 as a Domain Controller.'
Microsoft encourages that, if at all possible, you seriously consider creating one large single tree domain such as the one in Figure 3.2. Assuming that there are no organizational reasons why you can't do this, how do you create one big, happy domain if some of your Windows Server 2003 servers are on low−bandwidth links? As I mentioned in passing in Chapter 2 and in the previous sidebar, 'Active Directory Isn't the Whole House,' you use the site connector and folder replication technology that Windows Server 2003 borrowed from Exchange Server 5.5.
Tip The Active Directory naming choices that you make within your organization need have no impact on how your organization looks to the outside world. Your organization can be killandplunder.com internally and worldlover.com to the Internet. That doesn't mean that you might not want to use the same domain
As long as you know where you want to go both internally and externally, you'll build the right structure from the beginning. If you don't have a road map, watch out. There's nothing less fun than fixing naming decisions down the road. We'll spend more time on naming issues in Chapters 5 and 6.
Now, let's say that you've got a more complex organizational structure and you need to preserve that structure in your Active Directory. Then you need a namespace with a forest that contains multiple trees or domains. Such namespaces are called noncontiguous namespaces because each tree in the forest is independent of the others. There are no unbroken lines from one tree to the other.
In Figure 3.3, you see an organization−let's call it Eat the World, Inc.−that just can't get everything into one root tree. This organization needs four root trees because Eat the World, Inc. really consists of four distinct organizational entities. Note that I've included just the top level of each root tree. Be assured, however, that each of the four trees has a full set of subtrees, just like bgerber.com in Figure 3.2 (shown earlier).
Figure 3.3: An Active Directory namespace based on a forest of root trees or a noncontiguous namespace model
Now let's say that Eat the World, Inc. buys another company. This one, destroyall.com, is such a deviant organization that even the folks who run Eat the World, Inc. can't stomach it being in the same forest as their other blighted trees. Figure 3.4 shows the structure required to make this organizational decision work.
Figure 3.4: An Active Directory noncontiguous namespace based on two forests of root trees
The key here is to understand that both Forest 1 and Forest 2 have their own Active Directory structure and namespace−more specifically, they have their own schema. Each forest must be viewed independently in any Microsoft Management Console Active Directory snap−in. For example, if you open the Active Directory Users and Computers Microsoft Management Console snap−in on any computer that is a member of a domain in Forest 1, you'll be able to manage anywhere from none to all four of the domains in that forest, depending on security. If you open the same interface on a computer that is a member of the one and only domain in Forest 2, and if you have the correct security privileges, you'll be able to manage the domain destroyall.com. I can just hear you. 'Okay, so now I think I understand this namespace, forest, tree, and domain stuff. What's next?'
My first answer is that so much depends on Active Directory and its key components that without a good understanding of them, you're bound to make some serious mistakes. For example, if you don't get your domains and forests in order before you start planning and designing your Windows Server 2003 setup, you could face the misery of either combining domains in a forest or moving a domain from one forest to another. These are not easy tasks.
Furthermore, the domains represented by trees play a major role in Windows Server 2003 security. As with Windows NT Server 4 (and 3.51, for that matter), domains are at the heart of Windows Server 2003 network security. A domain is a security boundary. As with NT Server, users log into domains. When a user logs into a domain, internal security willing, that user can access any resource in the domain.
Windows Server 2003 automatically sets up trust relationships between a root domain and its child domains, such as between bgerber.com and accounting.bgerber.com back in Figure 3.2. Windows Server 2003 also automatically sets up trusts between domains in a noncontiguous namespace (see Figure 3.3, shown earlier). These trusts are transitive, meaning that because all child domains in the forest have trust relationships with the root domain, they also have trusts with each other. So, you don't have to do anything to give all users access to all resources in all child domains in a root domain. Of course, you do have to do something to allow or prevent a user in one domain from accessing specific resources in another domain.
Note Windows Server 2003 brings a neat new Active Directory feature to the table when compared with Windows 2000 Server. With 2003, you can set up cross−forest trusts. While this doesn't let you treat Forest A as though it were simply a domain in Forest B, it does make cross−forest authentication and, thus, resource access possible.
Now let's talk a bit more about objects. Objects in Active Directory are the resources that you work with. In a sense, they represent the real stuff that you work with in Active Directory. Forests, trees, and domains are objects. Like all objects, Active Directory objects have attributes that define them. For example, users have first, last, and middle name attributes. Printers have paper size, ink available, and other attributes.
I won't go into detail about all the issues relating to objects. Suffice it to say that Active Directory objects are the result of a very disciplined implementation of object−oriented programming design by Microsoft. As an Active Directory user, you don't need to understand object−oriented programming. You just need to
appreciate the role that objects play in making Active Directory a real−world repository for almost all the services and functionality required to run and manage a complex operating system.
Before we leave namespaces, forests, trees, domains, and objects, I should mention two other Windows Server 2003 objects: Global Catalogs and organizational units.
Every domain has a Global Catalog, which contains all the Active Directory information for its host domain. A Global Catalog also contains partial information for all the objects in other domains in the forest. This partial information is at least adequate to ensure that the object exists in the particular domain. A domain's Global Catalog allows for faster extra−domain searches, because a search for an object in another domain doesn't require time−consuming cross−domain network access and right−to−search authentication. Organizational units are used to group objects within a domain. They're a nice way to create domainlike substructures when you want to assign different tasks or security rights to different persons or groups within a domain. Rights and privileges in an organizational unit apply only within the unit, not to the domain as a whole. Organizational units require much less overhead than domains. They help you reach Microsoft's new goal of keeping everything in one domain, if at all possible. I'll discuss these neat little tools further in Chapter 11, 'Managing Exchange Users, Distribution Groups, and Contacts,' and Chapter 15, 'Installing and Managing Additional Exchange Servers.'