This article provides a complete walkthrough of both phases — from clicking “Create a New Virtual Machine” in VMware all the way to a fully operational Domain Controller serving the ignite.local domain.

Table of Contents:

• Introduction
• Part 1: Creating the Virtual Machine
  • Launch the New Virtual Machine Wizard
  • Select Typical Configuration
  • Point to the Windows Server 2019 ISO
  • Configure Disk Capacity
  • Remove the Floppy Drive
  • Set Firmware Type to BIOS
• Part 2: Installing Windows Server 2019
  • Windows Setup Language Selection
  • Initiate Installation
  • Select Windows Server 2019 Desktop Experience
  • Choose Custom Installation
  • Select the Installation Drive
  • Set the Administrator Password
  • First Login to Windows Server 2019
• Part 3: Configuring Active Directory Domain Services via PowerShell
  • Rename the Computer to DC1
  • Install the AD Domain Services Role
  • Promote the Server to a Domain Controller
  • Disable Windows Defender Real-Time Monitoring
  • Disable the Windows Firewall
  • Identify the Network Adapter and Configure DNS
• Part 4: Installing Active Directory Certificate Services (AD CS)
  • Install the AD CS Windows Feature
  • Configure the Enterprise Root Certification Authority
• Part 5: Creating Domain Users and Assigning Group Memberships
  • Create Five Domain User Accounts
  • Elevate raj to Domain Admin
  • Assign ankur to Backup Operators and Remote Management Users
• Part 6: Preparing and Joining the Windows 10 Client Machine
  • Rename the Client Machine
  • Identify the Network Adapter and Point DNS to the DC
  • Join the Windows 10 Client to the ignite.local Domain
• Part 7: Verifying Domain Authentication from the Client
  • Log In with Domain User Accounts
• Conclusion

Introduction

Active Directory Domain Services (AD DS) forms the backbone of enterprise identity management, authentication, and access control in Windows environments. Building a functional AD lab requires two sequential phases: creating and configuring a virtual machine in VMware Workstation Pro 17 and then installing and promoting Windows Server 2019 to a Domain Controller role.

Part 1: Creating the Virtual Machine

Launch the New Virtual Machine Wizard

Open VMware Workstation Pro 17 and click the “Create a New Virtual Machine” tile on the home screen. This launches the New Virtual Machine Wizard, which guides you through all configuration steps needed to define the VM hardware profile before installing the guest operating system.

Select Typical Configuration

The wizard presents two configuration modes. Select “Typical (recommended)” to create a standard Workstation 17.5 virtual machine in just a few steps. The Typical mode automatically handles hardware defaults such as disk controller type and virtual hardware compatibility, making it the ideal choice for lab deployments where simplicity and speed matter more than advanced customisation.

Point to the Windows Server 2019 ISO

On the Guest Operating System Installation screen, select “Installer disc image file (iso)” and browse to the Windows Server 2019 ISO file. In this lab, the ISO resides at D:\OS Images\Windows Server\server 2019.iso. VMware automatically detects the operating system and activates Easy Install, which pre-populates setup parameters and streamlines the installation process.

Name the Virtual Machine

Assign the virtual machine a descriptive name. Enter “Windows Server 2019 AD” to clearly identify this VM’s purpose within the VMware library. VMware stores the VM files at the displayed path under the user’s OneDrive Documents directory. The name appears in the VMware sidebar and in window titles, making it easy to distinguish this machine from other VMs in a multi-machine lab environment.

Configure Disk Capacity

Set the maximum disk size to 60 GB, which matches Microsoft’s recommended minimum for Windows Server 2019. Select “Split virtual disk into multiple files” to make the VM more portable — this option divides the virtual disk into 2 GB segments, allowing the VM folder to be copied across file systems that enforce individual file size limits. VMware grows the disk files dynamically as the guest OS writes data, so the full 60 GB is not consumed immediately on the host.

Remove the Floppy Drive

Open Virtual Machine Settings after the wizard completes. Under the Hardware tab, select the Floppy device — VMware’s Easy Install automatically creates an autoinst.flp floppy image for automated setup responses. Since this lab performs a manual installation, click “Remove” to delete the floppy device entirely. This prevents unexpected, automated prompts during the Windows Setup process and eliminates unnecessary virtual hardware overhead.

