Active Directory Security Lab in Azure

Build a secure Active Directory domain controller with GPOs in Azure.

Introduction

30 Second Summary

Every time you log into a work computer, a system behind the scenes is checking who you are, what you're allowed to access, and what security rules apply to your account. That system is Active Directory, and it runs in nearly every enterprise on the planet.

In this project, you will build your own Active Directory security lab from scratch in Azure. You'll deploy a Windows Server, promote it to a domain controller, create users and groups, and enforce security policies using Group Policy.

What You'll Build

A fully functional Active Directory domain controller running on a Windows Server 2022 VM in Azure, secured with Group Policy Objects and monitored by Azure-native security tools.

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

A Windows Server 2022 VM promoted to an Active Directory domain controller running your own domain.
An Organizational Unit structure with separate containers for IT Admins and Standard Users, following least-privilege principles.
Security Group Policy Objects enforcing password complexity, account lockout, and access restrictions scoped to specific user groups.
Azure-level monitoring with Activity Log alerts and a Defender for Cloud Secure Score baseline for your subscription.
Secret Mission: Create a firewall GPO that blocks outbound internet access on the domain controller, hardening it against compromise.

Are there any prerequisites?

You need an Azure account to complete this project. If you're new to Azure, you can sign up for a free account that includes $200 in credits for 30 days. No local software installs are required beyond a Remote Desktop client (built-in on Windows).

Deploy a Windows Server VM in Azure

Every Active Directory domain needs a server to run on. Before you can create users, groups, or security policies, you need infrastructure.

In this step, you'll deploy a Windows Server 2022 virtual machine in Azure and connect to it via Remote Desktop. You'll also configure a static IP address, which Active Directory requires to function properly.

In this step, get ready to:

Deploy a Windows Server 2022 VM in Azure.
Connect to the VM via Remote Desktop.
Set the VM's private IP to static for AD DS.

Create the virtual machine

You'll use the Azure Portal to create a Windows Server VM that will eventually become your domain controller.

Sign in to the Azure Portal at https://portal.azure.com.
Click Create a resource in the top left area of the portal.
Search for Virtual machine and select it.
Click Create to open the VM creation wizard.

The wizard opens on the Basics tab. Configure the following fields:

In the Subscription dropdown, select your subscription.
Under Resource group, click Create new and enter ad-security-lab-rg as the name.
In the Virtual machine name field, enter DC01.
For Region, select the region closest to you.
For Image, select Windows Server 2022 Datacenter: Azure Edition - x64 Gen2.
For Size, select Standard_B2s (2 vCPUs, 4 GiB memory, approximately $0.04/hour).
In the Username field, enter azureadmin.
In the Password field, create a strong password (12+ characters, mix of upper, lower, numbers, and symbols). Save it somewhere safe.
Under Public inbound ports, select Allow selected ports, then choose RDP (3389).

Leave other tabs (Disks, Networking, Management, etc.) as defaults.
Click Review + create.
Review the summary, then click Create.

Azure will now deploy your VM. This takes 2-3 minutes.

Why Standard_B2s?

The B2s is a burstable VM with 2 vCPUs and 4 GiB of RAM. It's the smallest size that comfortably runs Active Directory Domain Services for a lab environment.

At approximately $0.04/hour, you'll spend about $2-5 for a few hours of lab work. You'll delete the entire resource group when you're done.

Deployment failed?

If you see a quota error, your subscription may not have enough vCPU quota in the selected region. Try selecting a different region.

If the Standard_B2s size isn't available, click See all sizes and search for it. Some regions have limited availability.

Help me troubleshoot my VM deployment failure in Azure.

Connect via Remote Desktop

Your VM is running in Azure's data center. To interact with it, you'll connect using Remote Desktop Protocol (RDP), which gives you a full graphical desktop session.

Once the deployment completes, click Go to resource to open your VM's overview page.
Click Connect in the top menu, then select RDP.
Click Download RDP File.
Open the downloaded RDP file. Your Remote Desktop client launches automatically.
Enter your credentials: username azureadmin and the password you created earlier.
A certificate warning appears. This is expected for new VMs. Click Yes to accept and continue.

You're now inside your Windows Server 2022 desktop. Server Manager should open automatically after a moment.

What is Server Manager?

Server Manager is the central dashboard for Windows Server administration. It's where you'll install roles (like Active Directory) and manage your server's configuration.

If it doesn't open automatically, click the Start menu and search for Server Manager.

