Deploy a Secure Azure Virtual Desktop

Deploy Azure Virtual Desktop with NSG network segmentation and RBAC access control.

Introduction

30 Second Summary

When companies give employees remote access to virtual desktops, a password alone is not enough to keep things secure. The best setups use multiple layers of protection to control both who can connect and what network traffic is allowed to reach the system.

In this project, you will deploy an Azure Virtual Desktop environment secured with network segmentation and identity-based access control. Only authorized users will be able to see and connect to the desktop, and all unnecessary traffic will be blocked at the network layer.

What You'll Build

A production-style Azure Virtual Desktop deployment protected by Network Security Groups (NSGs) for network segmentation and Azure RBAC for user-level access control.

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

  • A segmented virtual network with NSG rules using Azure service tags to control AVD traffic.
  • A fully deployed Azure Virtual Desktop host pool with a Windows 11 session host joined to Entra ID.
  • An RBAC-based access model using security groups and the Desktop Virtualization User role to restrict who can connect.
  • Secret Mission: Create a Conditional Access policy that requires MFA for Azure Virtual Desktop connections.

Are there any prerequisites?

You need an active Azure subscription with Contributor and User Access Administrator roles. You also need a credit card to sign up for the free Microsoft 365 E3 trial (you will not be charged during the 30-day trial period).

On your Mac, you will use Windows App to connect to the virtual desktop. Step 1 walks you through licensing setup and everything else you need.

Set Up Licensing and Register the Resource Provider

Before you can deploy any Azure Virtual Desktop resources, Azure needs two things in place: a valid license that grants AVD access rights, and a registered resource provider that unlocks the AVD service in your subscription.

In this step, you will activate a free Microsoft 365 E3 trial (which bundles both the AVD license and Entra ID P1), register the resource provider, and confirm you have enough VM quota to spin up a session host later.

In this step, get ready to:
  • Activate a free M365 E3 trial and assign the license to your account.
  • Register the Microsoft.DesktopVirtualization resource provider in your Azure subscription.
  • Verify VM quota for the Standard_D4ds_v4 size in your chosen region.
Activate the Microsoft 365 E3 trial

The M365 E3 license gives you two things in one activation: the right to connect to Azure Virtual Desktop, and Entra ID P1 (which you will need for Conditional Access in the Secret Mission).

  • Open your browser and navigate to the Microsoft 365 trials page:
https://www.microsoft.com/en-us/microsoft-365/microsoft-365-trials
  • Scroll down to the Enterprise section and find the Microsoft 365 E3 (no Teams) plan.
  • Click Try for free.
  • Follow the sign-up wizard to enter your details and credit card information.

Will I be charged?

The trial is free for 30 days. After that, it auto-converts to a paid subscription at $35.44/user/month unless you cancel.

You will turn off recurring billing in the Before You Go section at the end of this project, so you will not be charged.

Once the trial is activated, you need to assign the license to your user account.

  • Navigate to the Microsoft 365 admin center at admin.microsoft.com.
  • In the left sidebar, click Users, then Active users.
  • Select your user account from the list.
  • In the right pane, click Licenses and Apps.
  • Expand the Licenses section and check the box for Microsoft 365 E3.
  • Click Save changes.

You should see a confirmation banner indicating the license was successfully assigned.

Don't see Microsoft 365 E3 in the license list?

It can take a few minutes for the trial to provision. Refresh the page and try again.

Make sure you completed the trial sign-up wizard fully (you should have received a confirmation email).

help me troubleshoot why my M365 E3 trial license is not showing in the admin center

Why M365 E3 instead of a standalone Entra ID trial?

The M365 E3 trial bundles both the AVD access license and Entra ID P1 in a single activation. This avoids needing two separate trials and ensures you can both connect to the desktop and use Conditional Access for the Secret Mission.

Register the Microsoft.DesktopVirtualization resource provider

