Build an Active Directory Domain

Stand up a Windows Server 2025 Domain Controller with OUs, RBAC, and GPOs.

Introduction

30 Second Summary

Every time someone logs in to a work computer, resets their password, or gets access to a shared drive, there is an Active Directory domain behind the scenes making it happen. It is the backbone of identity management in nearly every enterprise.

In this project, you will build a fully functional Active Directory domain from scratch on a local Windows Server 2025 virtual machine. You will promote a server to a Domain Controller, design an enterprise-style organizational structure, create users with role-based access, and enforce security policies with Group Policy.

What You'll Build

By the end, you can open Active Directory Users and Computers, navigate a department-based hierarchy you designed, reset a user's password in seconds with PowerShell, and prove your security baselines are enforced by running a single audit command.

By the end of this project, you'll have:

  • A running Domain Controller hosting a new AD forest where you can log in as any user you created and see centralized authentication working.
  • A clean OU structure organized by department (IT, HR, Finance, Sales) with security groups that control who can access what.
  • Enforced Group Policy security baselines you can prove are active by running net accounts and seeing your exact password and lockout rules reflected back.
  • PowerShell-driven helpdesk operations where you reset passwords, unlock accounts, and onboard or offboard users in seconds.
  • Secret Mission: Automate bulk user provisioning from a CSV file using PowerShell.

Are there any prerequisites?

This project assumes you have VMware Workstation Pro already installed on a Windows PC with at least 16GB of RAM. You should also be comfortable navigating the Windows Server interface.

You do not need any prior Active Directory experience. This project starts from a blank server and builds everything step by step.

Before We Start

Before you dive in, take a moment to commit to what you are building and why it matters. This step locks in your goals so every action that follows has a clear purpose.

Set Up Your Windows Server 2025 VM

Building an Active Directory domain requires a dedicated server environment, isolated from your personal machine.

In this step, you will download the Windows Server 2025 evaluation ISO and create a virtual machine in VMware Workstation Pro. By the end, you will have a fully running server with networking configured, ready to become a Domain Controller.

In this step, get ready to:
  • Download the Windows Server 2025 evaluation ISO from Microsoft.
  • Create and install a VMware virtual machine with the correct resources.
  • Configure a static IP address and apply Windows updates.
Download the Windows Server 2025 evaluation ISO

Microsoft offers a free 180-day evaluation of Windows Server 2025. You need to download the ISO image so VMware can use it to install the operating system inside your virtual machine.

  • Open your browser and navigate to the Microsoft Evaluation Center.
  • Sign in with your Microsoft account (or create one if needed).
  • Select the 64-bit edition ISO download.
  • Save the ISO file to a location you can easily find, such as your Downloads folder.

What is an ISO file?

An ISO file is a complete copy of a disc image. VMware will mount this file as a virtual DVD drive, letting your VM install Windows Server from it just as a physical server would install from a real disc.

Activate within 10 days

The evaluation is free for 180 days, but you must activate it over the internet within 10 days of installation. Otherwise the server will shut down automatically.

Create and install the virtual machine

Now that you have the ISO, you will create a new VM in VMware Workstation Pro and install Windows Server 2025 inside it.

  • Press the Windows key to open your search bar.
  • Type VMware Workstation and press Enter to open it.
  • Click File in the top menu bar.
  • Click New Virtual Machine.
  • Select Typical (recommended) and click Next.
  • Select Installer disc image file (iso) and click Browse.
  • Navigate to the Windows Server 2025 ISO you downloaded and select it.
  • Click Next through the wizard until you reach the hardware settings.

When you reach the hardware configuration, set the following resources.

  • Set Memory to 4096 MB (4 GB).
  • Set Processors to 2 CPU cores.
  • Set the virtual disk size to 50 GB.
  • Click Finish to create the VM.

The VM will power on and boot from the ISO. The Windows Setup wizard will appear.

  • Click Next on the language and keyboard screen.
  • Click Install now.
  • When prompted to select an operating system, choose Windows Server 2025 Standard Evaluation (Desktop Experience).
  • Accept the license terms and select Custom: Install Windows only.
  • Select the 50 GB drive and click Next to begin installation.

Why Desktop Experience?

Windows Server can be installed as Server Core (command-line only) or with the Desktop Experience (full GUI). You need the Desktop Experience because later steps use graphical tools like Active Directory Users and Computers (ADUC) and the Group Policy Management Console (GPMC) alongside PowerShell.

