Active Directory – Part 3: 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.
Checks user credentials and issues Kerberos tickets for domain access.
Stores users, computers, groups, policies, and other AD objects inside NTDS.dit.
Multiple DCs replicate with each other so the domain can continue working during failures.
What Is a Domain Controller?
A Domain Controller is a Windows Server with the Active Directory Domain Services role installed. It holds the Active Directory database, a file called NTDS.dit, which contains every object in the domain: user accounts, computer accounts, groups, policies, and more.
When you log into a domain-joined machine, your computer sends your credentials to a Domain Controller. The DC checks them against the AD database, issues a Kerberos ticket if they are valid, and your session begins.
Every access decision after that touches Active Directory in some way. Opening a shared folder, applying Group Policy, resetting a password, unlocking an account, or validating application access all depend on a Domain Controller at some point.
Why One Domain Controller Is Never Enough
A single Domain Controller is a single point of failure. If it goes offline because of a failed update, disk issue, power event, hardware fault, or operating system crash, authentication immediately becomes fragile.
Users who have never logged into a machine before may not be able to log in. Machines that contact the DC at startup may fail to apply Group Policy. Password changes fail. New user provisioning fails. Any system that calls AD for authentication, such as email, VPN, file shares, or internal applications, can start returning errors.
The impact is not theoretical. In a single-DC environment, one outage can quickly become a business-wide incident. Helpdesk tickets rise, users lose access, and recovery depends on bringing that DC back online or promoting a replacement.
The solution is straightforward: deploy at least a second Domain Controller. When two DCs exist in the same domain, they replicate the AD database between them. If one DC goes offline, the other continues handling authentication and directory lookups.
What Actually Breaks When a DC Goes Down?
The impact depends entirely on whether another healthy Domain Controller is available.
With Only One Domain Controller
Authentication can fail for users whose credentials are not cached locally. New machines may not be able to log in. Group Policy cannot refresh properly at startup or login.
DNS may also fail if the DC was providing DNS services, which is common in AD environments. Password changes, password resets, account unlocks, and LDAP queries from applications can also fail.
With Additional Domain Controllers
Client machines automatically locate another available Domain Controller using DNS SRV records. Authentication continues. Group Policy continues. DNS continues to resolve if DNS is also available on the remaining DCs.
In this scenario, the failed DC becomes an operational issue, not a user-facing outage. Monitoring raises an alert, a ticket is created, and the DC is restored or replaced while users continue working.
Primary vs Additional Domain Controllers
This is where a lot of confusion comes from, because older terminology does not match how modern Active Directory works.
In Windows NT, domain controllers followed a master-replica design. One server was the Primary Domain Controller, or PDC. It held the single writable copy of the directory database.
Other servers were Backup Domain Controllers, or BDCs. They held read-only copies and could authenticate users, but they could not accept directory changes. New users, password changes, and group modifications had to go to the PDC.
If the PDC went offline, a BDC could be promoted, but it was a manual process and not seamless. The PDC was a genuine single point of failure for write operations.
The Modern Active Directory Model
Active Directory, introduced with Windows Server 2000, removed the old PDC and BDC model.
In modern AD, every normal writable Domain Controller holds a full writable copy of the AD database. Any DC can accept changes. A user created on DC01 replicates to DC02 and other DCs. A password changed at a branch office DC replicates back to headquarters.
This model is called multi-master replication. There is no single master for normal directory changes.
One writable PDC, multiple read-only BDCs, and manual failover for write operations.
Multiple writable DCs that replicate changes using multi-master replication.
The first DC is simply the first DC. Once another DC is added, both are peers.
Is There Still a Primary DC?
In modern Active Directory, there is no “primary” Domain Controller in the old Windows NT sense. The first DC promoted when a domain is created is not permanently superior to every other DC.
However, some special domain and forest roles still exist. These are called FSMO roles. One of them is the PDC Emulator, which exists mainly for compatibility, password change handling, time synchronization behavior, and certain administrative operations.
This can confuse people because the name still contains “PDC”, but the modern PDC Emulator is not the same as the old Windows NT Primary Domain Controller.
Final Thoughts
Domain Controllers are the core infrastructure of Active Directory. They authenticate users, store the directory database, process policy, answer LDAP queries, and replicate changes across the domain.
A domain with only one DC is fragile. A domain with multiple healthy DCs is resilient. That difference is one of the most important design decisions in any Active Directory environment.
In Active Directory – Part 4, we can cover FSMO roles and explain why some special responsibilities still belong to specific Domain Controllers.