Azure resource providers are services that supply specific resource types. Until you register the AVD resource provider, Azure does not know your subscription wants to use virtual desktop resources.

  • Sign in to the Azure portal at portal.azure.com.
  • In the top search bar, type Subscriptions and select it from the results.
  • Select the name of the subscription you want to use for this project.
  • In the left menu, click Resource providers.
  • In the search box, type Microsoft.DesktopVirtualization.
  • If the status shows NotRegistered, select the checkbox next to Microsoft.DesktopVirtualization, then click Register.
  • Wait for the status to change to Registered. This may take up to a minute.

What is a resource provider?

A resource provider is a service that makes Azure resource types available. For example, Microsoft.DesktopVirtualization unlocks host pools, workspaces, and application groups in your subscription.

Registering requires the Contributor or Owner role on the subscription.

Register button is greyed out?

This means your account does not have permission to register resource providers. You need at least Contributor role on the subscription.

Ask your subscription owner to assign you Contributor, or have them register the provider on your behalf.

help me get permission to register a resource provider in my Azure subscription

Verify your VM quota

Azure subscriptions have quota limits on how many vCPUs you can use per VM family in each region. You need to confirm you have enough quota for the Standard_D4ds_v4 size (4 vCPUs) before deploying your session host.

  • In the Azure portal, navigate back to your subscription.
  • In the left menu, click Usage + quotas.
  • In the filter bar, search for Standard Ddsv4 Family.
  • Check that the available quota shows at least 4 vCPUs in the region you plan to use.

What region should I pick?

Choose a region close to your physical location for the best latency. Popular choices include East US, West Europe, or Australia East. You will use this same region for all resources in this project.

✔️ I have at least 4 vCPUs available

You are good to go. Your subscription can handle the session host VM you will deploy in Step 3.

ⓧ My quota shows 0 or less than 4

You need to request a quota increase before continuing.

  • Click the pencil/edit icon next to the Standard Ddsv4 Family row.
  • Enter 4 (or higher) as the new quota limit.
  • Click Submit.
  • Wait for the request to be approved. Simple increases are usually approved within minutes.

help me request a VM quota increase in my Azure subscription

Your licensing is active, the resource provider is registered, and your VM quota is confirmed. Next up, you will build the segmented network that your session host will live inside.

Build the Segmented Network

Your licensing and resource provider are ready. Now you need a secure network foundation for your virtual desktop session hosts to live inside.

In this step, you will create a Virtual Network with a dedicated subnet, then lock it down using a Network Security Group. The NSG enforces a default-deny posture for inbound traffic and only allows the specific outbound traffic that Azure Virtual Desktop requires.

In this step, get ready to:
  • Create a resource group, Virtual Network, and subnet for AVD session hosts.
  • Create and configure a Network Security Group with inbound deny-all and targeted allow rules.
  • Configure outbound NSG rules using service tags to allow AVD control plane traffic.
Create the resource group and Virtual Network

A resource group is a logical container that holds all related Azure resources together. You will place your VNet, NSG, and later your session host VM all inside a single resource group for easy management and cleanup.

  • In the Azure portal search box at the top, type Resource groups and select Resource groups from the search results.
  • Click + Create.
  • Select your Azure subscription.
  • Enter rg-avd-secure in the Resource group field.
  • Select your preferred Azure region (use the same region throughout this project).
  • Click Review + create, then click Create.

Now create the Virtual Network with a dedicated AVD subnet.

  • In the portal search box, type Virtual networks and select Virtual networks from the results.
  • Click + Create.
  • On the Basics tab, select your subscription.
  • Select rg-avd-secure as the resource group.
  • Enter a name for your VNet (for example, vnet-avd-secure).
  • Select the same region you chose for your resource group.
  • Click Next to proceed through the Security tab (leave defaults).
  • Click Next to reach the IP Addresses tab.
  • Set the IPv4 address space to 10.0.0.0/16.
  • In the Subnets section, select the default subnet to edit it.
  • Change the subnet name to snet-avd-hosts.
  • Set the starting address to 10.0.1.0 and the subnet size to /24 (256 addresses).
  • Click Save to confirm the subnet settings.
  • Click Review + create, then click Create.

Why a dedicated subnet for AVD?

