Windows Server Domain Lab on Azure

Deploy an Active Directory domain on Azure and enforce security with GPOs and Kerberos auditing.

Introduction

30 Second Summary

Every time you log into a work computer or access a company file share, there's an invisible handshake happening behind the scenes. A trusted authority vouches for your identity, issues you a cryptographic "ticket," and grants you access without ever sending your password across the network.

In this project, you will build a two-machine Active Directory domain lab on Azure, promote a Windows Server to a domain controller, enforce security policies through Group Policy, and observe Kerberos authentication happening in real time.

What You'll Build

You'll have a live Active Directory domain where you can log in from a client machine, inspect your Kerberos tickets, trigger security policy enforcement, and watch authentication events appear in the Security Event Log as they happen.

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

A working domain where you log in as different users and inspect your Kerberos TGT and service tickets to confirm AES-256 encryption is protecting every authentication.
GPOs enforcing password complexity and account lockout that you can prove work by testing weak passwords and watching them get rejected.
Kerberos auditing that captures every ticket request, letting you correlate live logons with Security Event Log entries showing exactly who authenticated, when, and how.
Secret Mission: Implement Fine-Grained Password Policies so different security groups get different password rules based on their role.

Are there any prerequisites?

You'll need an Azure account (a pay-as-you-go subscription or a free trial with $200 credit works). You'll also need Microsoft Remote Desktop installed on your Mac, which is free from the Mac App Store.

No prior Active Directory experience is required. This project walks you through everything from deploying the VMs to observing Kerberos tickets.

Before We Start

Before We Start...

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

This project gives you hands-on experience with enterprise identity and access management. You'll deploy a real Active Directory domain on Azure, observe Kerberos authentication as it happens, and enforce security policies through Group Policy Objects.

Deploy Azure Infrastructure

Building an Active Directory domain requires two machines on the same network. One will become the domain controller (running the Kerberos Key Distribution Center), and the other will be a client that authenticates against it.

Azure gives you virtual machines and a private network you can deploy in minutes. It also sidesteps Apple Silicon limitations that make local Windows Server virtualization unreliable.

In this step, get ready to:

Create a resource group, virtual network, and network security group in Azure.
Deploy a Windows Server 2025 domain controller VM.
Deploy a Windows 11 client VM and confirm RDP access to both.

Create a resource group and virtual network

Every Azure deployment starts with a resource group. This is a container that holds all related resources so you can manage and delete them together.

Open your browser and navigate to portal.azure.com.
Sign in with your Azure account credentials.
In the search bar at the top, type Resource groups and select it from the results.
Click + Create.
Set Resource group name to ad-lab-rg.
Set Region to East US.
Click Review + create, then click Create.

You should see a notification that your resource group was created successfully.

What is a resource group?

A resource group is a logical container in Azure that holds related resources for a solution. When you delete the resource group later, it removes everything inside it in one action.

Next, you need a virtual network so both VMs can communicate privately. Create it inside your new resource group.

In the search bar, type Virtual networks and select it from the results.
Click + Create.
Select ad-lab-rg as the Resource group.
Enter ad-lab-vnet as the Virtual network name.
Set Region to East US.
Click Next to move to the IP Addresses tab.
Confirm the address space is 10.0.0.0/16. If it shows a different value, edit it to match.
Under Subnets, confirm a default subnet exists with range 10.0.0.0/24. If not, add one with that name and range.
Click Review + create, then click Create.

Wait for the deployment notification that says your virtual network was created.

Why a /16 address space?

The 10.0.0.0/16 space gives you 65,534 usable addresses. The /24 subnet carves out 254 of those for your lab machines. This is far more than you need, but it mirrors how real enterprise networks allocate space for growth.

Now create a Network Security Group to control which traffic can reach your VMs.

In the search bar, type Network security groups and select it from the results.
Click + Create.
Select ad-lab-rg as the Resource group.
Enter a name for the NSG (for example, ad-lab-nsg).
Set Region to East US.
Click Review + create, then click Create.

Once the NSG is deployed, add an inbound rule that allows RDP from your IP only.

Click Go to resource to open your new NSG.
In the left menu, click Inbound security rules.
Click + Add.
Set Source to My IP address.
Set Service to RDP.
Leave Action as Allow.
Click Add.

You should see the new rule appear in the rules list with destination port 3389 and source set to your IP address.

Why restrict to your IP?

RDP exposes port 3389 to the internet. Restricting the source to your current public IP means only you can connect. If you move to a different network later (a coffee shop, a different office), you will need to update this rule with your new IP.

Finally, associate the NSG with your subnet so the rule applies to all VMs on that subnet.

In the left menu of your NSG, click Subnets.
Click + Associate.
Select ad-lab-vnet as the Virtual network.
Select default as the Subnet.
Click OK.

You should see ad-lab-vnet/default listed under associated subnets.

Don't see your VNet in the dropdown?

Make sure the NSG and the VNet are in the same region (East US). Azure only shows VNets in the same region as the NSG.

help me associate my NSG to a subnet