Installation takes several minutes. The VM will reboot during the process.

  • When prompted, set the Administrator password. Choose something memorable for your lab (you will use this throughout the project).
  • Press Ctrl+Alt+Insert (the VMware shortcut for Ctrl+Alt+Delete inside a VM) to unlock the login screen.
  • Log in with your Administrator password.

You should now see the Windows Server 2025 desktop with Server Manager opening automatically.

VM won't boot from the ISO?

If you see a black screen or a "No bootable device" message, the ISO may not be mounted correctly.

  • Power off the VM, then go to VM > Settings > CD/DVD and confirm the ISO file path is correct.
  • Make sure Connect at power on is checked for the CD/DVD device.

Still stuck? Help me troubleshoot my VMware VM not booting from the Windows Server ISO.

Configure a static IP address and apply updates

Your server needs a predictable IP address so other machines (and the DNS it will host) can always find it. You will set a static IP now, before promoting this server to a Domain Controller.

  • Press Win+R to open the Run dialog.
  • Type ncpa.cpl and press Enter to open Network Connections.
  • Right-click your Ethernet adapter and select Properties.
  • Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
  • Select Use the following IP address.
  • Enter 192.168.1.10 in the IP address field.
  • Enter 255.255.255.0 in the Subnet mask field.

Now set the DNS server to point to itself. Once AD DS is installed in the next step, this server will host its own DNS.

  • Select Use the following DNS server addresses.
  • Enter 127.0.0.1 in the Preferred DNS server field.
  • Click OK to close the IPv4 properties.
  • Click Close on the adapter properties window.

Why point DNS to 127.0.0.1?

When you promote this server to a Domain Controller in the next step, it will install a DNS server role. Setting the Preferred DNS to 127.0.0.1 (localhost) means the server will query itself for domain name resolution. This is required for Active Directory to function correctly.

To verify the IP was set correctly, open a Command Prompt or PowerShell window and type ipconfig. You should see 192.168.1.10 listed as the IPv4 address for your Ethernet adapter.

Finally, apply any available Windows updates to keep the server current.

  • Open Settings by pressing Win+I.
  • Click Windows Update.
  • Click Check for updates and install any available updates.
  • Restart the VM if prompted.

Windows Update failing to connect?

Since you set DNS to 127.0.0.1 but no DNS server is running yet, Windows Update may not resolve Microsoft's servers.

  • Temporarily change the Preferred DNS server to 8.8.8.8 (Google DNS) to run Windows Update.
  • After updates complete, change it back to 127.0.0.1 before continuing to the next step.

Still having trouble? Help me fix Windows Update connectivity issues in my Windows Server 2025 VM.

Before you verify, what do you expect to see when you check the Windows version on this server?

  • Press Win+R to open the Run dialog.
  • Type winver and press Enter.

You should see the About Windows dialog displaying "Windows Server 2025". This confirms your VM is running the correct operating system.

Your server is running and networked. Next up, you will install Active Directory Domain Services and promote this machine to a Domain Controller, transforming it from a standalone server into the central authority for your entire domain.

Install AD DS and Promote to Domain Controller

Your Windows Server 2025 VM is up and running with a static IP address. The server is ready, but it cannot manage user accounts, enforce security policies, or authenticate anyone on a network.

A bare Windows Server needs the Active Directory Domain Services (AD DS) role installed and then promoted to a Domain Controller before it can become the central identity authority for your domain. In this step, you will install that role and create a brand-new forest.

In this step, get ready to:
  • Install the AD DS role and management tools using PowerShell.
  • Promote the server to a Domain Controller for a new forest called corp.local.
  • Verify the domain is operational after the automatic reboot.
Install the AD DS role

Before a server can become a Domain Controller, you need to install the AD DS role. This adds the binaries and management tools you will use throughout the rest of the project.

  • Open PowerShell as Administrator by right-clicking the Start menu and selecting Windows PowerShell (Admin).
  • Install the AD DS role with management tools by running this command:
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

What does this command do?

  • `Install-WindowsFeature` adds a Windows Server role to the local machine.
  • `-Name AD-Domain-Services` specifies the Active Directory Domain Services role.
  • `-IncludeManagementTools` installs GUI tools like Active Directory Users and Computers (ADUC) and the Group Policy Management Console (GPMC) alongside the role.
  • Wait for the command to complete. You should see output showing Success with True and the feature name AD-Domain-Services listed as installed.

Do I need to reboot?

No reboot is required after installing the AD DS role. The reboot happens later, after you promote the server to a Domain Controller.

