Build an Active Directory Domain

Deploy a Windows Server domain with OUs, GPOs, and security monitoring.

Introduction

30 Second Summary

Every company with more than a handful of computers needs a way to manage who can log in, what they can access, and what security rules apply to them. Active Directory is the system that handles all of this in Windows environments, and it runs in nearly every enterprise on the planet.

In this project, you will promote a Windows Server to a Domain Controller, build an organizational structure with departments and users, enforce different security and audit policies per group, then monitor your domain's health using Performance Monitor and Event Viewer.

What You'll Build

By the end, you can log into a Windows client with domain credentials, watch different audit policies kick in depending on which department the user belongs to, and trace every logon event in real time on your Domain Controller.

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

  • A working Active Directory domain where you can log into a Windows client with domain credentials and see Group Policies applied automatically.
  • Differentiated audit policies per department. IT gets full logon auditing, HR gets basic account management auditing only.
  • Real-time monitoring using Performance Monitor to observe DC health counters and Event Viewer to trace security events (Event IDs 4624 and 4625) generated by domain logons.
  • Secret Mission: automate bulk user creation with a PowerShell script that reads from a CSV and creates 20+ users across multiple departments in seconds.

Are there any prerequisites?

You need a Windows Server 2025 Datacenter VM already running and a Windows 10/11 client VM available. Basic familiarity with the Windows Server interface (clicking around Server Manager, opening PowerShell) is helpful but not required.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters.

Active Directory is the identity backbone of nearly every enterprise Windows environment. The skills you build here, promoting a Domain Controller, structuring OUs, enforcing Group Policies, and reading Event Viewer logs, are the daily tools of a Windows sysadmin.

Install AD DS and Promote to Domain Controller

Right now, your Windows Server is just a standalone machine. Every user account lives locally, and every computer manages itself.

By promoting this server to a Domain Controller, you get centralized control over authentication, authorization, and policy for every machine that joins your domain. In this step, you will configure a static IP, install the Active Directory Domain Services role, and create a brand-new forest called corp.local.

In this step, get ready to:
  • Configure a static IP address and point DNS to the server itself.
  • Install the AD DS role and Group Policy Management Console via PowerShell.
  • Promote the server to a Domain Controller for a new forest.
Configure a static IP address

A Domain Controller must have a predictable IP address. If the address changes, every domain-joined machine loses contact with it. You also need to point DNS to 127.0.0.1 because the server will become its own DNS resolver once AD is installed.

GUI

  • Press the Windows key, type Control Panel, and press Enter.
  • Click Network and Sharing Center.
  • Click Change adapter settings in the left sidebar.
  • Right-click your active network adapter and select Properties.
  • Double-click Internet Protocol Version 4 (TCP/IPv4).
  • Select Use the following IP address.
  • In the IP address field, enter a static IP in your VM's subnet (for example, 192.168.1.10).
  • In the Subnet mask field, enter 255.255.255.0.
  • In the Default gateway field, enter your gateway IP (for example, 192.168.1.1).
  • Select Use the following DNS server addresses.
  • In the Preferred DNS server field, enter 127.0.0.1.
  • Click OK to close the IPv4 properties, then OK again to close the adapter properties.

Verify the change by opening a Command Prompt and running ipconfig /all. You should see your static IP address and 127.0.0.1 listed as the DNS server.

PowerShell

  • Open PowerShell as Administrator on your Windows Server VM.
  • View your current network configuration by running this command:
Get-NetIPConfiguration

You will see output showing your interface alias (often Ethernet or Ethernet0), your current IP address, default gateway, and DNS servers. Note the InterfaceIndex number for your primary adapter.

  • Set a static IP address by running this command, replacing the placeholder values with your VM's network details:
New-NetIPAddress -InterfaceIndex [[INTERFACE_INDEX="your InterfaceIndex number from above"]] -IPAddress [[STATIC_IP="a static IP in your VM's subnet e.g. 192.168.1.10"]] -PrefixLength 24 -DefaultGateway [[GATEWAY_IP="your default gateway IP e.g. 192.168.1.1"]]

What does this command do?

The New-NetIPAddress cmdlet assigns a static IPv4 address to your network interface. Once you set a static IP, DHCP is automatically disabled for that interface.

The -PrefixLength 24 is the subnet mask (equivalent to 255.255.255.0). The -DefaultGateway must be in the same subnet as your new IP.

  • Set the DNS server to the loopback address by running:
Set-DnsClientServerAddress -InterfaceIndex [[INTERFACE_INDEX="your InterfaceIndex number from above"]] -ServerAddresses 127.0.0.1
  • Verify your new configuration by running:
Get-NetIPConfiguration

You should see your static IP address and 127.0.0.1 listed as the DNS server.

Why point DNS to 127.0.0.1?

When you promote this server to a Domain Controller, it installs a DNS server automatically. Setting DNS to 127.0.0.1 tells the server to resolve names using itself. This is required for AD to function properly.

🙋‍♀️ Static IP not taking effect?

If you used the GUI and the adapter still shows DHCP, close and reopen the IPv4 properties to confirm the settings saved. If you used PowerShell and see an error about an existing IP, run Remove-NetIPAddress with the old IP first, then retry.

Confirm the change took effect with ipconfig /all in a Command Prompt.

Help me troubleshoot this

Install the AD DS role and GPMC

With a stable IP in place, you can install the software that turns this server into a Domain Controller. You will install two features: Active Directory Domain Services (the core identity service) and the Group Policy Management Console (used to create and manage policies later).

GUI

  • Open Server Manager (it launches automatically at logon).
  • Click Manage in the top menu bar.
  • Click Add Roles and Features.
  • Click Next on the Before you begin page.
  • Select Role-based or feature-based installation and click Next.
  • Confirm your server is selected and click Next.
  • Check the box next to Active Directory Domain Services.
  • In the popup, click Add Features to include the management tools.
  • Click Next through the Features page.
  • On the Features page, also check Group Policy Management, then click Next.
  • Click Next on the AD DS information page.
  • Click Install.

Wait for the installation to complete. You should see a success message with a link to Promote this server to a domain controller. Do not click it yet.

PowerShell

  • Open PowerShell as Administrator.
  • Install the AD DS role with its management tools by running:
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

This takes a minute or two. You should see a progress bar, followed by output showing Success as the Exit Code and True under the Success column.

What does -IncludeManagementTools do?

Without this flag, PowerShell installs only the role binaries. The -IncludeManagementTools parameter also installs the RSAT tools (Active Directory Users and Computers, DNS Manager) so you can manage the domain from this server.

  • Install the Group Policy Management Console by running:
Install-WindowsFeature -Name GPMC

You should see another Success result. Both features are now installed but Active Directory is not yet running.

Installation failing or command not recognized?

If using PowerShell, make sure you are running it as Administrator. The Install-WindowsFeature cmdlet is only available in an elevated session on Windows Server.

If using the GUI and the role is greyed out, confirm you selected Role-based or feature-based installation and that your server is selected in the server pool.

Help me fix this

Promote the server to a Domain Controller

Installing the role added the software, but your server is still not a Domain Controller. Promotion creates the Active Directory database, sets up DNS, and establishes the domain that other machines can join.

Remember your DSRM password

Write this password down somewhere safe. You will need it if you ever have to boot into Directory Services Restore Mode to recover Active Directory.

  • After the reboot, log in with CORP\Administrator and the same password you used for the local Administrator account before promotion.

Before you check the result, what do you expect to see in Server Manager now that the server is a Domain Controller?

  • Open Server Manager (it should launch automatically at logon).
  • Look at the left navigation pane. Confirm that AD DS and DNS both appear with green status indicators.

Both roles showing green means your Domain Controller is healthy and serving DNS for the corp.local zone.

Don't see AD DS or DNS in Server Manager?

If Server Manager only shows the old roles, close it and reopen it. Server Manager sometimes needs a refresh after a reboot. If the roles still do not appear, the promotion may not have completed. Check Event Viewer under Windows Logs > System for errors related to the directory service.

Help me troubleshoot this

Your server is now a fully functional Domain Controller with its own DNS zone. Next up, you will build the organizational structure with departments, security groups, and user accounts that bring this domain to life.

Build the Organizational Structure and Users

Your Domain Controller is live, but right now it is an empty directory. Without users or structure, there is nothing for it to actually control.

Organizational Units let you group users by department so you can apply different policies to each group later. In this step, you will build a company structure with three departments, create test users, and join a Windows client to the domain.

In this step, get ready to:
  • Create Organizational Units and security groups for IT, HR, and Sales departments.
  • Add test users to the IT and HR departments.
  • Join a Windows client to the domain and verify authentication.