Set Firmware Type to BIOS

Navigate to the Options tab in Virtual Machine Settings, then click “Advanced.” Under Firmware type, confirm BIOS is selected rather than UEFI. BIOS mode ensures maximum compatibility with older lab tools and penetration testing frameworks that may not fully support UEFI boot environments. This setting must be configured before the first power-on — changing the firmware type after OS installation will render the VM unbootable.

Part 2: Installing Windows Server 2019

Power on the VM. The Windows Server 2019 installer boots from the ISO and presents the language and locale selection screen. Keep all defaults — Language: English (United States), Time and currency format: English (United States), Keyboard: US — and click Next. These settings establish the base locale for the server operating system and affect default date formats, input behavior, and system language packs installed during setup.

Initiate Installation

The setup welcome screen presents the prominent “Install now” button alongside a “Repair your computer” link at the bottom left. Click “Install now” to proceed with a fresh installation. This initiates the setup engine, which begins collecting system information in the background while presenting the configuration wizard screens in the foreground.

Select Windows Server 2019 Desktop Experience

The OS edition selection screen presents four options. Select “Windows Server 2019 Standard Evaluation (Desktop Experience)” — the highlighted entry in the list. This edition installs the full graphical user interface (GUI) shell, enabling Server Manager, MMC snap-ins, and all graphical administration tools. The Server Core alternatives omit the GUI entirely and are better suited for production environments, but the Desktop Experience edition is essential for a hands-on lab where visual administration tools are required.

Choose Custom Installation

When prompted “Which type of installation do you want?”, select “Custom: Install Windows only (advanced).” This option performs a clean installation on the target disk without preserving any existing files, settings, or applications. The Upgrade option is unavailable for a fresh virtual disk and would only apply when migrating from an existing Windows installation. Custom installation gives full control over partition layout, which is important for lab environments where the disk must be configured from scratch.

Select the Installation Drive

The drive selection screen displays “Drive 0 Unallocated Space” with 60.0 GB total and 60.0 GB free — exactly the disk configured in VMware. Select this drive and click Next. Windows Setup automatically creates the required system partition (typically 500 MB for the recovery environment) and allocates the remaining space to the primary Windows partition. No manual partitioning is necessary for a standard Domain Controller lab deployment.

Set the Administrator Password

After installation completes and the system restarts, Windows presents the “Customize settings” screen. The built-in Administrator account username is pre-populated and cannot be changed here. Enter a strong password in the Password and Reenter password fields, then click Finish. This password becomes the local Administrator credential used for all initial configuration steps before domain promotion. Store it securely — it will remain the DSRM (Directory Services Restore Mode) recovery password after AD DS is installed.

First Login to Windows Server 2019

The lock screen presents the Administrator account login prompt against the default Windows Server 2019 wallpaper. Enter the password set in the previous step to log in for the first time. Server Manager launches automatically after login, confirming that the Desktop Experience installation succeeded. The server is now ready for hostname configuration and Active Directory Domain Services installation.

Part 3: Configuring Active Directory Domain Services via PowerShell

All remaining configuration steps execute in an elevated Windows PowerShell session. Open PowerShell as Administrator from the Start menu or by right-clicking the taskbar PowerShell icon. Using PowerShell for AD DS configuration is the preferred method in professional and lab environments because it produces reproducible, scriptable results and builds fluency with tools used throughout penetration testing and administration workflows.

Rename the Computer to DC1

Execute the following command to rename the server and trigger an automatic restart:

Rename-Computer -NewName "DC1" -Restart

This cmdlet changes the NetBIOS name and DNS hostname of the server to DC1 — a standard naming convention for the first Domain Controller in a lab domain.

Install the AD Domain Services Role

Install the Active Directory Domain Services Windows Feature along with its management console by running:

Install-WindowsFeature -name AD-Domain-Services -IncludeManagementTools

The cmdlet installs the AD-Domain-Services role and automatically includes the Group Policy Management Console and all AD DS snap-ins (-IncludeManagementTools).

Promote the Server to a Domain Controller

