8.1 Active Directory Domains

One of the first issues you have to consider when implementing an Active Directory infrastructure is how many domains you need and what to name them. Active Directory domain names are DNS domain names, but—and this is important—not every DNS domain name is an Active Directory domain name.^[1] So while an organization's Active Directory namespace resembles its DNS namespace, the two don't have to be identical.

^[1] And every square is a rectangle, but not all rectangles are squares. All registered mail is certified, but not all certified mail is registered. You get the idea.

The number of domains you create in your forest is largely dependent on your administrative and replication requirements. A domain is mastered by one or more domain controllers, which are servers that have writeable copies of the data (about users, groups, computers, etc.) contained in the domain. Unfortunately, Active Directory is not like DNS, where a single name server can be authoritative for multiple zones. A domain controller can be authoritative only for a single Active Directory domain. To create a new Active Directory domain, you have to install a new domain controller—your existing domain controllers cannot be used. However, Active Directory uses a multimaster replication system, unlike DNS, and consequently any domain controller can process updates and replicate the changes to the other domain controllers in the domain.

8.1.1 Domains, Domain Trees, and Forests

Domain trees and forests are two important Active Directory concepts. A domain tree is simply a collection of one or more domains that share a common namespace. The fx.movie.edu and movie.edu domains would be considered part of the movie.edu domain tree; however, the example.com domain, if created after movie.edu, would be in a separate domain tree called example.com. If the domain you create does not contain the full name of the parent domain or forest root domain, it is considered part of a separate domain tree.

A forest is a collection of one or more domain trees. The domains in the movie.edu domain tree and the example.com domain tree could be part of the same forest. A domain tree is based on a common namespace, but a forest is not.

A forest is named after the first domain created in the forest. If movie.edu was the first domain we created, the forest is automatically named movie.edu. We can then create additional domains for fx.movie.edu and example.com all belonging to the movie.edu forest. Another option is to create the example.com domain in its own forest, which has certain implications for user access.

All domains within a forest, regardless of which domain tree they are part of, are trusted by each other from an authentication and authorization perspective. For this reason, the forest is considered the primary security boundary in Active Directory. By making the example.com domain part of the movie.edu forest, users in example.com, by default, have read access to much of the information in the movie.edu domains, and vice versa. Also, users in example.com can have control delegated to them over objects in the movie.edu domains and vice versa. If example.com is created in a separate forest, the users in that domain do not have access to the movie.edu forest, and they cannot have access delegated to it (unless a special cross-forest trust is created between the two forests).^[2]