Seeing an error about features not being found?

  • Make sure you are running PowerShell as Administrator. Right-click the Start menu and choose the Admin option.
  • If you see a "requires a restart" message, reboot the VM first (a pending Windows Update may need to finish), then run the command again.

Help me troubleshoot the AD DS role installation

Promote the server to a Domain Controller

The role is installed, but the server still is not a Domain Controller. Promotion creates a new AD forest, installs DNS, and establishes your server as the authority for the corp.local domain.

This command will automatically reboot your server

After the promotion completes, your VM will reboot on its own. This is expected behaviour. Do not interrupt the reboot. The process takes a few minutes.

  • Promote the server to a Domain Controller by running this command:
Install-ADDSForest -DomainName "corp.local" -DomainNetBIOSName "CORP" -InstallDNS:$true -SafeModeAdministratorPassword (ConvertTo-SecureString "YourDSRMPassword123!" -AsPlainText -Force)

What does this command do?

  • `Install-ADDSForest` creates a brand-new Active Directory forest from scratch.
  • `-DomainName "corp.local"` sets the fully qualified domain name for your new forest.
  • `-DomainNetBIOSName "CORP"` sets the short (NetBIOS) name used for legacy compatibility.
  • `-InstallDNS:$true` installs the DNS Server role so the domain can resolve names internally.
  • `-SafeModeAdministratorPassword` sets the Directory Services Restore Mode (DSRM) password. This password is used to boot the DC in recovery mode if AD ever breaks.

What is the DSRM password?

DSRM stands for Directory Services Restore Mode. It is a special boot mode for Domain Controllers that lets you repair or restore Active Directory offline. The password you set here is the only way to access that mode. In a production environment you would store it securely. For this lab, the inline password is fine.

  • After you press Enter, the promotion process runs prerequisite checks and then begins configuring AD DS. This takes 2-5 minutes.
  • The VM will reboot automatically when finished. Wait for it to come back to the login screen.
  • Log in as CORP\Administrator using the same Administrator password you set during Windows Server installation.

Server not rebooting or stuck?

  • If the PowerShell window shows errors about prerequisite checks failing, make sure your DNS is set to 127.0.0.1 (configured in Step 1). AD DS requires the server to point to itself for DNS.
  • If the reboot seems stuck for more than 10 minutes, use VMware's reset button (VM menu > Power > Reset Guest) to force a restart.

Help me troubleshoot the domain promotion

Verify the domain is operational

Your server has rebooted and you are now logged in as CORP\Administrator. Before moving on, confirm that the domain is actually live.

  • Open PowerShell as Administrator again (right-click Start > Windows PowerShell (Admin)).
  • Verify this server is listed as a Domain Controller by running:
Get-ADDomainController -Filter *
  • You should see your server's hostname listed with its domain set to corp.local.

Now for the final check. Before you run the next command, what do you expect to see in the output? Think about what domain name and forest name should appear.

  • Confirm the domain details by running:
Get-ADDomain

You should see output showing DomainName as corp and Forest as corp.local. This confirms your domain is live and operational.

Get-ADDomain returns an error?

  • If you see a message about the server not being operational, the Active Directory Web Services may still be starting. Wait 30 seconds and try again.
  • Make sure you logged in as CORP\Administrator (not the local Administrator). After promotion, the domain account is required.

Help me troubleshoot Get-ADDomain errors

Your domain is live. You have a fully functional Domain Controller hosting the corp.local forest. Next up, you will design the Organizational Unit structure that organizes your domain into departments.

Design the Organizational Unit Structure

Your domain is live, but it's completely empty. Right now, any object you add would land in the default containers, which cannot be targeted by Group Policy or used for delegated administration.

Organizational Units solve this by giving you a structured hierarchy that mirrors your organization. In this step, you'll create a department-based OU structure using PowerShell. This structure enables Group Policy targeting and role-based access control in the steps that follow.

In this step, get ready to:
  • Explore the current empty domain in Active Directory Users and Computers.
  • Create department OUs with Users and Computers sub-OUs using PowerShell.
  • Create department security groups for role-based access control.
Explore the empty domain in ADUC

Active Directory Users and Computers (ADUC) is the GUI tool you'll use to view and manage domain objects. Before creating anything, take a look at the empty domain to understand what the default containers look like.

  • Open the Run dialog by pressing Win+R.
  • Type dsa.msc and press Enter to open ADUC.
  • In the left panel, expand corp.local.

You should see default containers like Computers, Users, and Builtin. These are flat containers with no hierarchy. You cannot link a GPO directly to them.

Why not use the default containers?

