This project focuses on designing and validating a secure Azure network architecture that allows administrators to manage virtual machines without exposing them directly to the public internet.

Instead of relying on public IP addresses, open RDP ports, or jumpbox VMs, administrative access is enforced through Azure Bastion, a Microsoft-managed access service.

The objective of this project was to demonstrate how modern Azure environments reduce attack surface by shifting from network-based access to identity-based access, a core responsibility of an Azure Administrator and a key concept tested in the AZ-104 exam.

Problem Statement

Traditionally, virtual machines were managed by:

• Assigning public IP addresses

• Opening ports like RDP (3389) or SSH (22) to the internet

• Relying on firewall rules and passwords for protection

This model significantly increases attack surface and exposes management ports to:

• Internet scanning

• Brute-force attacks

• Exploitation of protocol vulnerabilities

Organizations need a way to:

• Manage virtual machines securely

• Eliminate public exposure

• Enforce identity-based access

• Maintain operational simplicity

Architecture Overview

This project implements a private Azure network where virtual machines are never directly reachable from the internet.

Administrative access is provided exclusively through Azure Bastion, which requires authentication through Microsoft Entra ID before any network connectivity is established.

High-level design

• Virtual machines have no public IP addresses

• No inbound internet access is allowed

• Azure Bastion serves as the only management entry point

• Access is authenticated and audited via Entra ID

Network Design

Virtual Network

A custom virtual network was created with the following address space:

• VNet address space: 10.0.0.0/16

Azure Bastion requires a dedicated subnet named AzureBastionSubnet with a minimum /26 address range, which was created using Azure’s Bastion subnet purpose to enforce Microsoft’s requirements.

Azure Bastion Deployment

Azure Bastion was deployed as a managed PaaS service within the virtual network.

Key characteristics:

• Deployed into AzureBastionSubnet

• Uses HTTPS (443) via the Azure Portal

• Requires Microsoft Entra ID authentication

• Does not expose RDP or SSH ports publicly

• No NSGs or custom routing required

Bastion acts as a secure access broker, not a jumpbox VM. Administrators connect through Bastion rather than logging into it.

Virtual Machine Deployment

A Windows Server virtual machine was deployed with the following security controls:

• No public IP address

• Placed in app-subnet

• Default NSG behavior only (no inbound internet rules)

• RDP enabled internally for administrative access

Because the VM has no public IP and no inbound internet access, it is completely isolated from direct external connectivity.

Access & Security Model

Identity-based access

To connect to the VM:

1. The administrator authenticates to Microsoft Entra ID

2. Access is authorized through Azure RBAC

3. The connection is initiated via Azure Bastion

4. Bastion establishes a private RDP session to the VM

At no point is the VM exposed to the internet.

This design ensures that:

• Identity is verified before network access exists

• Unauthorized users cannot probe or reach management ports

• All access is authenticated and logged

Validation & Testing

Secure access validation

• The VM was successfully accessed using Azure Bastion

• The RDP session was established entirely within the browser

• No public IP was assigned to the VM

Exposure validation

• VM networking configuration confirms Public IP: None

• No inbound rules allowing internet traffic exist

• Direct RDP from an external machine is not possible

This confirms that administrative access is fully private and identity controlled.

Key Takeaways

• Public IP addresses are not required for VM management

• Azure Bastion reduces attack surface

• Identity-based access is more secure than network-based exposure

• Secure architectures can be simple and cost-effective

• Azure-native services can replace legacy jumpbox patterns

Final Thoughts

This project demonstrates how Azure administrators can design secure-by-default environments by eliminating public exposure and enforcing identity-based access. By leveraging Azure Bastion, administrative connectivity is tightly controlled, audited, and aligned with modern Zero Trust principles.

This architecture mirrors real-world Azure environments where security, simplicity, and operational efficiency are prioritized.

Overview

Identity is the foundation of security in Azure. Before deploying workloads, organizations must define who can access resources, what actions they are allowed to perform, and how access is protected.

In this project, I implemented a secure identity and access model using Microsoft Entra ID and Azure Role-Based Access Control (RBAC). The focus was on least-privilege access, role separation, and MFA enforcement — core responsibilities of an Azure Administrator in real production environments.

This project aligns directly with AZ-104 exam objectives and reflects real-world Azure administration practices.

Business Problem

Organizations must answer three critical questions before creating any resources in Azure:

1. Who should be able to access Azure resources?

2. What level of access does each role require?

3. How is access protected if credentials are compromised?

Without proper role separation and MFA enforcement, cloud environments are exposed to misconfiguration, unauthorized changes, and security incidents.

Architecture Overview

This project uses Microsoft Entra ID for identity management and Azure RBAC for authorization.

Access model:

• Azure administrators manage resources

• Helpdesk users have read-only visibility

• MFA is required before Azure access is granted

Core components:

• Microsoft Entra ID users and security groups

• Azure RBAC at subscription and resource group scopes

• Microsoft Entra Security Defaults for MFA enforcement

• Audit and sign-in logs for validation

The diagram below illustrates the identity authentication and authorization flow implemented in this project.

Identity & RBAC Design

Users and Groups

The following users were created for validation:

• cloudadmin.lab – Azure administrator account

• helpdesk.lab – Helpdesk / support user

• breakglass.lab – Emergency access account

Access was assigned using security groups instead of individual users to reflect enterprise best practices:

• Azure-Admins

• Helpdesk-Ops

Group-based RBAC simplifies permission management and scales effectively as environments grow.

Role Assignments

Azure RBAC roles were assigned as follows:

Why Contributor instead of Owner?
Contributor enables full resource management without allowing role assignment changes, reducing the risk of privilege escalation.

Why Reader for Helpdesk?
Helpdesk users can view resources and assist with troubleshooting while being prevented from making configuration changes.

MFA Enforcement

Custom Conditional Access policies require Microsoft Entra ID Premium licensing. Since this tenant did not include that license, Microsoft Entra Security Defaults were enabled instead.

Security Defaults enforce:

• Mandatory MFA for users and administrators

• Blocking of legacy authentication protocols

• Microsoft-managed Conditional Access policies

MFA enforcement was validated when helpdesk.lab was required to register an MFA method before accessing the Azure portal.

Validation & Testing

RBAC Validation

To confirm least-privilege access enforcement:

• The helpdesk.lab account attempted to create an Azure resource

• Azure denied the action due to insufficient permissions

This validated that the Reader role was correctly enforced at the resource group scope.

Logging & Auditability

Audit logs confirmed:

• Group membership changes

• RBAC role assignments

• Security configuration updates

Sign-in logs may experience brief propagation delays in smaller tenants; however, MFA enforcement was verified through mandatory MFA registration and successful authenticated access.

Key Takeaways

• Identity is the primary security perimeter in Azure

• Group-based RBAC enables scalable access control

• Least-privilege access reduces security and operational risk

• MFA enforcement is essential, even in small environments

• Azure identity controls behave consistently across lab and production environments

Skills Demonstrated

• Microsoft Entra ID administration

• Azure RBAC design and validation

• Least-privilege access modeling

• MFA enforcement using Security Defaults

• Azure identity and access troubleshooting

Final Thoughts

This project demonstrates how Azure identity and access controls are designed, implemented, and validated in real environments. The focus on security, governance, and verification reflects the expectations of an Azure Administrator role rather than a theoretical exercise.

Monitoring is one of the most critical responsibilities of an Azure Administrator — and one of the most heavily tested subjects on the AZ-104 exam. Azure’s monitoring ecosystem has evolved dramatically, and today it revolves around a modern, modular pipeline that gives you full control over what data is collected and where it flows.

In this hands-on lab, you’ll build the full 2025 Azure monitoring pipeline manually, including:

• Azure Monitor Agent (AMA)

• Data Collection Endpoint (DCE)

• Data Collection Rules (DCR)

• Log Analytics Workspace (LAW)

• Metric alerts + Action Groups

• KQL log queries

• Azure Monitor Workbooks

This approach is the standard used in many enterprise environments — and it is the version of monitoring Microsoft expects you to understand for the AZ-104 exam as of November 2025.

Unlike the automatic “Enable Insights” button, the manual pipeline ensures:

• You control exactly which counters and event logs are collected

• You choose the workspace

• You understand the DCE + DCR architecture

• Your KQL tables load correctly

• No hidden, auto-generated resources

• Monitoring is predictable and consistent across environments

This is the cleanest, most exam-accurate, and most professional way to configure Azure VM monitoring

What You’ll Build (Architecture Overview)

You will deploy the full monitoring chain:

1. Log Analytics Workspace (LAW)
   Stores performance logs, events, and KQL data.

2. Data Collection Endpoint (DCE)
   The secure endpoint AMA sends data to.

3. Data Collection Rule (DCR)
   Defines which performance counters and logs are collected and where they go.

4. Azure Monitor Agent (AMA)
   Installed on the VM and connected to the DCE + DCR + workspace.

5. Metric Alerts
   Lightweight alerts based on platform metrics.

6. KQL Queries
   Validate Perf, Heartbeat, and InsightsMetrics tables.

7. Monitor Workbook
   Build a dashboard visualizing the collected data.

This architecture is used in real-world monitoring scenarios for Azure VMs, Azure Arc servers, AKS nodes, and hybrid resources.

Lab Requirements

• Azure subscription (free trial works)

• Region: East US

• One VM (Windows Server 2022 recommended)

• 60–90 minutes

• Very small ingestion charges may apply

PART 1 — Create the Virtual Machine

Step 1.1 — Create a Resource Group

Azure Portal → Resource groups → Create

• Name: rg-az104-monitoring-lab

• Region: same region for all resources

Click Review + create → Create

Step 1.2 — Create the VM

Azure Portal → Virtual Machines → Create → Azure virtual machine

Click Next: Disks → accept defaults.

Click Next: Networking → accept defaults.

Click Next: Management → Disable everything for this lab:

Click Next: Monitoring → Enable Boot Diagnostics: Enable with managed storage account (recommended)

Click Next → Advanced

• Do NOT add extensions

• Do NOT add VM applications

Click Review + create → Create

PART 2 — Connect to the VM

Step 2.1 — Navigate to the VM

Azure Portal → Virtual Machines → LabVM01

Ensure:

• Status: Running

• Public IP assigned

Step 2.2 — Connect using RDP

Left menu → Connect → RDP → Download RDP File

Login:

• Username: labadmin

• Password: your password

You are now inside the VM.

PART 3 — Check the Pre-Monitoring State

Before enabling advanced monitoring:

Azure Portal → LabVM01 → Insights

You should see:

• Basic CPU graph (host metrics)