Can't connect via RDP?

If the connection times out, go back to the Azure Portal and verify the VM is in the Running state on its overview page.

If you see "Your credentials did not work", double-check that you're entering azureadmin as the username (not an email address).

Help me troubleshoot my RDP connection to an Azure VM.

Set a static private IP

Active Directory Domain Services requires a stable IP address because other machines on the network look to the domain controller for DNS resolution. If the IP changed, every device on the domain would lose contact.

Switch back to the Azure Portal in your browser (leave the RDP session open).
Navigate to your VM DC01 and click Networking in the left menu.
Click on the Network Interface name (it will look something like dc01123).
Click IP configurations in the left menu.
Click the IP configuration entry (usually named ipconfig1).
Under Private IP address settings, change Assignment from Dynamic to Static.
Note the private IP address displayed (e.g., 10.0.0.4). You'll need this later.
Click Save.

Azure confirms the change with a notification banner. Your VM's private IP is now locked in place.

Why does AD DS need a static IP?

When you promote this server to a domain controller, it also becomes the DNS server for your domain. Every computer that joins the domain points to this IP for name resolution.

If the IP changed (which Dynamic IPs can do after a restart), all domain-joined machines would suddenly be unable to find the domain controller. A static IP prevents that.

Don't see the Static option?

Make sure you clicked into the actual IP configuration entry (ipconfig1), not just the IP configurations list page. The assignment toggle only appears on the individual configuration's edit screen.

Help me find where to set a static IP on my Azure VM.

Your Windows Server VM is deployed, connected, and configured with a static IP. Next up, you'll promote it to a domain controller and bring your Active Directory domain to life.

Promote to a Domain Controller

Your Windows Server VM is running, but right now it's just a plain server with no identity management capabilities.

To turn it into the backbone of your security lab, you need to install Active Directory Domain Services and promote the server to a domain controller. A domain controller is the central authority that manages users, groups, and security policies for every device joined to its domain.

In this step, get ready to:

Install the Active Directory Domain Services role.
Promote the server to a domain controller for a new forest.
Verify that AD DS is running and the domain is live.

Install the AD DS role

Before you can create a domain, your server needs the AD DS software role installed. Windows Server uses a role-based system where you add only the features you need.

In Server Manager (inside your RDP session), click Manage in the top menu bar.
Click Add Roles and Features.
Click Next through the wizard pages until you reach the Server Roles page.
Check the box next to Active Directory Domain Services.
A popup will ask you to add required features. Click Add Features.
Click Next through the remaining pages.
Click Install and wait for the installation to complete (1-2 minutes).

What is Active Directory Domain Services?

AD DS is the core Windows Server role that stores information about users, computers, and groups on a network. It handles authentication (proving who you are) and authorization (deciding what you can access).

Almost every enterprise network uses AD DS to manage employee accounts and enforce security policies across thousands of devices.

Promote the server to a domain controller

Installing the role gives your server the AD DS software, but it doesn't activate it. You now need to promote the server, which creates your domain and makes this server the authority for it.

After the installation completes, look for a yellow warning triangle (notification flag) in the top menu bar of Server Manager.
Click the notification flag.
Click Promote this server to a domain controller.

The Active Directory Domain Services Configuration Wizard opens. Configure it with these settings:

Select Add a new forest.
In the Root domain name field, enter seclab.local.
Click Next.
Set a Directory Services Restore Mode (DSRM) password. Use a strong password and save it somewhere safe.
Click Next through the DNS delegation warning and all remaining pages (accept the defaults).
Click Install.

What is a forest?

A forest is the top-level container in Active Directory. It holds one or more domains that share a common schema and trust each other automatically. By creating a new forest, you're building a completely independent AD environment from scratch.

The .local TLD is commonly used for internal lab domains because it avoids DNS conflicts with real internet domains.

The server will automatically restart after promotion. This takes 3-5 minutes.

Save your DSRM password

The DSRM password is your emergency recovery key for Active Directory. If the domain ever becomes corrupted, this password is the only way to boot into restore mode and fix it. Store it separately from your regular admin password.

Wait for the server to restart (your RDP session will disconnect).
Reconnect via RDP using SECLAB\azureadmin as the username and your original password.

Can't reconnect after restart?

The promotion restart can take up to 5 minutes. If your RDP connection is refused, wait another minute and try again.

Make sure you're using the domain-qualified username SECLAB\azureadmin (not just azureadmin). After promotion, the server only accepts domain credentials.