Deploy the domain controller VM

The domain controller is the heart of your Active Directory lab. It will host the AD database, DNS, and the Kerberos KDC.

In the search bar, type Virtual machines and select it from the results.
Click + Create, then select Azure virtual machine.
Set Resource group to ad-lab-rg.
Set Virtual machine name to DC01.
Set Region to East US.
Set Image to Windows Server 2025 Datacenter: Azure Edition - x64 Gen2.
Set Size to Standard_B2s (2 vCPUs, 4 GiB RAM).
Set Username to azureadmin.

Set a strong Password and confirm it. Write this down somewhere safe.
Click Next: Disks, then click Next: Networking.
Set Virtual network to ad-lab-vnet.
Set Subnet to default.
Under NIC network security group, select None (the subnet-level NSG you created already handles security).
Click Review + create, then click Create.

Deployment takes 2-3 minutes. Wait for the notification that says your deployment is complete.

Now set a static private IP so the domain controller always has the address 10.0.0.4. Other machines will point their DNS here.

Click Go to resource to open the DC01 VM.
In the left menu, click Networking, then click Network settings.
Click on the network interface name (it will look something like dc01-nic).
In the left menu of the NIC, click IP configurations.
Click the ipconfig1 row.
Change Allocation from Dynamic to Static.
Set the IP address to 10.0.0.4.
Click Save.

You should see the private IP address update to 10.0.0.4 with allocation type Static.

Why a static IP for the DC?

Once you promote this server to a domain controller, every machine on the network will use it for DNS. If the IP changed on reboot, all domain-joined machines would lose contact with the domain.

Deployment failed?

The most common cause is a quota limit on your subscription. Free trial accounts sometimes restrict the number of vCPUs per region. Try selecting a different region, or check your subscription's usage and quotas under Subscriptions > Usage + quotas.

help me troubleshoot my Azure VM deployment failure

Deploy the client VM and connect

Before creating the client VM, point the VNet's DNS to the DC's static IP. This ensures the client can find the domain after you promote the DC in the next step.

In the search bar, type Virtual networks and select it from the results.
Click ad-lab-vnet.
In the left menu under Settings, click DNS servers.
Select Custom.
Enter 10.0.0.4 in the DNS server field.
Click Save.

You should see the DNS servers setting update to show 10.0.0.4 under Custom.

Now create the client VM that you will later join to the domain.

In the search bar, type Virtual machines and select it from the results.
Click + Create, then select Azure virtual machine.
Set Resource group to ad-lab-rg.
Set Virtual machine name to CLIENT01.
Set Region to East US.
Set Image to Windows 11 Pro.
Set Size to Standard_B2s.
Set a Username and strong Password.

Click Next: Disks, then click Next: Networking.
Set Virtual network to ad-lab-vnet.
Set Subnet to default.
Under NIC network security group, select None.
Click Review + create, then click Create.

Wait for the deployment to complete. This takes 2-3 minutes.

Why set DNS before creating the client?

Azure VMs pick up VNet DNS settings at boot time via DHCP. By setting the VNet DNS to 10.0.0.4 before creating CLIENT01, the client automatically uses your DC for DNS from its very first boot. This avoids manual reconfiguration later.

Both VMs are now deployed. Time to confirm you can reach them via RDP from your Mac.

In the Azure Portal, navigate to Virtual machines.
Click DC01 and copy the Public IP address shown on the Overview page.
Open the Microsoft Remote Desktop app on your Mac.
Click Add PC (or the + button).
Paste the DC01 public IP into the PC name field.
Click Add.
Double-click the new connection tile to connect.
Enter username azureadmin and the password you set during VM creation.

Before you try connecting, what do you expect to see if your NSG rule is working correctly?

You should see the Windows Server desktop appear with Server Manager opening automatically. That confirms DC01 is reachable via RDP.

Go back to the Azure Portal and navigate to Virtual machines.
Click CLIENT01 and copy its Public IP address.
In Microsoft Remote Desktop, click Add PC again.
Paste the CLIENT01 public IP into the PC name field and click Add.
Double-click the CLIENT01 tile to connect using the credentials you set.

You should see the Windows 11 desktop. Both VMs are now accessible from your Mac.

RDP connection timing out?

The NSG rule uses your IP at the time you created it. If your public IP changed (you switched networks, restarted your router), update the inbound rule source. Open the NSG in the Azure Portal, edit the RDP rule, and set Source to My IP address again to refresh it.

Also confirm both VMs show Running status on their Overview pages. A stopped VM cannot accept connections.

help me troubleshoot my RDP connection to an Azure VM

Your Azure infrastructure is ready. You have two VMs on the same network, locked down to your IP, and accessible via RDP. Next up, you will promote DC01 to a domain controller and bring Active Directory to life.

Promote to Domain Controller and Build AD Structure

Your Azure infrastructure is up and you can Remote Desktop into both VMs. Now it's time to transform DC01 from a plain Windows Server into the identity authority for your entire network.

