Domain Controllers
Part 2 covered how Active Directory scales across domains, trees, and forests. Part 3 goes back inside a single domain and focuses on the server that makes all of it work — the Domain Controller. What it does, why one is never enough, what actually breaks when one goes down, and how the concept of primary versus additional DCs evolved from Windows NT to modern Active Directory.
What is a Domain Controller?
A Domain Controller is a Windows Server with the Active Directory Domain Services role installed. It holds the AD database — a file called NTDS.dit — which contains every object in the domain. Every user account, every computer account, every group, every policy. Everything.
When you log into a domain-joined machine, your computer sends your credentials to a Domain Controller. The DC checks them against NTDS.dit, issues a Kerberos ticket if they are valid, and your session begins. Every access decision after that — whether you can open a shared folder, whether your Group Policy applies, whether your password reset goes through — flows through a Domain Controller at some point.
This is not a background service you occasionally notice. The Domain Controller is the engine of the entire domain. Without it, the domain does not function.
Why One Domain Controller Is Never Enough
A single Domain Controller is a single point of failure. If it goes offline — crashed hard drive, failed Windows update, power event, hardware fault — authentication stops. Users who have never logged into that machine before cannot log in. Machines that contact the DC at startup for Group Policy cannot apply it. Password changes fail. New user provisioning fails. Any system that calls AD for authentication — email, VPN, file shares, internal applications — starts returning errors.
The impact is not theoretical. In environments running a single DC, an unplanned outage means a helpdesk queue that fills within minutes and a problem that cannot be resolved until the DC is back online or a new one is promoted — a process that takes time even in the best conditions.
A single Domain Controller is an architectural decision that treats Active Directory as a service that can have downtime. In practice, AD cannot have downtime. Every business process that involves a computer depends on it.
The solution is straightforward: deploy a second Domain Controller. When two DCs exist in the same domain, they replicate the NTDS.dit database between them. Changes made on one — a new user created, a password changed, a group membership updated — replicate to the other automatically. If one DC goes offline, the second continues handling authentication and replication without interruption. Users experience nothing. The incident becomes a maintenance task, not an outage.
Most organisations of any meaningful size run at minimum two DCs per domain. Larger environments with multiple sites run at least one DC per physical location so that authentication traffic does not have to cross a WAN link.
What Actually Breaks When a DC Goes Down
The impact depends entirely on whether you have other DCs available.
With only one DC: Authentication fails for any user whose credentials are not cached locally on their machine. Machines that have never logged in before cannot log in at all. Group Policy cannot be refreshed at startup or login. DNS resolution may fail entirely if the DC was also serving DNS — which it almost always is in AD environments. Password changes and resets fail. Account unlocks fail. Any application querying LDAP for user information receives no response.
With additional DCs: Client machines automatically locate another available DC using DNS service records called SRV records. Authentication continues without interruption. Group Policy continues to apply. DNS continues to resolve. The failed DC generates monitoring alerts, a ticket is raised, and it is restored or replaced — but none of that is visible to users.
The difference in outcome between these two scenarios is the entire reason DC redundancy exists.
Primary vs Additional Domain Controllers — How the Terminology Evolved
This is where a lot of confusion lives, because the terminology in use today does not match what “primary” used to mean.
In Windows NT, there was a strict master-replica architecture. One server was designated the Primary Domain Controller (PDC). It held the single writable copy of the directory database. Every other DC was a Backup Domain Controller (BDC) — it held a read-only copy, could authenticate users, but could not accept any changes. All writes — new users, password changes, group modifications — had to go to the PDC.
If the PDC went offline, you could promote a BDC to take over, but it was a manual process and not seamless. The PDC was a genuine single point of failure for write operations even in environments with multiple DCs.
Active Directory, introduced with Windows Server 2000, eliminated this model entirely.
In modern AD, every Domain Controller holds a full, writable copy of the NTDS.dit database. Any DC can accept changes. A user account created on DC01 replicates to DC02, DC03, and every other DC in the domain. A password changed at a branch office DC replicates back to headquarters. This model is called multi-master replication — there is no single master, and there is no read-only replica in normal operation.
There is no “primary” Domain Controller in modern Active Directory. The first DC promoted when a domain is created is simply the first DC. Once a second DC is added, both are peers.
