The next step to getting my lab ready is to make some updates to my servers and computers. The fastest way to update all of my machines is to update the group policy objects (GPOs). After I update the GPO policies I am going to check the DNS configuration an make sure my domain is ready for the remaining workstations.

Updating GPO policies

Prerequisite: Creating a File and Windows Server Update Services (WSUS) Server

I am going to use group policy management console (GPMC) to update GPO policies for my domain. The first policy change I need to make is to finish enabling WSUS on my domain by mapping all of the workstations and servers to WSUS for updates. To make this change I am going to make a new GPO for the domain called WSUS settings in GPMC.

Now I go to Computer configuration > Policies > Administrative Templates > Windows components > Windows Update > Specify intranet Microsoft update service location.

First, I map the domain servers and workstations to my WSUS server, I need to enter the address for my WSUS server. Then I enable the policy so it takes effect.

Next, I need to configure the schedule for automatic updates. This sets all the machines to download updates from the internal WSUS and selects the desired behavior. I set the Configure Automatic Updates setting to make this change.

Update Policy for Add/Remove Features

I need to make one more change related to WSUS. Right now WSUS is only used for software updates, but I also need to map workstations and servers to WSUS for adding and removing features. That is in Computer configuration > Policies > Administrative Templates > System > Specify settings for optional component installation and component repair.

That’s it for the WSUS GPO. Now my workstations will map to the internal server for updates and features. Next I need to check DNS settings. I am going to use the DNS manager in RSAT for this.

First, I am going to set the server to only listen on the IPv4 interface for DNS queries. Then I am going to check the DNS forwarders and make sure it is using the Pi-hole in the DMZ.

My DNS is configured and working as expected. Now that my domain is ready for workstations. Before I add workstations though, I am going to add one more service: Email.

In this step I am creating a new server using the Windows Server 2019 template created earlier in this process. The first role is providing my network with shared storage by creating a file server, then adding Windows Server Update Services (WSUS). I can install the basic services with PowerShell and use the remote administration tools on my Admin PC to manage WSUS.

Creating a File Server

Prerequisites:

• Streamline and Simplify Installs: Create a Windows Server Template
• Creating a Domain: Install Active Directory in Server Core
• Creating a Windows 10 Template and the Windows 10 Admin PC

The first step is to clone the Windows Server template into a new VM that I am going to call FileSrv. After cloning, I just start the machine and change the Administrator password.

Joining the domain in Server Core is easily done using SConfig. I changed the name on the server to FileSrv and joined the CORP domain in my lab. I also checked the network settings to make sure everything is correct.

Once the server reboots, I logged in with the Bob Admin credentials and prepared to install the File Server role. Installing the file server role is done through Powershell using the command below.

PS C:\Users\BAdmin> Install-WindowsFeature File-Services

Next I had to create a shared folder and then set the permissions using PowerShell. Here are the commands.

PS C:\Users\BAdmin> md C:\Globoshare
PS C:\Users\BAdmin> $acl = get-acl C:\GloboShare\

PS C:\Users\BAdmin> $ace = new-object system.security.AccessControl.FileSystemAccessRule('Authenticated Users', 'Modify', 'Allow')

PS C:\Users\BAdmin> $acl.AddAccessRule($ace)
PS C:\Users\BAdmin> $acl|Set-Acl

Finally I could share the folder using New-SmbShare.

PS C:\Users\BAdmin> New-SmbShare -Name Globoshare -Path C:\Globoshare -FolderEnumerationMode AccessBased -CachingMode Documents -EncryptData $True -FullAccess Everyone

Now the File share is available on the entire domain using \\Globoshare\ to access.

Installing Windows Server Update Services (WSUS)

Installing WSUS on Server Core is a little more complicated than configuring a shared file. For this role, I will need to use a combination of PowerShell commands and the admin tools on my Win10Admin PC. The first step is installing the Windows Feature in PowerShell.

PS C:\Users\BAdmin> Install-WindowsFeature UpdateServices -Restart

After installing, I need to run a post install task using this command.

PS C:\Users\BAdmin> "C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall CONTENT_DIR=C:\WSUS

Next I need to enable remote administration of this server. That involves adding Web Management Service, along with ensuring it starts up automatically on reboot. I also need to make a registry change to enable remote management.

PS C:\Users\BAdmin> Install-WindowsFeature Web-Mgmt-Service

PS C:\Users\BAdmin> reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebManagement\Server /v EnableRemoteManagement /t REG_DWORD /d 00000001

PS C:\Users\BAdmin> Set-Service WMSVC -StartupType "Automatic"
PS C:\Users\BAdmin> Start-Service WMSVC

From here the remaining steps are done in the remote admin tool. I followed the prompts and selected Microsoft Update as my upstream provider. This step took a long time for the initial sync.

After that I selected the language and products that apply to my domain, along with the classifications. Then I configured the Synchronization schedule.

After finishing I chose to begin the initial synchronization.