Create Organizational Units for the company

A flat Active Directory is no better than a spreadsheet of usernames. Organizational Units (OUs) create a hierarchy that mirrors your real company structure. Without them, you cannot enforce that IT staff get different security settings than HR staff.

  • Open PowerShell as Administrator on your Domain Controller by pressing the Windows key, typing PowerShell, right-clicking Windows PowerShell, and selecting Run as administrator.
  • Create three Organizational Units for your company departments by running these commands:
# Create an OU for each department
New-ADOrganizationalUnit -Name "IT" -Path "DC=corp,DC=local"
New-ADOrganizationalUnit -Name "HR" -Path "DC=corp,DC=local"
New-ADOrganizationalUnit -Name "Sales" -Path "DC=corp,DC=local"

What do these commands do?

Each New-ADOrganizationalUnit command creates a container inside your domain. The -Name parameter sets the OU's display name. The -Path parameter places each OU at the root of your corp.local domain.

Think of OUs like folders on your computer. You will place users inside them and apply policies to the folder level, affecting everyone inside.

  • Verify the OUs were created by running:
Get-ADOrganizationalUnit -Filter 'Name -ne "Domain Controllers"' | Select Name

You should see three entries listed: IT, HR, and Sales.

Not seeing all three OUs?

  • Check for typos in the -Path parameter. It must be exactly DC=corp,DC=local with no spaces after the comma.
  • If you see an error about an object already existing, the OU was already created. Run the verify command again to confirm.
  • help me troubleshoot OU creation errors in Active Directory
Create security groups for each department

Security Groups control access to resources. By placing a security group inside each OU, you can assign permissions to an entire department at once instead of managing users individually.

  • Create a Global Security group inside each OU by running these commands:
# Create a security group in each department OU
New-ADGroup -Name "IT-Staff" -GroupScope Global -GroupCategory Security -Path "OU=IT,DC=corp,DC=local"
New-ADGroup -Name "HR-Staff" -GroupScope Global -GroupCategory Security -Path "OU=HR,DC=corp,DC=local"
New-ADGroup -Name "Sales-Staff" -GroupScope Global -GroupCategory Security -Path "OU=Sales,DC=corp,DC=local"

What do these parameters mean?

  • -GroupScope Global means the group can contain members from this domain and be used for permissions anywhere in the forest.
  • -GroupCategory Security means the group can be assigned permissions on resources (as opposed to a Distribution group used only for email).
  • -Path places each group inside its matching department OU.
  • Verify the groups exist by running:
Get-ADGroup -Filter 'GroupScope -eq "Global"' -SearchBase "DC=corp,DC=local" | Select Name

You should see IT-Staff, HR-Staff, and Sales-Staff listed alongside any default groups.

Groups not appearing?

  • Confirm the OU path in -Path matches exactly what you created above (e.g. OU=IT,DC=corp,DC=local). A mismatch means the group was created somewhere else in the directory.
  • help me troubleshoot security group creation in Active Directory
Create test users in each department

Now you will populate the OUs with real user accounts. Each user gets a username (SamAccountName), a User Principal Name for logging in, and membership in their department's security group.

  • Create two test users and add them to their respective groups by running these commands:
# Create Alex Chen in the IT department
New-ADUser -Name "Alex Chen" -SamAccountName achen -UserPrincipalName achen@corp.local -Path "OU=IT,DC=corp,DC=local" -AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) -Enabled $true

# Add Alex Chen to the IT-Staff security group
Add-ADGroupMember -Identity "IT-Staff" -Members achen

# Create Jamie Lee in the HR department
New-ADUser -Name "Jamie Lee" -SamAccountName jlee -UserPrincipalName jlee@corp.local -Path "OU=HR,DC=corp,DC=local" -Department "Human Resources" -AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) -Enabled $true

# Add Jamie Lee to the HR-Staff security group
Add-ADGroupMember -Identity "HR-Staff" -Members jlee

What is happening with each user?

  • -SamAccountName is the short login name (e.g. achen). This is what appears after CORP\ when the user logs in.
  • -UserPrincipalName is the email-style login (e.g. achen@corp.local).
  • -AccountPassword sets the initial password. ConvertTo-SecureString converts the plain text into the encrypted format AD requires.
  • -Enabled $true activates the account immediately so the user can log in.
  • Add-ADGroupMember links each user to their department's security group for access control.
  • Confirm both users exist by running:
