Domain controllers are servers that host an Active Directory domain and provide authentication and directory services to clients. A Domain controller is authoritative for a single domain, but can store partial read-only copies of objects in other domains in the forest if it is enabled as a global catalog server. All domain controllers in a forest also host the Configuration and Schema Naming Contexts, which are replicated to all domain controllers in a forest.
Active Directory is a multi-master directory, meaning that updates can be issued to any domain controller, but some tasks cannot be distributed to all servers due to concurrency issues. For example, if two different domain controllers made conflicting updates to the schema, the impact could be severe and could result in data loss. For this reason, Active Directory supports Flexible Single Master Operations (FSMO) roles. For each role there is only one domain controller that acts as the role owner and performs the tasks associated with the role. See Recipe 3.25 for more information on FSMO roles.
The Anatomy of a Domain Controller
Each domain controller is represented in Active Directory by several objects; the two main ones are a computer object and an nTDSDSA object. The computer object is necessary because a domain controller needs to be represented as a security principal like any other type of computer in Active Directory. The default location in a domain for domain controller computer objects is the Domain Controllers OU at the root of the domain. They can be moved to a different OU, but it is highly recommended that you don't unless you know what you are doing. Table 3-1 contains some useful attributes of domain controller computer objects.
Domain controllers are also represented by several objects under the Sites container in the Configuration NC. The Sites container stores objects that are needed to create a site topology, including site, subnet, sitelink, and server objects. The site topology is necessary so that domain controllers can replicate data efficiently around the network. See Chapter 11 for more information.
Each domain controller has an nTDSDSA object that is subordinate to the domain controller's server object in the site it is a member of. For example, if the DC1 domain controller were part of the RTP site, its nTDSDSA object would be located here:
Table 3-2 lists some of the interesting attributes that are stored with nTDSDSA objects.