Creating a Simple Windows Domain for Offensive Testing: Part 3

By Red Siege | June 15, 2022

by Security Consultant Justin Palk

Welcome back to my series on setting up a Windows domain for offensive testing. In the first two installments (Part 1, Part 2), I stood up a DC for the domain, and created users, groups and organizational units (OU) to organize it. Now I’m going to stand up some machines other than the DC inside the domain.

Creating and Joining Workstations

Creating one or more workstation VMs for the domain will be very similar to the process of creating server VMs. I’m only going to hit key parts of the process here. First, I make sure to set that I’ll install the operating system later, so as not to engage the Quick Install process.

The only real differences with standing up a server are that when given the option to set my guest operating system, I choose Windows 10 and later x64, and I make sure to mount the Windows 10 Enterprise evaluation ISO, rather than the Windows Server 2019 ISO.

Otherwise, I drop the vm to 1 CPU, 40GB of storage, and set the network adapter to the one for the domain network, just as I did with the server. I also drop the RAM to 2 GB.

Once the VM boots, I accept the license terms, pick a custom Windows installation, and direct it to the sole hard disk for the VM, just as I did for the server. After a few minutes of installation and a restart or two, the VM comes up for its initial configuration. Most of this is a matter of personal preference (region, keyboard layout, etc), except for when I hit the Sign in with Microsoft page. Here, rather than entering an account name, I hit Domain join instead.

Perversely, this does not start the process of joining a machine to a domain. What it will do is create a local account with admin privileges I can then use to domain join the computer. So, I pick an account name (rslabs-admin), set a password and pick security questions and answers.

After this comes setting the device’s privacy settings, all of which I set to No. This goes along with disabling Cortana, on the following screen.

After a few more minutes of under-the-hood work the workstation presents its desktop. This Before attempting to join the computer to the domain, I need to change the computer’s DNS server to point at the DC. I type ethernet into the search bar, then click on Ethernet Settings. I click on Change Adapter Options in the settings window, then right-click on the ethernet adapter and choose Properties.

When the Properties window opens, I select Internet Protocol Version 4 (TCP/IPv4) Properties, and the hit the Properties button.

Here I configure leave the setting to Obtain an IP Address Automatically checked, because I want the workstation to get its address from DHCP, but I set the DNS server to the address of the DC (, which is handling DNS for the domain. I hit OK, then close my way out of the network configuration screens.

If I wanted to add a bunch of workstations to the domain in rapid succession, this would be a good time to shut the machine down and snapshot it so I can make clones.

To domain join the workstation, I go back to the desktop, type name into the search bar, then click on Change workgroup name in the results.

In the System Properties window, I hit the Change button, then set the name I want the computer to have in the domain, and set the domain name and hit OK.

I’m then prompted for credentials. Any domain user should work for this.

After a minute or two of thinking, I’m welcomed to the domain.

I’m also asked whether I want this machine to be discoverable on this network, and I select Yes.

After rebooting, as prompted, I receive a RSLABS domain login screen.

I’m not quite done getting things set up. I did create a Workstations OU earlier, and I’d like to put this host into it so the proper GPOs will be applied. Going back to my DC, I open the AD Users and Computers manager from the Tools menu in the upper right hand corner of the Server Manager. Clicking on the Computers OU, I see the new computer rsl-wks-1 there. I click and drag it into the Workstations OU, so that it will receive GPOs I’ve applied to that OU.

I can repeat this process

Creating and Joining Servers

I’m leaving this as an exercise for the reader. The process for standing up the VM is exactly the same as that for the Domain Controller, other than, instead of promoting the computer to a DC, it gets joined to the domain. I can even bypass most of the VM creation process by cloning the VM, since I made a snapshot right after standing it up. The domain-joining process is exactly the same as that for workstations, unless you want to give the computer a static IP rather than using DHCP when configuring the networking.


That’s it for part three. I now have a domain with a DC, one or more workstations, and one or more servers. The fourth and final part of the series will focus on creating Group Policy Objects (GPOs) to enable services and manage access to machines based on us.

About Justin Palk, Security Consultant:

Justin Palk has more than 16 years of experience in IT and information security, and has worked in the academic, federal civilian government and health research sectors. He has held a variety of roles including system administrator, developer, auditor, assessment team lead and web application penetration tester. He regularly competes in CTFs in the U.S. and Europe.


Connect on Twitter & LinkedIn

Dumping LSASS Like it’s 2019

By Red Siege | March 4, 2024

By Alex Reid, Current Red Siege Intern   A long-time tactic of threat actors and offensive security professionals alike, tampering with LSASS.exe in order to recover credentials remains a highly […]

Learn More
Dumping LSASS Like it’s 2019

Better Living Through OpenSSH Config Files

By Red Siege | February 15, 2024

By: Justin Palk, Senior Security Consultant   SSH is an incredibly valuable tool for penetration testing. It provides us with a secure channel for administering machines, remotely executing tools, transferring […]

Learn More
Better Living Through OpenSSH Config Files

GraphStrike: Anatomy of Offensive Tool Development

By Red Siege | January 22, 2024

By: Alex Reid, Current Red Siege Intern Introduction This blog post accompanies the release of an open source tool called GraphStrike which can be found here. Those familiar with my […]

Learn More
GraphStrike: Anatomy of Offensive Tool Development

Find Out What’s Next

Stay in the loop with our upcoming events.