Get-ADUser -Filter * -SearchBase "DC=corp,DC=local" | Select Name,SamAccountName

You should see Alex Chen (achen) and Jamie Lee (jlee) in the output alongside the built-in Administrator account.

Users not showing up?

  • If you see a password complexity error, confirm the password P@ssw0rd123 includes uppercase, lowercase, a number, and a special character.
  • If the user was created but is not in the expected OU, check the -Path value for typos. Correct it with Move-ADObject.
  • help me fix user creation errors in Active Directory PowerShell
Join the Windows client VM to the domain

Your domain has users, but nobody can log in from another machine yet. The Windows client must join the domain before it trusts your Domain Controller for authentication.

First, the client needs to know where to find your DC by pointing its DNS settings to the DC's IP address.

  • Switch to your Windows 10/11 client VM.
  • Press the Windows key, type Control Panel, and press Enter to open it.
  • Click Network and Sharing Center.
  • Click Change adapter settings in the left sidebar.
  • Right-click your active network adapter and select Properties.
  • Double-click Internet Protocol Version 4 (TCP/IPv4).
  • Select Use the following DNS server addresses.
  • In the Preferred DNS server field, enter your Domain Controller's IP address.

Find your DC's IP address

If you do not remember the static IP you set on your Domain Controller in Step 1, switch back to the DC and run ipconfig in PowerShell. The IPv4 Address shown on the Ethernet adapter is what you enter on the client.

  • Click OK to close the IPv4 properties, then OK again to close the adapter properties.

Now join the client to your domain.

  • Press the Windows key, type sysdm.cpl, and press Enter to open System Properties.
  • Click the Computer Name tab.
  • Click Change.
  • Under Member of, select Domain.
  • Type corp.local in the domain field.
  • Click OK.
  • When prompted for credentials, enter CORP\Administrator and the password you set during domain promotion.
  • Click OK on the welcome message.
  • Restart the client VM when prompted.

What is the domain join doing?

When a computer joins a domain, it creates a trust relationship with the Domain Controller. From this point on, the client checks with the DC to validate every login attempt. This is how centralized authentication works in every enterprise Windows environment.

After the restart, verify that domain authentication works.

  • On the client login screen, click Other user.
  • Log in with username CORP\achen and password P@ssw0rd123.

Before you run the next command, what do you think whoami will return now that you are logged in with a domain account?

  • Open PowerShell on the client by pressing the Windows key, typing PowerShell, and pressing Enter.
  • Run this command to confirm your domain identity:
whoami

The output reads corp\achen. This confirms the client authenticated against your Domain Controller and you are logged in as a domain user.

Domain join failed or whoami shows a local account?

  • If the domain join failed with a DNS error, confirm the client's Preferred DNS server is set to your DC's exact IP address. The client must resolve corp.local through your DC's DNS service.
  • If you see a timeout error, confirm both VMs are on the same virtual network and can ping each other.
  • If whoami shows a local account name instead of corp\achen, you may have logged in with local credentials. Sign out and select Other user on the login screen to enter domain credentials.
  • help me troubleshoot my Windows client domain join failure

Your domain now has a real organizational structure with departments, security groups, and users who can authenticate from a separate machine. Next up, you will enforce different security and audit policies per department using Group Policy.

Create Differentiated Group Policies per Department

Your domain has users and OUs, but every account is treated identically. There are no password requirements beyond the default, and no audit trail recording who logs in or fails to log in.

In a real company, the IT department needs stricter security because they have privileged access. HR might only need basic account-management auditing. Group Policy Objects let you attach different security and audit rules to each OU, so the right controls land on the right people automatically.

In this step, get ready to:
  • Create the IT Security Policy GPO with strict password rules and full logon auditing.
  • Create the HR Audit Policy GPO with account management auditing only.
  • Verify policies apply on the client and the Domain Controller.
Create and configure the IT Security Policy

The IT OU holds your most privileged accounts. You will create a GPO that enforces a 12-character minimum password and logs every logon attempt (success and failure) so suspicious activity is visible immediately.

  • On your Domain Controller, open Server Manager.
  • Click Tools in the top menu bar.
  • Click Group Policy Management.
  • In the left pane, expand Forest: corp.local, then Domains, then corp.local.
  • Right-click the IT OU.
  • Select Create a GPO in this domain, and Link it here.
  • In the Name field, type IT Security Policy and click OK.

