Installing & Managing ADDS DNS Server on Windows Server Core 2019 - cfloquetprojects/homelab GitHub Wiki

Introduction:

  • We will be installing Active Directory Domain Services (ADDS) onto a Windows Server 2019 host, which is a powerful service provided by Microsoft simplifying and centralizing control of user management & access across our environment.
    • While this service (as well as the DNS server we will be installing with it) can be run on a Windows Server desktop installation, we will be deploying it on a headless (core) version of Windows Server, which means it will have no desktop (only a command prompt for management/configuration).

💡 Learn more about the benefits of deploying Windows Server Core (over desktop) here, but in summary the limited amount of software (no graphics, etc.) required reduces the operational overhead, as well as the attack surface for the underlying system.

Resources:

Pre-Flight Check:

  • We will be using two VMs with the following hardware resources provisioned:
    • ZEUS01: Windows Server 2019 Core (Headless ADDS Domain Controller)
      • 2 vCPUs
      • 4gb RAM
      • 30gb HDD
    • HERA01: Windows Server 2019 Desktop (Full GUI Management Server)
      • 4 vCPUs
      • 8gb RAM
      • 60gb HDD

💣 This guide assumes that you have already networked the VMs above with private/internal IPv4s on a lab/test network isolated from any production workloads, applied the latest available patches, and properly secured them with strong credentials. If you are unsure how to accomplish this on a Windows Server Core system, I'd reccomend using this guide from Microsoft on the sconfig utility to get started.

Install Active Directory Domain Services (on ZEUS01) using PowerShell:

  • On our default CMD prompt (within server core), we can run PowerShell by just typing powershell.exe, and begin the installation by using the Install-WindowsFeature AD-Domain-Services -IncludeManagementTools command, as shown in the screenshot below:

1

  • Once that operation has completed, we need to create a "forest" within ADDS using Install-ADDSForest -DomainName sysadmin.local, which will contain our local domain (in our case we chose the name "homer.local" but in your case this will almost certainly be different!), as well as all subsequent users, computers, GPOs, etc.

2

  • Now that our domain has been created, we need to create a named account within this domain that can we can use for administrative/configuration purposes, and also have tied to our identity for accountability/attribution in logs later on.

💡 As a best practice, I will be using the *-adm suffix to delineate between privileged/administrative accounts within systems on the "homer.local" domain. I strongly reccomend this as well, since limiting your use of highly privileged accounts to only operations/functions requiring those high privileges is a very important step to take in security.

  • Create this administrative account in the same PowerShell prompt using the command included below, as shown in the screenshot:

New-ADUser -Name "Charlie Floquet - Admin" -GivenName "Charlie" -Surname "Floquet" -SamAccountName "cfloquet-adm" -AccountPassword(Read-Host -AsSecureString "Password") -Enabled $true

  • On its own, this newly created cfloquet user is not privileged (or a member of any privileged group), but we can change that by adding them to the Domain Administrators group with the command below:

Add-ADGroupMember -Identity DomainAdministrators -Members cfloquet-adm

  • Finally let's confirm our new users group membership by using the Get-ADPrincipalGroupMembership module:

Get-ADPrincipalGroupMembership cfloquet-adm | select name

3

Configure & Join Management Server Workstation (HERA01) to New Domain (homer.local):

  • Log in to your management (desktop) server, and first navigate to Control Panel > Network & Internet > Network & Sharing Center before clicking on the Ethernet icon for the existing active network, going to Properties and then double clicking on Internet Protocol Version 4 (TCP/IPv4) and setting the custom DNS server to match the IPv4 of your newly installed ADDS server, as shown in the screenshot below:

4

  • Save the new network configuration, and then navigate to Control Panel > System & Security > System before opting to "rename this computer" and changing the Member of option to the domain of homer.local:

5

  • Enter the credentials you created for your named domain administrator account, which in my case was HOMER\cfloquet-adm, and you should be greeted with the following message, indicating that our management workstation is now a member of homer.local.

6

💣 If this domain join does not work for you, ensure you are appending the name of your domain with a backslash '' infront of your username for the authentication, this specifies that you are authenticating to that specific domain, as opposed to the localhost.

  • Upon joining the domain, you should be prompted to reboot the server.

