What makes Active Directory so configurable, and so scalable, is that it separates the logical structure of the Windows Server 2003 domain hierarchy—which is made up of domains, trees, forests, organizational units, and objects—from the physical structure of the network itself. The logical structure of Active Directory does not rely on the physical location of servers or the network connectivity throughout the domain. This provides the powerful ability to structure domains according to your administrative and organizational needs.
Because Active Directory separates the logical structure of network resources from the physical structure of the network itself, it is useful to break the discussion of Active Directory along those same lines. The logical components of the Active Directory struc ture include the following:
■ Objects ■ Domains ■ Trees ■ Forests ■ Organizational Units Objects
Resources are stored in the Active Directory as objects. Since the object is the most eas ily understood component of the Active Directory (being that it usually represents a tangible resource), it is a good place to start.
Objects are stored in the Active Directory in a hierarchical structure of containers and subcontainers, making the objects easier to find, access, and manage—much like orga nizing files in a set of Windows folders. You can tailor a directory structure to meet the needs of your organization, and scale that structure to easily accommodate a network of any size.
■ Object Classes An object is really just a collection of attributes. A user object, for example, is made up of attributes such as name, password, phone number, group membership, and so on. The attributes that make up an object are defined by an object class. The user class, for example, specifies the attributes that make up the user object.
Object classes help organize objects by their similarities. All user objects fall under the object class Users. When you create a new object, it automatically inherits attributes from its class. Microsoft defines a default set of object classes (and the attributes they define) used by Active Directory in Windows Server 2003. Of course, because Active Directory is extensible, administrators and applications can modify the object classes available and the attributes that those classes define.
■ The Active Directory Schema The classes and the attributes that they define are collectively referred to as the Active Directory Schema—in database terms, a schema is the structure of the tables and fields and how they are related to one another. You can think of the Active Directory Schema as a collection of data (object classes) that defines how the real data of the directory (the attributes of an object) is organized and stored.
Just about everything in the Active Directory is an object and that includes the schema itself. As with all other objects, the schema is protected by access control lists (ACL) that are managed by the Windows Server 2003 security subsystem. Users and applications with the appropriate permissions can read, use, and even modify the schema.
Domains
The basic organizational structure of the Windows Server 2003 networking model is the domain. A domain represents an administrative boundary. The computers, users, and other objects within a domain share a common security database.
Using domains allows administrators to divide the network into security boundaries. In addition, administrators from different domains can establish their own security mod els; security from one domain can then be isolated so that other domains’ security models are not affected. Primarily, domains provide a way to logically partition a net- work along the same lines as an organization. Organizations large enough to have more than one domain usually have divisions that are responsible for maintaining and securing their own resources.
A Windows Server 2003 domain also represents a namespace that corresponds to a naming structure that most network administrators are already familiar with: the same DNS used on the Internet (and covered in detail in the next lesson). A domain, when created, is given a name that follows the DNS structure.
For example, a server named msnews in a domain named microsoft.com would have the fully qualified domain name (FQDN) msnews.microsoft.com.
Exam Tip The word namespace is used often. You will do well to remember that, at its sim plest, a namespace is a structure (often a database) in which all objects are named similarly, but are still uniquely identified.
Off the Record When all domain controllers in a domain are running Windows Server 2003, the full set of Active Directory features is available to the domain. In domains where previous versions of Windows Server coexist, not all features are available. The same is true of forests. Having all domain controllers in a forest running Windows Server 2003 provides access to additional forest-level Active Directory features when compared to forests that run previous versions. Pure Windows Server 2003 domains or forests are said to have a higher functional level than those with mixed versions. This chapter deals with pure Windows Server 2003 domains and forests. Coexistence with previous versions is examined more closely in Chapters 2 and 5.
Trees
Multiple domains are organized into a hierarchical structure called a tree. Actually, even if you have only one domain in your organization, you still have a tree. The first domain you create in a tree is called the root domain. The next domain that you add becomes a child domain of that root. This expandability of domains makes it possible to have many domains in a tree. Figure 1-1 shows an example of a tree. Microsoft.com was the first domain created in Active Directory in this example and is therefore the root domain. microsoft .com sales. microsoft.com research. microsoft.com europe.sales. usa.sales. microsoft.com microsoft.com
Figure 1-1 A tree is a hierarchical organization of multiple domains.
All domains in a tree share a common schema and a contiguous namespace. In the example shown in Figure 1-1, all of the domains in the tree under the microsoft.com root domain share the namespace microsoft.com. Using a single tree is fine if your
organization is confined within a single DNS namespace. However, for organizations that use multiple DNS namespaces, your model must be able to expand outside the boundaries of a single tree. This is where the forest comes in.
Forests
A forest is a group of one or more domain trees that do not form a contiguous namespace but may share a common schema and global catalog. There is always at least one forest on a network, and it is created when the first Active Directory–enabled computer (domain controller) on a network is installed. This first domain in a forest, called the forest root domain, is special because it holds the schema and controls domain naming for the entire forest. It cannot be removed from the forest without removing the entire forest itself. Also, no other domain can ever be created above the forest root domain in the forest domain hierarchy.
Figure 1-2 shows an example of a forest with two trees. Each tree in the forest has its own namespace. In the figure, microsoft.com is one tree and contoso.com is a second tree. Both are in a forest named microsoft.com (after the first domain created).
microsoft.com
research. microsoft.com
also root domain of microsoft.com tree contoso.com root domain of contoso.com tree sales. contoso.com mktg. contoso.com root domain of microsoft.com forest sales. microsoft.com europe.sales. microsoft.com usa.sales. microsoft.com
Figure 1-2 Trees in a forest share the same schema, but not the same namespace.
A forest is the outermost boundary of Active Directory; the directory cannot be larger than the forest. However, you can create multiple forests and then create trust relation- ships between specific domains in those forests; this would let you grant access to resources and accounts that are outside of a particular forest.
Organizational Units
Organizational Units (OUs) provide a way to create administrative boundaries within a domain. Primarily, this allows you to delegate administrative tasks within the domain. Prior to the introduction of the Active Directory, the domain was the smallest container to which you could assign administrative permissions. This meant that giving a group of administrators administrative control over particular resources was difficult or impossible to do without giving them sweeping permissions throughout the domain. OUs serve as containers into which the resources of a domain can be placed. You can then assign administrative permissions on the OU itself. Typically, the structure of OUs follows an organization’s business or functional structure. For example, a relatively small organization with a single domain might create separate OUs for departments within the organization.
You can even nest OUs (create OUs inside other OUs) for further control. However, an overly complicated OU structure within a domain has its drawbacks. For one thing, the simpler you keep your structure, the simpler the implementation and management of that structure. For another, once you go beyond about 12 OUs deep in a nesting struc ture, you start running into significant performance issues.