Domain controllers (DCs) are at the heart of Active Directory Domain Services (AD DS), the directory service that provides authentication, authorization, and password management for Microsoft Windows networks. Find out here why they’re so important and what they do.
A domain controller (DC) is a server on your network that manages access for users, computers, servers, etc. centrally. It uses Active Directory to house this database information.
Domain controllers respond to security authentication requests from network endpoints, like servers and user workstations. Domain controllers are responsible for securely authenticating network resources on a local or wide area network. Domain controllers authenticate users, they store user account information, like names and addresses, and they enforce security policies for Active Directory domains.
Domain controllers provide the physical storage for the AD DS database. In addition, they also provide services that allow enterprises and IT pros to manage their servers, computers, laptops, users, printers, and other applications. They are vitally important to your network and need to be secured. A malicious user, if they can take control of a DC, could wreak havoc on your Friday afternoon (or early Sunday morning!) by wiping out your AD database.
Well, these two, as you probably have guessed already, are not the same. A domain controller essentially houses the guts of Active Directory. Active Directory is the software that centrally houses your network in database form. The domain controller(s) physically house the information stored in your Active Directory.
Yes. Of course, you do. Now, technically, you don’t. Confused yet?
If you have 5 or less users in your organization, and a semi-dedicated IT pro available, you could do without an Active Directory environment. However, you would have local accounts on each of your users’ computers, you would have to maintain a list of usernames and passwords on each computer…if you wanted to have one user share their files to a file server, you would need to maintain those password lists.
All of what I just described is automatically maintained in a domain controller. So, long story short, you need one…at LEAST one…read on.
Try to imagine you have installed AD DS in your environment and promoted one of your servers to a domain controller. Your users are happy, computing and processing all those Excel spreadsheets with ease.
Now, one of your user’s passwords expires…they go to change it and they get an error that there are no domain controllers available to process the password change (No, the error of course is not that direct and explicit, but you catch my drift). Your single domain controller has blue screened and it has halted. Your Active Directory is essentially dead in the water.
You need redundancy. It is a very simple process to add a second (and third, fourth…) domain controller to your environment. Once you have 2 or more DCs, you are protected from one of them being unavailable for any reason. Through AD replication, a service that automatically runs on each DC, any changes made to your directory on one DC get replicated to all the other DCs in the same domain.
When Active Directory debuted with Windows 2000, the first DC you created was dubbed the Primary Domain Controller, or PDC. This was a ‘role’ that this specific DC took charge of. There are other roles including the schema master role, domain naming master role, RID pool manager, and infrastructure master.
Although the ‘importance’ of these Flexible Single Master Operations (FSMO) roles has diminished over time, for legacy reasons, they are still maintained across your DCs. You can query which DC has each role and even move the FSMO roles amongst your DCs.
You can learn more about transferring and seizing domain controller FSMO roles here:
There are two main methods to set up a new domain controller – PowerShell and Server Manager. I’ll go through the basics of using Server Manager here.
Depending on your scenario, your environment, and if this is your first DC in a new forest, if you’re adding a second DC to your forest, or if you’re building a new domain in your existing forest with this DC, there are varying steps to installing Active Directory domain controllers.
The commonly known best practices for deploying domain controllers has changed a lot over the years. Back in the day (around Windows 2000, when AD debuted), it was best to maintain your AD database on one set of disk spindles, place the log files on another volume/partition, and Windows Server on another! With the advancement of technology, these practices have shifted.
Today, these are the general best practices to installing DCs in your network:
If you want to separate domain controllers from your physical network and get more flexibility and additional protection for your Active Directory infrastructure, it’s also possible to virtualize your DCs. Check our best practices for installing Active Directory domain controllers in a virtual machine for more details