The default Users and Computers containers are not OUs. Group Policy can only be linked to OUs, domains, or sites. If all your accounts live in the default containers, you cannot apply different policies to different teams.

Creating dedicated OUs for each department lets you target Group Policy precisely. It also enables delegated administration, where you grant a team lead the ability to reset passwords only for their own department.

Create the OU structure with PowerShell

You could right-click and create each OU manually in ADUC, but that becomes tedious and error-prone at scale. PowerShell makes the creation repeatable and fast.

  • Switch back to your PowerShell window (still running as Administrator).
  • Create the four department OUs with Users and Computers sub-OUs by running this script:
# Define the four departments
$departments = @("IT","HR","Finance","Sales")

# Create each department OU with Users and Computers sub-OUs
foreach ($dept in $departments) {
    New-ADOrganizationalUnit -Name $dept -Path "DC=corp,DC=local"
    New-ADOrganizationalUnit -Name "Users" -Path "OU=$dept,DC=corp,DC=local"
    New-ADOrganizationalUnit -Name "Computers" -Path "OU=$dept,DC=corp,DC=local"
}

What does this script do?

  • $departments stores the four department names in an array, so you can loop through them.
  • The first New-ADOrganizationalUnit creates a top-level OU (like IT) directly under DC=corp,DC=local.
  • The next two calls create Users and Computers sub-OUs inside that department OU. This separates user accounts from machine accounts.
  • Switch back to the ADUC window.
  • Right-click corp.local in the left panel and click Refresh.

You should now see four new OUs listed: Finance, HR, IT, and Sales. Expand any one of them to confirm it contains a Users sub-OU and a Computers sub-OU.

Don't see the new OUs?

  • Make sure you right-clicked corp.local (the domain node) and selected Refresh. The view does not auto-update.
  • Check PowerShell for red error text. A typo in the -Path value (like a missing comma between DC=corp and DC=local) would cause the command to fail.
  • help me troubleshoot why my OUs did not appear in ADUC after running the PowerShell script
Create department security groups

Each department needs a security group that controls access. When you add a user to a group like IT-Users, that membership determines what resources they can reach.

  • Return to your PowerShell window and create a security group for each department by running this script:
# Create a Global Security group in each department's Users OU
foreach ($dept in $departments) {
    New-ADGroup -Name "$dept-Users" -GroupScope Global -GroupCategory Security -Path "OU=Users,OU=$dept,DC=corp,DC=local"
}

What does this script do?

  • It reuses the $departments variable that's still in memory from the previous command.
  • New-ADGroup creates a security group (not a distribution group). The -GroupScope Global setting means the group can contain members from the same domain and be used for permissions anywhere in the forest.
  • Each group is placed inside its department's Users sub-OU. This keeps the group logically close to the users it will contain.

Before you check the results, what do you expect to see inside each department's Users sub-OU? Think about it, then verify.

  • Switch back to ADUC.
  • Right-click corp.local and click Refresh.
  • Expand any department OU (for example, IT), then click the Users sub-OU.

You should see a security group named IT-Users in the right panel. Check the other departments as well. Each Users sub-OU should contain its matching group: HR-Users, Finance-Users, and Sales-Users.

Groups not appearing in the Users sub-OU?

  • Make sure you refreshed ADUC after running the script. ADUC does not update automatically.
  • If PowerShell printed an error about the variable $departments not being found, run the $departments = @("IT","HR","Finance","Sales") line again first, then re-run the group creation loop.
  • help me figure out why my security groups are not showing in the correct OU in ADUC

✔️ Awesome, I've got everything!

Great. Make sure your ADUC window shows all four department OUs, each with their sub-OUs and security groups.

ⓧ I'd like to double check the full code

Here is the complete script combining both the OU creation and group creation. Compare this with what you ran:

$departments = @("IT","HR","Finance","Sales")
foreach ($dept in $departments) {
    New-ADOrganizationalUnit -Name $dept -Path "DC=corp,DC=local"
    New-ADOrganizationalUnit -Name "Users" -Path "OU=$dept,DC=corp,DC=local"
    New-ADOrganizationalUnit -Name "Computers" -Path "OU=$dept,DC=corp,DC=local"
}

foreach ($dept in $departments) {
    New-ADGroup -Name "$dept-Users" -GroupScope Global -GroupCategory Security -Path "OU=Users,OU=$dept,DC=corp,DC=local"
}

Your domain now has a clean organizational structure with four departments, each containing dedicated sub-OUs and a security group. Next up, you'll populate these OUs with users and assign them to the groups that control their access.