Placing AVD session hosts in their own subnet allows you to apply NSG rules specifically to AVD traffic without affecting other resources. This is the foundation of network segmentation. Each segment gets its own security policy.

You should see a deployment confirmation showing your VNet is created with the snet-avd-hosts subnet inside it.

VNet creation failed?

Ensure the subnet address range (10.0.1.0/24) falls within your VNet address space (10.0.0.0/16). If you see an overlap error, delete any pre-existing default subnet and recreate it with the correct range.

Help me troubleshoot my VNet creation error in Azure.

Create the NSG and configure inbound rules

A Network Security Group acts as a virtual firewall for your subnet. You will create one that blocks all inbound traffic by default, then add specific allow rules only for what AVD needs internally.

  • In the portal search box, type Network security groups and select Network security groups from the results.
  • Click + Create.
  • Select your subscription and choose rg-avd-secure as the resource group.
  • Enter nsg-avd-hosts as the name.
  • Select the same region as your VNet.
  • Click Review + create, then click Create.

Now associate the NSG with your AVD subnet.

  • Open the nsg-avd-hosts resource you just created.
  • In the left menu under Settings, select Subnets.
  • Click + Associate.
  • Select your VNet for Virtual network.
  • Select snet-avd-hosts for Subnet.
  • Click OK.

Next, add the inbound security rules. You will create an explicit deny-all rule at the highest custom priority number, then add allow rules at lower priority numbers (which means higher priority) for internal VNet and load balancer traffic.

How do NSG rule priorities work?

NSG rules are evaluated from lowest priority number to highest. A rule at priority 100 is checked before a rule at priority 4096. The first matching rule wins and stops further evaluation.

Custom rules can use priorities between 100 and 4096. Azure has built-in default rules at priorities 65000+ that you cannot delete. Your custom deny rule at 4096 fires before those defaults.

  • In the left menu of your NSG, select Inbound security rules under Settings.
  • Click + Add to create the first rule.

Create the Allow VirtualNetwork inbound rule with these settings:

  • Set Source to Service Tag and select VirtualNetwork.
  • Set Source port ranges to *.
  • Set Destination to Any.
  • Set Destination port ranges to *.
  • Set Protocol to Any.
  • Set Action to Allow.
  • Set Priority to 100.
  • Enter AllowVNetInbound as the name.
  • Click Add.

Create the Allow AzureLoadBalancer inbound rule:

  • Click + Add again.
  • Set Source to Service Tag and select AzureLoadBalancer.
  • Set Source port ranges to *, Destination to Any, Destination port ranges to *.
  • Set Protocol to Any and Action to Allow.
  • Set Priority to 110.
  • Enter AllowAzureLoadBalancerInbound as the name.
  • Click Add.

Finally, create the DenyAllInbound rule:

  • Click + Add again.
  • Set Source to Any, Destination to Any.
  • Set Destination port ranges to * and Protocol to Any.
  • Set Action to Deny.
  • Set Priority to 4096.
  • Enter DenyAllInbound as the name.
  • Click Add.

Why these three inbound rules?

Azure Virtual Desktop uses Reverse Connect. Session hosts initiate outbound connections to the AVD service. No inbound ports from the internet need to be open for user connections.

The VirtualNetwork and AzureLoadBalancer allows are needed for internal Azure infrastructure communication (health probes, DNS, internal routing). The DenyAllInbound at priority 4096 blocks everything else before Azure's built-in default allows at priority 65000 can fire.

You should now see three custom inbound rules listed in your NSG.

Configure outbound NSG rules for AVD traffic

Session hosts need to reach the AVD control plane and authenticate with Microsoft Entra ID. Azure provides service tags that represent groups of IP addresses for specific Azure services. You will use these tags to create precise outbound allow rules.

  • In the left menu of your NSG, select Outbound security rules under Settings.
  • Click + Add to create the first outbound rule.

Create the Allow WindowsVirtualDesktop TCP 443 rule:

  • Set Source to Any.
  • Set Destination to Service Tag and select WindowsVirtualDesktop.
  • Set Destination port ranges to 443.
  • Set Protocol to TCP and Action to Allow.
  • Set Priority to 100.
  • Enter AllowAVDOutboundTCP as the name.
  • Click Add.