• Availability

• Basic platform data

You will NOT see full performance charts yet.

This confirms AMA, DCR, and workspace is not active.

PART 4 — Create the Log Analytics Workspace

Azure Portal → Log Analytics workspaces → Create

Click Review + create → Create

This workspace will store your VM logs.

PART 5 — Create the Data Collection Endpoint (DCE)

Azure Portal → Monitor → Data Collection endpoints → Create

You now have:

• A VM

• A Log Analytics Workspace

• A Data Collection Endpoint

Next, you will create the Data Collection Rule (DCR) that defines what data the VM will send to the workspace.

PART 6 — Create the Data Collection Rule (DCR)

Azure Portal → Monitor → Data Collection Rules → Create

Fill out the Basics tab:

• Name:
  dcr-az104-monitoring

• Subscription:
  Your subscription

• Resource group:
  rg-az104-monitoring-lab

• Region:
  Same as your VM (East US)

• Platform Type:
  Windows

• Data Collection Endpoint:
  Select your endpoint:
  dce-az104-monitoring

Click Next: Resources

Step 6.2 — Assign DCR to the VM

On the Resources tab:

Click Add resources → select: LabVM01

Click Apply

Click Next: Collect and deliver

Step 6.3 — Add a Data Source

You should now be on the Collect and deliver tab.

Click:

+ Add data source

A panel opens with two tabs: Data source and Destination.

Stay on Data source.

Step 6.4 — Configure Performance Counters

Under Data source type, choose: Performance Counters

Below that, select:

Basic (recommended)

This automatically enables the 4 standard counters:

Leave all four selected
Leave sample rates at 60 seconds

Click Next (Destination)

6.5 — Select Destinations (Mandatory)

This is where many people get stuck — but the choices are simple:

Destination type: Azure Monitor Logs

Subscription: Your Subscription

Destination details: Lab 6 Monitoring

This sends the performance logs into the Perf and InsightsMetrics tables.

Click Next: Tags
(You can skip tags.)

Click Review + Create → Create

Your DCR is now live.

Important - AMA is automatically installed on the VM as soon as you attach the VM to a DCR.

You do NOT manually install AMA under Extensions.

You do NOT click “Enable Insights” inside the VM.

Assigning the VM to a DCR triggers a background deployment of AMA.

Azure handles it for you.

RESULT AFTER PART 6

You now have the full monitoring ingestion pipeline configured:

• AMA (auto-installed when DCR is applied)

• DCE created

• DCR created and assigned

• Performance collection configured

• Data flowing to LAW (incoming within ~10 minutes)

This is exactly how Azure Monitor works in production.

PART 7 — Create a High-CPU Metric Alert

Azure Portal → Virtual Machines → LabVM01 → Alerts

Step 7.1 — Create New Alert Rule

Click Create alert rule.

Under Condition → Add condition

Search for metric: Percentage CPU

Configure:

Step 7.2 — Create an Action Group

Under Action Group → Create action group

Step 7.3 — Basics Tab

Project details:

• Subscription: Your subscription

• Resource group: rg-az104-monitoring-lab

• Region: Global
  (Action Groups are always Global — this is correct)

Click Next: Notifications

Notifications Tab

Click + Add notification

Configuration:

• Notification type: Email/SMS message/Push/Voice

• Name: emailNotify

• Channel: Email

• Email address: your email address

Click OK, then Next: Actions

Actions Tab

Leave blank → Click Next: Tags
Skip tags → Click Review + create → Create

Your Action Group is now created.

Step 7.4 — Attach Action Group to the Alert Rule

Back in the alert rule wizard:

• Under Actions, select the new Action Group:
  ag-az104-notify

Click Next: Details

Step 7.5 - Complete the Alert Rule

Set:

• Alert rule name: ar-az104-highcpu

• Severity: 2 (Warning)

• Enable upon creation:

Click Review + create → Create

Your CPU alert is now active.

PART 8 — Validate Log Ingestion with KQL

Now that AMA + DCR are attached to the VM, we verify that logs are flowing into your Log Analytics Workspace.

Step 8.1 — Open the KQL Query Interface

Azure Portal → Monitor
Left menu → Logs

If prompted for a scope:

• Resource type: Log Analytics Workspace

• Workspace: lab6-monitoring

Click Apply.

You are now inside the KQL query editor.

Step 8.2 — Validate VM Connectivity (Heartbeat)

Run:

Heartbeat | where Computer == "LabVM01" | sort by TimeGenerated desc

If you see rows → AMA is connected and reporting.

Step 8.3 — Validate Performance Counters (Perf Table)

Run:

Perf | where Computer == "LabVM01" | summarize Count = count() by ObjectName, CounterName | sort by ObjectName asc

You should see:

• Processor

• Memory

• LogicalDisk

• Network Interface

This confirms the DCR is collecting CPU, memory, disk, and network counters.

Step 8.4 - Generate a CPU Spike (Inside the VM)

Inside LabVM01, open PowerShell and temporarily stress the CPU:

while ($true) { 1..50000 | ForEach-Object { [Math]::Sqrt($_) } }

Let this run for 60–90 seconds.
It will push CPU to 80–100%.

Close the PowerShell window to stop the loop.

This generates real performance data for the Perf table and will also trigger the High-CPU alert we created earlier.

Step 8.5 — Validate the CPU Spike in Log Analytics

Run the following KQL in your Log Analytics Workspace:

Perf | where Computer == "LabVM01" | where CounterName == "% Processor Time" | sort by TimeGenerated desc

You should see:

• A sharp jump in CPU percentage

• Several Perf entries around the timestamp when the spike occurred

This confirms:

• AMA is functioning

• DCR is collecting Perf

• The VM is sending data to LAW

• Alerts will fire correctly

• Monitoring pipeline is working

RESULT AFTER PART 8

You have verified:

• AMA is installed

• Heartbeat data is flowing

• Perf counters are flowing

• CPU spike is visible in KQL

• Alert rule will trigger

• Log Analytics Workspace is receiving data

Your VM is successfully sending monitoring data into Azure Monitor.

PART 9 — Build an Azure Monitor Workbook (Visual Dashboard)

Workbooks let you visualize performance and insights from your VM.

Step 9.1 — Create a New Workbook

Azure Portal → Monitor
Left menu → Workbooks
Click + New

A blank workbook opens.

Step 9.2 — Add a CPU Chart

1. Click Add → Add query

2. Ensure your workspace is set to lab6-monitoring

3. Run:

   Perf | where Computer == "LabVM01" | where CounterName == "% Processor Time" | summarize AvgCPU = avg(CounterValue) by bin(TimeGenerated, 5m)

4. Visualization → Line chart

5. Title: CPU Usage (5m Average)

Click Save inside the query pane.

Step 9.3 — Add a Memory Chart

Perf | where Computer == "LabVM01" | where CounterName == "Available MBytes" | summarize AvgMem = avg(CounterValue) by bin(TimeGenerated, 5m)

Visualization → Line chart
Title: Available Memory (MB)

Step 9.4 — Add a Disk Activity Chart

Perf | where Computer == "LabVM01" | where ObjectName == "LogicalDisk" | summarize AvgIO = avg(CounterValue) by bin(TimeGenerated, 5m)

Visualization → Line chart
Title: Disk Activity

Step 9.5 — Add Heartbeat Table

Heartbeat | where Computer == "LabVM01" | sort by TimeGenerated desc

Visualization → Table
Title → Heartbeat Logs

Step 9.6 — Save the Workbook

Top: Save

Name:
Azure VM Monitoring Dashboard

Resource Group:
rg-az104-monitoring-lab

Click Save

You now have a complete, custom dashboard.

PART 10 — Final Validation Checklist (2025 Azure Monitor Pipeline)

Before closing the lab, verify that each component in your monitoring pipeline is working as expected. This ensures your configuration matches real-world Azure monitoring architecture and AZ-104 exam requirements.

Log Analytics Workspace (LAW)

• Workspace exists in East US

• Data tables (Perf, Heartbeat) are receiving entries

• KQL queries return results without errors

Data Collection Endpoint (DCE)

• Provisioning state = Succeeded

• Region matches the VM, LAW, and DCR

• Connected to the DCR

Data Collection Rule (DCR)

• Assigned to LabVM01

• Platform Type = Windows

• Collects Basic Performance Counters (CPU, Memory, Disk, Network)

• Sends data to lab6-monitoring

Azure Monitor Agent (AMA)

• Automatically installed when the DCR was applied

• No need to manually install or enable VM Insights

• Heartbeat entries appear every 1–5 minutes

KQL Log Validation

• Heartbeat table shows connectivity

• Perf table shows performance metrics

• CPU spike appears in recent Perf logs

• Workspace ingestion pipeline is healthy

Azure Monitor Workbook

• Custom dashboard created

• CPU, Memory, Disk, Heartbeat visualizations display correctly

• Shows real metric data collected via DCR

Alerts + Action Group

• High-CPU alert rule created

• Action Group configured with Email/SMS/Push

• Alerts will fire when CPU spike occurs

• Demonstrates end-to-end monitoring and notification flow

FINAL SUMMARY — Azure Monitoring Lab (2025 Pipeline)

In this lab, you built the complete modern Azure Monitor ingestion pipeline exactly as used in production environments and expected on the AZ-104 exam. Instead of relying on auto-generated resources from VM Insights, you deployed everything manually:

• A Log Analytics Workspace for storing telemetry

• A Data Collection Endpoint for secure ingestion

• A Data Collection Rule defining what data to collect

• The Azure Monitor Agent, automatically deployed

• Performance data flowing into Perf and Heartbeat

• A High-CPU Alert Rule with email notifications

• A Custom Azure Monitor Workbook for visualization

You validated the entire workflow using a real CPU spike, confirming that the VM is sending logs to your workspace and that Azure Monitor is capturing, storing, analyzing, and alerting on activity.

This hands-on approach gives you a deep understanding of how Azure monitoring really works, helps you stand out in job interviews, and builds exactly the skills needed to pass the AZ-104 exam.

Your monitoring environment is now fully operational.
You're ready for advanced monitoring labs or for integrating this pipeline into real enterprise deployments.

Week 5 Goal

This week, you will learn how to secure sensitive application secrets using:

• Azure Key Vault (Secrets Management)

• System-Assigned Managed Identity

• RBAC roles for Key Vault

• PowerShell secret retrieval from inside an Azure VM

This is an important skill for Azure Administrators — useful to learn for the exam and will be necessary on the job.

Why This Lab Matters (Real Azure Admin Scenario)