Right now, DC01 has no special role. It cannot authenticate users or issue tickets. Promoting it to a domain controller installs the Key Distribution Center (KDC), creates the Active Directory database, and makes Kerberos authentication possible on this network.

In this step, get ready to:

Install Active Directory Domain Services and promote DC01 to a domain controller.
Create Organizational Units, users, and security groups.
Verify DNS and domain health with diagnostic commands.

Install AD DS and promote DC01

The promotion process has two phases. First you install the Active Directory Domain Services role. Then you run the configuration wizard that actually promotes the server and creates your forest.

Switch to your RDP session on DC01.
Server Manager should already be open. In the top-right area, click Manage, then click Add Roles and Features.
On the Before you begin page, click Next.
On Installation Type, keep Role-based or feature-based installation selected and click Next.
On Server Selection, confirm DC01 is selected and click Next.
On Server Roles, check the box for Active Directory Domain Services.
A popup asks you to add required features. Click Add Features, then click Next.
Click Next through the Features and AD DS information pages.

On Confirm installation selections, click Install.
Wait for the installation to complete. You will see a success message and a blue link that says Promote this server to a domain controller.

What just happened?

You installed the AD DS role, which is the prerequisite for promotion. The server is not yet a domain controller. The next phase runs the Active Directory Domain Services Configuration Wizard that creates your forest and the KDC.

Click Promote this server to a domain controller. The AD DS Configuration Wizard opens.
On the Deployment Configuration page, select Add a new forest.
In Root domain name, type corp.lab and click Next.
On Domain Controller Options, leave the forest and domain functional levels at their defaults (Windows Server 2025).
In the Password and Confirm password fields, enter a strong DSRM password you will remember. Click Next.
On the DNS Options page, ignore the delegation warning (this is expected for the first DC in a new forest). Click Next.
On Additional Options, confirm the NetBIOS name is CORP and click Next.
Click Next through the Paths and Review Options pages, accepting defaults.

On the Prerequisites Check page, wait for validation to pass, then click Install.
The server will reboot automatically when promotion completes.
After the reboot, sign in as CORP\azureadmin using your original password.

Why sign in as CORP\azureadmin?

Before promotion, you signed in as a local user. Now that DC01 is a domain controller, all authentication goes through Active Directory. The local azureadmin account was automatically migrated to become the domain administrator account CORP\azureadmin.

Can't sign in after reboot?

If the sign-in screen shows only the local account, click Other user and type CORP\azureadmin as the username with your original password.

If the VM takes a long time to become available after reboot, wait 2-3 minutes. Azure VMs can be slow to restart after a promotion.

Why can't I sign into DC01 after promotion?

Create Organizational Units, users, and groups

With the domain running, you need to build the organizational structure that represents your company. Organizational Units (OUs) are containers that let you group users and apply policies to specific departments.

On DC01, open Server Manager. Click Tools in the top-right menu, then click Active Directory Users and Computers.
In the left pane, expand corp.lab. You will see default containers like Computers, Domain Controllers, and Users.
Right-click corp.lab, select New, then Organizational Unit. Name it Corp and click OK.
Right-click the new Corp OU, select New > Organizational Unit. Name it IT and click OK.
Repeat to create HR and Service Accounts OUs inside Corp.

You should now see three OUs nested under Corp: IT, HR, and Service Accounts.

Right-click the HR OU, select New > User.
Enter jsmith as both the Full name and User logon name. Click Next.
Set the password to Password1. Uncheck User must change password at next logon. Check Password never expires. Click Next, then Finish.
Right-click the IT OU, select New > User. Create kadmin with the same password Password1 and the same checkbox settings.

Why such a weak password?

You are setting a deliberately weak password on purpose. In Step 4, you will discover that the default domain policy allows this. Then you will create a GPO that blocks it. This is the designed learning moment.

Right-click the IT OU, select New > Group. Name it IT-Admins, keep scope as Global and type as Security. Click OK.
Double-click IT-Admins, go to the Members tab, click Add, type kadmin, click Check Names, then OK.
Create a group HR-Staff in the HR OU. Add jsmith as a member.
Create a group All-Employees in the Corp OU. Add both kadmin and jsmith as members.

Your AD structure now mirrors a real organization with department-based OUs, user accounts, and security groups.

Can't find the user when adding to a group?

When the Check Names button underlines the name, it was found. If you get an error, make sure you typed the username exactly (kadmin or jsmith) and that the From this location field shows corp.lab.

Help me add a user to a security group in Active Directory.

Verify DNS and domain readiness

Before moving on, you need to confirm that DNS is working and the domain controller is healthy. A broken DNS zone or an unhealthy DC will cause the client join in the next step to fail silently.

In Server Manager, click Tools, then click DNS to open DNS Manager.
In the left pane, expand DC01 > Forward Lookup Zones > corp.lab.
Confirm you see an A record for dc01 pointing to 10.0.0.4. This means the domain controller registered itself in DNS.

Now run the domain controller diagnostic tool to confirm overall health.