Installing Remote Server Administration Tools on Management Server (HERA01):

  • Once it's back online you should now be able to authenticate to the system as your created cfloquet-adm user, open up the Server Manager utility, and right click on "All Servers" before choosing to "Add Server". Since we are now a member of the homer.local domain, by hitting "Find Now" on the "Add Servers" wizard, ZEUS01 should populate and allow us to add it into our server manager GUI for management/monitoring.

7

💣 It's common for this step to fail if you are not logged in as a domain administrator/user, so if you signed in after rebooting as the local account, you will need to log out and log back in for this to be successful.

  • Once our domain controller has been added for management (and we've confirmed there's no problems), we'll need to install some important features to allow our desktop server to function as a remote management/administrative host for our network infrastructure.

    • We can accomplish this on our Windows Server 2019 Desktop management host (HERA01), using an elevated/administrative PowerShell prompt which you can open by right clicking and choosing "Run as Administrator", as shown below:

8

  • Using our administrative PowerShell prompt, let's first confirm the install state for the packages we'll be needing to complete our initial deployment of ADDS/DNS, using the Get-WindowsFeature method as shown below:

Get-WindowsFeature -Name RSAT-ADDS*,RSAT-DNS* -Online | Select-Object -Property DisplayName, State

  • After confirming the proper remote server administration tools (RSATs) are available, we can install them using the Install-WindowsFeature module within PowerShell:

Install-WindowsFeature -Name RSAT-AD-PowerShell,RSAT-DNS-Server,RSAT-ADDS -IncludeAllSubfeatures

9

  • In my expirience, it's wise to reboot after these installations are completed, even though the installer says "no" for whether a 'restart is required', the "DNS Manager" menu that we need for the next section only appeared for me after rebooting the machine.

Configuring Reverse/Forward Lookup Zones, A Records on DNS Server (ZEUS01):

  • After a reboot, let's log back in as our named *-adm domain admin account, and open the DNS Manager installed on your domain controller within Server Manager > DNS:

10

  • Under your DNS server hostname (which in my case is ZEUS01), navigate to Reverse Lookup Zones, and right click on it to create a New Zone for your domain (as shown in the screenshot below).

💣 It's extremely important you take this step to create this reverse lookup zone, since otherwise accounts/services in our domain will not be able to retrieve FQDN/hostname info by IPv4 address alone. Read more about how reverse DNS works in this article by Cloudflare here.

11

  • In the "New Zone Wizard" it will first ask for "Zone Type", "Active Directory Zone Replication Scope", and "Reverse Lookup Zone Name", for which leaving all at their default options (for our lab/practice purposes) will work just fine.

  • The next step of the "New Zone Wizard" is to configure the Network ID of the zone the DNS server will be performing reverse lookups for, which in our case is three different distinct zones (LAN, MGMT, DMZ), but for simplicity I will just show steps for configuring one:

12

  • Lastly we should choose to "Allow only secure dynamic updates" within the "Dynamic Update" section of the wizard, before choosing to Finish the setup.

  • After successfully creating our reverse lookup zone(s), we can pivot to & expand the "Forward Lookup Zones" section before right clicking on your domain to create a "New Host (A or AAAA)" record (as shown below):

13

  • Enter the hostname of a device which is not domain-joined (since those will be added automatically) but you'd like your domain clients to be able to resolve, as an example I chose my primary ESXi node (which is a Dell PowerEdge server running ESXi 6.7 I refer to as 'artemis'):

💣 In the screenshot below be sure to note that I've checked "Create associated pointer (PTR) record", which will automatically create a reverse lookup entry. This will be an important step going forward to ensure that your internal DNS records can be resolveable in a reverse lookup fashion.

14

  • After creating the forward (A) record for the host you're targeting for resolution, pivot back to the "Reverse Lookup Zone" section and hit the "Refresh" button (highlighted in the screenshot below) to see if your records have been generated:

💡 If your PTR records are still not generating after refreshing, try closing DNS manager and re-opening to see if that does the trick, this worked for me on my server when the refresh wasn't.

15

  • If that worked, and your PTR records are visible you should be able to confirm a successful setup/test of your DNS records by issuing the following test using the nslookup and ping utilities in PowerShell:

16

  • That concludes the scope of this blog/project, in the next section we will demonstrate how we can expand/enhance the security and visibility we have into DNS queries made within our environment (while still allowing internal DNS queries to be resolved internally by our domain controller) using a PiHole device.