Suppose you’re supporting an application that runs on an Azure Virtual Machine.
The application needs to securely access:

• Application passwords

• API keys

• Database connection strings

• Sensitive configuration values

Storing these secrets inside the VM or code repository is insecure.

Instead, you will:

• Store secrets in Azure Key Vault

• Give the VM a Managed Identity

• Assign the VM one specific role: Key Vault Secrets User

• Retrieve secrets securely using Azure AD authentication

• No passwords, No access keys, No service principals, No SAS

This is the modern, recommended way to secure secrets across Azure.

Lab Prerequisites

• Active Azure Subscription

• Basic familiarity with Azure Portal

• Region: East US (recommended)

• RDP access to one Windows VM (we will create it)

Step 1 — Create the Resource Group

• In the Azure Portal search bar, type Resource groups.

  1. Click + Create.

  2. Fill in:

     • Subscription: your default

     • Resource group name: rg-week5-keyvault

     • Region: East US

  3. Click Review + create → Create.

This will hold your Key Vault, VM, and related resources.

Step 2 — Create the Azure Key Vault (2025 Portal UI)

Azure has updated the Key Vault creation wizard, so follow this carefully.

2.1 Open the Key Vault creation blade

• In the Azure Portal search bar, type Key Vaults.

• Click + Create.

2.2 — Basics Tab

Project Details:

• Subscription: your subscription

• Resource Group: rg-week5-keyvault

Instance Details:

• Key Vault Name: kv-week5-mcnairtech (must be globally unique)

• Region: East US

• Pricing Tier: Standard (premium is not required)

Click Next: Access Configuration →

2.3 — Access Configuration

Choose:

Azure RBAC (NOT Vault Access Policy)
This is the modern recommended approach.

2.4 — Networking Tab

• Public access: Enabled

• Firewall: Allow access from all networks (for lab)

Click Review + create → Create

Wait for deployment to finish.

Your Key Vault is now deployed.

Next, you will give your user account permission to create and manage secrets inside the vault (required when using Azure RBAC).

Step 3 — Assign Yourself Key Vault Permissions & Add a Secret

Because the vault uses Azure RBAC, your user needs a Key Vault data-plane role to manage secrets.

Without this, you’ll see the error:

The operation is not allowed by RBAC…

Let’s fix that and add your first secret.

3.1 — Open Access Control (IAM)

1. Go to your Key Vault: kv-week5-mcnairtech

2. On the left menu → click Access control (IAM)

3. Click + Add → Add role assignment

3.2 — Assign yourself a Key Vault role

In the Role tab, search for:

Key Vault Secrets Officer

(Recommended — lets you create & read secrets, but not keys/certificates.)

OR, if you want full permissions:

Key Vault Administrator

(Admin-level: manage everything in the vault)

Select the role → click Next

3.3 — Choose your user account

Assign access to:
User, group, or service principal

1. Click + Select members

2. Search for your user account (e.g., ITAdmin@yourdomain.com)

3. Select → Next

4. Click Review + assign

Wait 30–60 seconds for RBAC propagation.

3.4 — Add a secret to the Vault

1. In the left menu, go to Objects → Secrets

2. Click + Generate/Import

3. Fill in:

• Name: dbPassword

• Value: SuperSecurePassword123!

4. Click Create

Your secret is now stored securely.

Step 4 — Create a Virtual Machine with a System-Assigned Managed Identity

This VM will securely retrieve the secret you stored in Key Vault.
Instead of storing passwords locally, the VM will authenticate using its built-in Managed Identity.

4.1 — Open the VM creation wizard

1. In the Azure Portal search bar, type Virtual machines

2. Click + Create → Azure virtual machine
   This opens the modern 2025 VM creation UI.

4.2 — Basics tab

Instance details:

• Virtual machine name: vm-week5-client

• Region: East US

• Availability options: No infrastructure redundancy required

• Security type: Standard

• Image:

  • Click See all images

  • Search for: Windows Server 2025 Datacenter: Azure Edition (Gen 2)

• Architecture: x64

• Size:

  • Recommended: Standard_B2s

  • Budget option: Standard_B1s

Administrator account:

• Username: azureuser

• Password: (choose a strong password)

Inbound port rules:

• Public inbound ports: Allow selected ports

• Select inbound ports: RDP (3389)

Click Next: Disks → and keep defaults
Click Next: Networking → and keep defaults

4.3 — Management tab (Enable Managed Identity)

Scroll to the Identity section:

• System-assigned managed identity: On

This allows the VM to authenticate to Key Vault without keys or credentials.

Leave all other options at default.

Click Review + create → Create
Deployment takes 1–3 minutes.

Step 5 — Grant the VM Permission to Read Key Vault Secrets (RBAC)

Your VM now has a Managed Identity — but it has zero permissions until you grant them.
In this step, you’ll assign the VM the Key Vault Secrets User role.

This gives it read-only access to secrets (perfect for lab and real-world scenarios).

5.1 — Open your Key Vault’s IAM blade

1. Open the vault: kv-week5-mcnairtech

2. Left-hand menu → Access control (IAM)

3. Click + Add → Add role assignment

5.2 — Select the correct role

In the Role tab:

• Search: Key Vault Secrets User

• Select the role

• Click Next

This role allows your VM to read secrets, but not write or delete them.

5.3 — Assign role to the VM’s system-assigned identity

Assign access to: Managed identity

1. Click + Select members

2. In the scope selector:

   • Resource type: Virtual machine

   • Select: vm-week5-client

3. Click Select → Next → Review + assign

RBAC propagation usually takes 10–60 seconds.

Step 6 — Connect to the VM & Retrieve the Secret Using Managed Identity

Now it’s time to test the full chain:

• VM authenticates using its identity

• Key Vault authorizes the VM through RBAC

• PowerShell retrieves the secret through Azure AD

No passwords, no access keys, no SAS tokens — this is exactly how secure workloads operate in Azure.

6.1 — RDP into the VM

1. Go to Virtual machines

2. Click vm-week5-client

3. Click Connect → RDP

4. Download the RDP file and open it

5. Sign in with:

   • Username: azureuser

   • Password: the one you created

6.2 — Open PowerShell (as Administrator)

Right-click → Run as administrator. Install the Az PowerShell module (if needed)

6.3 — Install the Az PowerShell module (if needed)

Install-Module -Name Az -Repository

PSGallery -Force Import-Module Az

6.4 — Authenticate using the VM’s Managed Identity

Connect-AzAccount -Identity

Expected output:

• Account: Managed Identity

• Environment: AzureCloud

• Tenant: your directory

• Subscription: your Azure subscription

If you see that, authentication succeeded.

6.5 — Retrieve the Secret Object (Secure Access Validation)

Set variables for readability: $vaultName = "kv-week5-mcnairtech" $secretName = "dbPassword"

Retrieve the secret object: $secret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $secretName -ErrorAction Stop

Now validate that the VM was able to securely access the secret: $secret

This proves the VM successfully accessed the secret.

6.6 — Secure Handling: Keep the Secret Encrypted

Because the purpose of this lab is to learn identity-based authentication, not reveal sensitive values, we will keep the secret in its secure form.

The following confirms the secret exists and is usable — without ever exposing the plaintext value:

$secret.SecretValue

This returns a SecureString, which is the recommended format for:

• Applications

• Scripts

• Automation

• Production workloads

No plaintext exposure = best practice.

6.7 — (Optional) Use the Secure Secret in a Script

Here’s a common real-world pattern:

$securePassword = $secret.SecretValue

This is how admins securely use secrets without ever printing them.

Final Summary — Week 5: Azure Key Vault + Managed Identity

In this lab, you built a complete, real-world Azure security workflow centered around identity-based access.
By combining Azure Key Vault, RBAC, and System-Assigned Managed Identity, you secured application secrets using the same model enterprises rely on today.

By the end of Week 5, you successfully:

• ✔️ Created a new Azure Key Vault using the 2025 Portal UI

• ✔️ Assigned yourself proper data-plane RBAC to manage secrets

• ✔️ Added a secret (dbPassword) to the vault

• ✔️ Created a Windows Server 2025 VM with a system-assigned Managed Identity

• ✔️ Granted Key Vault Secrets User to the VM’s identity

• ✔️ Connected to the VM using RDP

• ✔️ Authenticated the VM to Azure AD using Connect-AzAccount -Identity

• ✔️ Retrieved the Key Vault secret securely (as a SecureString)

• ✔️ Verified identity-based access without exposing any sensitive values

  Identity authentication with RBAC is the recommended design for any secure Azure workload, and it is heavily tested in the AZ-104 exam.

You now understand how to:

• Protect secrets with Key Vault

• Leverage Managed Identity

• Apply least-privilege RBAC

• Authenticate securely inside Azure resources

This is a major skill for Azure Administrators and a powerful addition to your cloud portfolio.

Goal: Learn how to connect an Azure Virtual Machine to Azure Storage securely using Managed Identities and RBAC — no access keys, no SAS tokens, no secrets.

This is an important task as a real-world Azure Administrator skill and a key part of the AZ-104 exam.

What You’ll Learn This Week

• create a new Azure Storage Account using the 2025 portal interface

• create a private Blob container and upload a file

• deploy a Virtual Machine using the modern VM creation UI

• enable a System-Assigned Managed Identity on a VM

• assign RBAC permissions such as Storage Blob Data Reader

• access Blob Storage from inside the VM using identity-based authentication

• download blobs inside the VM with Azure CLI or PowerShell using

Prerequisites

• Active Azure subscription

• Basic familiarity with the Azure Portal

• We’ll use East US as the region (you can choose your own)

Lab Scenario (Real Azure Admin Task)

You are an Azure Administrator responsible for supporting a line-of-business application that processes files uploaded by employees.
These files—images, PDFs, and documents—are stored in an Azure Blob Storage container.

Your application server runs on a Virtual Machine, and the VM needs to:

• download files from the Blob container

• process or analyze those files (for example: resize images, scan PDFs, extract text, run scripts, etc.)

• upload results or processed outputs back to storage

Instead of using storage account keys or SAS tokens (which are hard to manage and insecure), you’ll give the VM a System-Assigned Managed Identity and assign it the Storage Blob Data Reader role.

This allows the VM to access Blob Storage securely using Azure AD authentication — no keys, no secrets, no passwords.

Step 1 — Create a Resource Group

Resource groups help you organize all related resources so you can clean up easily at the end.

1.1

In the Azure Portal search bar, type Resource groups and select it.

1.2

Click + Create.

1.3 Fill in:

• Subscription: your default

• Resource group name: rg-week4-lab

• Region: East US

Click Review + create → Create.

