Windows Server 2016 – Active Directory Setup – Part 3

With this series I hope to put my own spin on the well documented process to build an Active Directory Domain Controller from scratch.  I’ll of course be using Microsoft Windows Server 2016 for this.  I’m going to include tons of screenshots to document the process step-by-step.  The new AD domain is going to be VILAB.local which is clearly for my lab.  It will be the cornerstone of my lab in terms of authentication, authorization and centralized LDAP domain management.  I’ve broken this series into 3 parts as below:

• Part 1 – AD Domain Controller Requirements & Basic Server Configuration
• Part 2 – Adding AD Domain Services Roles & Adding a new Forest
• Part 3 – AD Configuration & Validation

Active Directory Configuration & Validation

In Part 1 and Part 2 of this series I covered the hardware requirements, recommended server configuration settings, installed the Roles needed for Active Directory Domain Services and then promoted the server to the first domain controller in our new forest.  So we’re done right?  No, not exactly.  A few things I noticed a lot of articles on this topic didn’t talk about is that we need to validate things are working and there is additional configuration necessary to get us closer to a best practice scenario.

Our first login after promoting the server to a domain controller is going to be a little different.  Previously we were logged in as the local administrator account.  Since we promoted this server to a domain controller that local administrator account no longer exists.  The VILAB\Administrator account is our domain admin account and has the same previous password as our former local administrator account.  When I attempt to login it indicates my password is expired and must be changed so I click OK.

Windows now asks for the Current Password and to enter a New Password twice so I enter the password and click OK to change the VILAB\Administrator password to something else.

After the password changes Windows continues to login to the desktop.  From here we need to open Server Manager.

Clicking on the Tools menu in Server Manager now gives us many additional options.  We’re only concerned with Active Directory Sites and Services, Active Directory Users and Computers and DNS so we’ll click all 3 of those and open each up.

In Active Directory Users and Computers we can now see the domain Folders and OUs.  We see we’re connected to the local server VILAB-DC01 and the default containers are all showing up correctly.  You can dig further into the AD structure but typically if you’ve made it this far it’s working as expected.

Moving over to Active Directory Sites and Services we also dig down and check out the Default-First-Site-Name and make sure our server is listed as a Global Catalog and in this case it is.  Notice the Subnets folder is blank at this point.

As we build out our network and Active Directory Infrastructure it will become more important to have subnets specified and attached to Sites, as well as servers attached to the correct sites for replication, authentication and service location.  Proper configuration here determines how computers/servers authenticate on your domain from local and remote sites, how replication occurs between domain controllers and how services are located through the domain.  To properly configure the subnets to start with we’ll right-click the Subnets folder and click New Subnet.

Since I only have the one site, I’m adding all subnets that devices/computers/servers that will communicate with my Active Directory domain are on.

As you can see here I added the 10.10.10.0./24 and 10.10.11.0/24 subnets to the Subnets folder.  10.10.10.0/24 is my Management subnet  and 10.10.11.0/24 is my Virtual Server subnet.  These are attached to the Default-First-Site-Name but could be attached to another site if I had one created.

Lastly we’re on to DNS Manager.  From here I make sure the Forward Lookup Zone for VILAB.local is created and has records in it.

One thing that isn’t automatically setup when you install the DNS role on your new domain controller is Reverse Lookup Zones.  These are becoming increasingly important especially with more and more Linux appliances coming out of VMware and other manufacturers because in some cases they require reverse lookups to function correctly.  Just like the subnets in AD Sites and Services we need to define the networks we’ll be using as Reverse Lookup Zones in DNS Manager.

Click Next to continue.

These are going to be Primary zones which means this server is the owner of this zone.  We leave the box checked to Store the zone in Active Directory and click Next.

Even though this is a new forest and this is currently the only domain controller, we want to set this To All DNS servers running on domain controllers in this forest: VILAB.local and click Next.  This means this zone will automatically replicate to other DNS servers in this forest as we add new domain controllers.

This is of course an IPv4 network so we leave this on the default of IPv4 Reverse Lookup Zone and click Next.

We only need to enter the first three octets of our subnet in the Network ID field and click Next.  This gets much more complicated if you’re using anything other than /24 networks.  Here’s a fun read to learn how to configure a subnetted reverse lookup zone.

Dynamic Update asks if you want to allow secure or non-secure updates to DNS from entities on your network.  In almost all cases the answer here is Allow only secure dynamic updates and in this case we leave that option selected and click Next.  This option means that any authenticated device can update DNS records but devices not authenticated to Active Directory cannot update records.  There are several use cases where you may want to put this option to Allow both nonsecure and secure dynamic updates but as it states this is a significant security vulnerability.

Here we get a brief overview of the new Reverse Lookup Zone we’re creating and click Finish to complete the task.

I’ve added the same two subnets from earlier as Reverse Lookup Zones in DNS.

From here there are a number of additional items you could check but the above are the main items to consider.  A few additional roles that may be necessary that come to mind are DHCP, Certificate Services, Network Policy Services and WSUS to name a few.

In Conclusion

In this series we’ve gone from a base Windows Server 2016 install all the way through to building a new domain controller for a new domain.  While the steps aren’t all that difficult I hope to have added some context to each of the choices made during the process.  Thanks for reading!