With that, my new server is ready to go. I installed file services, created a network share, and configured WSUS so my machines have a single update server where I can approve each update. Next I have some group policy changes and other domain changes to make from RSAT on the Windows 10 Admin PC.

The next step in getting my lab up and running is to create a Windows 10 admin machine in Proxmox. As with most of my VMs, I am going to create a Windows 10 template first so I can quickly set up additional workstations using cloning. I created a new VM with the following settings:

• Name: Win10Template
• CD/DVD image: Win10Eval.iso
• Disk: 60GB on local-lvm
• CPU: 1 socket / 4 cores
• Memory: 4096MB
• Network: LANnet / 1450 MTU

Once it loads I started the standard Windows 10 install process.

I selected the following options during install:

• Custom: Install Windows only (advanced)
• Install Windows on Drive 0
• I did not create any partitions

After reboot Windows enters OOBE, so I chose:

• Selected region
• Selected keyboard layout
• Use domain join instead of a Microsoft account
• Enter the information for Bob Admin created in the previous step
• Answer security questions
• Turn off all location and data sharing
• No Coratana

Finally I got to the Windows Desktop and could start the remaining steps.

The next step was to run a Windows update and restart after updating.

Creating the Windows 10 template

Once I had all the desired configuration and updates covered, the final step was to remove all the specific information like user accounts. Just like with the Windows Server template, I can use the Windows Sysprep tool for this portion.

C:\Users\Bob> C:\Windows\System32\Sysprep\sysprep.exe

After the Sysprep finishes, Windows 10 will shutdown and the machine is ready. To create a Windows 10 template all I need to do is right click the machine and select the option to convert to template.

That’s it! Overall the process is a little faster than making a server template. Now it’s ready for cloning into the Windows Admin workstation.

Creating the Admin PC

Once I cloned the template, it goes through the same out of box experience as before. I selected the same options until I got to the main desktop.

Now I need to rename the machine and join it to the Globomantics domain I created in the last post. Renaming the PC is found in the system settings.

Now it’s ready to join to the domain. For that I use Advanced System Settings and select the change option to change to domain from workgroup.

After adding to the domain and rebooting the machine, I could login to the CORP domain using the credentials for Bob Admin.

The last step was installing the Remote Server Admin Tools (RSAT). This is a simple download and install, but it is a Windows update pack and not an executable. After install the tools are available in the start menu and the Windows 10 Admin PC is ready for our next phase: creating a File Server and WSUS Server.

Creating a base Windows Server template for my future VMs and later another for my Windows workstations allows me to conduct all the basic configuration, updates, and other typical install task once rather than with each server I create. This also allows me to clone the template which is much faster than an install from ISO. While I only have two servers planned for now, this will save time creating even the second machine, and significant time on all future servers I create.

Creating Windows Server Templates

I am using Proxmox if you haven’t been following along, but the process of creating a template to clone is similar in all Virtualization platforms with minor variations.

Creating any virtual machine template consists of four basic steps:

1. Install the VM with all drivers, updates, and software packages
2. Configure any other standard configurations that will apply to all servers
3. Remove all user data, passwords, and keys – for Windows run a sysprep
4. Convert the machine to a template

I created a virtual machine in Proxmox with the following specs:

• Name: WinSrv2019
• OS: mapped to ISO file on my host
• Disk: 100GB (can be less)
• CPU: 1 socket / 4 cores
• Memory: 4096MB (4 GB)
• Network: LAN / MTU 1450 (this is due to VXLAN in my lab)

After creating the VM and booting up, I get the install screen for Windows Server 2019.

When selecting an operating system I am going to use Windows Server 2019 Standard Evaluation edition without the desktop experience. I will configure the servers from command prompt / PowerShell and then remotely administer from one of the Windows 10 workstations.

After this step I configured my desired install drive and started the server installation.

After the install finished, I rebooted the server and then logged in with the Administrator account to access the command prompt.

To update the server, I used PowerShell to check Windows update with the command below and then reviewed the updates.

PS C:\Users\Administrator> $updates = Start-WUScan

To install the updates, I used the command below. You get some feedback showing the install progress as it runs.

PS C:\Users\Administrator> Install-WUUpdates -Updates $updates

Once complete I got the feedback “True” in the command prompt. I then ran the command below to check for pending reboot. In my case a reboot was required so I rebooted the server.

PS C:\Users\Administrator> Get-WUIsPendingReboot

After reboot I enabled Windows Remote Management (winrm).

PS C:\Users\Administrator> winrm quickconfig

I also set some basic options like enabling remote desktop and ensuring my servers had the correct timezone using SConfig.

I also made a firewall change and registry change to ensure remote desktop access is enabled.

PS C:\Users\Administrator> netsh advfirewall firewall set rule group="remote desktop" new enable=Yes

PS C:\Users\Administrator> cscript C:\windows\system32\scregedit.wsf /ar 0

These were all the custom changes I wanted to make so now I just need to run a sysprep to make the server ready for use as a template.

Prepare for Template Creation