Step 2 — Create a New Azure Storage Account

This storage account will hold the files that your Virtual Machine needs to access securely using its Managed Identity.

2.1 — Navigate to the Storage Center

1. In the Azure Portal search bar, type Storage accounts.

2. Select Storage accounts from the results.

You will now see the new Storage Center (with tiles for different storage types).

2.2 — Choose the Storage Type (Required in 2025 UI)

• From the Storage Center categories, select Object storage.

• Then select Blob Storage.

• The Create button will now appear.

• Click + Create to begin the Storage Account wizard.

2.3 — Basics tab

Project details

• Subscription: your active subscription

• Resource group: rg-week4-lab

Instance details

• Storage account name: storweek4mcnair

• Region: East US

• Preferred storage type: Azure Blob Storage

• Performance: Standard

• Redundancy: LRS (Locally Redundant Storage)

Click Next: Advanced →

2.4 — Advanced tab

• Minimum TLS version: TLS 1.2

• Enable hierarchical namespace: Off

• SFTP, NFS, and large file shares: Off

• All other settings: leave defaults

Click Next: Networking →

2.5 — Networking tab (Updated for 2025 Portal)

Public network access

• Enable: Yes

Public access scope

• Enable from all networks

Routing preference

• Microsoft network routing (default)

Private endpoints

• Leave empty

Click Next: Data protection →

2.6 — Data protection tab

• Enable soft delete for blobs: 7 days

• Leave all other options at default

Click Next: Encryption →

2.7 — Encryption tab

• Encryption type: Microsoft-managed keys

• Enable support for customer-managed keys: Blobs and files only

• Enable infrastructure encryption: Unchecked

Click Review + Create → Create

After deployment completes, your new Storage Account is ready to use.

Step 3 — Create a Blob Container & Upload a Test File (2025 UI)

In this step, you will create a secure container inside your Storage Account and upload a sample file that your VM will access later using its Managed Identity.

3.1 — Open your new Storage Account

• After deployment finishes, click Go to resource
  or search for your storage account name:

  • storweek4mcnair

• In the left-hand menu, scroll to the Data storage section.

• Click Containers

This opens the Blob Containers page.

3.2 — Create a new Blob Container

• Click + Add Container (top-left)

• Fill in the container details:

  • Name: lab4-files

    • lowercase

    • no spaces

  • Public access level: Private (no anonymous access)

    • This ensures files can only be accessed through RBAC, identity, or SAS.

• Click Create

3.3 — Upload a test file

Inside your container:

• Click lab4-files

• Click Upload at the top

• Browse your computer for a small sample file, for example:

  • test.txt

  • document.pdf

• Click Upload

The file will now appear inside your container.

3.4 — Confirm the container is private

You can verify private access by:

• Clicking the file you uploaded

• Copying the Blob URL

• Pasting it into a new browser tab

You should see: “Public access not permitted”

This is expected — the container is private and cannot be accessed without identity-based authentication or a SAS token.

Step 4 — Create a Virtual Machine with a System-Assigned Managed Identity

This VM will act as your application or processing server.
Later in the lab, it will authenticate to Blob Storage without keys or SAS tokens — using Azure AD and RBAC instead.

4.1 — Open the VM creation blade

• In the Azure Portal search bar, type Virtual machines

• Click Virtual machines

• Click + Create → Azure virtual machine

This opens the modern VM creation wizard.

4.2 — Basics Tab

Fill out the fields as follows:

Instance details

• Virtual machine name: vm-week4-client

• Region: (US) East US

• Availability options:

  • Select No infrastructure redundancy required
    (This avoids zone restrictions and keeps the lab simple.)

Security type

• Standard
  (Trusted Launch is not needed for this scenario.)

Image

• Click See all images

• Search for and select:
  Windows Server 2025 Datacenter: Azure Edition (Gen 2)
  (Easier for RDP and PowerShell testing.)

VM architecture

• x64

Size

• Click See all sizes

• Choose:

  • Standard_B2s (recommended), or

  • Standard_B1s (cheapest option)

Administrator account

• Username: azureuser

• Password: a strong password you will remember

Inbound port rules

• Public inbound ports: Allow selected ports

• Select inbound ports: RDP (3389)

Click Next: Disks

4.3 — Disks Tab

• OS disk type: Standard SSD

• Leave all other settings at default

Click Next: Networking

4.4 — Networking Tab

• Virtual network: auto-created default VNet

• Subnet: default

• Public IP: Enabled

• NIC network security group: Basic

• Inbound port: RDP (3389)

Click Next: Management

4.5 — Management Tab (Enable Managed Identity)

Scroll to the Identity section:

• System-assigned managed identity: On

This identity allows the VM to authenticate to Azure Storage securely later in the lab.

Leave all other settings at default:

Click Review + Create
Then click Create

Deployment will complete in 1–3 minutes.

Your VM is now deployed and has a system-assigned managed identity enabled.
This identity is what will securely access the Blob Storage container in the next steps.

Step 5 — Assign the VM Access to Blob Storage (RBAC)

Now that your VM has a System-Assigned Managed Identity, you must grant that identity the correct permissions so it can access your Blob Storage.

Azure uses Role-Based Access Control (RBAC) for this.
You will assign the VM’s identity the Storage Blob Data Reader role.

5.1 — Open Your Storage Account

• In the Azure Portal search bar, type Storage accounts

• Select your storage account: storweek4mcnair

• In the left-hand menu, click Access control (IAM)

5.2 — Add a Role Assignment

• Click + Add → Add role assignment

• Under Role, search for:

  • Storage Blob Data Reader

• Select the role and click Next

This role allows the VM to read blobs but not upload or delete.

5.3 — Assign Role to the VM’s Managed Identity

Under Assign access to, choose Managed identity

• Click + Select members

• In the identity browser:

  • Select Virtual machine

  • Choose vm-week4-client

• Click Select

• Click Review + assign

  

  5.4 — Confirm Role Assignment

  After the assignment completes:

  • You should now see Storage Blob Data Reader

  • Assigned to: vm-week4-client (Managed Identity)

  • Scope: This storage account

This means the VM can now authenticate to Blob Storage using its Azure AD identity.

If you want your VM to also upload files, you can assign Storage Blob Data Contributor

But for this lab, Reader is enough.

Step 6 — Connect to the VM and Access Blob Storage Using PowerShell (Data-Plane, Managed Identity)

In this step, you’ll RDP into the VM, sign in with its Managed Identity, create a data-plane storage context, list containers, and download a blob — all without keys or SAS.

6.1 — Connect to the Virtual Machine (RDP)

• In the Azure Portal, go to Virtual machines

• Click vm-week4-client

• Click Connect → RDP

• Click Download RDP file

• Open the RDP file

• Log in using:

  • Username: azureuser

  • Password: the one you created

Once logged in, wait a moment for Windows Server to load.

6.2 — Open PowerShell on the VM

• Click Start

• Search for PowerShell

• Right-click → Run as administrator

This ensures all commands run properly.

6.3 — Install the Az PowerShell Module (if needed)

If Connect-AzAccount is not recognized, install the module:

Install-Module -Name Az -Repository PSGallery -Force

Import-Module Az

6.4 — Authenticate Using the VM’s Managed Identity

Run this inside PowerShell: Connect-AzAccount -Identity

You should see output similar to:

This means the VM is now authenticated to Azure using its Managed Identity.

No passwords.
No keys.
No SAS tokens.
Modern Azure Admin technique.

6.5 — Build a data-plane Storage Context (no management rights needed)

# Replace with your storage account name
$accountName = "storweek4mcnair"

# Create a context that uses the current connected identity
$ctx = New-AzStorageContext -StorageAccountName $accountName -UseConnectedAccount

This avoids management-plane APIs (like Get-AzStorageAccount) and uses only the blob data plane, which your Storage Blob Data Reader role allows.

6.6 — List containers (data plane)

Get-AzStorageContainer -Context $ctx

6.7 — Download a blob (data plane)

Replace the blob name with the file you uploaded earlier (e.g., test.txt, photo.jpg)

$container = "lab4-files"

$blobName = "<yourfilename>"

$destPath = "C:\Users\azuser\Desktop\$blobName"

Get-AzStorageBlobContent -Container $container -Blob $blobName -Destination $destPath -Context $ctx

6.8 — Verify the Downloaded File on the VM

Now that you downloaded the blob onto your VM, let’s confirm it’s there and readable.

Get-Item "C:\Users\azuser\Desktop$blobName"

At this point, you have fully validated that:

• The VM authenticated using Managed Identity

• RBAC allowed access

• Your Storage Blob Data Reader assignment is working

• The VM downloaded the file through Azure AD (not keys or SAS)

Week 4 Summary — Azure VM to Blob Storage Access with Managed Identity

In this lab, you built a complete, real-world Azure scenario: a Virtual Machine securely accessing a Blob Storage container using a System-Assigned Managed Identity.

This is the modern, recommended way to authenticate Azure workloads — without keys, without SAS tokens, and without storing any secrets inside scripts.

By the end of the lab, you successfully:

• created a new Storage Account using the updated 2025 Azure Portal

• created a private Blob container and uploaded a test file

• deployed a Windows Server VM with a System-Assigned Managed Identity

• connected to the VM via RDP and installed the Az PowerShell modules

• authenticated the VM using Connect-AzAccount -Identity

• built a data-plane storage context using the VM’s identity

• listed containers and downloaded a blob directly to the VM desktop

• accessed everything through Azure AD and RBAC only

This lab mirrors exactly how Azure administrators secure compute-to-storage communication in real enterprise environments. Please stay tuned for more labs if you’re interested in Azure or currently studying for the AZ-104 certification from Microsoft.

What you’ll learn

• What You’ll Learn

  • How to create and configure an Azure Storage Account

  • The difference between redundancy types (LRS, GRS, ZRS)

  • How to secure access using SAS tokens

  • How to upload and manage Blob Containers

  • How to revoke access by rotating keys

  • Best practices for network security and HTTPS-only connections

Prerequisites

• Azure subscription

• Portal access

• We’ll use East US for the lab (you can change it based on your location)

Step 1 — Create a resource group

Why: keeps everything in one place so you can delete it later.

1.1

In the Azure Portal search bar, type Resource groups and select it.

1.2

Click + Create.

1.3

Fill in:

• Subscription: your default

• Resource group: rg-lab3-storage

• Region: East US

Click Review + create → Create.

Step 2 — Create an Azure Storage Account (Updated for new 2025 portal)

Goal: create a storage account that will hold your blob containers, files, and other data types — while learning the different redundancy and performance options.

