Active Directory

Each of you reading this book will have a different acquired skillset and level of experience with the Windows Server environment. As I mentioned previously, being able to make servers run the operating system is great and a very important first step for doing real work in your environment. But until you know and understand what the purposes behind the main roles available to run on Windows Server 2019 are, the only thing your new server does is consume electricity.

A server is intended to serve data. The kind of data that it serves and to what purpose depends entirely on what roles you determine the server must ... well ... serve. Appropriately, you must install roles within Windows Server 2019 to make it do something. We already know how to get roles installed onto our server but have not talked about any of the purposes behind these roles. Over the next few chapters, we will start looking into what I commonly refer to as the core infrastructural roles available...

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 domain controller be one of the first servers in your Microsoft-centric network, you might as well not even start building that...

Creating your first domain

I must admit that I have cheated a little bit and have already been working from within a domain for the purpose of taking screenshots for the book up to this point. My test lab already has a DC1 server up and running, and on it I have configured a domain called contoso.local. However, saying "domains are important" and not showing you how to create one would not be helpful to you, the reader, and so we are going to build a brand-new domain now, on a brand-new server.

You probably recognize "Contoso" if you've ever read over Microsoft tutorials or example configuration documentation, because it is one of several fake business names Microsoft uses often in documentation or for the purpose of showing example scenarios. I am using it here as well, but you could name your domain anything you want to. For setting up our second domain, I am going to pull another company name from the Microsoft hat, Fabrikam.

One of the first things...

Multiple domain controllers for redundancy

Now, having configured our first domain controller, we should jump in and start setting up objects inside Active Directory, right? Not yet! I'm being a little dramatic here, of course you can jump ahead and start using the tools that interface with AD, which we will discuss immediately following this section of our chapter. But if you are setting up a real environment and not just monkeying around in a test lab, it is going to be super critical that you establish redundancy in your domain.

Adding a second domain controller is even easier than spinning up the first one. Simply take the same steps that you did last time, with one exception to the way that the NIC is configured:

1. Spin up a new server.
2. Set a static IP.
3. Configure a good permanent hostname.
4. Deviation from before: Instead of configuring your NIC's DNS server settings to point at the new server itself, point your primary DNS to the existing...

Active Directory Users and Computers

There is not a single tool that is used to manage all facets of Active Directory. Since it is such an expansive technology, our configuration of the directory is spread across a number of different management consoles. Let's take a look at each of them, and a couple of the most common tasks that you will be performing inside these tools. Any of these management consoles can be launched from any of your domain controller servers, and just as we saw in a previous chapter, the easiest way to launch these consoles is right from the Tools menu in the upper-right corner of Server Manager.

I'll start with the tool that is alphabetically last in the list of our Active Directory tools, because this is by far the one that the everyday server administrator will use most often. AD Users and Computers is the console from which all of the user accounts and computer accounts are created and managed. Open it up, and you will see the name of your...

Active Directory Domains and Trusts

This tool is generally only used in larger environments that have more than one domain within the same network. As we discussed earlier, a company may utilize multiple domain names to segregate resources or services, or for the better organizational structure of their servers and namespaces within the company. You already know the differences between a domain and a forest and how the domain resides within the forest. Another way to think of the forest is as the boundary of your AD structure. If you have multiple domains beneath a single forest, it does not necessarily mean that those domains trust each other. So, users from one domain may or may not have permission to access resources on one of the other domains, based on the level of trust that exists between those domains. When you have a domain and are adding child domains under it, there are trusts placed automatically between those domains, but if you need to merge some domains together in...

Active Directory Sites and Services

Sites and Services is another tool that is generally only employed by companies with larger Active Directory infrastructures. As is the case with any server, if having one domain controller is good, then having two domain controllers is even better. As your company grows larger, so does your Active Directory infrastructure. Before you know it, you will be looking into setting up servers in a second location, then a third, and so on. In a domain-centric network, having domain controller servers in each significant site is a general practice, and you could soon be looking at dozens of domain controller servers running in your network.

Turning on new domain controllers and joining them to your existing domain so that they start servicing users and computers is pretty easy. The harder part is keeping all of the traffic organized and flowing where you want it to. If you have a primary datacenter where the majority of your servers are located, you...

Active Directory Administrative Center

While it is critical to understand and be familiar with the tools we have looked at so far that help us manage Active Directory, you can tell that their aesthetics are a bit dated. The Active Directory Administrative Center (ADAC), on the other hand, has a much more streamlined interface that looks and feels like the newer Server Manager that we are all becoming more and more comfortable with. Many of the functions available within the ADAC accomplish the same things that we can do through the other tools already, but it pulls these functions into a more structured interface that brings some of the most commonly utilized functions up to the surface and makes them easier to run.

One great example is right on the landing page of ADAC. A common helpdesk task in any network is the resetting of passwords for user accounts. Whether the user forgot their password, changed it recently and mistyped it, or you are resetting a password during some other...

Read-only domain controllers

The first domain controller you set up in your network will be a fully writable 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 and writeable. 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 from a user's computer, such as a password change or new user account creation, are impossible with an RODC. Instead, RODCs receive their directory data from other more traditional domain controllers and then utilize that data to verify authentication requests from users and computers. Where would a limited-access domain controller like this be beneficial? Many companies are installing them in smaller branch offices...

Group Policy

In a network that is based upon Windows Server and Active Directory, it is almost always the case that the primary set of client computers is also based upon the Microsoft Windows operating systems, and that these machines are all domain-joined. Setting everything up this way not only makes sense from an organizational perspective inside Active Directory, but also allows centralized authentication across devices and applications, as we have already talked about. I know that a couple of the examples I gave earlier in the book went something like, What about when a company has a security policy in place that... or Make sure your servers don't get those existing security policies because... So what are these magical security policies anyway, and how do I set one up?

This is the power of Group Policy. It enables you to create Group Policy Objects (GPOs) that contain settings and configurations that you want to apply to either computers or users in your Active Directory...

Summary

Anyone who has been around Windows Server before knows that Active Directory is nothing new and certainly not something coming to us new in Windows Server 2019. AD has been the authentication underpinning of any Microsoft-centric environment for a very long time and will continue to be far into the future for anyone who hosts an on-premise datacenter. Knowing and understanding AD is entirely critical for the mastery of Windows Server 2019, because without this knowledge your career in server administration won't even make it off the ground.

Some hints were dropped in this chapter about another core infrastructure technology that is often in place alongside Active Directory on all of your domain controller servers, DNS. To effectively manage a Microsoft infrastructure, in my opinion there are three in-the-box server technologies that any admin must be able to work with fluently: Active Directory, DNS, and DHCP. Follow along to Chapter 4, DNS and DHCP, as we cover the...

Questions

1. Inside Active Directory, a container (folder) that holds computer and user accounts is called a(n)…?
2. What is the term for creating a computer account inside Active Directory prior to that computer being joined to your domain?
3. Which management tool is used to specify that certain physical locations in your network are bound to particular IP subnets?
4. What is the name of a special domain controller that cannot accept new information, only synchronize from an existing domain controller?
5. What tool is needed to create a Fine-Grained Password Policy?
6. What must be configured inside DNS prior to establishing a forest trust?