Open an elevated PowerShell window by right-clicking the Start button and selecting Windows PowerShell (Admin).
Run the domain controller diagnostic by entering this command:

dcdiag /q

What does this command do?

The dcdiag /q command runs a suite of health tests on the domain controller and only outputs errors. If nothing appears, everything is healthy.

You should see no errors in the output. If the terminal returns with no messages, that means all tests passed.

Before you run the final verification command, think about what information you expect to see about your new domain.

Run this command to display your domain details:

Get-ADDomain

You will see output showing your domain name corp.lab, the forest name, the domain functional level (Windows Server 2025), and DC01 listed as the infrastructure master. This confirms your domain controller is fully operational.

Get-ADDomain returns an error?

If you see a message about the server not being operational, make sure you signed in as CORP\azureadmin (not the local account) and that the PowerShell window is elevated (run as administrator).

Help me troubleshoot Get-ADDomain not working on my new domain controller.

Your domain controller is live, your organizational structure is built, and DNS is healthy. Next up, you will join CLIENT01 to this domain and watch Kerberos authentication happen in real time.

Domain-Join the Client and Observe Kerberos

Your domain controller is live and your users exist, but CLIENT01 is still a standalone machine. It has no idea that corp.lab exists.

Joining a client to the domain triggers Kerberos authentication for the first time. The moment you log in as a domain user, the KDC on DC01 issues a Ticket Granting Ticket (TGT) that proves your identity across the network. You can inspect that ticket and the service tickets it spawns to confirm that Kerberos is working, not NTLM.

In this step, get ready to:

Join CLIENT01 to the corp.lab domain.
Log in as a domain user and inspect your Kerberos TGT and service tickets.
Request a specific service ticket and examine its encryption type.

Join CLIENT01 to the domain

CLIENT01's DNS already points to 10.0.0.4 (DC01), so it can locate the domain. Now you need to formally join it.

Switch to your CLIENT01 RDP session in Microsoft Remote Desktop. Sign in with the local admin account (azureadmin and the password you set during VM creation).
Press Win + R to open the Run dialog.
Type sysdm.cpl and press Enter to open System Properties.
In the Computer Name tab, click Change.
Select Domain under "Member of".
Enter corp.lab and click OK.
When prompted for credentials, enter CORP\azureadmin and its password, then click OK.
You will see a "Welcome to the corp.lab domain" message. Click OK.
Click Restart Now when prompted to reboot the VM.

What just happened?

When you joined the domain, CLIENT01 contacted DC01's KDC (Key Distribution Center) and registered itself as a domain member. A computer account was created in Active Directory, and CLIENT01 now trusts DC01 to authenticate users.

From this point forward, every login to CLIENT01 using a domain account uses Kerberos instead of local password-based authentication.

Seeing 'domain could not be contacted'?

This means CLIENT01 cannot reach DC01 via DNS. Verify that CLIENT01's DNS server is set to 10.0.0.4 in its network settings (Settings > Network & Internet > Ethernet > DNS server assignment). Also confirm DC01 is running and not deallocated in the Azure Portal.

Help me troubleshoot my domain join

Log in as a domain user and inspect Kerberos tickets

The VM has restarted. Logging in as a domain user triggers the full Kerberos authentication flow. The KDC issues a TGT to prove your identity, then service tickets are issued automatically as you access resources on DC01.

In Microsoft Remote Desktop, reconnect to CLIENT01.
On the Windows sign-in screen, click Other user.
Enter CORP\kadmin as the username and Password1 as the password.
Press Enter to sign in.
Once the desktop loads, right-click the Start button and select Terminal (Admin).
If prompted by User Account Control, click Yes.

Before you run the next command, what do you think was issued to kadmin the moment you signed in? Think about what the KDC gives you first before you can access any service.

View your Ticket Granting Ticket by running:

klist tgt

You should see output showing your TGT with ServiceName: krbtgt and TargetDomainName: CORP.LAB. Look at the Session Key line. It shows the encryption algorithm used for this ticket.

What does this output tell you?

The TGT is your master ticket. It was issued by krbtgt/CORP.LAB, which is the KDC service account. On Windows Server 2025, the session key uses AES-256 encryption because DCs no longer issue RC4 TGTs.

The StartTime and EndTime show the ticket's validity window (typically 10 hours). The RenewUntil shows how long the ticket can be renewed without re-entering your password (typically 7 days).

Now view all cached service tickets by running:

klist tickets

You should see tickets for LDAP and CIFS services pointing to DC01. These were automatically requested when your login session accessed Active Directory resources (Group Policy download, profile loading).

What are LDAP and CIFS tickets?

The LDAP ticket authenticates your session to query Active Directory on DC01. The CIFS ticket authenticates file-sharing access (used for things like Group Policy file retrieval and SYSVOL access).

Each ticket's KerbTicket Encryption Type field shows AES-256-CTS-HMAC-SHA1-96. This confirms the entire authentication chain uses modern encryption.

klist shows no tickets or 'No TGT'?