2.1 — Open the Storage Account creation wizard

1. In the Azure Portal search bar, type Storage accounts.

2. Click + Create.

3. The new “Storage Center | Blob Storage” interface opens.

2.2 — Basics tab

Project details

• Subscription: your active Azure subscription

• Resource group: rg-lab3-storage (Create it first if you haven’t already.)

Instance details

• Storage account name: storlab3mcnair

  • must be all lowercase, 3–24 characters, globally unique.

• Region: (US) East US

• Preferred storage type: Azure Blob Storage or Azure Data Lake Storage Gen 2

  Microsoft recently updated this field. Choose “Azure Blob Storage” because this lab focuses on blob containers, SAS, and lifecycle management (all AZ-104 exam topics).

• Performance: Standard (General-purpose v2)

  Premium is for high-throughput or low-latency scenarios; Standard keeps costs low.

• Redundancy = LRS

  LRS stores three copies of your data within one datacenter. It’s low-cost and perfect for lab work or testing.

Click Next: Advanced → at the bottom.

2.3 — Advanced tab

Leave defaults for now, but confirm:

• Minimum TLS version: TLS 1.2

• Allow large file shares: Disabled

• Enable hierarchical namespace (Data Lake Gen2): Leave unchecked (not needed for this lab)

Click Next: Networking →

2.4 — Networking tab

The Networking tab controls how your Storage Account is accessed — publicly, privately, or only from specific networks.

For this lab, we’ll keep it open so you can test uploads, SAS links, and RBAC access later.

Public network access

Select:

Enable
This allows inbound and outbound traffic to your Storage Account over the public Azure network.

Explanation:
Azure gives you three levels here:

• Enable → open access (best for labs and learning)

• Disable → blocks all network traffic except private endpoints

• Secure by perimeter → used in enterprise networks with perimeter controls

Public network access scope

Select:

Enable from all networks

Explanation:
This makes the Storage Account reachable from any public IP address or Azure service (perfect for practicing SAS and RBAC access).
Later, in production or advanced labs, you’d restrict this to specific virtual networks or IP ranges.

Private endpoint

Leave this section empty for now.

Private endpoints let you connect privately to your Storage Account inside a VNet — you’ll explore that later in your AZ-104 journey (network security and hybrid connectivity modules).

Result:
Your Storage Account is configured for public access — allowing you to easily upload blobs, generate SAS tokens, and test access controls during this lab.
Later on in the series, you’ll learn how to restrict access securely using Azure RBAC and private endpoints.

2.5 — Data protection tab

Enable:

Select Soft delete for blobs (7 days)

Leave everything else default.
Click Next: Encryption →

2.6 — Encryption tab

Keep defaults:

• Encryption type: Microsoft-managed keys

• Infrastructure encryption: Off

Click Review + Create →

Step 3 — Create a Blob Container & Upload Files (2025 Portal Layout)

Goal:
Create a private blob container, upload a test file, and verify access before adding SAS.

3.1 Open your new Storage Account

1. After deployment, click Go to resource.

2. In the left-side menu, under Data storage, click Containers.

3. 

   3.2 Create a new Blob Container

   1. Click + Add Container.

   2. Fill in the fields:

3.3 Upload a test file

1. Select lab3-files.

2. Click Upload → Browse for files.

3. Pick a small file (e.g., test.txt or photo.jpg).

4. Click Upload.

3.4 Verify access behavior

1. Click your uploaded blob.

2. Copy the Blob URL.

3. Paste it into a new browser tab (not signed in).

   • You should see a “PublicAccessNotPermitted” message.

   • That’s expected—your container is private. Private containers reject anonymous requests; you need an auth token or SAS to access them.

Result:
You’ve successfully created a private blob container and uploaded data securely.
Next, you’ll generate a Shared Access Signature (SAS) to grant temporary access without making the container public.

Step 4 — Step 4 — Generate a Shared Access Signature (SAS) in Azure (2025 Portal UI)

Goal:
Grant temporary, permission-based access to your private blob data without exposing your storage account keys.

4.1 — Open the Shared Access Signature settings

1. In the Azure portal, open your storage account (mine is storlab3mcnair.)

2. In the left-hand menu, scroll to Security + networking → Shared access signature.

   Do not select Access keys — those are full-control root credentials.

4.2 Configure your SAS parameters

Click Generate SAS and connection string. Azure will display two outputs:

• SAS token: the long string starting with ?sv=...

• Blob service SAS URL: your blob endpoint + token

4.3 Copy your SAS and test it

• Copy the Blob service SAS URL.

• Paste it into a browser’s address bar.

  • You’ll see an XML-style listing error or empty page → That’s expected!

  • This SAS works at the account level; it isn’t pointing to your file yet.

• You may want to keep this SAS token handy if you plan to use it later in Azure CLI or automation.

4.4 — Generate a SAS for a specific blob (to actually view the file)

1. Navigate to Data storage → Containers → lab3-files.

2. Click your uploaded blob (e.g., photo.jpg).

3. Click the link on the file and choose select Generate SAS or Generate SAS token and URL.

4. Click Generate → Copy the Blob SAS URL which should look similar to the example link below.

   https://storlab3mcnair.blob.core.windows.net/lab3-files/photo.jpg?sv=...

5. Open a Private/Incognito browser window and paste the URL.
   Your image or file should open or download instantly.

   4.5 – (Optional) Revoke the SAS

   If you accidentally shared a SAS link or just want to demonstrate revocation, you can instantly invalidate it by rotating the key it was signed with.

   1. In the Azure Portal, go to Security + networking → Access keys

   2. Find the key used for your SAS (for example key1)

   3. Click Rotate key → then Regenerate

      Every SAS signed with that key immediately becomes invalid.
      This is a powerful security feature for when credentials are exposed, or a link was shared publicly.

Lab 3 Complete — Secure Azure Storage with SAS Tokens

You’ve now:

• Built an Azure Storage Account from scratch

• Created a private blob container

• Uploaded and verified data access

• Generated time-limited SAS tokens for secure sharing

• Learned how to revoke access instantly by rotating keys

These are core AZ-104 administrator skills — you can now explain and demonstrate how Azure protects data at rest and in transit.

This directly maps to AZ-104 exam objectives under “Manage Virtual Networking.”

Lab Objectives

• Create and configure Azure VNets and subnets

• Apply NSGs for subnet-level security

• Connect VNets using peering

• Use Azure Bastion for secure, no-public-IP access

What You’ll Need

• Active Azure subscription

• RDP client or web Bastion access

• Your public IP (for temporary RDP rule)

• Enough credit (free tier is fine if you delete resources afterward)

Step 1 – Create a Resource Group

Goal: keep all lab resources organized and easy to delete later.

Step 1.1

In the Azure Portal search bar, type Resource groups and select it.

Step 1.2

Click + Create.

Step 1.3

• Subscription: your default

• Resource group name: rg-lab2-network

• Region: choose your closest (e.g., East US)

• Click Review + Create → Create.

Step 2 – Create Virtual Networks and Subnets

Goal: establish one “hub” (primary) and one “spoke” VNet.

Step 2.1 – Create Primary VNet

1. In the portal, search Virtual networks → + Create.

2. Basics tab:

   • Resource group: rg-lab2-network

   • Name: vnet-lab2-primary

   • Region: East US

3. IP Addresses tab:

   • Address space: 10.1.0.0/16

4. Add two subnets:

   • subnet-app → 10.1.1.0/24

   • subnet-db → 10.1.2.0/24

5. Click Review + Create → Create.

Step 2.2 – Create Spoke VNet

1. + Create → Virtual Network again.

2. Resource group: rg-lab2-network

3. Name: vnet-lab2-spoke

4. Address space: 10.2.0.0/16

5. Add subnet: subnet-spoke → 10.2.1.0/24

6. Create.

Step 3 – Deploy the Virtual Machines

Goal: create three small servers to test routing and security.

Step 3.1 – Create vm-app-1

1. In the Portal, search Virtual machines → + Create → Azure virtual machine.

2. Basics:

   • RG: rg-lab2-network

   • Name: vm-app-1

   • Region: East US

   • Image: Windows Server 2025 Datacenter

   • Size: Standard D2s

   • Username: itadmin

   • Password: (secure)

3. Networking tab:

   • VNet: vnet-lab2-primary

   • Subnet: subnet-app

   • Public IP: Enabled

   • NIC NSG: Basic → RDP (3389)

4. Review + Create → Create.

Step 3.2 – Create vm-db-1

Same process but choose Subnet: subnet-db.

Step 3.3 – Create vm-spoke-1

• VNet: vnet-lab2-spoke

• Subnet: subnet-spoke

• Public IP: Enabled

• Size: small

Step 4 – Install IIS on vm-app-1

Goal: host a test web page.

Step 4.1

RDP into vm-app-1 using its public IP.

Step 4.2

Open Server Manager → Add roles and features → Web Server (IIS) → Install.

Step 4.3

After it finishes, open a browser on the VM → visit http://localhost.
You should see the IIS splash page.

Step 4.4 (Optional)

Edit iistart.htm and type “Hello from vm-app-1”

Step 5 – Configure Network Security Groups (NSGs)

Goal: allow only needed traffic between subnets.

Step 5.1 – Create NSG for App Subnet

1. In the portal, search Network security groups → + Create.

2. Name: nsg-app-lab2, RG: rg-lab2-network, Region: East US → Create.

3. Open nsg-app-lab2 → Inbound security rules → + Add.

   • Allow-HTTP-From-Internet:

     • Source: Any | Port: 80 | Protocol: TCP | Action: Allow | Priority: 200

   • Allow-RDP-From-Home:

     • Source: Your home IP/32 | Port: 3389 | Action: Allow | Priority: 210

4. Under Subnets, click Associate → vnet-lab2-primary → subnet-app.

Step 5.2 – Create NSG for DB Subnet

1. Create nsg-db-lab2 similarly.

2. Add inbound rules:

   • Allow-App-to-DB-1433: Source 10.1.1.0/24, Port 1433, Allow, Priority 200.

   • Allow-App-to-DB-RDP: Source 10.1.1.0/24, Port 3389, Allow, Priority 210.

3. Associate to subnet-db.

Step 5.3 – Test NSGs

• From your PC → RDP to vm-app-1 - allowed

• From your PC → RDP to vm-db-1 - not allowed

• From inside vm-app-1 → RDP to vm-db-1 - allowed

Step 6 – Peer the VNets

Goal: enable private routing between primary and spoke VNets.

Step 6.1

Open vnet-lab2-primary → Peerings → + Add.

• Peering name: primary-to-spoke