Create the Allow WindowsVirtualDesktop UDP 3478 rule:

  • Click + Add again.
  • Set Source to Any, Destination to Service Tag, select WindowsVirtualDesktop.
  • Set Destination port ranges to 3478.
  • Set Protocol to UDP and Action to Allow.
  • Set Priority to 110.
  • Enter AllowAVDOutboundUDP as the name.
  • Click Add.

Create the Allow AzureActiveDirectory TCP 443 rule:

  • Click + Add again.
  • Set Source to Any, Destination to Service Tag, select AzureActiveDirectory.
  • Set Destination port ranges to 443.
  • Set Protocol to TCP and Action to Allow.
  • Set Priority to 120.
  • Enter AllowAADOutbound as the name.
  • Click Add.

Finally, create the Deny Internet outbound rule:

  • Click + Add one more time.
  • Set Source to Any, Destination to Service Tag, select Internet.
  • Set Destination port ranges to * and Protocol to Any.
  • Set Action to Deny.
  • Set Priority to 4096.
  • Enter DenyInternetOutbound as the name.
  • Click Add.

What do these outbound rules accomplish?

The WindowsVirtualDesktop service tag covers the IP ranges for the AVD control plane. TCP 443 handles the primary session broker communication. UDP 3478 supports RDP Shortpath for lower-latency connections.

The AzureActiveDirectory tag allows session hosts to authenticate users. The deny Internet rule at priority 4096 blocks general outbound internet access that is not already matched by the service tag allow rules above it.

Why NSGs instead of Azure Firewall?

Azure Firewall adds approximately $1.25/hour in cost and supports FQDN-based filtering. For this learning project, NSGs are free, teach the same segmentation concepts, and are the customer's responsibility per the AVD security baseline. NSGs filter by IP and service tag only, which covers the AVD requirements.

You should now see four custom outbound rules listed in your NSG. Verify the priorities and service tags match what you configured.

Service tag not appearing in the dropdown?

Make sure you selected Service Tag from the Destination dropdown before searching for the tag name. If you leave it set to Any or IP Addresses, no service tag search will appear.

Help me find the WindowsVirtualDesktop service tag in my NSG rule configuration.

Your network is now segmented and locked down. Next up, you will deploy the Azure Virtual Desktop environment inside this protected subnet.

Deploy the Azure Virtual Desktop Environment

Your network is locked down and ready to host virtual desktops. Now it is time to deploy the actual Azure Virtual Desktop environment that will live inside your secured subnet.

AVD has several components that work together. A host pool is a collection of virtual machines that serve desktops to users. A workspace is what end users see when they open their remote desktop client. An application group connects the host pool to the workspace so users can access their desktops.

In this step, get ready to:
  • Create a pooled host pool with breadth-first load balancing.
  • Deploy a session host VM into your secured subnet.
  • Create a workspace and register your application group to it.
Create the host pool

The host pool defines how your virtual desktops are organized and how sessions are distributed across VMs. A pooled host pool shares VMs among multiple users, which is ideal for task workers and learning environments.

  • In the Azure portal search bar at the top, type Azure Virtual Desktop and select it from the results.
  • In the left sidebar, click Host pools.
  • Click Create at the top of the page.

You are now on the Basics tab of the host pool creation wizard. Fill in the following settings:

  • Set Resource group to rg-avd-secure.
  • Enter a name for your host pool (e.g., hp-avd-secure).
  • Set Location to the same Azure region you used for your resource group.
  • Set Host pool type to Pooled.
  • Set Load balancing algorithm to Breadth-first.
  • Leave Max session limit at its default value.

What is breadth-first load balancing?

Breadth-first distributes new user sessions evenly across all available VMs in the pool. This prevents one VM from getting overloaded while others sit idle.

The alternative is depth-first, which fills one VM completely before moving to the next. Breadth-first is better for consistent user experience.

  • Do NOT click Review + create yet. Click Next: Virtual Machines at the bottom of the page.