Promote the server to the first Domain Controller in a new Active Directory forest by running:

Install-ADDSForest -DomainName ignite.local -skipprechecks

This cmdlet creates a brand-new Active Directory forest with ignite.local as the root domain.

Disable Windows Defender Real-Time Monitoring

Disable Windows Defender‘s real-time monitoring to prevent it from interfering with penetration testing tools and payloads used in the lab:

Set-MpPreference -DisableRealtimeMonitoring $true

This PowerShell cmdlet instructs Windows Defender Antivirus to stop scanning files in real time. In a controlled lab environment, real-time protection frequently blocks Metasploit payloads, Impacket tools, Mimikatz, and other offensive security utilities that are legitimate and necessary for security research. This setting applies immediately and persists across reboots until explicitly reversed. Never disable Defender on production systems — this step is strictly for isolated lab environments.

Disable the Windows Firewall

Disable the Windows Firewall across all network profiles to allow unrestricted communication between lab machines:

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

This single command disables the Windows Firewall for the Domain, Public, and Private network profiles simultaneously. In a lab network, the firewall would otherwise block inbound SMB (445), WinRM (5985), RPC (135), and RDP (3389) connections — all of which are essential for AD DS replication, remote administration, and security testing. As with Defender, disabling the firewall applies only to this isolated virtual machine and must never be performed in production environments.

Identify the Network Adapter and Configure DNS

First, discover the network adapter name, then configure the DNS client to point to the Domain Controller itself:

Get-NetAdapter
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 192.168.1.7

This is a critical step: Domain Controllers must always point to themselves (or another DC) for DNS resolution because Active Directory relies entirely on DNS for service location records (SRV records), replication, and Kerberos ticket issuance.

Verify DNS Server Address Assignment

Before deploying any additional services, verify that the Domain Controller correctly resolves DNS queries using its own IP address. Run the following command to display the DNS client configuration for all network interfaces:

Get-DnsClientServerAddress

output confirms that the DC will resolve all AD-related DNS records (SRV, A, and PTR records) using itself — a mandatory requirement for correct Kerberos authentication, LDAP lookups, and AD replication. No further DNS configuration is necessary.

Part 4: Installing Active Directory Certificate Services (AD CS)

Active Directory Certificate Services provides the domain’s Public Key Infrastructure — enabling certificate-based authentication, encrypted communications, smart card logon, and protocols such as LDAPS. In a penetration testing lab, AD CS is particularly valuable because it introduces ESC (Escalation via Certificate) attack paths, including ESC1 through ESC8, which are commonly found in real enterprise environments and tested during red team engagements.

Install the AD CS Windows Feature

Install the ADCS-Cert-Authority Windows Feature along with its management tools by executing the following command in an elevated PowerShell session on DC1:

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

The -IncludeManagementTools flag automatically pulls in the Certification Authority MMC snap-in and all PowerShell management cmdlets for AD CS administration. No restart is required at this stage.

Configure the Enterprise Root Certification Authority

With the role installed, configure it as an Enterprise Root CA using the Install-AdcsCertificationAuthority cmdlet with the following full parameter set:

Install-AdcsCertificationAuthority `
  -CAType EnterpriseRootCA `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -KeyLength 2048 `
  -HashAlgorithmName SHA256 `
  -ValidityPeriod Years `
  -ValidityPeriodUnits 10 `
  -CACommonName "ignite-CA"

The Active Directory Certificate Services infrastructure is now fully operational on DC1 — domain members can request and auto-enroll for certificates immediately.

Part 5: Creating Domain Users and Assigning Group Memberships

A realistic Active Directory lab requires multiple user accounts with varied privilege levels to simulate real organizational structures and to provide targets for enumeration, credential attacks, and privilege escalation exercises. The following steps create five domain user accounts and assign deliberate group memberships that introduce intentional misconfigurations commonly found in enterprise environments.

Create Five Domain User Accounts

Create five domain user accounts using the net user command with the /add /domain flags.

Execute each command separately in the Administrator PowerShell session on DC1:

net user raj Password@1 /add /domain
net user ankur Password@1 /add /domain
net user aarti Password@1 /add /domain
net user kavish Password@1 /add /domain
net user sanjeet Password@1 /add /domain