• Remote VNet: vnet-lab2-spoke

• Allow traffic both ways → Add.

Step 6.2

Check that the reverse peering appears automatically; if not, add it manually on vnet-lab2-spoke.

Step 6.3 – Test Connectivity

RDP into vm-spoke-1 → open Command Prompt:

ping 10.1.1.x (private IP of vm-app-1)

Step 7 – Deploy Azure Bastion (Zero Public RDP)

Goal: secure management without exposing public IPs.

Step 7.1

Open vnet-lab2-primary → Subnets → + Subnet

• Name: AzureBastionSubnet

• Address prefix: 10.1.3.0/26 → Save

Step 7.2

Search Bastions → + Create

• Name: bastion-lab2

• RG: rg-lab2-network

• VNet: vnet-lab2-primary

• Public IP: new static IP

• Create

Step 7.3

Once deployed:

• Go to vm-app-1 → Connect → Bastion → Use Bastion.

• Enter credentials and connect through browser.

• From inside, RDP to vm-db-1 using its private IP.

  You’re now securely managing both VMs without public exposure.

Step 7.4

Remove the public IPs from all three VMs:

• VM → Networking → NIC → IP configurations → dissociate public IP.

Step 8– Validation and Cleanup

Cleanup:

• Delete optional LB, public IPs, Bastion if done testing.

• Or delete rg-lab2-network entirely to avoid charges.

You’ve now:

• Built hub-and-spoke VNets with unique address spaces.

• Secured subnets with NSGs.

• Connected networks using peering.

• Replaced open RDP with Azure Bastion.

Please reach out to me if you have any questions or need help with the lab. I’d be happy to hear from you!

In this first lab, I built a simple yet essential Azure environment — a Virtual Network (VNet) and a Virtual Machine (VM) — the basic foundation for everything else in cloud administration.

Lab Objective

The goal of this lab was to deploy a Windows Server 2022 virtual machine inside a secure virtual network using best practices like:

• Organizing resources with a Resource Group

• Creating a Virtual Network and Subnet

• Deploying a VM with secure access controls

• Configuring Network Security Groups (NSGs)

• Enabling monitoring and auto-shutdown

This type of setup is the backbone of most Azure workloads — from application servers to lab environments.

Step 1: Create a Resource Group

Resource Groups in Azure act as logical containers to organize and manage related resources.
I started by creating a new group called RG-Lab1-AZ104 in the East US region.

Azure Portal → Resource groups → + Create

• Name: RG-Lab1-AZ104

• Region: East US

Step 1.1: Add Tags for Organization and Cost Management

Before finishing the resource group setup, I added tags to help identify and manage my resources.

Tags in Azure are key-value pairs that make a big difference in real-world environments. They’re used for:

• Cost tracking — seeing how much each project or department spends

• Automation — applying policies or scripts based on tags

• Organization — grouping resources logically across regions and subscriptions

For this lab, I added these tags:

Adding tags even in a small lab like this helps build good habits early — Azure administrators rely heavily on tagging for cost analysis and lifecycle management.

Step 2: Create a Virtual Network (VNet) and Subnet

Next, I set up a private network for my virtual machine to live in.

Azure Portal → Virtual Networks → + Create

• Name: VNET-Lab1

• Address space: 10.0.0.0/16

• Subnet: Subnet-VMs (10.0.1.0/24)

This subnet acts like a private section of the network where the VM can securely communicate.

Step 3: Deploy a Windows Server 2022 VM

With the network in place, I created a virtual machine inside that subnet.

Azure Portal → Virtual Machines → + Create

• Name: VM-Lab1-Server

• Image: Windows Server 2022 Datacenter (Gen2)

• Size: Standard_D2 (lowest allowed at the time for Windows Server 2022 testing)

• Username: azureuser

• Password: (*******************)

• Inbound ports: RDP (3389)

After validation, I clicked Create, and Azure began provisioning the VM.

🔌 Step 4: Connect to the VM

Once the deployment finished, I connected to the VM using Remote Desktop.

• From the VM overview page → Connect → RDP

• Downloaded the .rdp file and logged in using my credentials

Seeing the Windows Server desktop for the first time confirmed that the environment was working perfectly.

Step 5: Monitoring and Auto-Shutdown

While Azure Monitor VM Insights offers deeper performance tracking, I chose not to enable it for this lab to keep costs low and focus on foundational deployment skills. The default metrics provided by Azure — like CPU and disk usage — were sufficient for validating the VM’s health and connectivity.

• Auto-shutdown: Set for 7 PM daily

These features help simulate how administrators manage uptime and costs in real production environments.

Step 6: Cleanup

Once testing was complete, I cleaned up my environment to avoid extra charges:

az group delete --name RG-Lab1-AZ104 --no-wait --yes

Azure automatically removed every resource inside that resource group.

What I Learned

• How Azure resources are logically grouped and connected

• The purpose of VNets, subnets, and NSGs in secure networking

• How to provision, connect to, and manage a Windows Server VM

• Why cost management and monitoring are essential for administrators

This lab helped me connect the dots between core networking, resource management, and infrastructure deployment — all key areas of the AZ-104 exam.

Thanks for reading!
If you’re learning Azure too, follow along here on jmcnairtech.com — I’ll be posting new labs as I work toward the AZ-104 and my goal of becoming an Azure Administrator.

Introduction

In today’s hybrid work environment, businesses need more than just antivirus and VPNs—they need a scalable way to manage devices, enforce security policies, and streamline onboarding. That’s where Microsoft Intune comes in.

This post walks through a real-world lab scenario where Intune is used to meet core business requirements: securing endpoints, ensuring compliance, and automating device provisioning. Whether you're an IT admin or a job seeker building your portfolio, this guide shows how Intune translates business needs into technical solutions.

Scenario: The Business Requirements

Let’s imagine a mid-sized company with 150 employees, half of whom work remotely. Their IT goals include:

• Enforcing BitLocker encryption and strong password policies

• Ensuring devices are compliant before accessing Microsoft 365

• Automating new hire onboarding with Autopilot

• Monitoring device health and compliance status

Lab Walkthrough: Building the Solution in Intune

1. Compliance Policies

We start by creating a compliance policy that enforces:

• BitLocker encryption

  

• Minimum password length (8+ characters)

  

• Firewall enabled

• 

  Tip: Devices that fail any of these checks will show as “non-compliant,” which can be used to trigger Conditional Access blocks.

  2. Configuration Profiles

  Next, we deploy settings that improve user experience and security:

  • OneDrive auto sign-in for file backup

    

  • Windows Update ring to enforce patching

    

  • Windows Defender settings

3. Autopilot Deployment

Using a test VM, we register the hardware hash and assign an Autopilot profile:

• Company branding (logo + background)

• Pre-installed apps (Office, Teams)

• Automatic enrollment into Intune

As you can see the device has been added to the Intune Tenant for Autopilot enrollment and device is waiting for the chosen 365 Apps to install.

Summary: Translating Business Needs into Intune Solutions

This hands-on lab demonstrates how Microsoft Intune can solve real business challenges in a hybrid work environment. By enforcing compliance policies, deploying secure configuration profiles, and automating onboarding with Autopilot, IT teams can:

• ✅ Protect endpoints with BitLocker and password policies

• ✅ Ensure only compliant devices access Microsoft 365

• ✅ Streamline new hire setup with branded, pre-configured devices

• ✅ Monitor device health and enforce patching across the fleet

Whether you're optimizing your current environment or building a portfolio project, Intune offers scalable, cloud-native tools that align technical execution with business goals.

You’d think that Intune auto-enrollment would be predictable. This week, I built a fresh Windows 11 VM, applied the usual GPO settings, and expected it to slide right into compliance. But instead of enrolling, the device just sat there. No obvious errors, no status change… just refusing to cooperate.

After retracing my steps, testing registry tweaks, and trying almost everything else I could possibly find on the subject, I ended up enabling Windows Hello for Business — mostly out of curiosity. That’s when everything clicked. Suddenly, the device enrolled, compliance kicked in, and voilà — the “Access work or school” > “Info” sync option finally showed up.

This post documents that journey — not just as a troubleshooting log, but as a case study in how so-called “optional” features like WHfB can unexpectedly become critical in your lab environment. If you're running into strange auto-enrollment issues, this might be the clue you didn’t know you needed.

Lab Setup

• Platform: Windows 11 VM hosted on Hyper-V

• Domain Context: Joined to on-prem AD with Azure AD Connect syncing; hybrid join confirmed

• Policy Applied: Group Policy enabling automatic MDM enrollment via user credentials

• Expectation: Device should enroll in Intune after login

• Outcome: No enrollment. No sync button. No errors.

Troubleshooting Steps

Before WHfB entered the picture, I tried nearly everything:

• Verified hybrid join status via dsregcmd /status

• Confirmed GPOs were applying correctly

• Cleared MDM-related registry keys under HKLM\SOFTWARE\Microsoft\Enrollments

  

• Rebooted multiple times

• Ran mdmdiagnosticstool.exe -area Enrollment -cab and reviewed the logs

Still, the device wouldn’t enroll.

Windows Hello for Business: The Unexpected Fix

Eventually, I enabled Windows Hello for Business — just a basic PIN setup. I didn’t expect much. But immediately after configuring WHfB:

• The device enrolled in Intune

• Compliance policies began applying

• The long-lost “Info” button in the “Access work or school” settings appeared

Something in the token or credential flow had changed.

Why WHfB Might Matter More Than You Think

WHfB is typically framed as a passwordless security feature. But in hybrid or cloud-joined setups, it can affect the authentication context used for token generation — a critical piece of MDM enrollment.

Without WHfB, the device may lack sufficient context to initiate enrollment. Microsoft’s documentation doesn’t make this dependency clear, but in practice, enabling WHfB can resolve silent failures in scenarios like mine.

Helpful Commands and Registry Paths

Commands to Run

• dsregcmd /status – Confirms Azure AD join and token status

• mdmdiagnosticstool.exe -area Enrollment -cab – Generates diagnostic output

Registry Locations to Check

• HKLM\SOFTWARE\Microsoft\Enrollments

• HKLM\SOFTWARE\Microsoft\PolicyManager\current\device

GPO to Review

• Policy: Enable automatic MDM enrollment using user credentials

• Confirm it's applied under the correct scope and timing

Conclusion

This experience was a reminder of why lab testing matters — not every deployment scenario goes exactly the way you would hope. WHfB, while technically optional, played a key role in enabling successful auto-enrollment in this Hyper-V VM. If you’re seeing similar issues, try setting up Windows Hello — it may be the silent key that unlocks your workflow.