Add a session host VM

A session host is the VM that actually runs the Windows desktop your users will connect to. You will place it inside your secured subnet so the NSG rules you created in the previous step protect it.

  • On the Virtual Machines tab, set Add virtual machines to Yes.
  • Set Resource group to rg-avd-secure.
  • Set Number of VMs to 1.

Next, configure the VM image and size:

  • For Image, click See all images and search for Windows 11 Enterprise multi-session. Select it.
  • For Virtual machine size, click See all sizes and search for Standard_D4ds_v4. Select it.

Why Windows 11 Enterprise multi-session?

Multi-session is a special Windows edition that allows multiple users to connect to the same VM simultaneously. This is what makes pooled host pools cost-effective compared to giving every user their own dedicated VM.

Now configure the network settings to place the VM inside your secured subnet:

  • Under Network and security, set Virtual network to the VNet you created in rg-avd-secure.
  • Set Subnet to snet-avd-hosts.

Configure how the VM joins your identity directory:

  • Under Domain to join, select Microsoft Entra ID.

Why join to Microsoft Entra ID?

Entra ID join means the VM authenticates users through your cloud identity provider. There is no need to set up a traditional Active Directory domain controller. This simplifies the architecture and aligns with Zero Trust principles.

Finally, set up the local administrator account for the VM:

  • Enter a Username for the local admin account (e.g., avdadmin).
  • Enter a strong Password and confirm it. Save this password somewhere safe.
  • Click Next: Workspace at the bottom of the page.

This VM takes a few minutes to deploy

You will not wait for the VM yet. You will finish the wizard first by configuring the workspace on the next tab. The actual deployment happens after you click Review + create.

Create the workspace and register the application group

A workspace is the container that end users interact with in their remote desktop client. When you register an application group to a workspace, the desktops in that group become visible to authorized users.

  • On the Workspace tab, set Register desktop app group to Yes.
  • Click Create new next to the workspace dropdown.
  • Enter ws-avd-secure as the workspace name.
  • Click OK to confirm the workspace.

What about the application group?

Azure automatically creates a Desktop Application Group when you create a host pool. You do not need to create it manually. By registering it to your workspace here, you are connecting the host pool's desktops to the workspace that users will subscribe to.

  • Click Review + create.
  • Review the summary. Confirm your host pool type is Pooled, the subnet is snet-avd-hosts, and the workspace is ws-avd-secure.
  • Click Create.

The deployment will take approximately 10-15 minutes. Azure is creating the VM, installing the AVD agent, joining it to Entra ID, and registering everything together.

  • Wait for the deployment to complete. You will see a Your deployment is complete message when it finishes.

Deployment failed?

If you see a quota error, your subscription does not have enough vCPU quota for Standard_D4ds_v4 in your chosen region. Go back to your subscription's Usage + quotas page and request an increase for the Standard_Ddsv4 family.

If you see a networking error, double-check that your NSG outbound rules allow the WindowsVirtualDesktop and AzureActiveDirectory service tags on TCP 443. The session host needs these to register with the AVD service.

help me troubleshoot my AVD deployment failure

  • After the deployment completes, navigate back to Azure Virtual Desktop in the portal search bar.
  • Click Host pools in the left sidebar. Verify your new host pool appears in the list.
  • Click your host pool name, then click Session hosts in the left sidebar. Verify your VM shows a status of Available.

What if my session host shows Unavailable?

It can take a few extra minutes after deployment for the AVD agent on the VM to fully register. Refresh the page after 2-3 minutes. If it remains unavailable, the NSG outbound rules may be blocking the VM from reaching the AVD control plane.

Your AVD environment is fully deployed. You have a host pool, a session host VM secured inside your network-segmented subnet, and a workspace ready for users. Next up, you will lock down exactly who can access this desktop using RBAC and security groups.

Lock Down User Access with RBAC

Your AVD infrastructure is deployed and network-segmented. But right now, anyone with an Entra ID account in your tenant could potentially connect to the desktop if they had the right client.

