Creating a Simple Windows Domain for Offensive Testing: Part 2

By Red Siege | June 7, 2022

By: Justin Palk, Security Consultant

Welcome back to my series on setting up a Windows domain for offensive testing. In the first installment, I did my basic network setup, created a Windows Server 2019 VM and promoted it to Domain Controller (DC) for the rslabs.lan domain. Now I’m going to create some users, group them into regular users and administrators, and create Organizational Units (OU) for my workstations and servers.

Creating Users

At the moment, the domain has only a single user, the built-in Administrator account. Using this account directly isn’t a great practice, so I’m going to create some other accounts and groups, so the management and use of the domain makes at least a little sense.

In the server manager, under the Tools menu at upper right, is an option for Active Directory Users and Computers.

Clicking that brings up the AD Users and Computers manager. Expanding my domain in the navigation pane reveals a further series of folders, including Users. Clicking on that gives a list of the current users and groups in the domain, all of which are the built-in defaults, as I haven’t created anything else yet.

Clicking the New User button at the top of the screen gives me a user creation window.

The first account I create I plan to eventually make a domain admin, so I have a DA account that isn’t the Administrator account. I name it James Angleton DADM, with a username angletonj_dadm deciding that for my domain, _dadm accounts will denote Domain Admins. James will also get a separate, regular user account in a minute.

I then click Next and set the user’s password. I unclick User must change password at next login, since this isn’t a production network and there’s no sense in making me change the password I just set.

A confirmation screen follows that, and seeing everything is good, I hit Finish and the user is created.

This is the basic process for creating a domain user. I repeat it several times until I have the following users, which I will be assigning various rights and privileges in the domain:

  • angletonj_dadm – Domain Admin

  • angletonj

  • howardb

  • obrienm

  • wilsonp

  • hazardp

I noted above that angletonj_dadm is supposed to be a domain admin, but he isn’t actually in the domain admins group yet. To fix that, I right click on the account name, then hit properties.

I navigate to the Member of tab, and see that this account is only a member of the Domain Users group.

I hit the Add button, and in the Select Groups window that pops up, I first type Domain Admins, then hit the Check Names button. When Domain Admins is underlined, I know that it’s found the group name.

I hit OK, and then Apply back in the account properties window, and angletonj_dadm@rslabs.lan is now a Domain Admin. This is the basic process for adding a user to a group.

Creating Groups

To create a new group, again in the AD Users and Groups management tool, I click the New Group button.

I get a New Object - Group window, where I can name my group, specify its scope and type. I only set the name here, the default scope and type are fine for this use. I create a group for Domain Controller RDP Users because, while to this point and for a bit yet, I’ve been using VMWare’s console to access my DC, at some point I’m likely going to want to access it from inside the domain, and for that I’ll need to turn on RDP, and this group will be necessary for that. I’ll create similar groups for accessing servers and workstations.

To add users, I can either do it user-by-user, like I did for making angletonj_dadm a domain admin, or to add multiple users to a group, like the Workstation RDP Users group, I can do it a little more efficiently by adding users through the group. Right clicking on the group name Workstation RDP Users and selecting Properties brings up the group properties window.

Going to the Member of tab will give a list of current group members, which is empty.

Hitting Add pops up an object selection window, much like the one used to select the Domain Admins group earlier. Entering either a username (e.g. howardb), or part of a name (e.g. monique), and hitting Check Names will find the relevant user. This needs to be done one at a time, as if the system tries to search for “howardb monique” or “howardb, monique”, it won’t find a match.

If I enter something with multiple matches, like Angleton, a second window pops up asking me to pick the result I want.

Once I’ve added everyone I want, I hit OK, then Apply in the group properties window, and the group is populated.

I repeat the process, creating the following groups and memberships: +Workstation Admins – howardb, hazardp +Workstation RDP Users – all users except angletonj_dadm +Server Admins – howardp +Server RDP Users – howardp +Domain Controller RDP Users – angletonj

Creating Organizational Units

The process for creating new Organizational Units is similar. I’m going to create Workstation and Server OUs so I can apply some group policies to specifc sets of computers, rather than the Computers OU as a whole. To do this, I right-click on my domain (rslabs.lan) in the navigation pane, select New, then Organizational Unit.

I enter my new OU name (Workstations), hit OK, and I’m done. I repeat the process to create a new Servers OU (a Domain Controllers OU exists by default. Note that the new OUs are empty; I’ll need to add machines to them once I’ve stood them up.


This is the end of part two. The domain has users, groups and Organizational Units, but no hosts, other than the DC. In part 3, I’ll stand up some workstations and a server, and in part 4 I’ll create some useful Group Policy Objects for managing services and access in the domain.

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

Adventures in Shellcode Obfuscation! Part 1: Overview

By Red Siege | June 17, 2024

by Mike Saunders, Principal Security Consultant This blog is the first in a series of articles on methods for obfuscating shellcode. I’ll be focusing on how to obfuscate shellcode to […]

Learn More
Adventures in Shellcode Obfuscation! Part 1: Overview

Essential Steps for Management to Maximize the Value of a Penetration Test Report

By Red Siege | June 3, 2024

by Tim Medin, CEO Penetration testing is a critical component of a well-rounded cybersecurity strategy. Penetration testing identifies vulnerabilities before malicious actors can exploit them. However, the true value of […]

Learn More
Essential Steps for Management to Maximize the Value of a Penetration Test Report

Fun With JWT X5u

By Red Siege | May 30, 2024

by Senior Security Consultant Douglas Berdeaux On a recent web application penetration test engagement, I came across a JSON Web Token (JWT) that contained an x5u header parameter. I almost […]

Learn More
Fun With JWT X5u

Find Out What’s Next

Stay in the loop with our upcoming events.