What is a domain controller?
If we are going to discuss the core infrastructure services that you need to piece together your Microsoft-driven network, there is no better place to start than with the domain controller. A Domain Controller, commonly referred to as a DC, is simply a server that is hosting Active Directory. It is a central point of contact, a central “hub” so to speak, that is accessed prior to almost any communication that takes place between a client and server in your network. Perhaps the easiest way to describe it is as 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 DC be one of the first servers in your Microsoft-centric network, you might as well not even start building that network. DCs are essential to the way that our computers and devices communicate with each other and with the server infrastructure inside our companies.
Active Directory Domain Services
If you’ve stopped reading at this point to install the Domain Controller role onto your server, welcome back! 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 a directory, or database, of objects 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. You might be thinking, “didn’t we just say these same words in a slightly different way?” and you’re not wrong. AD is important, and I want to make sure you know it. A career in IT guarantees that you will in some way interface with AD in your work.
Most of the time when you hear anyone talking about “Active Directory” it is likely that what they really mean is a single domain within the directory. There is a whole hierarchy within an Active Directory schema, comprising forests, trees, domains, and organizational units. We will discuss each of these organizational levels of Active Directory as we navigate through the tools that you will be utilizing to interact with AD further along in this chapter.
Once you have created a domain in which you can store accounts, objects, and devices, you can then create user accounts and passwords for your employees to utilize for authentication. You can 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 on to each of them with your own username and password, even when you have never logged in to 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 operating system 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 on my desktop and open an application – let’s say I open my Outlook to access my email – that email program is designed to reach out to my email 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? Generally not. And the reason I do not have to re-enter my credentials over and over again is that my username, my computer, and the application servers are all part of the same domain.
When this is true, and it is for most business networks, my authentication token can be shared among my programs. So, once I log in to the computer itself, my applications can 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.
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.