And if you've encountered other unexpected Intune or hybrid join behaviors, share them — the more we surface these edge cases, the better we can guide others through the maze.

Whether you’re working helpdesk, managing a fleet of machines, or just solving your cousin’s gaming Wi-Fi woes—this trick might be the quickest fix in your toolbox.

How to Flush DNS Cache in Windows

1. Press Win + X and select Command Prompt (Admin)

2. Type the following and press Enter: ipconfig /flushdns

3. You’ll get a confirmation: “Successfully flushed the DNS Resolver Cache.”

That’s it—no need to reboot your computer or mess with complicated registry tweaks. This command instantly clears outdated DNS entries, letting Windows re-query servers and fetch the most current domain information.

Why This Fix Works

Windows keeps a local copy of domain-to-IP address translations—kind of like a shortcut list to get you where you’re going faster online. But over time, those shortcuts can get outdated, like using an old GPS that sends you to a restaurant that’s already closed or moved.

Flushing the DNS cache is like updating your map. It clears out stale directions so your computer can get accurate guidance from DNS servers—avoiding detours, delays, or those dreaded “site not found” errors.

Real-World Scenario

A client’s payroll app kept showing “server not reachable.” Ping tests worked, the browser didn’t reach the page. Flushed the DNS cache. Boom—problem solved.

Follow it up with a browser cache clear, and you’ve just saved 20 minutes of unnecessary troubleshooting. -- Even after flushing DNS sends your machine to the correct server, your browser might still load outdated visuals like an old login page or broken styles. That’s because it cached things like HTML, images, and JavaScript from a previous visit and didn't bother asking the new server for fresh files. Clearing the browser cache ensures you’re not seeing remnants from the old server—so what shows up on screen actually reflects what’s hosted now.

Try It Yourself

Next time you're faced with a mysterious “site won’t load” error, don't dive straight into deep diagnostics. Start simple: flush the DNS, clear the browser cache, and reload with fresh eyes.

Skip either step, and you might be solving half the problem. Knock them both out and move on to the next trouble ticket. That's how pros troubleshoot.

Step One: Verify Mic Settings in Windows - Start with the basics. I opened Windows Sound settings to ensure the headset was the default input device. Sometimes, Windows switches to an internal mic without warning.

Pro tip: If the wrong device is set as default, Five9 may still "look" like it's using the headset but actually route audio through something else.

Step Two: Set the Mic in Five9 Settings - Inside the Five9 softphone (web-based), I clicked the gear icon and selected the correct headset under Audio Device settings. In many cases, leaving this set to "Default" causes Five9 to pick the wrong mic.

Lesson learned: Always manually select the exact headset—"Default" is not always reliable.

Step Three: Disable Exclusive Mode in Windows This was the fix that finally worked. I went to:

• Sound Settings

• Right clicked the headset > Properties

• Switched to the Advanced tab

• Unchecked "Allow applications to take exclusive control of this device"

After applying this change, the user's audio was instantly clear.

Why it works: Exclusive mode lets one app hijack the audio channel. If Five9 and Windows clash here, it can muffle or distort sound.