^[2] Windows Server 2003 supports a new trust type called forest trust, which allows you to have a single transitive trust that spans two forests. If you want to understand more about how trusts work, get Active Directory (O'Reilly).

8.1.2 Domain Models

Two Active Directory domain models are commonly used. Your choice of domain model is important because it dictates DNS requirements, as we discuss later. One model consists of an empty root domain with geographic or organizational subdomains. We recommend that you do not create organizational-based subdomains if you can help it since they are very likely to change at some point.^[3]

^[3] Fortunately, a new feature of Windows Server 2003 allows you to rename domains, but the process is arduous. For more information on renaming domains, see http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx.

Some of the benefits of the multidomain model include the ability to delegate administration for management of portions of a forest, greater control over how data is replicated within the forest, and decreased exposure to problems that can impact a single domain. For example, if an application went out of control and mistakenly started creating tons of objects in a domain, at some point the hard disk on the domain controllers in that domain would fill up. The domain would then enter an unstable and possibly unusable state. However, the domain controllers in other domains would continue to function without much impact. This example is admittedly contrived, but it shows you the benefits of autonomy in the multidomain model.

The downsides of this model include the increased support costs of setting up additional domain controllers—remember that each domain must have its own set of domain controllers—and additional domain configuration (configuring security, group policy objects, organizational units, etc.). Also, finding data in a multidomain forest is not always easy. Since data can be spread across several domains, you have to query the global catalog to perform forestwide searches. The global catalog contains a read-only copy of the objects in all domains in the forest. The drawback to the global catalog is that it contains only a subset of the attributes of objects. If the global catalog doesn't contain the attribute you want, you have to perform an additional query against the domain the object resides in after you've queried the global catalog.

The other common domain model is simply a single domain. Over time, many organizations have come to recognize the increased support costs associated with supporting additional domains and have found that their initial reasons for needing multiple domains may no longer be valid. With a single domain, you typically need fewer domain controllers, which results in decreased costs. Also, the global catalog does not play as big a role because you do not need to search across multiple domains.

The downside to the single domain model is decreased flexibility in replicating data. Since all of your objects are in a single domain, wherever you need to deploy a domain controller, you have to replicate all of the objects in the domain to it. This type of model does not lend itself well to branch office deployments where you have a lot of domain controllers, many of which may have slow WAN connections.

There are variations to these models, but this should give you the general idea. A good rule of thumb is the fewer domains the better. And if you can get by with a single domain, that's great.

8.1.3 Three Options for the Root Domain Name

Once you've decided on a domain model, you need to choose a name for your root domain, also known as the forest root domain. The root domain name is very important because it determines which name servers can be authoritative for the corresponding DNS namespace. You have three basic options for naming your root domain: use the same name as an existing DNS domain, create a new subdomain from an existing domain, or use a name that doesn't correspond to any of your DNS domains (i.e., a disjoint or private namespace). Each option has minor advantages and disadvantages based on your environment, but, as with most naming convention discussions, the decision is largely subjective.

8.1.3.1 Same name as an existing DNS domain

Consider Movie University. The apex (or top) of Movie U.'s DNS namespace is movie.edu, with subdomains named fx.movie.edu, classics.movie.edu, and comedies.movie.edu. This namespace is represented in Figure 8-1.

Figure 8-1. Movie University's namespace

We could root Active Directory's namespace at the root of Movie U's DNS namespace. That would result in movie.edu being the forest root domain. If we decide that the special effects lab needs a dedicated Active Directory domain, we can create the fx.movie.edu domain as a child domain in the movie.edu forest. Everyone else at Movie U. can be part of the movie.edu Active Directory domain, even though individual hosts may fall into different DNS domains. If we did nothing more, the resource records needed by Active Directory would be added to the movie.edu and fx.movie.edu zones.

If your authoritative name servers are not domain controllers and you want to use AD-integrated zones (more on this later), or you want some other name servers to be authoritative for the zone that contains the Active Directory resource records, you have to create delegations. All of the required Active Directory-specific resource records are stored in subdomains of the DNS domain whose name corresponds to the AD domain. These subdomains are named _msdcs (e.g., _msdcs.movie.edu), _tcp, _udp, _sites, and DomainDNSZones. The forest root domain will also have a ForestDNSZones subdomain.^[4] To delegate the Active Directory DNS responsibilities when the Active Directory domains are named after an existing DNS domain, you need to delegate those subdomains. In turn, those subdomains become zones on the delegated servers.

^[4] The DomainDNSZones and ForestDNSZones domains are new in Windows Server 2003. They are used to support application partitions, described later in this chapter.

8.1.3.2 Subdomain of an existing DNS domain

Now let's say that Movie U. wanted to completely separate its AD namespace from its DNS namespace. Another common approach is to create a subdomain of an existing domain, such as the top-level domain for the organization. For example, we could name the forest root domain ad.movie.edu or corp.movie.edu. If we still needed to create a subdomain for the special effects lab, it could be named fx.ad.movie.edu.

This model is the easiest to implement if you want to delegate responsibility for the Active Directory-critical zones to name servers other than the main set of authoritative name servers for your organization. Instead of delegating subdomains as in the previous model, you need to delegate only the zone with the same name as the forest root domain (e.g., ad.movie.edu) from your main forward-mapping zone (e.g., movie.edu).

Microsoft recommends this option for most deployments and uses it for its own corporate Active Directory deployment.

8.1.3.3 Disjoint or private name

The last major option for naming your forest root domain is not to base it on any of your top-level domain names and use a disjoint or private name. The most common suffix that is used in this scenario is .local (e.g., movie.local). This model is typically chosen by organizations that do not want their Active Directory DNS namespace to be public.

In nonproduction forests, we recommend following the guidelines in RFC 2606 and using .test or .example instead of .local, which are suffixes reserved for testing purposes. If you need to create a lab or test environment that your general community does not need to access, this is a good model to use. In fact, you can create a forest without requiring any delegations at all from your main forward-mapping zone, assuming you have control over the resolver configuration for the clients in the lab. To do this, you would need to create the movie.test forest, enable the DNS server on one or more domain controllers in the domain, and make the movie.test zone AD-integrated.

In order for clients to resolve DNS names outside of the forest, you would need to point the resolvers on the domain controllers to each other, and configure forwarders to forward unresolved requests to your organization's main authoritative name servers. At that point, all you need to do is point the resolvers of the clients that are going to use the movie.test forest to one of the domain controllers that are running the Microsoft DNS Server in movie.test. Now you have a fully functional Active Directory forest that didn't require any delegations from your main forward-mapping zone.

Microsoft strongly discourages using a single-label domain name, such as movie, for your forest root domain name. If you do, it requires additional configuration on your servers. Microsoft's reasoning behind this is to limit the number of misconfigurations that result in hammering the top-level root name servers with unnecessary DNS requests.