All five commands complete with “The command completed successfully,” confirming that Active Directory created each account in the default Users container (CN=Users,DC=ignite,DC=local).

Elevate raj to Domain Admin

Add the user raj to the Domain Admins group to create a high-privilege domain account that security tools can target during privilege escalation and lateral movement exercises:

net group "Domain Admins" raj /add /domain

The Domain Admins membership grants raj full administrative privileges over every machine in the ignite.local domain, making this account the primary high-value target for Kerberoasting, Pass-the-Hash, and DCSync attacks in penetration testing scenarios.

Assign ankur to Backup Operators and Remote Management Users

Configure the user ankur with two local group memberships that grant elevated but non-administrator access — a common misconfiguration pattern in real environments:

net localgroup "Backup Operators" ankur /add
net localgroup "Remote Management Users" ankur /add

The Backup Operators group grants the ability to bypass file and directory permissions for backup purposes — a right that attackers frequently abuse to read sensitive files such as NTDS.dit and the SAM database. The Remote Management Users group grants WinRM access, allowing tools like Evil-WinRM to authenticate as ankur and obtain a remote PowerShell session. This deliberate over-privileging makes ankur an ideal target for privilege escalation exercises and WinRM-based lateral movement attacks.

Part 6: Preparing and Joining the Windows 10 Client Machine

A Domain Controller without client machines provides limited value for lateral movement and authentication attack exercises. This part sets up a Windows 10 virtual machine (initially named MSEDGEWIN10) as a domain-joined workstation, creating a two-machine lab environment where attacks can travel from the client to the DC and vice versa.

Rename the Client Machine

Open an elevated PowerShell session on the Windows 10 VM and rename it to “client” — a clean, descriptive hostname for the workstation role:

Rename-Computer -NewName client

Identify the Network Adapter and Point DNS to the DC

Discover the client’s network interface name and configure it to use the Domain Controller as its DNS server — the same essential step performed on the DC itself:

Get-NetAdapter
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 192.168.1.7

Join the Windows 10 Client to the ignite.local Domain

Execute the domain join command, which immediately prompts for Domain Administrator credentials:

Add-Computer -DomainName ignite.local -Restart

On this restart, the client boots as a domain member, applies domain Group Policy objects, and registers its DNS A record with the DC’s DNS server — completing the domain join process.

Part 7: Verifying Domain Authentication from the Client

Log In with Domain User Accounts

After the client restarts as a domain member, the Windows 10 login screen presents domain authentication options. The bottom-left corner shows two available accounts — IGNITE\raj (the Domain Admin) and an “Other user” option. Select “Other user,” enter “ankur” as the username and the corresponding domain password, and observe the “Sign in to: IGNITE” label below the password field, which confirms domain authentication mode is active.

The “Sign in to: IGNITE” text confirms that the client successfully joined the ignite.local domain (NetBIOS name: IGNITE) and is routing authentication requests to the Domain Controller via Kerberos. The presence of IGNITE\raj in the bottom-left tile demonstrates that domain accounts are available on this workstation. Successfully logging in as ankur validates the entire lab setup chain: the DC serves authentication requests, the user accounts exist in AD, group memberships are active, and the client machine communicates with the DC over the domain trust. The Active Directory lab environment is now fully operational.

Conclusion

This article delivered a complete, end-to-end walkthrough for constructing a fully functional Active Directory lab environment inside VMware Workstation Pro 17 — from creating the virtual machine hardware profile all the way to domain-joined client authentication. The setup spanned eight structured phases, each building directly on the last, producing a two-machine Windows environment that closely mirrors real enterprise Active Directory deployments.

The resulting lab provides a self-contained, deliberately misconfigured Active Directory environment that replicates the attack surface of real enterprise networks. It serves as the direct foundation for companion exercises covering remote RDP enabling, SMB lateral movement, credential harvesting with Impacket and NetExec, Active Directory enumeration with BloodHound, Kerberos ticket attacks, and AD CS exploitation via Certipy. Security students, penetration testers, and red team practitioners can use this lab to safely develop, test, and refine attack techniques against a realistic Windows domain — without impacting any production infrastructure.