Other Fixes I Tried (That Didn't Work but Might Help You):

• Plugging the headset directly into the laptop instead of the docking station

• Clearing the Chrome browser cache and restarting Five9

While these didn’t solve it for this case, they’re good steps to include in your troubleshooting process.

Takeaway for IT Pros: Don’t overlook audio settings that seem small. In softphone apps like Five9, fixing muffled audio might come down to a single Windows checkbox. Bookmark this one—it saved my user, and it might save yours too.

Why Build a Simple Active Directory Lab?

If you're serious about a career in IT support or system administration, building a home lab is one of the best investments of your time. It gives you hands-on experience with real-world tools like Active Directory — the same tech used by many companies to manage users, devices, and policies.

In this guide, I’ll show you how to join a Windows 11 computer to your own AD domain — a core task every IT pro should know how to do. It’s quick, straightforward, and sets the foundation for more advanced lab scenarios.

What You’ll Need

• A Windows Server 2022 VM with Active Directory Domain Services (AD DS) installed and configured

• A Windows 11 VM

• Both VMs on the same virtual network (via VirtualBox, Hyper-V, VMware, etc.)

• Your domain name (e.g., mcnairtech.local)

• Admin credentials for your domain

Step 1: Point the Windows 11 Client to the Correct DNS Server

Active Directory relies heavily on DNS, so make sure your Windows 11 VM is using your domain controller’s IP as its DNS server.

1. Go to Settings > Network & Internet > Ethernet (or Wi-Fi) > Edit IP assignment

   

2. Change the DNS settings to Manual

   

3. Set the Preferred DNS to your DC’s IP address (e.g., 192.168.50.254)

4. Click Save

Pro Tip: If your DNS is misconfigured, the domain join will fail — even if everything else is perfect. This is because Active Directory heavily relies on DNS to locate domain controllers and other essential services within the network. When your Windows 11 client tries to join the domain, it queries DNS for the domain controller's address. If the DNS server is not set to your domain controller’s IP or cannot resolve the domain name, your client won’t be able to find the controller, causing the domain join process to fail.

Step 2: Join the Windows 11 Computer to the Domain

1. Open Settings > System > About

2. 

2. Scroll down and click Domain or Workgroup

3. Select Join this device to a local Active Directory domain

4. Enter your domain name (e.g., mcnairtech.local)

5. Provide domain admin credentials (like Administrator)

6. Reboot when prompted

   After restarting, your computer will be part of the domain.

Step 3: Test the Domain Join

1. On the Windows 11 login screen, choose Other user

2. Enter the domain and username, such as:
   MCNAIRTECH\Administrator

3. Once logged in, open Command Prompt and run: whoami

4. You can also test by running:

   gpupdate /force

If Group Policy updates successfully, you're connected.

What’s Next?

• Create a new user in Active Directory and log in from the Windows 11 VM

• Apply a basic Group Policy (like a custom desktop background or password policy)

• Set up DHCP and DNS roles on the domain controller

• Build toward a multi-site or multi-domain environment

The more you experiment, the more confident you’ll get with AD — and the closer you are to becoming job-ready.

Wrapping Up

Joining your Windows 11 VM to an Active Directory domain might seem small, but it’s a key step in getting comfortable with Windows networking and domain management. Once you’ve done this, you’ll have a solid foundation to start exploring more complex AD features in your lab.

If you found this helpful, bookmark the site or share it with someone else working on their IT skills. More easy-to-follow lab guides are coming soon!

1. Windows + D – Show Desktop

Minimize everything and jump straight to your desktop.

2. Windows + S – Open Search

Quickly find apps, files, or settings with one shortcut.

3. Ctrl + Shift + Esc – Open Task Manager

Skip Ctrl + Alt + Delete — this opens Task Manager directly.

4. Windows + L – Lock Your PC

Great for when you step away and want to secure your screen fast.

5. Windows + E – Open File Explorer

Instant access to your files and folders without using the mouse.

6. Ctrl + Z / Ctrl + Y – Undo / Redo

Whether you're typing or managing files, this one will save you when you make mistakes.

7. Windows + Left / Right Arrow – Snap Windows

Snap apps to each side of the screen for better multitasking.

8. Ctrl + T – Open New Browser Tab

No need to click — just pop open a fresh tab instantly.

9. Windows + V – Clipboard History

Paste beyond your last copy. Just enable clipboard history in settings first.

10. Ctrl + Shift + N – Create a New Folder

Quickly make new folders in File Explorer or on your desktop.

These shortcuts save me time every single day — and once you get used to them, you'll fly through your workflow. Got a favorite shortcut I missed? Drop it in the comments below or share it with me on LinkedIn.

Want more tips like this? Subscribe to the blog or check out the YouTube video post!

Everything looked great — the policy was linked, no errors in Group Policy Management Console, and the correct OU was targeted. Still, the drive wouldn’t show up.

Here’s how I troubleshooted it in my lab and what actually fixed the issue.

1. Check the GPO Scope and OU Placement

If the drive mapping is set under User Configuration, make sure the user account is in the correct OU where the GPO is linked.

Tip: OU structure matters — it’s easy to overlook which container your user is actually in.

2. Verify Security Filtering and Delegation

In Group Policy Management:

• Go to the GPO → Scope tab

• Make sure the right users or groups are listed under Security Filtering

• Under Delegation, ensure they have both:

  • Read

  • Apply group policy

3. Use gpresult or rsop.msc to Confirm Application

Run the following command on the user’s machine to see if the GPO is even applying:

If it’s missing, the policy isn’t reaching the user at all — often due to filtering or OU issues.

gpresult /r /scope:user

4. Switch GPO Action from “Update” to “Replace”

By default, drive mappings use the Update action.

With “Update,” the GPO will only act if it detects a change in the mapping—for example, if the drive letter, path, or label has been altered. But if a user’s session has residual mappings from a previous logon or a policy hiccup prevents the drive from showing up, “Update” won’t intervene. It assumes all is well.

In my case, switching to Replace ensured the drive was re-created at every logon, which solved the issue.

5. Double-Check NTFS and Share Permissions

Even with a perfect GPO, the drive won’t appear if users don’t have permission to access the folder.

Check both:

• Share permissions (right-click → Sharing → Advanced Sharing → Permissions)

• NTFS permissions (right-click → Properties → Security tab)

Make sure the target group has at least Read on both levels.

What Worked for Me

In my lab, the issue turned out to be a combination of:

• GPO not scoped correctly to the user's OU

• Incorrect NTFS permissions on the shared folder

• GPO action needing to be switched to “Replace”

Once I adjusted all three, the drive showed up consistently at logon.

Final Thoughts

Mapped drive issues seem simple — until they aren’t. I always recommend using gpresult, testing with a clean user account, and reviewing both OU placement and folder permissions as your first steps.

Let me know if you’ve run into this one too — it’s one of the most common (and frustrating) help desk tickets out there.

In this lab, we’ll walk through how to deploy a desktop wallpaper to Windows 11 clients using a centrally stored image in the SYSVOL folder.

Why Use SYSVOL for Wallpaper?

SYSVOL is a shared folder on your domain controllers that replicates across all DCs in the domain. Storing your wallpaper here means:

• Centralized management — one place to update the image

• Automatic replication across all DCs

• Easy access via UNC path for clients

Lab Setup

• Domain Controller: Windows Server 2022 - DC01

• Client Machine: Windows 11 (domain joined) -win11

• Domain: mcnairtech.local

• Test OU: TestOU with test computer inside

• Wallpaper file: default.png (or any .jpg/.png you prefer)

Step 1: Place Your Wallpaper in SYSVOL

1. On your DC, navigate to:
   C:\Windows\SYSVOL\sysvol\mcnairtech.local\scripts

2. Create a folder named Wallpaper.

3. Copy your wallpaper file (default.png) into that folder.

Your image should now be available at:
\\mcnairtech.local\SYSVOL\mcnairtech.local\scripts\Wallpaper\default.png

Step 2: Create a GPO to Set the Wallpaper

1. Open Group Policy Management on your DC.

2. Right-click your test OU (TestOU) and choose Create a GPO in this domain, and Link it here...

3. Name the new GPO: Set Desktop Wallpaper

Step 3: Configure the GPO

1. Right-click the new GPO and click Edit.

   

2. Navigate to:
   User Configuration > Policies > Administrative Templates > Desktop > Desktop

   

3. Double-click Desktop Wallpaper.

4. Select Enabled.

5. In the Wallpaper Name field, enter:
   \\mcnairtech.local\SYSVOL\mcnairtech.local\scripts\Wallpaper\default.png

6. Choose your Wallpaper Style (Fill, Fit, Stretch, etc.).

7. Click OK.

Step 4: Test the Wallpaper Deployment

1. Ensure your test computer is in the TestOU.

2. On the Windows 11 client, run:

    gpupdate /force
   

3. Sign out and back in (or reboot).

You should now see your custom wallpaper applied!

Troubleshooting Tips

• Make sure the user logging in is in the OU where the GPO is linked.

• Confirm clients can access the UNC path to the wallpaper.

• Check spelling and path accuracy in the GPO setting.

• If the wallpaper doesn’t apply, try rebooting the client.

Wrapping Up

Deploying a desktop wallpaper via Group Policy is a simple but powerful way to get comfortable with Active Directory GPOs and SYSVOL shares. It’s practical for branding, reminders, or just a better user experience in your organization.

Want help customizing this lab or turning it into a full tutorial with screenshots? Let me know!

Why This Lab?

This week I wanted to document a small but useful task I set up in my home Active Directory lab: using Group Policy to map a network drive for a specific group of users.

It's one of those things that feels simple, but in a real job setting, this kind of automation cuts down on support tickets and keeps users from constantly asking, “Where’s that shared folder again?”

What I Needed

• A Windows Server with AD DS and Group Policy Management Console

• A Windows 11 VM joined to the domain

• A test OU with a few dummy users

• A shared folder on the domain controller

Step 1 – Set Up the Shared Folder

On my DC, I created a folder at C:\SharedFolder. Right clicked it, went to Properties → Sharing → Advanced Sharing, and shared it as “Shared Folder.”

In Permissions, I gave access to Domain Users just for testing. (In production, I'd scope this to a specific security group instead.)

Step 2 – Create and Link the GPO

I opened the Group Policy Management Console, found the OU I wanted (in this case, “Sales”), and created a new GPO called “Map Drive Z.”

Then I linked it to that OU so it would only affect users inside Sales.

Step 3 – Configure the Drive Map

In the GPO editor, I went to:
User Configuration → Preferences → Windows Settings → Drive Maps

Right-clicked → New → Mapped Drive

Settings:

• Location: \DC01\Shared Folder

• Drive Letter: Z:

• Action: Update

• Gave it a label of “Company Share”

Saved and closed the editor

.

Step 4 – Testing

On my Windows 11 VM (joined to the domain), I logged in as a test user from the Sales OU. After logging in, the Z: drive appeared in File Explorer, mapped to the shared folder on the server. If it doesn’t show up right away, running gpupdate /force helps, or just reboot.

A Few Notes

• You can also target drives by security group using item-level targeting

• Make sure your NTFS permissions on the folder itself match your share permissions, or users will see access denied errors even if the drive maps.

• Drive letter conflicts can be an issue if users already have something on Z:. Use an uncommon letter or set “Use first available” if needed.

Wrapping Up

This is a small task, but it’s something I’ve done many times in real environments, and it always saves headaches in the long run. If you're working on building a HomeLab or prepping for an IT role, it's worth practicing how to set this up.

Prerequisites

Before you begin, make sure you have the following:

• A Windows Server domain controller (e.g., mcnairtech.local)

• Active Directory and DHCP roles already installed

• A domain-joined client workstation for testing

Step 1: Configure Password and Lockout Policies

1. Open Group Policy Management Console (gpmc.msc)

   

2. Right-click your domain (mcnairtech.local) and choose Create a GPO in this domain and link it here. Name it something like:

   Domain Password Policy

   

3. Right-click the new GPO and select Edit

1. Navigate to:

   Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies

Under Password Policy, set:

• Minimum password length: 12 characters

• Password must meet complexity requirements: Enabled

• Enforce password history: 24 passwords remembered

Under Account Lockout Policy, set:

• Account lockout threshold: 5 invalid logon attempts

• Account lockout duration: 15 minutes

• Reset account lockout counter after: 15 minutes

5. Close the editor. Ensure the GPO is linked to the domain root.

Step 2: Force the Policy to Apply

Group Policy refreshes on a schedule, but you can apply it immediately:

1. Open Command Prompt as Administrator

2. Run: gpupdate /force

1. Restart your domain controller to ensure all settings apply

If you have a domain-joined client, restart that too.

Step 3: Create a Test User

1. Open Active Directory Users and Computers (dsa.msc)

2. Right-click the Users container or a test OU, then choose New > User

1. Create a user:

   • Full name: Test User

   • Username: testuser

   • Password: Try a weak one like pass123 (it should be rejected)

   • Use a valid password like McnairTech!2024 to proceed

Step 4: Test the Account Lockout Policy

1. On a domain-joined PC or the domain controller:

2. Try logging in as testuser with the wrong password 5 times

3. You should see a message:

   "The referenced account is currently locked out and may not be logged on to."

   

   Step 5: Verify the Lockout in Active Directory

   1. Open Active Directory Users and Computers

   2. Right-click the testuser account > Properties > Account tab

   3. You should see the checkbox for "Unlock account" unchecked

To unlock it manually:

• check the box and click OK

• Or wait for the configured lockout duration to expire

Optional: Verify Policy with GPResult

To confirm the policy applied successfully:

Run:

    gpresult /h report.html

Open report.html in a browser and scroll to Computer Settings > Account Policies.

Conclusion

With these steps, you’ve enforced and verified password complexity, length, and account lockout policies using Group Policy in Active Directory. This foundational task is essential in any secure Windows domain.

Stay tuned for more AD and GPO hands-on guides!

This weekend's exercise was focused on installing and configuring the DHCP (Dynamic Host Configuration Protocol) role on a Windows Server that's part of an Active Directory (AD) environment. DHCP is essential in network management because it automates the assignment of IP addresses to client machines on the network.

Lab Setup

• Host Machine: Windows 11 with Hyper-V enabled

  • Virtual Machines:

    • DC01: Windows Server 2022 (Domain Controller + DHCP Server)

    • WIN11: Windows 11 (Client)

  • Virtual Network: Private virtual switch (Hyper-V)

  • Tools Used: Server Manager, DHCP Management Console (dhcp.msc)

1. Open Server Manager > Add roles and features

2. Choose Role-based or feature-based installation

3. Select Destination Server

4. Select Server Role - DHCP Server > Add Features > Choose features

5. Confirm Installation Selections > select restart the destination server automatically if required

   

   6. Complete Post-deployment Configuration

Create new DHCP Scope

Select Tools > DCHP

In this example, the scope will be IPV4. Right click and choose new scope > Select scope name

Select scope range

Choose exclusion - Added Domain Controller to exclusion list

Select Scope Options

Add the Router (Default Gateway) and any other relevant options if needed.

Testing the Setup

After activating the scope, I powered on the Windows 11 client VM (WIN11), which is also connected to the same Private virtual switch.

• Ran ipconfig on the client and confirmed it received a 192.168.0.x address from the DHCP server.

• Verified the lease appeared under Address Leases in the DHCP Manager on DC01.

Confirmed inside of DCHP manager as well.

Lessons Learned

• DHCP does not require the client to be joined to the domain—just on the same network.

• A Private virtual switch in Hyper-V simulates a small, isolated network—perfect for AD labs.

• If you get an APIPA address (169.254.x.x), check the DHCP server’s authorization, firewall, and whether the client can reach the server at all.

If you’re dipping your toes into cybersecurity certifications, you’ve probably heard Security+ and CySA+ mentioned on many technology/learning platforms. But it’s not always clear which one fits YOUR background or personal goals. Are you just starting out in tech, or do you already have some on-the-job experience and want to specialize? In this post, I’ll break down the differences between these two popular CompTIA certifications, share the kinds of jobs and salaries you can expect, and give my take on which one might be right for you in 2025.

Getting to Know Security+ and CySA+

Security+ is the classic starting point for anyone who wants to jump into cybersecurity. It covers the basics — network security, common threats, risk management, and all those fundamentals that every security pro should know. Think of it as cybersecurity 101. It touches on a broad range of topics but doesn’t expect you to be an expert in any one area.

On the flip side, CySA+ (short for Cybersecurity Analyst) dives deeper into hands-on skills. It focuses on detecting threats, analyzing data to spot bad actors, and responding to incidents. This cert is designed for folks who already have some experience and want to move into roles like threat hunting or security operations.

What’s the Real Difference?

When Should You Pick Which?

If you’re just starting out, Security+ is a fantastic way to get your feet wet. It builds a solid foundation and is often required for entry-level security roles.

But if you’ve got some IT or security experience already and want to get serious about analyzing threats and responding in real time, CySA+ is the next logical step.

What Others in the Field Are Saying

I found some honest takes from people who’ve earned both certs:

“Security+ is like learning the rules of the game. CySA+ is actually playing it, reading the field, and making moves.” — Reddit user

“CySA+ made me feel like I was doing real work, not just studying concepts. It’s definitely harder but way more rewarding.” — Another Reddit contributor

A Helpful Video Walkthrough

If you prefer video learning, check out this clear, practical YouTube explanation breaking down the differences:

Heads up: While perspectives may vary, this video offers a clear and practical overview to help you understand the key differences.

📺 Security+ vs. CySA+: Which Cert Should YOU Choose?

Wrapping Up

Choosing between Security+ and CySA+ really boils down to where you are in your career and what you want to do next. Don’t stress — both are respected certifications that can open doors.

Start with Security+ if you need to build your foundation. Go for CySA+ when you’re ready to specialize and get hands-on with threat detection and response.

Remember, certifications are just one piece of the puzzle — keep learning, practicing, and gaining real-world experience.