Create Users and Assign Role-Based Access

Your OU structure is ready with empty departments waiting for people. Right now, those security groups you created have no members, which means no one can actually authenticate against your domain.

In this step, you'll create user accounts in each department and assign them to the matching security group. This implements Role-Based Access Control (RBAC): users inherit permissions through group membership, not through individual account settings.

In this step, get ready to:
  • Create user accounts in each department OU.
  • Add each user to their department security group.
  • Verify group memberships with PowerShell.
Create user accounts in each department

Every user account in Active Directory needs a few core attributes: a display name, a logon name (SamAccountName), a User Principal Name (UPN) for email-style sign-in, and a password. You'll also place each user directly into the correct department OU so they are organized from the start.

  • Create four test users, one per department, by running this in your PowerShell window:
# Store a shared password as a secure string
$password = ConvertTo-SecureString "P@ssw0rd2025!" -AsPlainText -Force

# Create one user in each department OU
New-ADUser -Name "Alice Johnson" -SamAccountName "ajohnson" -UserPrincipalName "ajohnson@corp.local" -Path "OU=Users,OU=IT,DC=corp,DC=local" -AccountPassword $password -Enabled $true
New-ADUser -Name "Bob Smith" -SamAccountName "bsmith" -UserPrincipalName "bsmith@corp.local" -Path "OU=Users,OU=HR,DC=corp,DC=local" -AccountPassword $password -Enabled $true
New-ADUser -Name "Carol Davis" -SamAccountName "cdavis" -UserPrincipalName "cdavis@corp.local" -Path "OU=Users,OU=Finance,DC=corp,DC=local" -AccountPassword $password -Enabled $true
New-ADUser -Name "Dan Wilson" -SamAccountName "dwilson" -UserPrincipalName "dwilson@corp.local" -Path "OU=Users,OU=Sales,DC=corp,DC=local" -AccountPassword $password -Enabled $true

What does this code do?

  • ConvertTo-SecureString converts a plain text password into an encrypted object that New-ADUser requires.
  • -Path places each user directly in the correct department's Users OU instead of the default container.
  • -Enabled $true activates the account immediately. Without this, the account would be created in a disabled state.
  • Confirm the users were created by running:
Get-ADUser -Filter * | Select-Object Name, SamAccountName, Enabled

You should see your four new users (ajohnson, bsmith, cdavis, dwilson) listed alongside the built-in Administrator, Guest, and krbtgt accounts. All four should show True in the Enabled column.

Seeing an error about the password not meeting requirements?

The password in the script includes uppercase, lowercase, a digit, and a special character. If you changed it to something simpler, the domain's default password policy may reject it. Use the password exactly as shown above.

Help me fix a New-ADUser password policy error.

Assign users to department security groups

Creating user accounts puts people in the right OUs, but OUs are only for organization and policy targeting. Access control happens through security group membership. Adding each user to their department group is what actually grants them the permissions that group holds.

  • Add each user to their department security group by running:
# Assign each user to their matching department group
Add-ADGroupMember -Identity "IT-Users" -Members "ajohnson"
Add-ADGroupMember -Identity "HR-Users" -Members "bsmith"
Add-ADGroupMember -Identity "Finance-Users" -Members "cdavis"
Add-ADGroupMember -Identity "Sales-Users" -Members "dwilson"

What does this code do?

Add-ADGroupMember links a user to a security group. The -Identity parameter is the group name, and -Members takes the user's SamAccountName. From now on, any permissions assigned to the group automatically apply to that user.

Why groups instead of individual permissions?

In an enterprise with hundreds of users, assigning permissions to each account individually is unmanageable. Security groups let you control access for an entire department in one place. When a new hire joins Finance, you add them to Finance-Users and they immediately inherit all the group's permissions.

Verify group memberships

Before you run this, what do you expect to see for each department group?

  • Run this verification script to check all group memberships at once:
# Verify each department group has the correct member
foreach ($dept in $departments) {
    Write-Host "`n$dept-Users members:" -ForegroundColor Cyan
    Get-ADGroupMember -Identity "$dept-Users" | Select-Object Name
}

If $departments is not defined

This script uses the $departments variable you created in the previous step. If you closed and reopened PowerShell since then, redefine it first:

$departments = @("IT","HR","Finance","Sales")

You should see each department group listing its member. IT-Users shows Alice Johnson, HR-Users shows Bob Smith, Finance-Users shows Carol Davis, and Sales-Users shows Dan Wilson.

  • Open Active Directory Users and Computers from Server Manager > Tools.
  • Expand corp.local, then expand any department OU (for example IT), and click the Users sub-OU.
  • Double-click a user (for example Alice Johnson) to open their properties.
  • Click the Member Of tab. You should see their department group (IT-Users) listed alongside Domain Users.