If klist tgt returns nothing, you are logged in with a local account instead of a domain account. Sign out, select Other user, and sign in as CORP\kadmin (include the domain prefix).

Help me debug my missing Kerberos tickets

Request a specific service ticket and examine it

The tickets you saw earlier were requested automatically by Windows during login. You can also explicitly request a service ticket for any registered SPN (Service Principal Name) on the domain. This lets you see the full lifecycle: you ask the KDC, it issues a ticket, and you find it in your cache.

Request a service ticket to DC01's HOST service by running:

klist get HOST/DC01.corp.lab

You should see a message confirming the ticket was retrieved successfully, followed by your updated ticket cache.

Confirm the new ticket appears in your cache by running:

klist tickets

Find the entry with Server: HOST/DC01.corp.lab in the output. Look at its KerbTicket Encryption Type field. It shows AES-256-CTS-HMAC-SHA1-96.

Why AES-256 and not RC4?

Starting with Windows Server 2025, domain controllers no longer issue RC4 Ticket Granting Tickets. The KDC selects AES-256 as the strongest encryption type that both the client and service support.

This is a significant security improvement. RC4 is vulnerable to offline cracking attacks (Kerberoasting). AES-256 makes those attacks computationally infeasible.

List all the SPNs registered for DC01 by running:

setspn -L DC01

You should see a list of registered service principal names including entries for HOST, LDAP, DNS, and others. Each SPN is a service you can request a Kerberos ticket for.

What is an SPN?

A Service Principal Name (SPN) uniquely identifies a service instance on the network. When you ran klist get HOST/DC01.corp.lab, you told the KDC which service you wanted to access. The KDC looked up that SPN, found DC01's computer account, and encrypted the ticket with DC01's key.

The setspn -L DC01 command shows every service that DC01 has registered. Any of these SPNs can be targeted with klist get.

You now have live proof that Kerberos is handling all authentication between CLIENT01 and DC01. Every ticket uses AES-256, and you can trace the full ticket lifecycle from TGT to service ticket. Next up, you will discover a serious security gap in the default domain policy and fix it with Group Policy.

Enforce Password Policy and Account Lockout via GPO

Your domain is live, users are authenticating with Kerberos, and tickets are flowing. But there is a critical gap.

Right now, your domain has zero password complexity enforcement and no account lockout. Both jsmith and kadmin have Password1 as their password, and an attacker could try unlimited guesses without being stopped. In this step, you will prove that gap exists, then close it with a Group Policy Object that enforces password complexity and account lockout across the entire domain.

In this step, get ready to:

Demonstrate that weak passwords and unlimited login attempts are allowed by default.
Create and link a GPO enforcing password length, complexity, and account lockout.
Test the policies by attempting a weak password change and triggering an account lockout.

Demonstrate the security gap

Before creating any policy, you need to see the problem with your own eyes. You will attempt to set a weak password on a domain account and watch it succeed.

Switch to your RDP session on CLIENT01, signed in as CORP\kadmin.
Open an elevated Command Prompt by right-clicking the Start button and selecting Terminal (Admin).

Before you run the next command, do you think changing kadmin's password to a three-character string like abc will succeed or fail on this fresh domain?

Try changing kadmin's password to something extremely weak by running this command:

net user kadmin abc /domain

The command completes successfully. A three-character password with no complexity was accepted.

Why did this work?

A newly created Active Directory domain ships with minimum password length set to 7 (or less depending on promotion defaults) and no complexity requirement enforced at the domain level. The default domain policy also sets the account lockout threshold to 0, meaning no lockout ever occurs regardless of how many wrong passwords are tried.

An attacker could brute-force every account in the domain indefinitely. This is the gap you are about to close.

Reset the password back to the original by running:

net user kadmin Password1 /domain

The password is back to Password1. Now you have proof that your domain allows dangerously weak credentials.

Create and link a password and lockout GPO

You will now create a Group Policy Object on DC01 that enforces password complexity and account lockout across the entire corp.lab domain.

Switch to your RDP session on DC01, signed in as CORP\azureadmin.
Open Group Policy Management by clicking Start, typing gpmc.msc, and pressing Enter.
In the left pane, expand Forest: corp.lab > Domains > corp.lab.
Right-click corp.lab and select Create a GPO in this domain, and Link it here....
Name the GPO Security - Password and Lockout and click OK.
Right-click the new Security - Password and Lockout GPO and select Edit....

The Group Policy Management Editor opens. Now configure the password policy settings.

In the 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 Enforce password history. Check Define this policy setting, set the value to 24 passwords remembered, and click OK.
Double-click Password must meet complexity requirements. Check Define this policy setting, select Enabled, and click OK.
Double-click Maximum password age. Check Define this policy setting, set the value to 90 days, and click OK.

What do these password settings do?

Minimum length of 12 blocks short passwords like abc or Password1. Complexity requires at least three of four character types (uppercase, lowercase, digits, symbols). Password history prevents users from cycling back to the same password.

Now configure the account lockout settings in the same editor window.

