Domain ControllerConcepts | Windows Server 2003 in a Nutshell

Domain ControllerConcepts

Domain controllers enable users to log on to the network and access resources for which they have suitable permissions. They also enable users to search Active Directory for shared folders, shared printers, and other published information. A domain must have least one domain controllerin fact, promoting a standalone WS2003 computer to the domain controller role is what creates the domain. However, for redundancy, a minimum of two domain controllers is recommended for each domain, for if you have only one domain controller and it goes down, no one will be able to log on. If your company has multiple sites separated by slow WAN links, you probably also want at least one domain controller at each site to reduce logon traffic over the WAN and to enable logons when the WAN goes down. See Site later in this chapter for more information.

Authentication

When a user wants to log on to the network from a client computer, the client computer first needs to find a domain controller to authenticate its logon request. What happens is that the client issues a DNS query to locate the nearest domain controller that the client can use. The client then contacts this domain controller, and authentication is performed using one of two authentication protocols:

Kerberos v5: This protocol is used to authenticate computers running Active Directory client software, which is included with WS2003, W2K, and XP. Active Directory client extensions are also available for Windows 95, Windows 98, and NT.
NTLM: This protocol is used to authenticate NT clients that don't have Active Directory client extensions installed and for communications with NT domain controllers in domains running in W2K mixed or WS2003 interim domain functional level.

Replication

Unlike the NT approach in which one domain controller (the PDC) in each domain was the master domain controller (the one containing a writable copy of the domain directory database), WS2003 and W2K use a multimaster approach in which all domain controllers in a given domain are peers and contain identical, writable copies of the directory database (Active Directory). Domain controllers within a domain automatically replicate their directory updates to every other domain controller in the domain. The result is that every domain controller in a domain essentially contains identical directory information. This replication process requires no special configuration unless the domain spans multiple sites.

In general, however, domain controllers in different domains don't replicate all their directory information with each other. Otherwise , in a large enterprise every domain controller in every domain would need to contain information about every directory object in the entire enterprise, and this might cause the directory database to grow too large to provide adequate performance when queries are issued against it. Also, the amount of replication traffic needed to keep domain controllers up to date could swamp other forms of normal network traffic.

To solve these problems, Active Directory is partitioned into several naming contexts, with the Schema and Configuration contexts being replicated to all domain controllers in the forest while the Domain context for each domain is replicated only to domain controllers in that domain. As a result, domain controllers in general have knowledge about objects (such as users and computers) only in their own domain and not in other domains. Of course, if this were strictly true then it would be difficult for a user to log on to a computer belonging to a different domain than her home domain. The solution to this problem is the global catalog.

Global Catalog

The global catalog is a partial replica of the most commonly searched attributes for all objects in all domains in the forest. The purpose of the global catalog is to help speed up search queries issued against Active Directory, especially forestwide queries and cross-domain logon attempts. This global catalog typically resides on one or more domain controllers in a domain or site. A domain controller that contains a copy of the global catalog is called a global catalog server. Global catalog servers thus contain the following Active Directory objects:

A full replica of all objects in its own domain
A partial replica of all objects in the forest in all naming contexts

By default, the first domain controller in the first domain (forest root domain) of a forest is automatically configured as a global catalog server, and any other domain controller can also be configured as a global catalog server. In W2K, it was critical in native mode domains to have one domain controller per site since domain controllers needed to contact a global catalog server to determine a user's universal group membership before they could authenticate the user's logon attempt, and, if no global catalog server could be found, the logon attempt would fail. As a result, administrators usually designated a global catalog server for each site, which led to increased WAN traffic due to global catalog replication. WS2003 resolves this situation; domain controllers can be configured to cache universal group membership for all users, with the result that global catalog servers are no longer needed for every site.

Operations Master Roles

Although in most senses no domain controller is more important than any other, there are a few special domain controller roles that stand out from the rest. These domain controllers are called FSMO (flexible single master of operations) roles and they are the only domain controllers that can be used to perform certain operations on Active Directory. There are five of these FSMO roles, of which two are forestwide in scope:

Schema master: By default, this is the first domain controller installed in the forest root domain, and it is the only one on which the Active Directory schema can be modified. There can and must be only one schema master per forest; otherwise, conflicting modifications made to the schema on different machines could cause inconsistencies in Active Directory.
Domain-naming master: By default, this is the first domain controller installed in the forest root domain. It controls the namespace and is the only one that allows domains to be added, removed, or renamed in your forest.

The remaining three FSMO roles are domainwide in scope:

Infrastructure master: Responsible for maintaining references to objects located in other domains and for updating group information when groups are renamed or have their membership changed. In a single-domain scenario, this FSMO role is unnecessary.
RID master: Ensures that globally unique security IDs (SIDs) are assigned to newly created objects (users, computers, or groups) in Active Directory.
PDC emulator: Acts as a PDC for downlevel NT BDCs when the domain functional level is W2K mixed or WS2003 interim.

How these FSMO roles are assigned by Active Directory depends on the number of domains in your forest and the number of domain controllers in your domains:

Single domain with one domain controller: The domain controller automatically assumes all five FSMO roles.
Single domain with two domain controllers: The first domain controller installed automatically assumes all five roles. If maintenance is planned for the first domain controller, all five FSMO roles should first be transferred to the second domain controller. If the first domain controller goes down unexpectedly, the five FSMO roles can be seized by the second domain controller.
Two or more domains: The schema master and domain-naming master roles must remain in the forest root domain. In all other domains, the first domain controller in each domain automatically assumes the infrastructure master, PDC emulator, and RID master roles for that domain.

In a multidomain environment, make sure the infrastructure master role is transferred to a domain controller that doesn't host the global catalog. Otherwise, domain controllers may end up with stale information concerning group membership.