Group membership query returns nothing?

  • Check spelling in the Add-ADGroupMember commands. The group name must match exactly (e.g. IT-Users not IT-User).
  • Confirm the user SamAccountName matches. Run Get-ADUser -Filter * to see actual account names.

Help me troubleshoot empty group membership in Active Directory.

Your domain now has real users with proper group membership. The RBAC model is in place. Next up, you'll enforce security baselines with Group Policy to make sure those accounts actually follow enterprise password and lockout rules.

Enforce Security with Group Policy

Your domain has users, security groups, and a clean OU hierarchy. But right now, there is nothing stopping a user from setting a weak 7-character password or leaving their workstation unlocked all day.

Group Policy Objects (GPOs) solve this by centrally enforcing security rules across every machine and user in the domain. In this step, you will create a Security Baseline GPO that enforces password length, account lockout, and automatic screen lock.

In this step, get ready to:
  • Expose the current default password policy gap.
  • Create and configure a Security Baseline GPO with password and lockout policies.
  • Enforce a screen lock timeout and verify all policies are applied.
Expose the current password policy gap

Before you create any GPO, take a look at what the domain currently enforces. This is the gap you are about to close.

Before you run this, what do you think the current minimum password length and lockout threshold are on a freshly promoted domain?

  • Check the current domain password policy by running this command in PowerShell:
net accounts

You should see Minimum password length: 7 and Lockout threshold: Never in the output.

Why is this a problem?

A minimum length of 7 characters is too short for enterprise security. Modern password-cracking tools can brute-force 7-character passwords in hours.

A lockout threshold of Never means an attacker can try unlimited passwords against any account without triggering a lockout. There is also no machine inactivity timeout, so an unattended workstation stays unlocked indefinitely.

Create and configure the Security Baseline GPO

You will now create a Group Policy Object that raises the password minimum to 12 characters, locks accounts after 5 failed attempts, and forces a screen lock after 10 minutes of inactivity.

  • Open the Group Policy Management Console by running this command:
gpmc.msc
  • In the left pane, expand Forest: corp.local, then expand Domains, then expand corp.local.
  • Right-click corp.local and select Create a GPO in this domain, and Link it here....
  • Type Security Baseline as the name and click OK.
  • Right-click the new Security Baseline GPO under corp.local and select Edit.

The Group Policy Management Editor window opens. You will now configure three policy areas inside it.

  • In the left pane, navigate to Computer Configuration then Policies then Windows Settings then Security Settings then Account Policies then Password Policy.
  • Double-click Minimum password length, check Define this policy setting, set the value to 12 characters, and click OK.
  • Double-click Password must meet complexity requirements, check Define this policy setting, set to Enabled, and click OK.
  • Double-click Maximum password age, check Define this policy setting, set to 90 days, and click OK.

What does this configure?

These three settings ensure every domain user must use a password at least 12 characters long, meeting complexity requirements (mix of uppercase, lowercase, numbers, and symbols), and must change it every 90 days.

  • In the left pane, click Account Lockout Policy (directly below Password Policy).
  • Double-click Account lockout threshold, check Define this policy setting, set to 5 invalid logon attempts, and click OK.
  • Windows will suggest values for the lockout duration and reset counter. Accept the suggested values of 30 minutes for both and click OK.

What does account lockout do?

After 5 failed password attempts, the account locks for 30 minutes. This blocks brute-force attacks where an attacker tries thousands of passwords against a single account.

Configure screen lock and verify the policies
  • Still in the Group Policy Management Editor, navigate to Computer Configuration then Policies then Windows Settings then Security Settings then Local Policies then Security Options.
  • Scroll down and double-click Interactive logon: Machine inactivity limit.
  • Check Define this policy setting, set the value to 600 seconds, and click OK.
  • Close the Group Policy Management Editor window.

Why 600 seconds?

600 seconds equals 10 minutes. If a user walks away from their workstation without locking it, Windows will automatically lock the screen after 10 minutes of inactivity. This prevents unauthorized access to an unattended machine.

  • Force the domain to apply the new policy immediately by running this command:
gpupdate /force

You should see messages confirming that both Computer Policy and User Policy updates completed successfully.

Now, do you think your Security Baseline GPO will appear in the applied policies list? What about the password length value?

  • Verify the GPO is applied by running:
