This article demonstrates the end-to-end process of building an Active Directory environment from scratch and performing structured enumeration to identify domain services, users, and access points within the network.

Table of Contents:

• Part 1: 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 2: 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 3: Installing Active Directory Certificate Services (AD CS)
• Install the AD CS Windows Feature
• Configure the Enterprise Root Certification Authority
• Part 4: Creating Domain Users and Assigning Group Memberships
• Create Five Domain User Accounts
• Elevate red to Domain Admin
• Assign root to Backup Operators and Remote Management Users
• Part 5: 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 lab.local Domain
• Part 6: Verifying Domain Authentication from the Client
• Log In with Domain User Accounts
• Part 7: Enumeration
• Nmap
• SMB Enumeration
• LDAP Enumeration
• Kerberos
• WinRM

Lab Requirements

• Virtual Machine (VMware Work Station/Player)
• Windows Server 2016
• Windows 10 Pro Operating System (Client)
• Kali linux (Enumaration)

1.Setting Up Windows Server 2016 (VirtualBox)

After downloading the required ISO file, we will now create a virtual machine in VirtualBox to install Windows Server 2016.

• Open VirtualBox
• Click on New
• Enter a name for the virtual machine (e.g., windows.server)
• Select Microsoft Windows as the Type
• Select Windows Server 2016 (64-bit) as the Version
• Attach the downloaded Windows Server 2016 ISO file
• Keep Unattended Installation unchecked (manual installation for learning)
• Click Next / Finish

2.Configuring Virtual Machine Settings

After creating the virtual machine, we now verify and adjust the basic settings before starting the installation.

• Open VirtualBox
• Select your virtual machine (windows.server)
• Click on Settings / Details

3.Configure the following:

• Base Memory (RAM): Set to at least 2048 MB (2GB) (4GB recommended)
• Storage:
• Ensure the Windows Server 2016 ISO is attached
• Verify virtual disk size (recommended 50 GB)
• Display:
• Video Memory: 128 MB (default is fine)
• Network:
• Set Adapter to Bridged Adapter (or NAT if beginner)

Now Lets Start the Windows Server 2016 configuration steps:

4.Start Your Windows Server VM, Click On Next >> Install Now.

5. Select Windows Server 2019 Standard Evaluation (Desktop Experience) > Next > Tick the license terms > Next

6. Select, Custom: Install Windows only (advanced) > New > Apply > Next.

7. Chose the Driver to install On it >> Next.

8. After successful installation, enter a password >> Finish. Then enter the password to login .

Ex: Password1

9. To access to the Login Click

Click On Input >> Keyboard >> Insert Vtrl+Alt+Del

now we have finished the Process of installing Windows Server , Now we will Start Installing Active Directory.

Part 2: 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.

1.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.

2.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).

3.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 lab.local -skipprechecks

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

4.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.

5.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.

6.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 "Ethernet" -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.

7.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 3: 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.

1.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.

2.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 "lab-CA"

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

Part 4: 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.

1.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 red Password@1 /add /domain
net user root Password@1 /add /domain
net user kali Password@1 /add /domain
net user basi Password@1 /add /domain
net user admin 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).

2.Elevate red to Domain Admin

Add the user red 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" red /add /domain

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

3.Assign root to Backup Operators and Remote Management Users

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

net localgroup "Backup Operators" root /add
net localgroup "Remote Management Users" root /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 root and obtain a remote PowerShell session. This deliberate over-privileging makes root an ideal target for privilege escalation exercises and WinRM-based lateral movement attacks.

Part 5: 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.

1.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

2.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 "Ethernet" -ServerAddresses 192.168.1.7

3.Join the Windows 10 Client to the lab.local Domain

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

Add-Computer -DomainName lab.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 6: Verifying Domain Authentication from the Client

1.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 — lab\red (the Domain Admin) and an "Other user" option. Select "Other user," enter "root" as the username and the corresponding domain password, and observe the "Sign in to: lab" label below the password field, which confirms domain authentication mode is active.

The "Sign in to: lab" text confirms that the client successfully joined the lab.local domain (NetBIOS name: lab) and is routing authentication requests to the Domain Controller via Kerberos. The presence of lab\red in the bottom-left tile demonstrates that domain accounts are available on this workstation. Successfully logging in as root 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

Part 7: Enumeration

1.Nmap Enumeration

Open Ports & Key Services

• 53 (DNS) → Domain name resolution
• 88 (Kerberos) → Authentication service
• 135 (RPC) → Windows remote operations
• 139 / 445 (SMB) → File sharing & user enumeration
• 389 / 636 (LDAP/LDAPS) → Active Directory services
• 3268 / 3269 (Global Catalog) → Domain-wide queries
• 5985 (WinRM) → Remote PowerShell access

Key Findings

• Target is a Domain Controller (DC1.lab.local)
• Domain identified: lab.local
• Multiple AD services exposed → high-value target for enumeration

2.SMB Enumeration

SMB enumeration revealed valid credentials (lab.local\root), accessible administrative shares, and multiple domain user accounts, indicating strong potential for further access and privilege escalation.

3.LDAP Enumeration

ldapsearch -x -H ldap://192.168.1.7 -D "lab\\root" -w 'Password@1' -b "DC=lab,DC=local"

Anonymous LDAP access was restricted on the target. However, using valid domain credentials, LDAP queries successfully retrieved Active Directory information, including users and domain structure.

4.Kerberos User Enumeration

Kerbrute successfully identified valid domain users, confirming multiple active accounts in the lab.local domain.

5.WinRM Access

WinRM access was successfully obtained using valid credentials, allowing remote command execution on the target system.

evil-winrm -i 192.168.1.7 -u root -p 'Password@1'

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