Help me reconnect to my domain controller after promotion.

Verify AD DS is running

Once you're reconnected, confirm that your domain controller is live and serving your new domain.

In Server Manager, click Tools in the top menu bar.
Click Active Directory Users and Computers.

You should see your domain seclab.local listed in the left panel with default containers: Builtin, Computers, Domain Controllers, and Users.

What are these default containers?

Active Directory creates these containers automatically when a new domain is built. Builtin holds default security groups. Computers is where new machines land when they join the domain. Domain Controllers contains your DC. Users holds default user and group accounts.

In the next step, you'll create your own Organizational Units to organize users in a more security-focused way.

Your domain controller is live and serving seclab.local. Next up, you'll build a security-focused Organizational Unit structure and create users with least-privilege group assignments.

Create a Security-Focused OU Structure

Your domain controller is live and your seclab.local domain is running. Now you need a way to organize users so you can apply different security policies to different groups of people.

In Active Directory, Organizational Units (OUs) are containers that let you group users, computers, and other objects together. By placing admin accounts in one OU and standard users in another, you can target security policies precisely where they need to go.

In this step, get ready to:

Design and create an OU structure that separates admin and standard user accounts.
Create security groups and user accounts within the appropriate OUs.
Verify least privilege by confirming no user has unnecessary Domain Admins access.

Design and create Organizational Units

A flat list of users in the default Users container gives you no way to apply different policies to different people. OUs solve this by creating a hierarchy you can target with Group Policy Objects (GPOs) later.

In Active Directory Users and Computers (already open from the previous step), right-click seclab.local in the left pane.
Select New > Organizational Unit.
Enter Corp as the name and click OK.

Now create three sub-OUs inside Corp to separate your object types.

Right-click the Corp OU and select New > Organizational Unit.
Enter IT-Admins and click OK.
Right-click Corp again and create another OU named Standard-Users.
Right-click Corp one more time and create an OU named Workstations.

Expand the Corp OU in the left pane. You should see three sub-OUs: IT-Admins, Standard-Users, and Workstations.

What is an Organizational Unit?

An OU is a container inside Active Directory that holds users, groups, computers, or other OUs. Think of it like a folder in a file system.

The key benefit is that you can link GPOs to specific OUs. A restriction applied to the Standard-Users OU only affects accounts inside it, leaving your IT admins unrestricted.

Don't see your new OUs?

Make sure you right-clicked the Corp OU (not seclab.local) when creating the sub-OUs. If they ended up at the domain level, drag them into Corp.

Try clicking View > Refresh in the menu bar if the tree hasn't updated.

Help me troubleshoot my OU structure in Active Directory.

Create security groups and users

With your OU structure in place, you need security groups to define who gets what permissions, and user accounts to represent the people in your organization.

Start by creating a security group for your IT administrators.

Right-click the IT-Admins OU and select New > Group.
Enter IT-Administrators as the group name.
Set Group scope to Global and Group type to Security.
Click OK.

Now create a group for standard staff members.

Right-click the Standard-Users OU and select New > Group.
Enter Standard-Staff as the group name.
Set Group scope to Global and Group type to Security.
Click OK.

Next, create your first user account for an IT administrator.

Right-click the IT-Admins OU and select New > User.
Enter Sarah in the First name field.
Enter Chen in the Last name field.
Enter schen in the User logon name field.
Click Next.
Set a password for the user (any strong password works for this lab).
Uncheck User must change password at next logon.
Click Next, then click Finish.

Now add schen to the IT-Administrators group.

Right-click the schen user and select Properties.
Click the Member Of tab.
Click Add.
Type IT-Administrators in the object name field and click Check Names.
The name should resolve with an underline. Click OK to add the group.
Click OK to close the Properties window.

Repeat the process to create a standard user in the Standard-Users OU.

Right-click the Standard-Users OU and select New > User.
Enter James in the First name field.
Enter Wilson in the Last name field.
Enter jwilson in the User logon name field.
Click Next.
Set a password and uncheck User must change password at next logon.
Click Next, then click Finish.

Add jwilson to the Standard-Staff group using the same process.

Right-click jwilson and select Properties.
Click the Member Of tab, then click Add.
Type Standard-Staff and click Check Names.
Click OK to add the group, then OK again to close Properties.

Why separate groups for each OU?

Security groups control access to resources (file shares, applications, admin tools). OUs control where GPOs apply. By placing groups inside the correct OU, you keep your directory organized and make it clear which policies affect which people.

