What is a domain controller?

If we are going to discuss the core infrastructure services that you need in order to piece together your Microsoft-driven network, there is no better place to start than the domain controller role. A domain controller, commonly referred to as a DC, is the central point of contact, sort of a central hub that is accessed prior to almost any network communication that takes place. The easiest way to describe it is a storage container for all identification that happens on the network. Usernames, passwords, computer accounts, groups of computers, servers, groups and collections of servers, security policies, file replication services, and many more things are stored within and managed by DCs. If you are not planning to have a domain controller be one of the first servers in your Microsoft-centric network, you might as well not even start building that network. They are essential to the way that our computers and devices communicate with each other and with the server infrastructure inside our companies.

If you've stopped reading at this point in order to go install the domain controller role onto your server, welcome back because there is no role called domain controller. The role that provides all of these capabilities is called Active Directory Domain Services, or AD DS. This is the role that you need to install on a server. By installing that role, you will have turned your server into a domain controller. The purpose of running a DC really is to create this directory, or database, of items in your network. This database is known as Active Directory, and is a platform inside which you build a hierarchical structure to store objects, such as usernames, passwords, and computer accounts.

Once you have created a domain in which you can store these accounts and devices, you can then create user accounts and passwords for your employees to utilize for authentication. You then also join your other servers and computers to this domain so that they can accept and benefit from those user credentials. Having and joining a domain is the secret sauce that allows you to walk from computer to computer within your company and log onto each of them with your own username and password, even when you have never logged into that computer before. Even more powerful is the fact that it enables directory-capable applications to authenticate directly against Active Directory when they need authentication information. For example, when I, as a domain user, log in to my computer at work with my username and password, the Windows running on my computer reaches out to a domain controller server and verifies that my password is correct. Once it confirms that I really am who I say I am, it issues an authentication token back to my computer and I am able to log in. Then, once I am into my desktop and I open an application, let's say I open my Outlook to access my e-mail, that e-mail program is designed to reach out to my e-mail server, called an Exchange Server, and authenticate against it to make sure that my own mailbox is displayed and not somebody else's. Does this mean I need to re-enter my username and password for Outlook, or for any other application that I open from my computer? No. And the reason I do not have to re-enter my credentials over and over is because my username, my computer, and the application servers, are all part of the domain. When this is true, and it is for most networks, my authentication token can be shared among my programs. So, once I log in to the computer itself, my applications are able to launch and open, and pass my credentials through to the application server, without any further input from me as a user. It would be quite a frustrating experience indeed if we required our users to enter passwords all day, every day as they opened up the programs that they need in order to do their work.

The first domain controller you set up in your network will be a fully writeable one, able to accept data from the domain-joined users and computers working within your network. In fact, most DCs in your network will likely be fully functional. However, it's worth taking a quick minute to point out a limited-scope DC that can be installed called a Read-only domain controller (RODC). Just like the name implies, an RODC can only have its directory data read from it. Writes that might try to be accomplished to the domain-like password changes or new user account creations are impossible with an RODC. Where would a limited-access domain controller like this be beneficial? Many companies are installing them into smaller branch offices or less secure sites, so that the local computers onsite in those smaller offices still have quick and easy access to read from and authenticate to the domain, without the potential security risk of an unauthorized user gaining access to the physical server and manipulating the entire domain in bad ways.

Active Directory itself is a broad enough topic to warrant its own book, and indeed there have been many written on the topic. Now that we have a basic understanding of what it is and why it's critical to have in our Windows Server environment, let's get our hands dirty using some of the tools that get installed onto your domain controller during the AD DS role installation process.