Windows Server 2016 – Active Directory Setup

– Part 3
Shawn June 1, 2017 No Commentson Windows Server 2016 – Active Directory Setup – Part 3

Windows Server 2016 - Active Directory Setup

 Windows Server 2016 – Active Directory Setup – Part 1

 Windows Server 2016 – Active Directory Setup – Part 2
 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!