You should see IT Security Policy appear beneath the IT OU in the left pane, confirming it is linked.

Now configure the password policy settings inside this GPO.

  • Right-click IT Security Policy under the IT OU and select Edit.
  • In the Group Policy Management Editor, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > 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, select Enabled, and click OK.

What do these password settings do?

Minimum password length of 12 means IT accounts cannot use short, easily guessed passwords. Complexity requirements force a mix of uppercase, lowercase, numbers, and symbols.

Together these settings make brute-force attacks significantly harder against your most privileged accounts.

Next, configure audit logging so every logon attempt is recorded.

  • In the same editor, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff.
  • Double-click Audit Logon.
  • Check Configure the following audit events.
  • Check both Success and Failure, then click OK.
  • Close the Group Policy Management Editor window.

Why audit both success and failure?

Logging failures reveals brute-force attempts and locked-out accounts. Logging successes creates a paper trail of who accessed what and when.

For IT staff with admin privileges, you want both sides visible so you can detect unauthorized access and verify legitimate logons.

Create the HR Audit Policy

HR staff do not need the same strict password rules as IT. They only need auditing on account management actions (creating, modifying, or deleting user accounts) so you can track HR-initiated changes.

  • Back in the Group Policy Management console, right-click the HR OU.
  • Select Create a GPO in this domain, and Link it here.
  • Type HR Audit Policy as the name and click OK.
  • Right-click HR Audit Policy under the HR OU and select Edit.
  • Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Management.
  • Double-click Audit User Account Management.
  • Check Configure the following audit events.
  • Check Success only (leave Failure unchecked), then click OK.
  • Close the Group Policy Management Editor window.

In the Group Policy Management console you should now see HR Audit Policy linked beneath the HR OU, alongside the IT Security Policy under the IT OU.

Why different audit levels per department?

IT staff have privileged access to servers and user accounts. Full logon auditing catches unauthorized access attempts in real time.

HR staff mainly create and modify employee accounts. Account management auditing tracks those changes without flooding the security log with irrelevant logon events.

Verify policies are applied on the client and DC

Creating and linking a GPO is only half the job. You need to confirm the policies actually reached the machines they target.

  • Switch to your Windows client VM (logged in as CORP\achen).
  • Open a Command Prompt as Administrator.
  • Force a policy refresh by running:
gpupdate /force

Wait for the message confirming both Computer Policy and User Policy updates completed successfully.

Before you run the next command, predict: will you see IT Security Policy listed under Applied Group Policy Objects?

  • Check which GPOs are applied by running:
gpresult /r

Scroll through the output and look for the Applied Group Policy Objects section. You should see IT Security Policy listed there.

What does gpresult /r show?

This command displays the Resultant Set of Policy for the current user and computer. The Applied Group Policy Objects section lists every GPO that successfully applied to this session.

If a GPO does not appear here, it means the user or computer object is not in the OU where the GPO is linked, or the policy has not yet replicated.

  • Switch back to your Domain Controller.
  • Open PowerShell and verify the audit policy is active by running:
auditpol /get /category:"Logon/Logoff"

In the output, find the Logon row. It should show Success and Failure, confirming the IT Security Policy's audit settings are in effect on the DC.

IT Security Policy not appearing in gpresult?

Make sure you ran gpupdate /force before running gpresult /r. Policies do not apply instantly without a forced refresh.

Confirm that the user account achen is in the IT OU. Run Get-ADUser achen | Select DistinguishedName on the DC to check.

If the Logon row shows No Auditing, reopen the IT Security Policy in the Group Policy Management Editor and confirm both Success and Failure checkboxes are selected under Audit Logon.

Still stuck? Help me troubleshoot why my GPO is not applying to the client.

Your domain now enforces different security rules per department. IT accounts have a 12-character password minimum and full logon auditing. HR accounts have account management auditing only. Next up, you will use Performance Monitor and Event Viewer to observe the domain controller in action and trace the security events these policies generate.

Monitor Performance and Analyze Security Events

Your domain is running with differentiated audit policies per department. But how do you know the domain controller is actually healthy?

In production, sysadmins must monitor DC performance (CPU load, LDAP latency, authentication throughput) and read Event Viewer to detect failed logons, account lockouts, and policy changes. Without monitoring, problems go unnoticed until users start complaining. This step teaches you the tools you will use every day on the job.

