Active Directory Homelab — Elliott Morris

Goal

Build a working AD domain from scratch and practice the day-to-day admin tasks an IT support tech handles: creating users, managing groups and OUs, resetting passwords, and applying basic Group Policy.

Lab Environment

Host: Windows 11 (Desktop PC)
Hypervisor: VirtualBox 7
DC: Windows Server 2022 Evaluation
Client: Windows 11 Pro VM
Network: VirtualBox Internal Network
Domain: morrislab.local

Domain setup

Installed Windows Server 2022 in VirtualBox

Allocated 4 GB RAM and 60 GB dynamic disk. Set the network adapter to VirtualBox Internal Network so the VMs share an isolated subnet without exposing the domain to my home LAN.

Promoted the server to Domain Controller

Added the AD DS role via Server Manager, then ran the AD DS Configuration Wizard. Created a new forest: morrislab.local. The wizard automatically installed and configured DNS on the DC.

Built the OU structure

Opened ADUC (dsa.msc) and created an OU layout that mirrors a real environment: Computers, Domain Controllers, and a Users container. Putting accounts in proper OUs makes GPO targeting clean.

Created users and security groups

Created user accounts including a test account, placed them in the correct OUs, and verified group membership appeared correctly in user properties.

Joined the Windows 11 client to the domain

Set the client's DNS to the DC IP. Went to System → Rename this PC (Advanced) → Domain → entered morrislab.local. After reboot, confirmed domain login worked with a test user account.

Practical task: user password reset

One of the most common help desk requests in any AD environment. Here's the full process documented end-to-end, performed on the morrislab.local domain.

Active Directory Users and Computers open showing morrislab.local domain tree with Users OU expanded — Step 1 — ADUC open with morrislab.local domain tree and user accounts visible

Right-click context menu on Elliott Morris user with Reset Password highlighted — Step 2 — Right-click the user → Reset Password...

Reset Password dialog with new password fields and User must change password at next logon checked — Step 3 — Set temp password, check "must change at next logon"

Active Directory Domain Services confirmation: The password for Elliott Morris has been changed — Step 4 — Confirmation: "The password for Elliott Morris has been changed"

Key practice: always force a password change

"User must change password at next logon" means the help desk never knows the user's actual password. The user owns their credentials from the moment they log in — this is the correct security practice, not optional.

PowerShell equivalent

PowerShell — DC (morrislab.local)

# Reset a user's password via PowerShell
Set-ADAccountPassword -Identity "emorris" `
  -NewPassword (ConvertTo-SecureString "TempP@ss1!" -AsPlainText -Force) `
  -Reset

# Force password change at next logon
Set-ADUser -Identity "emorris" -ChangePasswordAtLogon $true

# Confirm account status
Get-ADUser -Identity "emorris" -Properties LockedOut, Enabled, PasswordExpired
Enabled      : True
LockedOut    : False
PasswordExpired : False

# Unlock if locked out
Unlock-ADAccount -Identity "emorris"

What went wrong

Client couldn't find the domain during join

The Windows 11 client returned "domain not found." The problem was DNS — the client's DNS was still pointing to my home router instead of the DC. Changing the static DNS setting and retrying fixed it immediately.

Password reset failed — complexity requirements

First attempted reset with a simple password and got a rejection. The domain's default password policy requires uppercase, lowercase, number, and symbol. Used a compliant temp password and it went through.

What I learned

DNS is the foundation of AD

Active Directory won't function without correct DNS. The DC must be the DNS server for all domain-joined machines — pointing clients at the home router breaks everything silently.

Always force a password change

The help desk should never know a user's actual password. "Must change at next logon" enforces this automatically.

PowerShell scales where the GUI doesn't

Resetting one account in ADUC is fine. Resetting 50 accounts, or auditing lockout status across a domain, requires PowerShell — learning the cmdlets now is the right investment.

OU structure determines GPO flexibility

GPOs link to OUs. Planning the hierarchy before populating users means you can target policies precisely rather than applying everything to the whole domain.