In this step, you will create security groups and use RBAC (Role-Based Access Control) to explicitly control who can see and connect to your virtual desktop. Only users in the allowed group will have access. Everyone else will see nothing when they open Windows App.

In this step, get ready to:
  • Create two Entra ID security groups for allowed and blocked users.
  • Assign the Desktop Virtualization User role to the allowed group.
  • Verify the blocked group has no access to the desktop.
Create security groups in Microsoft Entra ID

Security groups in Microsoft Entra ID let you bundle users together so you can grant or deny access at the group level instead of managing each user individually.

  • In the Azure portal, search for Microsoft Entra ID in the top search bar and select it.
  • In the left sidebar, click Groups.
  • Click New group at the top.
  • Set Group type to Security.
  • Enter AVD-Allowed-Users as the Group name.
  • Under Members, click No members selected.
  • Search for your primary user account (the one you are currently signed in with) and select it.
  • Click Select, then click Create.

You should see AVD-Allowed-Users appear in the groups list.

Now create the second group for blocked users.

  • Click New group again.
  • Set Group type to Security.
  • Enter AVD-Blocked-Users as the Group name.

Before adding a member to this group, you need a second test user to demonstrate the blocked access scenario.

  • Under Members, click No members selected.
  • If you already have a second user account in your Entra ID tenant, search for it and select it.
  • If you do not have a second user, click Cancel on the member selection and first create a new user (instructions follow below).
  • Click Select, then click Create to finalize the group.

Need to create a second test user?

In the Entra ID left sidebar, click Users, then New user > Create new user. Give the user a display name (e.g. Test Blocked User) and a user principal name. Note down the password.

No additional license is needed for this test user since the blocked user will never actually connect to a desktop. Once the user is created, go back to Groups, open AVD-Blocked-Users, click Members > Add members, and add the new test user.

Don't see your user in the member search?

Make sure you are searching by the user's display name or email address. New users can take a minute or two to appear in search results after creation. Try refreshing the page and searching again.

Help me find my user account in Entra ID member search

Assign the Desktop Virtualization User role

The Desktop Virtualization User role is the standard RBAC role that grants end-user access to AVD application groups. Without this role, users simply see no resources when they open Windows App.

  • In the Azure portal top search bar, search for Azure Virtual Desktop and select it.
  • In the left sidebar, click Application groups.
  • Click the Desktop Application Group that was created with your host pool.
  • In the left sidebar of the application group, click Access control (IAM).
  • Click Add, then select Add role assignment.
  • In the search box on the Role tab, type Desktop Virtualization User.
  • Select Desktop Virtualization User from the results and click Next.
  • On the Members tab, click Select members.
  • Search for AVD-Allowed-Users, select it, and click Select.
  • Click Review + assign, then click Review + assign again to confirm.

You should see a notification confirming the role assignment was added successfully.

Why assign at the application group scope?

The Desktop Virtualization User role is assigned at the application group level, not the host pool or subscription level. This gives you granular control over which desktops or apps each group of users can access.

In a production environment, you might have multiple application groups for different teams. Each team only gets access to the group that contains their applications.

Don't see Desktop Virtualization User in the role list?

Make sure you are on the Access control (IAM) blade of the Desktop Application Group, not the host pool or subscription. The role only appears when scoped to a resource that supports it.

Help me find the Desktop Virtualization User role in Azure

Verify the blocked group has no access

The Zero Trust principle here is default-deny. You did not assign any role to AVD-Blocked-Users, which means members of that group will have no access at all.

  • Stay on the Access control (IAM) blade of the Desktop Application Group.
  • Click the Role assignments tab.
  • Confirm that AVD-Allowed-Users appears with the Desktop Virtualization User role.
  • Confirm that AVD-Blocked-Users does NOT appear anywhere in the role assignments list.

If you see only your allowed group in the role assignments and no entry for the blocked group, your RBAC configuration is correct.

What happens to users without a role assignment?

Users who are not assigned the Desktop Virtualization User role on an application group will see no workspaces or desktops when they subscribe in Windows App. They are not denied with an error message. The resources are simply invisible to them.