Verify least privilege group membership

The principle of least privilege means every user should only have the permissions they need to do their job. In Active Directory, the Domain Admins group has unlimited control over the entire domain. No regular user should be a member of it.

In the IT-Admins OU, right-click schen and select Properties.
Click the Member Of tab.
Confirm you see IT-Administrators and Domain Users listed. No other groups should appear.
Click OK to close.

Navigate to the Standard-Users OU, right-click jwilson and select Properties.
Click the Member Of tab.
Confirm you see Standard-Staff and Domain Users listed. No other groups should appear.
Click OK to close.

Neither user is in Domain Admins. The IT-Administrators group will receive targeted admin permissions through GPOs in the next step, not blanket domain admin access.

Why not just add IT admins to Domain Admins?

Domain Admins can do anything in the domain: delete users, change passwords, modify security settings, and access any resource. If an attacker compromises a Domain Admin account, they own the entire environment.

By keeping IT staff in a custom group with scoped permissions, you limit the blast radius if any single account is compromised. This is least privilege in action.

Your directory now has a clean separation between admin and standard user accounts. Next up, you'll create Group Policy Objects that enforce real security controls across these OUs.

Apply Security GPOs

Your OU structure and user accounts are in place. Now you need to enforce security rules across those containers.

Group Policy Objects are the mechanism Active Directory uses to push security settings, restrictions, and configurations to users and computers. In this step, you'll configure domain-wide password and lockout policies, then create a targeted GPO that restricts standard users without affecting your IT admins.

In this step, get ready to:

Configure domain-wide password and account lockout policies.
Create a restrictive GPO scoped only to standard users.
Verify GPO inheritance across the OU structure.

Create a domain-wide password and lockout policy

Password and account lockout policies must be configured at the domain level to apply to all accounts. The Default Domain Policy is the correct place for these settings in a single-domain environment.

In your RDP session on DC01, open Server Manager.
Click Tools in the top menu bar.
Select Group Policy Management.
In the left pane, expand Forest > Domains > seclab.local.
Right-click Default Domain Policy and select Edit.

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

Navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy.
Double-click Enforce password history and set it to 12 passwords remembered.
Double-click Maximum password age and set it to 90 days.
Double-click Minimum password age and set it to 1 day.
Double-click Minimum password length and set it to 12 characters.
Double-click Password must meet complexity requirements and set it to Enabled.

Now configure the account lockout settings in the same editor.

Navigate to: Account Policies > Account Lockout Policy.
Double-click Account lockout threshold and set it to 5 invalid logon attempts.
When prompted, click OK to accept the suggested values for the lockout duration and reset counter.
Double-click Account lockout duration and confirm it is set to 30 minutes.
Double-click Reset account lockout counter after and confirm it is set to 30 minutes.
Close the Group Policy Management Editor window.

Why these specific values?

A 12-character minimum password length with complexity requirements makes brute-force attacks significantly harder. The 90-day maximum age forces regular rotation without being so short that users write passwords on sticky notes.

The account lockout threshold of 5 attempts with a 30-minute lockout stops password spraying attacks while still allowing genuine users who mistype their password a few chances before getting locked out.

Why edit the Default Domain Policy?

In a single-domain environment, account policies (password and lockout) only take effect when configured at the domain level. Setting them on a lower-level OU has no effect on domain accounts. That is why Microsoft recommends using the Default Domain Policy for these settings.

Create a restrictive GPO for standard users

The password policy applies to everyone in the domain. Now you'll create a separate GPO that only restricts standard users, leaving IT admins unrestricted. This demonstrates targeted GPO scoping using your OU structure.

Return to the Group Policy Management console.
Expand seclab.local > Corp.
Right-click the Standard-Users OU.
Select Create a GPO in this domain, and Link it here...
Name the GPO Standard-Users-Restrictions and click OK.

Now edit the new GPO to add the restrictions.

Right-click Standard-Users-Restrictions and select Edit.
Navigate to: User Configuration > Policies > Administrative Templates > Control Panel.
Double-click Prohibit access to Control Panel and PC settings.
Set it to Enabled and click OK.

Next, block command prompt access for standard users.

Navigate to: User Configuration > Policies > Administrative Templates > System.
Double-click Prevent access to the command prompt.
Set it to Enabled.
In the options section, set Disable the command prompt script processing also? to Yes.
Click OK.
Close the Group Policy Management Editor.