In the left pane, click Account Lockout Policy (just below Password Policy under Account Policies).
Double-click Account lockout threshold. Check Define this policy setting, set the value to 5 invalid logon attempts, and click OK.
Windows will suggest values for the other two settings. Click OK to accept the suggested defaults.
Double-click Account lockout duration. Confirm or set the value to 15 minutes and click OK.
Double-click Reset account lockout counter after. Confirm or set the value to 15 minutes and click OK.
Close the Group Policy Management Editor.

What does account lockout do?

After 5 failed login attempts within 15 minutes, the account is locked for 15 minutes. This stops brute-force attacks cold. The counter resets after 15 minutes of no failures, so a single typo does not count against you permanently.

The GPO is created and linked to the domain. You can verify it appears under corp.lab in the Group Policy Management console.

Don't see your new GPO listed?

Right-click corp.lab in the left pane and select Refresh. The GPO should appear as a linked item under the domain. Make sure you created it at the domain level, not inside an OU.

help me troubleshoot why my GPO is not appearing in the Group Policy Management console

Test the policies

The GPO exists but CLIENT01 does not know about it yet. Group Policy refreshes automatically every 90 minutes, but you will force an immediate update.

Switch to your RDP session on CLIENT01.
In your elevated Command Prompt, force a Group Policy refresh by running:

gpupdate /force

Wait for both the Computer Policy and User Policy updates to complete successfully.

Now try the same weak password change that worked earlier. Do you expect it to succeed or fail this time?

Attempt to change kadmin's password to abc again by running:

net user kadmin abc /domain

This time the command fails. The system rejects the password because it does not meet the length and complexity requirements you just configured.

What does this prove?

The same three-character password that was accepted minutes ago is now blocked by your GPO. The domain-wide policy is actively enforcing password security on every account.

Now test the account lockout policy. You will deliberately enter wrong passwords for jsmith to trigger a lockout.

On CLIENT01, attempt to log in as CORP\jsmith with an incorrect password 5 times. You can do this by disconnecting your current RDP session and trying to RDP in as CORP\jsmith with a wrong password, or by running the following command 5 times (changing the wrong password each time):

net use \\DC01\SYSVOL /user:CORP\jsmith WrongPass1
net use \\DC01\SYSVOL /user:CORP\jsmith WrongPass2
net use \\DC01\SYSVOL /user:CORP\jsmith WrongPass3
net use \\DC01\SYSVOL /user:CORP\jsmith WrongPass4
net use \\DC01\SYSVOL /user:CORP\jsmith WrongPass5

Why use net use for this test?

Each net use command attempts to authenticate jsmith against the domain controller. Five failed authentication attempts will trigger the lockout threshold you just configured. Each attempt registers as a Kerberos pre-authentication failure on the KDC.

Now attempt a 6th authentication with jsmith by running:

net use \\DC01\SYSVOL /user:CORP\jsmith WrongPass6

This attempt returns a different error indicating the account is locked out. The account lockout policy is working.

Switch to your RDP session on DC01.
Open Event Viewer by clicking Start, typing eventvwr.msc, and pressing Enter.
In the left pane, expand Windows Logs > Security.
Click Filter Current Log... in the right Actions pane.
In the Event IDs field, type 4740 and click OK.

You should see an Event ID 4740 entry showing that jsmith was locked out. The event details include the account name and the caller computer name (CLIENT01).

What is Event ID 4740?

Event ID 4740 is logged every time a user account is locked out. It records which account was locked and which machine triggered the lockout. In a real enterprise, security teams monitor this event to detect brute-force attacks in progress.

Finally, unlock the account so jsmith can log in again.

On DC01, open Active Directory Users and Computers by clicking Start, typing dsa.msc, and pressing Enter.
Navigate to the Corp > HR OU.
Right-click jsmith and select Properties.
Click the Account tab.
Check the Unlock account checkbox (it shows the account is currently locked out).
Click Apply, then OK.

The account is unlocked immediately and jsmith can authenticate again.

Not seeing Event ID 4740?

Make sure you are filtering the Security log on DC01, not CLIENT01. Account lockout events (4740) are generated on the domain controller that processes the lockout. Also confirm you ran gpupdate /force on CLIENT01 before attempting the lockout test.

help me figure out why Event ID 4740 is not appearing in my DC01 Security log after triggering an account lockout

Your domain now rejects weak passwords and locks out accounts after 5 failed attempts. Next up, you will configure advanced Kerberos auditing so you can see every ticket request in real time and correlate authentication events across the domain.

Configure Kerberos Auditing and Correlate Events

In the previous step, you proved that Group Policy can enforce real security rules by watching a weak password get rejected and an account get locked out.

You can see Kerberos tickets on a single client with klist, but the domain controller sees every ticket request across the entire domain. Enabling Advanced Audit Policy makes Kerberos visible in the Security Event Log. This is how real administrators detect credential attacks, monitor encryption types, and troubleshoot authentication failures.

In this step, get ready to:

Create a GPO that enables Kerberos auditing on the Domain Controllers OU.
Generate fresh Kerberos traffic and find the matching events in the Security Log.
Correlate a failed authentication attempt with a Kerberos pre-authentication failure event.