Your access control model is now in place. Next up, you will connect to the virtual desktop from your Mac and verify that only authorized users can access it.

Test and Validate Access

You have built the entire security model. Network segmentation is in place with your NSG rules, and identity-based access control is configured through RBAC on the application group.

Now it is time to prove it actually works. You will connect as an authorized user, get denied as a blocked user, and inspect the NSG rules to confirm traffic is flowing through your configured security layer.

In this step, get ready to:
  • Connect to the virtual desktop as an authorized user via Windows App.
  • Verify that a blocked user cannot see any desktops or workspaces.
  • Review effective NSG rules on the session host VM's network interface.
Connect as an authorized user

Your primary user account is a member of AVD-Allowed-Users, which has the Desktop Virtualization User role on the application group. This means the workspace and desktop should be visible and connectable from Windows App.

  • Press Cmd+Space to open Spotlight search.
  • Type Windows App and press Enter to open it.
  • Sign in with your primary user account (the one you added to AVD-Allowed-Users).
  • Click the + button or look for an option to add a workspace.
  • Subscribe to the workspace by entering your account email or selecting the discovered workspace (ws-avd-secure).
  • Verify that a SessionDesktop icon appears under the workspace.
  • Double-click the SessionDesktop to connect.

After a brief loading period, you should see a full Windows 11 desktop appear inside the Windows App window.

What is happening behind the scenes?

Azure Virtual Desktop uses Reverse Connect. The session host initiates an outbound connection to the AVD service. No inbound ports are opened on your VM.

This is why your NSG focuses on outbound allow rules (WindowsVirtualDesktop and AzureActiveDirectory service tags) rather than inbound RDP rules.

Desktop not appearing or connection failing?

If no workspace appears after subscribing, wait 5-10 minutes. It can take time for the application group registration to propagate.

If the connection fails, confirm that the session host VM is running in the Azure portal. Navigate to rg-avd-secure and check the VM status shows Running.

Also verify your NSG outbound rules are not blocking the AVD control plane. The WindowsVirtualDesktop service tag (TCP 443, UDP 3478) and AzureActiveDirectory tag (TCP 443) must both be allowed outbound.

Why can't I connect to my Azure Virtual Desktop session?

Verify blocked user access is denied

The real proof of your RBAC configuration is showing that unauthorized users cannot see the desktop at all. Users without the Desktop Virtualization User role on the application group simply see no resources when they subscribe.

  • In Windows App, sign out of your primary user account.
  • Sign in with your second test account (the one you added to AVD-Blocked-Users).
  • Attempt to subscribe to the workspace using the test account's email.
  • Verify that no desktops or workspaces appear for this user.

The test account should see an empty state with no available resources. This confirms your RBAC restriction is working correctly.

Why does the blocked user see nothing instead of an error?

AVD does not show an "access denied" message. Instead, resources are simply invisible to users without the correct role assignment. This is a more secure approach because it does not reveal that the resource exists to unauthorized users.

Test user can still see the desktop?

Double-check that the test account is a member of AVD-Blocked-Users and NOT a member of AVD-Allowed-Users. Navigate to Microsoft Entra admin center > Groups and check both groups' member lists.

Also confirm that the Desktop Virtualization User role on the application group is assigned ONLY to AVD-Allowed-Users and not to a broader scope like "All Users" or the subscription level.

Why can my blocked test user still see the AVD desktop?

Review NSG effective security rules

The final validation confirms your network layer is doing its job. You will inspect the effective security rules applied to the session host VM's network interface to see all active NSG rules in one view.

  • Sign out of the test account in Windows App and sign back in with your primary account.
  • In the Azure portal, navigate to your resource group rg-avd-secure.
  • Click on your session host VM.
  • In the left menu under Networking, select Network settings.
  • Click on the network interface name to open its details.
  • Under Help in the left menu, select Effective security rules.

You should see a combined list of both inbound and outbound rules, including your custom rules and the default Azure rules.

What should I look for?

In the inbound rules, confirm you see your DenyAllInbound rule at priority 4096, plus the default AllowVNetInBound (65000) and AllowAzureLoadBalancerInBound (65001) rules.

