BUILD IT & BREAK IT LAB
Active Directory Lab (Part 2) — Configuring Active Directory Services
Configure Active Directory Domain Services and Automate Domain Users Creation with PowerShell
A domain controller is a server responsible for managing network access, verifying user credentials, and enforcing security policies. It consists of several key components that enable running the Windows domain environment, such as Active Directory, LDAP, DNS, Certificate Services, Kerberos, Group Policy, and Network Time Protocol (NTP).
Active Directory is a database that stores and manages information about network resources, including users, computers, and devices. It allows administrators to manage access to these resources and enforce security policies across the network.
Users and resources are represented in the Active Directory as objects. Each object has a unique identifier called a security identifier (SID) and is associated with a set of attributes that describe the object’s characteristics, such as its name, address, and security permissions.
In this post, we will configure the Active Directory services on the server we set up in Part 1 of this series and learn how to quickly automate the process of creating 200 domain users with PowerShell, representing a small business organization.
Let’s start …
Active Directory Setup
We will start installing the Active Directory services and create the forest root domain called “R3dbuck3t.org”. To begin the setup process, we click on the “Add roles and features” option in the server’s dashboard to add the AD role.
The difference between roles and features is that the role refers to the server’s function on the network; like in this lab, the server will function as a domain controller with the Active Directory role. And features refer to the capabilities that come with the role, such as AD administration tools, AD DS tools, Group Policy Management, etc.
In the Setup Wizard, choose the “Role-based or feature-based” installation option since the role is added physically to the virtual machine and not remotely through a Virtual Desktop Infrastructure (VDI).
Next, select the server from the Server Pool list; in our case, “DC01” and click “Next”.
In the Server Roles section, check the “Active Directory Domain Services” box and click on “Add Features” to install the additional capabilities that come with the role.
For the “Features” and “AD DS” sections, we don’t need to change anything; just click “Next” for both of them until the “Confirmation” section. When you get there, click on the “Install” button to begin the service installation.
After the installation is complete, a new notification will show for the Post-deployment Configuration to ask if we want to promote the server to a domain controller.
Click on it to start the Domain Controller configuration, and select “Add a new forest”; we will call the lab forest “R3dbuck3t.org”.
💡A forest is a big container that holds all objects and configurations in the Active Directory structure ( ex: child domains, users, computers, groups, policies, schemas, etc.)
A forest also is considered a security boundary, meaning that objects in different Active Directory forests cannot interact with each other unless the trust is established between the desired forests.
Next, we ensure the “Functional Forest level” is on Windows 2016, which is the highest level available, and choose a password for the “Directory Services Restore Mode (DSRM)”.
For the “DNS Options”, we will leave the “Create DNS Delegation” box unchecked and click “Next”.
💡 The functional level is the capabilities that Active Directory supports, and it also determines which Windows Server operating systems you can run on domain controllers in the forest. The Windows 2016 functional level supports running Windows 2022 on the DC.
💡 Directory Services Restore Mode (DSRM) is a special boot mode only available on the domain controller that allows the domain administrators to log into the domain controller using the DSRM password when the Active Directory fails. It is the local administrator account for the domain controller server.
The safe mode allows the DAs to access the Active Directory database to restore or repair objects.
Verify the NetBIOS domain name is the same as the forest name; in our case, it is“R3dbuck3t”. If all is good, click “Next” to move to the “Paths” section.
The path locations are for the Active Directory database (NTDS), the Log files, and the SYSVOL folder. It is recommended not to change the default paths so that it won’t break anything later; we will keep the default paths and click “Next.”
💡 NTDS is a database that stores Active Directory data, including information about users, computers, groups, and network resource objects.
💡 SYSVOL folder is located locally on the domain controller. It consists of public files, folders such as Group Policy Objects (GPOs), and scripts used to manage the domain users and computers in the forest.
Now that we have configured everything we need for the Active Directory, we can begin the installation process by clicking on “Install” in the “Pre-requisite Check” section. The process will take a few seconds, and you will need to reboot the machine when it ends.
After the machine restarts, we can go to the server dashboard and check the newly created domain “r3dbuck3t.org”.
Now we have installed Active Directory, take a snapshot of the current state before adding domain users.
Adding Domain Users
We can add domain users either manually or using a PowerShell script like the CREATE_USERS.ps1 by JonCyberGuy to create a bulk of domain users.
We are going to go over both the manual and automated ways.
Method #1 Creating Domain Users Manually
To add a new domain user, go to the Server Dashboard, click on “Tools” and “Active Directory Users and Computers.”
In the ADUC window, right-click on the domain name “r3dbuck3t.org” and select “New” -> “User”
Next, fill out the user information and create a password for it. In the real-world example, the “User must change password at logon” box is left checked as it is, so the user can change their own password when they access their account from their workstation for the first time.
However, I’ll uncheck the box for the lab and check the “Password never expires” box to keep things easy to manage. It is recommended to keep all the lab passwords in a Password Manager or spreadsheet 🤯.
Method #2 Automating Domain Users Creation With PowerShell
The “Create Users” PowerShell script that we are going to use creates a large number of domain users with a default password of “Password1”, then adds them to a new Organizational Unit called “_Users”. The domain users are created based on the list of names you provide to the script. In the GitHub report, Jon uses a list of 1000 users in the names.txt file to create the domain accounts.
For the size of our lab, I’ll modify the script to create six (6) standard Organizational Units (Marketing, Finance, Operations, Human Resources, Legal, and IT) and 200 domain users.
We will start with downloading the zip file from the GitHub repo (link); before extracting it, disable the Real-Time Monitoring and set the PowerShell Execution Policy to “Unrestricted.”
#Disable Real-Time Monitoring
Set-MpPreference -DisableRealtimeMonitoring $true -Verbose#PowerShell Execution Policy
Set-ExecutionPolicy Unrestricted 
Open the PowerShell script with a Notepad or PowerShell Windows ISE as Administrator. Then, for the $USER_FIRST_LAST_LIST variable, pass the file name for the user’s list. For example, I have divided my 200 domain users into different files based on the Organizational Units going to create for each of them.
I started with the Marketing department, passed the $USER_FIRST_LAST_LIST variable the marking users’ list, replaced the New-ADOrganizationalUnit from _Users to Marketing to create the Marketing OU, and changed the -Path where users are going to be added to the ou=Marketing.
After the modification, save the script and run it. It will create the domain users and add them to the specified OU.
Go through the process of creating additional OUs if you want for your lab and add users to them; I have already created the six(6) OUs and added the 200 domain users.
After running the script, go back to ADUC window, where you will see all the newly created OUs and domain users.
Now that we have enough users, I’ll pick one in the IT OU to be the domain Admin; I’ll probably add two (2) additional admins later when we need them for the attack scenarios.
🚩 I didn’t go over the naming schema for domain objects to keep this post short; I might have a separate post in the future about it.
To assign a User to a group like “Domain Admins”, select the desired user like “Kcrist”, right-click on their name, and select “Properties”.
Go to the “Member of” tab, click on “Add”, then type the name of the desired group in the “Enter the object names” box. Since we are adding the user to the “Domain Admins” group, we will type “Domain Admins”, click “Check Names” to ensure the name you entered exists, then click on Ok to complete the process.
When the user is added to a new group, it will be visible in the “Member of” list.
With this, we conclude Part 2 of the Active Directory Lab. Today, we went over setting up the Active Directory Domain Services and automated creating larger numbers of domain users with a PowerShell Script.
In the next post, we will cover setting up the DNS and DHCP services to allow domain clients to assign dynamic IPs from the DHCP pool.
Thanks for reading!!!
Check out the Active Directory Pentesting Methodology at R3dbuck3t Notion