Why does this only affect standard users?

You linked this GPO directly to the Standard-Users OU. GPOs are applied based on where user or computer objects live in the OU hierarchy. Since your IT admin account (schen) is in the IT-Admins OU, these restrictions never apply to her.

This is the principle of least privilege in action. Standard users get only what they need, while admins retain the tools required for their job.

Verify GPO application

Configuring GPOs is one thing. Confirming they actually apply where you intend is just as important.

In the Group Policy Management console, click on the Standard-Users OU in the left pane.
In the right pane, click the Group Policy Inheritance tab.

You should see two policies listed: the Default Domain Policy (inherited from the domain level) and Standard-Users-Restrictions (linked directly to this OU).

What does GPO inheritance mean?

GPOs flow downward through the hierarchy: domain-level policies apply to all OUs beneath them. OU-level policies add additional settings on top. The Standard-Users OU inherits the domain password policy AND gets its own restrictions. The IT-Admins OU only inherits the domain password policy.

Not seeing Standard-Users-Restrictions?

Make sure you right-clicked the Standard-Users OU (under Corp) when creating the GPO, not the domain root. If the GPO is linked at the wrong level, right-click it and select Delete, then recreate it on the correct OU.

Help me figure out why my GPO isn't appearing on the Standard-Users OU in Group Policy Management.

Your domain now enforces real security policies. The password and lockout rules protect every account, while the restrictions GPO demonstrates how enterprises use OU placement to scope policies precisely. Next, you'll shift to Azure-level monitoring to watch over this infrastructure from outside the VM.

Set Up Azure Security Monitoring

Your AD domain is now secured with password policies, account lockout rules, and targeted access restrictions. The next layer of defense happens at the Azure level, where you can track who changes your infrastructure and assess your overall security posture.

Azure provides built-in monitoring tools that watch for suspicious activity and grade your security configuration. In this step, you'll review your security score, set up an alert for VM changes, and explore your audit trail.

In this step, get ready to:

Review your Defender for Cloud Secure Score.
Create an Activity Log alert for VM changes.
Review Activity Log events for your subscription.

Review Defender for Cloud Secure Score

Microsoft Defender for Cloud gives you a single dashboard that grades your security configuration across all your Azure resources. The grade is called a Secure Score, a number from 0 to 100.

Switch back to the Azure Portal in your browser.
In the search bar at the top, type Microsoft Defender for Cloud and select it from the results.
The Overview page opens by default, showing your Secure Score.
Note the score number displayed. This is your security baseline for the subscription.
Click Recommendations in the left sidebar.
Look for recommendations related to your VM (for example, management ports or endpoint protection suggestions).

What is Defender for Cloud?

Microsoft Defender for Cloud continuously assesses your Azure resources against security best practices. It produces a Secure Score and actionable recommendations to help you close security gaps.

Foundational CSPM (Cloud Security Posture Management), including Secure Score and recommendations, is free for all Azure subscriptions. You don't need to enable a paid plan to use what we're reviewing here.

Don't see a Secure Score?

If Defender for Cloud shows a blank or zero score, it may still be calculating. It can take up to 24 hours after your first resource deployment for a full assessment. You should still see the Recommendations page with some initial findings.

Help me troubleshoot my Defender for Cloud Secure Score not showing up.

Create an Activity Log alert for VM changes

Your domain controller is the most critical server in your environment. If someone modifies or shuts it down, you want to know immediately.

An Activity Log alert watches for specific operations on your Azure resources and notifies you when they happen.

In the Azure Portal search bar, type Monitor and select Monitor from the results.
Click Alerts in the left sidebar.
Click Create, then select Alert rule.

Now configure each section of the alert rule:

Under Scope: select your subscription.
Filter to Resource type = Virtual machines, then select DC01.
Under Condition: select Signal type = Activity Log.
Select Deallocate Virtual Machine as the signal.

Why monitor VM deallocation?

Deallocating a domain controller takes it offline, which breaks authentication for every user and computer in the domain. This alert ensures you are notified if someone (or an automation) shuts down your DC.

Next, set up who gets notified:

Under Actions: click Create action group.
Set the Action group name to security-alerts-ag.
Under Notifications: select Notification type = Email/SMS message/Push/Voice.
Enter your email address in the Email field.
Click OK to save the action group.

Finally, name your alert rule:

Under Details: set the Alert rule name to VM-Config-Change-Alert.
Click Create.