gpresult /r

Under Applied Group Policy Objects, you should see Security Baseline listed. This confirms the GPO is active on your Domain Controller.

  • Confirm the password and lockout values have changed by running:
net accounts

This time you should see Minimum password length: 12 and Lockout threshold: 5 in the output. Compare that to the defaults you saw at the start of this step.

Still seeing the old values?

Make sure you linked the GPO to corp.local (the domain), not to an individual OU. Password policy in AD only takes effect when applied at the domain level.

Also verify you checked Define this policy setting in each policy dialog. Without that checkbox, the value is not enforced.

Try running gpupdate /force again and then re-check with net accounts.

Still stuck? Help me troubleshoot why my Security Baseline GPO is not applying.

Your domain now enforces enterprise-grade security baselines across every machine. Next up, you will use PowerShell to practice the helpdesk operations that keep a domain running day to day.

Practice Helpdesk Operations and Audit

Building a domain proves you can stand up infrastructure. Sysadmin interviews, however, test whether you can operate it day-to-day.

Password resets, account unlocks, and onboarding/offboarding are the top helpdesk ticket types in any enterprise. In this step, you will run those operations in PowerShell and then audit your domain to prove the configuration is correct.

In this step, get ready to:
  • Practice password resets, account unlocks, and offboarding via PowerShell.
  • Run audit queries that verify domain health and compliance.
  • Re-enable an offboarded user to simulate a rehire.
Reset a user's password and force change at next logon

The most common helpdesk ticket is a locked or forgotten password. The standard procedure is to reset the password to a temporary value and then force the user to set their own on next sign-in.

  • In your PowerShell window (still running as Administrator), reset ajohnson's password by running this command:
Set-ADAccountPassword -Identity "ajohnson" -Reset -NewPassword (ConvertTo-SecureString "NewP@ss2025!" -AsPlainText -Force)

If the command succeeds, PowerShell returns to the prompt with no output. No error means the password was reset.

  • Now force the user to change this temporary password at next logon by running:
Set-ADUser -Identity "ajohnson" -ChangePasswordAtLogon $true

What do these commands do?

Set-ADAccountPassword with -Reset clears the old password and sets a new one directly. The ConvertTo-SecureString wrapper is required because AD will not accept a plaintext password.

Set-ADUser -ChangePasswordAtLogon $true flips a flag on the account so the temporary password only works once. The user is forced to create their own password the moment they sign in.

Seeing a 'password does not meet complexity' error?

Your Security Baseline GPO requires 12 characters and complexity (uppercase, lowercase, number, special character). Make sure the password you pass to ConvertTo-SecureString meets all four requirements.

Help me troubleshoot a password complexity error in Active Directory.

Unlock an account and disable a user for offboarding

Account lockouts happen when a user exceeds the failed-attempt threshold (5 attempts, per your GPO). Offboarding means disabling the account so the departing employee can no longer authenticate.

  • Unlock ajohnson's account by running:
Unlock-ADAccount -Identity "ajohnson"

Again, no output means success. The account is unlocked even if it was not locked. The command is safe to run either way.

  • Now simulate offboarding Dan Wilson by disabling his account:
Disable-ADAccount -Identity "dwilson"
  • Verify that dwilson is now disabled by running:
Get-ADUser -Identity "dwilson" | Select-Object Name, Enabled

You should see output showing Name: Dan Wilson and Enabled: False. Dan can no longer log in to any domain-joined machine.

Why disable instead of delete?

Disabling preserves the account's SID, group memberships, and audit trail. If legal or compliance needs to review the departing employee's access history, the account is still there. Deletion is permanent and loses that information.

Run audit queries to verify domain health

Audit queries let you prove your domain is configured correctly and spot stale or risky accounts. These are the kinds of checks a security review would expect you to run regularly.

  • Run these three audit queries to inspect your domain:
# Find all disabled accounts
Get-ADUser -Filter {Enabled -eq $false} | Select-Object Name, SamAccountName

# Find users who have never logged in
Get-ADUser -Filter * -Properties LastLogonDate | Where-Object {$_.LastLogonDate -eq $null} | Select-Object Name

# List all OUs in the domain
Get-ADOrganizationalUnit -Filter * | Select-Object Name, DistinguishedName

What should I see?

The first query should return dwilson (you just disabled him) and possibly the built-in Guest account.

The second query lists all users with no LastLogonDate. Since these are fresh lab accounts that have never interactively signed in, all your users will appear here.

The third query lists every OU in corp.local. You should see your four department OUs plus their Users and Computers sub-OUs.