In the outbound rules, confirm you see your allow rules for the WindowsVirtualDesktop and AzureActiveDirectory service tags, plus your deny rule for Internet. These rules are what let the session host communicate with the AVD control plane while blocking general internet access.

Not seeing your custom rules?

Make sure you are looking at the network interface of the session host VM, not the NSG resource directly. Effective security rules show all rules (from all associated NSGs) that apply to a specific NIC.

If your custom rules are missing, verify that nsg-avd-hosts is still associated with the snet-avd-hosts subnet. Navigate to the NSG resource and check the Subnets section under Settings.

Why don't I see my NSG rules in the effective security rules view?

You have now validated all three layers of your secure AVD deployment. The network is segmented with explicit allow and deny rules. Only authorized users can see and connect to the desktop. Ready to add one more layer of protection? The Secret Mission introduces Conditional Access with MFA.

Secret mission

Add Conditional Access with MFA

Your AVD environment is locked down with NSGs and RBAC. But what if a user's credentials get compromised? In this Secret Mission, you'll add a Conditional Access policy that forces multifactor authentication before anyone can connect to the virtual desktop.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

Your session host VM costs approximately $0.40-0.50 per hour while running. That adds up to around $10-12 per day.

Your M365 E3 trial is free for 30 days but auto-converts to a paid subscription at $35.44/user/month if you do not cancel before the trial ends. If you are done with this project, pause or delete your resources now.

Resources you used:

  • Session host VM (Standard_D4ds_v4) in the rg-avd-secure resource group.
  • OS disk (Standard SSD) attached to the session host.
  • Virtual Network, subnet, and Network Security Group.
  • AVD host pool, workspace, and application group.
  • Two Entra ID security groups (AVD-Allowed-Users, AVD-Blocked-Users).
  • Microsoft 365 E3 trial license.

Keep everything running

No action needed. Choose this if you are still actively experimenting with your AVD environment or plan to continue within the next few hours.

  • Your session host VM will continue running at approximately $0.40-0.50 per hour.
  • Your M365 E3 trial will continue counting down its 30-day free period.
  • Set a reminder to come back and pause or delete resources when you are finished.

Pause - I'll come back to this later

Shut down the session host VM to stop compute charges while keeping all your configuration intact. You will still pay minimal disk storage costs (approximately $0.10/day).

  • In the Azure portal, navigate to your resource group rg-avd-secure.
  • Select your session host virtual machine.
  • Click Stop in the top toolbar and confirm the deallocation.
  • Wait for the status to show Stopped (deallocated). This confirms compute billing has stopped.
  • Your M365 E3 trial continues during this time. Set a reminder to cancel it before the 30-day period ends if you do not plan to use it.

Delete - I don't want to use this again

Remove all Azure resources and cancel the M365 trial to ensure no ongoing charges.

  • In the Azure portal, search for Resource groups and select rg-avd-secure.
  • Click Delete resource group.
  • Type the resource group name to confirm, then click Delete. This removes the VM, network, NSG, host pool, workspace, and all other Azure resources.
  • Go to the Microsoft 365 admin center (admin.microsoft.com).
  • Navigate to Billing, then Your products.
  • Select the Microsoft 365 E3 trial subscription.
  • Turn off Recurring billing to let the trial expire without converting to a paid subscription.
  • Optionally, delete the security groups (AVD-Allowed-Users, AVD-Blocked-Users) and the test user account from the Microsoft Entra admin center.

That's a Wrap!

That's a Wrap!

Nice work! You just deployed a secure Azure Virtual Desktop environment protected by both network segmentation and identity-based access control.

You've learned how to:

  • Built a segmented VNet with NSGs using service tags to control AVD traffic at the network layer.
  • Deployed an AVD host pool with a Windows 11 session host joined to Microsoft Entra ID.
  • Implemented RBAC-based user access control using security groups and the Desktop Virtualization User role to restrict who can connect to the desktop.
  • Created a Conditional Access policy enforcing MFA specifically for Azure Virtual Desktop connections.

Ready to quiz yourself?