Create a Kerberos auditing GPO

Right now, the KDC on DC01 issues and denies tickets silently. You need an audit policy that tells it to log every TGT and service ticket operation to the Security Event Log.

Switch to your RDP session on DC01.
Press Win+R to open the Run dialog.
Type gpmc.msc and press Enter to open Group Policy Management.
In the left pane, expand Forest: corp.lab then Domains then corp.lab then Domain Controllers.
Right-click Domain Controllers and select Create a GPO in this domain, and Link it here.
Name the GPO Security - Kerberos Auditing and click OK.
Right-click the new Security - Kerberos Auditing GPO and select Edit.

The Group Policy Management Editor opens.

In the left pane, navigate to Computer Configuration then Policies then Windows Settings then Security Settings then Advanced Audit Policy Configuration then System Audit Policies.

What is Advanced Audit Policy Configuration?

Windows has two audit systems: the legacy Audit Policy (broad categories) and Advanced Audit Policy Configuration (fine-grained subcategories). Microsoft recommends using the advanced version because it lets you target specific operations without flooding your logs with noise.

Click Account Logon in the left pane.
Double-click Audit Kerberos Authentication Service.
Check Configure the following audit events.
Check both Success and Failure.
Click OK.
Double-click Audit Kerberos Service Ticket Operations.
Check Configure the following audit events.
Check both Success and Failure.
Click OK.

Now configure the Logon/Logoff and Account Management subcategories.

Click Logon/Logoff in the left pane.
Double-click Audit Logon.
Check Configure the following audit events, then check both Success and Failure.
Click OK.
Double-click Audit Account Lockout.
Check Configure the following audit events, then check Failure only.
Click OK.
Click Account Management in the left pane.
Double-click Audit User Account Management.
Check Configure the following audit events, then check both Success and Failure.
Click OK.

Close the Group Policy Management Editor.

The GPO is linked to the Domain Controllers OU, so it only applies to DC01. Force it to take effect immediately.

Apply the policy immediately by running this command in an elevated Command Prompt on DC01:

gpupdate /force

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

Policy update failed?

Make sure you are running the Command Prompt as Administrator on DC01. If you see access denied, right-click Command Prompt and select Run as administrator.

Help me troubleshoot this

Generate Kerberos traffic and examine events

The audit policy is active. Now you need to generate fresh Kerberos traffic so the DC has something to log.

Switch to your RDP session on CLIENT01.
Click Start, then click your profile icon.
Click Sign out.
RDP back into CLIENT01 as CORP\kadmin with password Password1.

Why sign out and back in?

Signing in triggers a fresh AS-REQ to the KDC, which generates a new TGT. The audit policy you just applied will now log this ticket request as Event ID 4768 on DC01.

Open an elevated Command Prompt on CLIENT01.
Purge existing cached tickets and request a specific service ticket by running these commands:

klist purge
klist get HOST/DC01.corp.lab

You should see a confirmation that all tickets were purged, followed by the details of the newly retrieved service ticket for HOST/DC01.corp.lab.

What do these commands do?

klist purge deletes all cached Kerberos tickets for the current session, forcing the client to request fresh ones.
klist get HOST/DC01.corp.lab explicitly requests a service ticket for the HOST service principal name on DC01. This generates a TGS-REQ that the DC logs as Event ID 4769.

Before you check the logs on DC01, think about what you expect to find. What Event IDs should appear for a successful TGT request and a successful service ticket request?

Switch back to your RDP session on DC01.
Press Win+R to open the Run dialog.
Type eventvwr.msc and press Enter to open Event Viewer.
In the left pane, expand Windows Logs and click Security.
In the right Actions pane, click Filter Current Log.
In the Event IDs field, type 4768 and click OK.

You should see one or more Event ID 4768 entries. Find the one where the Account Name is kadmin.

Click the event to view its details in the lower pane.
Look at the Ticket Encryption Type field. It should show 0x12 which means AES-256.

Why 0x12 and not RC4?

Windows Server 2025 domain controllers no longer issue RC4 Ticket Granting Tickets. The encryption type 0x12 confirms your domain is using AES-256-CTS-HMAC-SHA1-96, the strongest symmetric encryption Kerberos supports.

Click Filter Current Log again in the Actions pane to clear the current filter.
Change the Event IDs field to 4769 and click OK.
Find the event where the Service Name is HOST/DC01.corp.lab.
Note the encryption type and the client address in the event details.

You have just correlated a specific klist get command on the client with the exact service ticket event on the DC.

Correlate a failed authentication

Successful ticket events are useful, but the real security value is catching failures. Event ID 4771 fires when the KDC rejects a pre-authentication attempt, which means someone tried the wrong password.

On DC01, open Active Directory Users and Computers by pressing Win+R and typing dsa.msc.
Find jsmith in the Corp then HR OU.
Right-click jsmith and select Properties.
Click the Account tab and uncheck Unlock account if it is checked.
Click OK.