Seeing more disabled accounts than expected?

The built-in Guest account is disabled by default in Windows Server. If you see it alongside dwilson, that is normal.

Help me understand unexpected disabled accounts in my AD audit query results.

Re-enable a user to simulate a rehire

When a former employee returns, you re-enable their account rather than creating a new one. This preserves their original SID and group memberships.

  • Re-enable dwilson by running:
Enable-ADAccount -Identity "dwilson"
Get-ADUser -Identity "dwilson" | Select-Object Name, Enabled

You should see Enabled: True. Dan is back in action with all his original group memberships intact.

Before you run the final count, what number do you expect to see? Think about how many users you created plus the default accounts that ship with Windows Server.

  • Count the total user objects in your domain by running:
Get-ADUser -Filter * | Measure-Object

You should see your four created users (ajohnson, bsmith, cdavis, dwilson) plus the default Administrator, Guest, and krbtgt accounts. The exact count depends on your environment, but expect at least 7 objects.

  • Run the disabled accounts query one more time to confirm all your users are enabled:
Get-ADUser -Filter {Enabled -eq $false} | Select-Object Name, SamAccountName

Only the default disabled accounts (Guest, krbtgt) should appear. None of your four project users should be listed.

Still seeing dwilson as disabled?

Make sure you ran Enable-ADAccount -Identity "dwilson" and that it returned without error. Run Get-ADUser -Identity "dwilson" | Select-Object Enabled to double check.

Help me figure out why my AD account isn't re-enabling.

You have just demonstrated the full identity lifecycle: creating users, assigning access, enforcing policy, and now operating the domain day-to-day. This is the complete sysadmin toolkit for Active Directory. Ready to take it further with automation?

Secret mission

Automate Bulk User Provisioning from CSV

Creating users one by one works for a handful of accounts, but real enterprises onboard dozens at once. In this secret mission, you will write a PowerShell script that reads a CSV file, creates user accounts in the correct OUs, assigns them to security groups, and handles errors gracefully.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally in a VMware VM, so there are no ongoing cloud costs. The Windows Server 2025 evaluation license is valid for 180 days.

Resources you used:

  • Windows Server 2025 VM in VMware Workstation (contains the Domain Controller, AD domain, all OUs, users, groups, and GPO).
  • Desktop files inside the VM: new_users.csv and bulk_provision.ps1.

Keep everything running

No action needed. Choose this if you are still actively building on your Active Directory lab or plan to continue practicing helpdesk operations.

  • Your VM continues running and the 180-day evaluation period keeps counting down.
  • The VM uses approximately 4GB of your host RAM while powered on.
  • VMware Workstation Pro remains installed on your host machine.

Pause - I'll come back to this later

Shut down or suspend the VM to free up host RAM and CPU. Your domain, users, groups, and GPO configuration are all preserved on the virtual disk.

  • In VMware Workstation, right-click your Windows Server 2025 VM and select Suspend to save its current state. You can also select Shut Down Guest for a clean shutdown.
  • When you are ready to return, select the VM and click Power On. Log in as CORP\Administrator and everything will be exactly where you left it.

Delete - I don't want to use this again

Remove the VM and all associated files from your machine. This frees up the 50GB virtual disk space and removes the entire Active Directory domain permanently.

  • In VMware Workstation, right-click your Windows Server 2025 VM in the library panel.
  • Select Manage, then Delete from Disk.
  • Confirm when prompted. This deletes the VM configuration and all virtual disk files, removing the Domain Controller, AD domain, OUs, users, groups, GPO, and Desktop files (new_users.csv and bulk_provision.ps1) entirely.
  • Verify the disk space is reclaimed by checking the folder where VMware stored the VM files. It should no longer exist.

Nice Work!

Nice Work!

You just built a production-style Active Directory domain from scratch on Windows Server 2025. You can now open ADUC, navigate a clean OU hierarchy you designed, show the security groups that control access, and demonstrate the GPOs enforcing your security baseline.

You've learned how to:

  • Promoted a Windows Server 2025 instance to a Domain Controller and designed a department-based OU structure with RBAC security groups controlling access.
  • Enforced enterprise security baselines through Group Policy, including password complexity, account lockout, and screen lock timeout across the entire domain.
  • Practiced the most common helpdesk operations (password resets, account unlocks, onboarding/offboarding) and ran PowerShell audit queries to verify domain health.
  • Secret Mission: Automated bulk user provisioning from a CSV file using PowerShell with error handling and summary reporting.

Ready to quiz yourself?