In this step, get ready to:
  • Add real-time performance counters to Performance Monitor and observe authentication traffic.
  • Trace successful and failed logon events in Event Viewer using Event IDs.
  • Create a reusable Custom View that filters all authentication activity into one dashboard.
Add performance counters to Performance Monitor

Performance Monitor (perfmon.exe) is the built-in Windows tool for tracking real-time system health. You will add counters specific to Active Directory so you can see exactly how hard the DC is working when users authenticate.

  • On the Domain Controller, open Performance Monitor by running this command:
perfmon.exe
  • In the Performance Monitor window, click the green plus icon (+) in the toolbar to open the Add Counters dialog.
  • In the Available counters list, expand Processor Information.
  • Select _Total under Instances of selected object.
  • Select % Processor Utilization from the counter list and click Add >>.
  • Back in Available counters, expand NTDS.
  • Select LDAP Searches/sec and click Add >>.
  • Expand DC Locator (DC).
  • Select Requests: Successes/sec and click Add >>.
  • Click OK to close the dialog.

The real-time graph now shows three lines representing CPU utilization, LDAP query rate, and DC locator success rate.

What do these counters tell you?

Processor Information(_Total) > % Processor Utilization shows overall CPU load on the DC. Microsoft recommends keeping this under 60% for healthy headroom.

NTDS > LDAP Searches/sec tracks how many directory queries the DC handles per second. Every logon, group policy lookup, and DNS query generates LDAP traffic.

DC Locator (DC) > Requests: Successes/sec is a counter new in Windows Server 2025 that tracks how often clients successfully locate this domain controller.

  • Switch to your Windows client VM.
  • Log in as CORP\achen (password: P@ssw0rd123).
  • Switch back to the DC and watch the Performance Monitor graph.

You should see a visible spike in LDAP Searches/sec at the moment achen authenticated. That spike is the DC processing the Kerberos ticket request, group membership lookup, and GPO retrieval.

Not seeing a spike in the graph?

Make sure you added the NTDS counter (not a similarly named counter from a different category). Expand NTDS specifically in the Available counters list.

If the lines are flat, try signing out of the client and signing back in as CORP\achen to generate fresh authentication traffic.

help me troubleshoot why Performance Monitor is not showing LDAP activity on my Domain Controller

Trace logon events in Event Viewer

Performance Monitor shows you throughput. Event Viewer shows you the details of every individual security event. Together they give you the full picture of what is happening on your DC.

  • On the DC, open Event Viewer by running this command:
eventvwr.msc
  • In the left pane, expand Windows Logs.
  • Click Security.
  • In the right pane under Actions, click Filter Current Log....
  • In the Event IDs field, type 4624 and click OK.