Now generate a failed authentication from the client.

Switch to CLIENT01.
In the elevated Command Prompt, attempt to authenticate as jsmith with a wrong password by running:

net use \\DC01\NETLOGON /user:CORP\jsmith WrongPassword123

You should see an error about incorrect credentials. This is expected.

Before you check the DC logs, predict what you will see. What Event ID should the KDC generate when someone provides the wrong password during Kerberos pre-authentication?

Switch back to DC01.
Return to Event Viewer (it should still be open).
Click Filter Current Log in the Actions pane.
Change the Event IDs field to 4771 and click OK.
Find the event where the Account Name is jsmith.
Click it to view the details.

You should see Event ID 4771 with a Failure Code of 0x18, which means the wrong password was provided. The event also shows the client IP address that sent the bad request.

Why does this matter for security?

Event ID 4771 with failure code 0x18 catches brute-force attempts at the KDC level before the account is even locked out. In a real environment, a sudden spike of these events from one IP address is an early warning of a password spray attack.

Combined with the lockout policy you configured in the previous step, you now have two layers of defense: detection (audit events) and prevention (account lockout).

Not seeing Event ID 4771?

Confirm that gpupdate /force was run on DC01 (not just CLIENT01) after creating the GPO. The audit policy must be active on the domain controller itself because that is where the KDC runs.

Also verify that the GPO is linked to the Domain Controllers OU, not the domain root. The DC needs to be in scope of the policy.

Help me troubleshoot why Kerberos audit events are not appearing

You now have end-to-end visibility into Kerberos authentication. You can see every TGT issued (4768), every service ticket granted (4769), and every failed pre-authentication attempt (4771) directly in the Security Event Log.

Next up, you will push your lab further with a Secret Mission that gives different user groups different password rules.

Secret mission

Fine-Grained Password Policies

A single domain-wide password policy treats the CEO and the intern the same. In real enterprises, privileged groups like IT Admins get stricter password rules than standard users. Can you implement Fine-Grained Password Policies to differentiate security posture by role?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Both VMs incur compute charges while running, so leaving them on will continue to bill your Azure subscription.

Cost warning

Your two B2s Windows Server VMs bill for compute while they are in the Running state. If you are done with the lab, delete the resource group immediately to stop all charges. If you want to come back later, deallocate both VMs to stop compute billing. Disk storage still bills at a small rate while deallocated.

Resources you used:

Resource Group ad-lab-rg containing all project resources.
2 Virtual Machines: DC01 (Windows Server 2025) and CLIENT01 (Windows 11 Pro).
2 OS disks, 2 network interfaces, 2 public IP addresses.
1 Virtual Network (ad-lab-vnet) and 1 Network Security Group.

Keep everything running

No action needed. Choose this if you are still actively building or plan to continue practicing within the next hour or two.

Both VMs remain running and accessible via RDP.
Compute charges continue to accumulate for as long as the VMs stay in the Running state.
Your Active Directory domain, GPOs, and Fine-Grained Password Policies remain intact.

Pause - I'll come back to this later

Shut down and deallocate both VMs to stop compute billing. Your domain, GPOs, and user accounts are preserved on disk. Restart later to continue practicing.

In the Azure Portal, search for Virtual machines and select the service.
Select DC01.
Click Stop at the top of the Overview page.
Confirm the action when prompted. Wait for the status to show Stopped (deallocated).
Repeat for CLIENT01.
Compute billing stops once both VMs reach the Stopped (deallocated) state. Disk storage continues to bill at a small rate.
To resume later, select each VM and click Start.

Delete - I don't want to use this again

Remove all project resources permanently. This is the recommended option once you are done with the lab.

In the Azure Portal, search for Resource groups and select the service.
Select ad-lab-rg from the list.
Click Delete resource group at the top of the Overview page.
Type ad-lab-rg in the confirmation field to confirm.
Click Delete. Azure removes all resources inside the group (VMs, disks, NICs, public IPs, VNet, NSG) and billing stops completely.

How long does deletion take?

Resource group deletion typically takes 2-5 minutes. You can close the browser tab after confirming. Azure completes the deletion in the background.

Nice Work!

You've just built a fully functional Active Directory domain lab on Azure. You deployed infrastructure, promoted a domain controller, enforced security policies through Group Policy, and traced Kerberos authentication from ticket issuance all the way to audit log entries.

You've learned how to:

Deploy a two-machine Active Directory domain on Azure with a Windows Server 2025 domain controller and domain-joined client, then observe real Kerberos TGTs and service tickets confirming AES-256 encryption.
Discover a default security gap (no account lockout, weak passwords allowed) and fix it by creating GPOs that enforce password complexity and lock accounts after failed attempts.
Configure Advanced Audit Policy to capture Kerberos events (4768, 4769, 4771) and correlate live ticket requests with Security Event Log entries on the domain controller.
Secret Mission: Implement Fine-Grained Password Policies giving IT-Admins stricter password requirements than standard users, differentiating security posture by role.

Ready to quiz yourself?