Running a Sysprep is done by running sysprep.exe and setting the options in a Window that comes up. I chose to generalize, Enter System Out-of-Box Experience (OOBE), and shutdown once complete.

PS C:\Users\Administrator> C:\Windows\System32\Sysprep\sysprep.exe

Once shutdown, the last step is converting to a template. In Proxmox that is a very simple process, I just right click and select “convert to template”.

That’s it, I am ready to clone the template into my domain controller and file server. The new servers will already have all the updates and basic configuration I want for my lab.

I need a Domain Name System (DNS) server to control DNS queries and allow my internal and DMZ networks to access the Internet. Due to the low resource requirements, I can use Linux Containers (LXCs) rather than a full VM for these servers. I am going to install a Pi-hole for DNS on an LXC in the DMZ and on the external network. This allows the internal network to forward requests to a server within the domains control without exposing the Active Directory servers to the Internet. Using Pi-hole also allows me to configure a blacklist for certain domains. I use this on my personal network to remove ads which is Pi-hole’s main purpose.

Set up a Linux Container (LXC) for Pi-hole

Prerequisite: Creating a DMZ in pfsense to Separate Internal Servers

Since it’s the first time I am using a Linux Container (LXC) I will walk through the process to set one up in Proxmox. The first step is to get a CT Template since I don’t have one already. I will use the Ubuntu-20.04-standard tempalte.

Once the download is complete you can create a LXC container in Proxmox.

After selecting the template I selected the system resources for the LXC. My DNS servers will have the following resources:

• Disk: 8GB
• CPU cores: 1
• Memory: 512MB / Swap: 512MB
• Network: Bridge for external / DMZ for DMZ server
• Static IP: follows network diagram
• DNS: use host settings for external / external DNS server IP for DMZ

Once you create the LXC the install happens automatically. Once you start it you access using root and the password set during configuration.

Install Pi-hole for DNS on the LXC

Like with the other VMs my first step is to update, upgrade, and install dependencies. All I need for Pi-hole is curl to run the command in Pi-hole’s install guide.

# apt update && apt upgrade -y
# apt install curl

After the update and upgrade I rebooted, then I ran the install command.

# curl -sSL https://install.pi-hole.net | bash

After running the system checks the Pi-hole automated installer will start.

From here I chose the following settings for my server:

• Upstream servers: OpenDNS for external / External pi-hole for DMZ
• Blocklists: Yes
• Install Admin Web Interface: Yes
• Web Server: Yes
• Everything else was left default

After that I had a summary page with admin webpage login password.

Once the server is finished installing I accessed the web interface, and then logged in to the Pi-hole dashboard.

Firewall and DHCP changes

I am using the pfsense firewall as my DHCP server so for the DMZ interface I needed to change the DNS servers to the new Pi-hole. I am not changing the LAN interface yet because those machines will eventually use the domain controller for its DNS which will forward requests to the Pi-hole.

Next it’s finally time to build my internal network, starting with a domain controller. Before installing that I am going to create a Windows Server template to streamline future server installs.

The next step to set up my lab involves configuring the pfsense firewall to create a DMZ. Within the DMZ I will create a DNS server using Pi-hole, email server using iRedMail, and a vulnerable web server from Vulnhub. Using a DMZ allows me to set different firewall rules for external facing and internal servers. This also allows me to control the traffic between the DMZ and LAN which provides a greater level of protection for the internal network.

How pfsense Firewall Rules Work

Before creating any rules it helps to understand the traffic flow through pfsense on our small network. There are two ways of setting up a DMZ. One way is to have two separate firewalls, one attached to the WAN, and one to the LAN. Between the two firewalls is the DMZ.

Configuring rules is fairly straightforward in this setup since each firewall only has two interfaces to configure. In my network I am using a single firewall to enable this using this network diagram.

To help understand how to configure rules in this setup, we need to think about how the traffic flows. The WAN interface is by default configured to block all traffic, and each interface is configured with a default deny. I will configure WAN rules later to forward specific ports to servers in the DMZ. To configure the DMZ I need to choose which traffic to allow out and to where. All traffic not specifically permitted will be denied.

Creating the DMZ in pfsense

Prerequisite: Creating the Linux Admin Workstation

Using the Linux admin workstation I accessed the firewall’s webConfigurator and changed the OPT1 interface’s firewall rules. The first rule shown in a step by step below was adding UDP port 53 to allow DNS traffic.

While configuring the DMZ I also added rule necessary for web traffic and the ability to ping between the LAN and DMZ. These rules included:

• TCP port 80 (HTTP) from DMZ to all
• TCP port 443 (HTTPS) from DMZ to all
• ICMP any from LAN to DMZ
• ICMP echo reply from DMZ to LAN

The last step I took was to rename the OPT1 interface and make sure the right MTU is set for VXLANs.

That’s all there is to it, I created a DMZ using pfsense and it’s ready for server deployment. Next I am going to install a DNS server on the external and DMZ networks.