You should see a confirmation that the alert rule was created successfully. From now on, any deallocation of your DC01 VM triggers an email to you.

Don't see the Activity Log signal type?

Make sure you selected your subscription and filtered to Virtual machines in the Scope section first. The signal options change depending on what scope you selected.

Help me find the Activity Log signal when creating an alert rule in Azure Monitor.

Review Activity Log events

The Azure Monitor Activity Log records every management operation on your subscription. It is Azure's built-in audit trail, showing who performed each action and when.

In the Azure Portal, go to Monitor (you may already be here from the previous substep).
Click Activity Log in the left sidebar.
Set the time range filter to Last 6 hours (or today's date range).
You should see events from creating your VM, resource group, and network resources.
Click any event to expand its details.
Note who performed the action, the timestamp, and what resource was affected.

What does the Activity Log track?

The Activity Log records subscription-level events including resource creation, modification, and deletion. Azure retains these events for 90 days at no cost.

In a production environment, this is your first stop when investigating unauthorized changes. Every action is tied to a specific user or service principal.

Activity Log shows no events?

Make sure your time range filter includes the time you created your VM. If you started the project earlier today, expand the range to cover the full day.

Help me troubleshoot why my Azure Activity Log is empty.

Secret mission

Harden the Domain Controller with a Firewall GPO

Domain controllers are high-value targets. If an attacker compromises your DC, outbound internet access lets them download tools, exfiltrate data, or call back to command-and-control servers. In this secret mission, you'll create a GPO that blocks outbound web traffic on the DC itself, following the security best practice that domain controllers should never browse the internet.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Your VM (DC01) is a Standard_B2s instance costing approximately $0.04/hour while running.

Cost warning

If you leave the VM running 24/7, it costs approximately $30/month in compute charges alone. Delete the resource group when you are done to avoid ongoing charges.

Resources you used:

Resource group ad-security-lab-rg containing: VM DC01, OS disk, network interface, public IP, virtual network, and network security group.
Azure Monitor alert rule VM-Config-Change-Alert and action group security-alerts-ag.
Active Directory domain seclab.local with OUs, users, groups, and GPOs (all stored on the VM).

Keep everything running

No action needed. Choose this if you are still actively building or want to experiment further with your Active Directory lab.

Your VM continues to incur compute charges at approximately $0.04/hour.
All AD DS configurations, GPOs, users, and groups remain intact and accessible via RDP.
Your Azure Monitor alert rule stays active and sends email notifications for any VM changes.

Pause - I'll come back to this later

Deallocate (stop) the VM from the Azure Portal to stop compute charges. Disk storage continues at approximately $1/month, but your AD configuration is preserved.

In the Azure Portal, navigate to Virtual machines and select DC01.
Click the Stop button in the top menu bar of the VM overview page.
Wait for the status to change to Stopped (deallocated). This confirms compute charges have stopped.
To resume later, return to the VM page and click Start. Reconnect via RDP using SECLAB\azureadmin.

Why not shut down from inside the VM?

Shutting down Windows inside the RDP session leaves the VM in a Stopped state (not deallocated). Azure continues billing for the allocated hardware. Always use the Stop button in the Azure Portal to fully deallocate and stop compute charges.

Delete - I don't want to use this again

Remove all project resources and stop all charges. This is the recommended option once you have finished the lab.

In the Azure Portal, search for Resource groups in the top search bar.
Select ad-security-lab-rg.
Click Delete resource group at the top of the page.
Type ad-security-lab-rg in the confirmation field to confirm deletion.
Click Delete.

This removes the VM, disks, network resources, alert rule, action group, and all Active Directory data. Deletion takes 2-5 minutes.

Verify deletion completed

After a few minutes, search for Resource groups again. Confirm that ad-security-lab-rg no longer appears in the list.

Nice Work!

You just built an enterprise-grade Active Directory security lab from scratch in Azure. You now have hands-on experience with the core identity and security tools used in enterprise environments worldwide.

Here's what you accomplished:

Deployed a Windows Server 2022 VM in Azure and promoted it to a fully functional domain controller running your own AD domain.
Designed a security-focused OU structure and applied Group Policy Objects enforcing password complexity, account lockout, and access restrictions scoped to specific OUs.
Configured Azure Activity Log alerts for VM changes and reviewed your Defender for Cloud Secure Score to assess your security posture.
Hardened the domain controller with a firewall GPO blocking outbound internet access, following the security best practice that DCs should have minimal connectivity.

Ready to quiz yourself?