The log now shows only Event ID 4624 entries (successful logons). Find the entry for achen's logon.

  • Double-click the 4624 event that shows achen in the description.
  • Note three key fields in the event details: Account Name (achen), Logon Type (a number indicating how the user logged in), and Source Network Address (the client's IP).

What do the Logon Type numbers mean?

Logon Type 2 means interactive (at the keyboard). Logon Type 3 means network (accessing a share). Logon Type 10 means Remote Desktop. For your client logon, you should see Type 3 for the network authentication to the DC.

Now generate a failed logon event so you can see how Event Viewer captures authentication failures.

  • Switch to your Windows client VM.
  • Sign out of achen's session.
  • On the Windows login screen, select Other user.
  • Type CORP\jlee as the username.
  • Type a deliberately wrong password (for example, WrongPass) and press Enter.
  • You will see a message that the username or password is incorrect. This is expected.
  • Switch back to the DC and return to Event Viewer.
  • Clear the current filter by clicking Clear Filter in the right pane under Actions.
  • Click Filter Current Log... again.
  • Type 4625 in the Event IDs field and click OK.
  • Find the 4625 event showing jlee's account name in the description.

This confirms the DC recorded jlee's failed authentication attempt. In a production environment, a flood of 4625 events for one account signals a brute-force attack or a user locked out of their account.

Not seeing Event ID 4625 for jlee?

The audit policy for Logon/Logoff must be set to capture both Success and Failure events. Verify by running this on the DC:

auditpol /get /category:"Logon/Logoff"

You should see Logon set to Success and Failure. If it shows only Success, the IT Security Policy GPO may not have applied to the DC. Run gpupdate /force on the DC and try the failed logon again.

help me figure out why failed logon events are not appearing in Event Viewer on my Domain Controller

Create a Custom View for authentication monitoring

Filtering the Security log manually every time is slow. A Custom View saves your filter as a permanent dashboard you can open any time. You will create one that captures all authentication activity: successful logons, failed logons, and account lockouts.

  • In Event Viewer, right-click Custom Views in the left pane.
  • Select Create Custom View....
  • In the By log dropdown, select the Event logs radio button and check Security under Windows Logs.
  • In the Event IDs field, type 4624,4625,4740.
  • Click OK.
  • In the Name field, type Authentication Monitor and click OK.

What do these Event IDs capture?

Event ID 4624 logs every successful logon. Event ID 4625 logs every failed logon attempt. Event ID 4740 logs account lockouts (when too many failed attempts trigger a lockout).

Together, these three IDs give you a complete view of authentication activity across every user and group in your domain from one place.

Before you check the Custom View, what do you expect to see in it? Think about which events you generated during this step.

  • In the left pane, expand Custom Views and click Authentication Monitor.

You should see Event ID 4624 entries for achen's successful logon and Event ID 4625 entries for jlee's failed logon attempt. All authentication events across all departments are now visible in one filtered dashboard.

Custom View showing no events?

Make sure you typed the Event IDs as 4624,4625,4740 with commas and no spaces. Also confirm you selected Security under Event logs (not Event sources).

If the Custom View exists but is empty, your audit policies may not have generated events yet. Log in as achen on the client one more time to produce a fresh 4624 event.

help me troubleshoot why my Custom View in Event Viewer is not displaying any security events

Secret mission

Bulk User Creation with PowerShell

Creating users one at a time works for a handful of employees. But when a company hires 20 people in a quarter, you need automation. In this secret mission, you will write a PowerShell script that reads a CSV file and creates users in bulk, placing each one in the correct OU and security group based on their department.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on your existing VMs, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Active Directory forest "corp.local" on your Windows Server VM (no ongoing cost).
  • Domain-joined Windows client VM (no ongoing cost).

Keep everything running

No action needed. Choose this if you are still actively building or want to experiment further.

  • Your lab is ready for further experimentation. Consider adding DHCP, Certificate Services, or a second Domain Controller.
  • All AD objects (OUs, users, groups, GPOs) persist as long as the VM disk is intact.
  • The Performance Monitor counters and Event Viewer Custom View you created remain available.

Pause - I'll come back to this later

Shut down both VMs to free up system resources. Your AD configuration persists on the virtual disks.

  • Shut down the Windows client VM from the Start menu or by running Stop-Computer in PowerShell.
  • Shut down the Windows Server VM the same way.
  • When you return, start the Windows Server VM first (the Domain Controller must be running before the client can authenticate).

Delete - I don't want to use this again

Remove all Active Directory configuration and start fresh. The cleanest option is reverting to a VM snapshot taken before Step 1.

  • Option A (recommended): In your hypervisor, revert the Windows Server VM to a snapshot taken before you installed AD DS. This restores the server to its original standalone state.
  • Option B: If you do not have a snapshot, remove Active Directory by running this command on the Domain Controller in PowerShell:
Uninstall-ADDSForest

This demotes the server and removes the forest. You will be prompted to confirm and the server will restart.

  • On the Windows client VM, unjoin from the domain: open sysdm.cpl, click Change, select Workgroup, type any workgroup name (e.g. WORKGROUP), and restart.
  • Delete the employees.csv file and the bulk user creation script from wherever you saved them on the server.

Nice Work!

Nice Work!

You just built a production-ready Active Directory domain from the ground up. Your Windows Server is now a fully functional Domain Controller managing authentication, security policies, and audit logging for an entire company's worth of users.

You've learned how to:

  • Promoted a Windows Server to a Domain Controller with integrated DNS, built departmental Organizational Units and Security Groups, and joined a Windows client that authenticates with domain credentials.
  • Created differentiated Group Policy Objects per department, enforcing strict password requirements and full logon auditing for IT while applying lighter account management auditing for HR.
  • Monitored real-time DC health with Performance Monitor counters and traced successful and failed logon events in Event Viewer, building a Custom View that filters authentication activity across the entire domain.
  • Secret Mission: Automated bulk user creation with a PowerShell script that reads a CSV and creates 20+ users across multiple departments in seconds, verified through Event ID 4720 audit trails.

Ready to quiz yourself?