Important Consideration: Host Pool Outbound Access to the Internet – Implement and Manage Networking for Azure Virtual Desktop

Important Consideration: Host Pool Outbound Access to the Internet

Based on your organization’s requirements, you may need to enable secure outbound Internet access for your end users. In instances where the list of allowed destinations is well-defined (for instance, Microsoft 365 access), you can use Azure Firewall applications and network rules to configure the required access. This routes end-user traffic directly to the Internet for the best performance.

If you want to filter outbound user Internet traffic using an existing on-premises secure web gateway, you can configure web browsers or other applications running on the Azure Virtual Desktop host pool with an explicit proxy configuration. These proxy settings only influence your end-user Internet access, permitting the Azure Virtual Desktop platform outbound traffic directly via Azure Firewall.

Manage Azure Virtual Desktop Session Hosts by Using Azure Bastion

In this section you’ll learn about Azure Bastion.

Configure AVD Session Hosts Using Azure Bastion

Azure Bastion offers secure connectivity to all VMs in a virtual network in which it is provisioned. Utilizing Azure Bastion protects your virtual machines from exposing RDP/ SSH ports to the outside world, while still offering secure access utilizing RDP/SSH.

It is important to verify the criteria that you need to meet. Here is the list:

•\   You need a VNet with the Bastion host already installed. Make sure that you have set up an Azure Bastion host for the virtual network in which the VM is located. Once the Bastion service is provisioned and deployed in your virtual network, you can make use of it to connect to any VM in the virtual network.

•\   You need a Windows virtual machine in the virtual network.

•\   The required roles are as follows: Reader role on the virtual machine, Reader role on the NIC with the private IP address of the virtual machine, and Reader role on the Azure Bastion resource.

•\   To connect to the Windows VM, you must have the inbound port RDP (3389) open on your Windows VM.

What Is a Workspace? – Design the Azure Virtual Desktop Architecture

What Is a Workspace?

A workspace is a logical grouping of application groups in Azure Virtual Desktop. Each Azure Virtual Desktop application group must be associated with a workspace for users to see the remote apps and desktops published to them.

Figure 2-8 shows the reference architecture for host pool placement.

Figure 2-8.  Azure Virtual Desktop host pool, session host, resource group placement

This diagram shows a typical Azure Virtual Desktop host pool placement recommendations are as follows:

•\   A dedicated subscription is recommended for Azure Virtual Desktop resources for easy management and scaling on-demand.

•\   A separate virtual network is recommended with multiple subnets for pooled and personal in each region and peering with a hub virtual network in that region.

•\   A virtual network scope range needs to be decided on, considering the number of VMs for pooled as well as personal and future growth.

•\   Multiple host pools of the same type can use the same subnet as far as there is no compliance/InfoSec requirement. Each subnet can be

restricted with a set of NSG rules.

•\   You need a separate host pool for each VM size, each region, and each type (pooled/personal).

•\   You need a dedicated resource group for each host pool to manage RBAC on the host pool–specific resources.

•\   RDP properties can be a set of host pool levels, so if we have a set of users that need different RDP properties, then we have to create different host pools. For example, some users need to copy the Azure Virtual Desktop option and some not.

•\   A separate pooled host pools for users who need a different set of applications.

How Do I Diagnose Network Routing Problems from a VM? – Implement and Manage Networking for Azure Virtual Desktop

How Do I Diagnose Network Routing Problems from a VM?

While supporting the VM environment as an admin, you may encounter the network routing issue, and you must know how to diagnose the routing problem. Once you create a virtual network, Azure creates several default outbound routes for network traffic.

The outbound traffic from all resources, like VMs, deployed in a virtual network, are routed based on Azure’s default routes. You might override Azure’s default routes or create additional routes. You may find that a VM can no longer communicate with other resources because of a specific route.

To troubleshoot the issue, you may check the next hop capability enables you to specify a source and destination IPv4 address. The next hop then tests the communication and informs you what type of next hop is used to route the traffic. You can then remove, change, or add a route to resolve a routing problem.

Azure Monitor Tool

In this section you’ll learn about the tool.

How Do I Monitor Azure Virtual Desktop Using Azure Monitor?

Azure Monitor is another tool that helps you in monitoring Azure Virtual Desktop. It is important to learn how to set up Azure Monitor for Azure Virtual Desktop to monitor your Azure Virtual Desktop environments. Prior to using Azure Monitor for Azure Virtual Desktop, you’ll need to set up the multiple things.

•\   You must have at least one configured Log Analytics workspace.

Make use of a designated Log Analytics workspace for your Azure Virtual Desktop session hosts to ensure that performance counters and events are collected only from session hosts in your Azure Virtual Desktop deployment.

•\   Allow data collection for the following things in your Log Analytics workspace:

\ a.\ Diagnostics from your Azure Virtual Desktop environment
\ b.\ Recommended performance counters from your Azure
Virtual Desktop session hosts
\ c.\ Recommended Windows Event Logs from your Azure Virtual
Desktop session hosts
•\ The data setup process explained in this page is the only one you’ll
need to monitor Azure Virtual Desktop. You can disable all other
items sending data to your Log Analytics workspace to save costs.
•\ Anyone monitoring Azure Monitor for Azure Virtual Desktop for your
environment will also need the read-access permissions that are
mentioned here:
\ a.\ Read-access to the Azure subscriptions that hold your Azure
Virtual Desktop resources
\ b.\ Read-access to the subscription’s resource groups that hold
your Azure Virtual Desktop session hosts
\ c.\ Read-access to the Log Analytics workspace or workspaces

Note  Read-access permissions only let admins view data. However, they will need different permissions to manage resources in the Azure Virtual Desktop portal.

Identity Design Recommendations – Design for User Identities and Profiles

Identity Design Recommendations

Here are some recommendations for identity design:

•\   Use Azure AD Connect to synchronize all identities to a single Azure AD tenant.

•\   Ensure Azure Virtual Desktop session hosts can communicate with Azure AD DS or AD DS.

•\   Use the least privilege principle to assign the minimum permissions needed for authorized tasks.

•\   Segregate session host virtual machines into Active Directory organization units for each host pool to manage policies and orphaned objects more easily.

•\   Use a solution like Local Administrator Password Solution (LAPS) to rotate local administrator passwords on Azure Virtual Desktop session hosts frequently.

•\   Create conditional access policies for Azure Virtual Desktop. Such policies can enforce multifactor authentication based on conditions such as risky sign-ins to increase an organization’s security posture.

•\   Configure AD FS to enable single sign-on for users on the corporate network. Different Directory Options

There are three common ways to use Active Directory–based services in Azure for identity and authentication. This choice of identity solutions is dependent on your organization’s needs. For example, if you have cloud-based application and cloud-only users accessing the application, then Azure Active Directory is a suitable solution, but in case you want to assign a policy on cloud-only devices and you don’t have on-premises AD DS, then you can select Azure Active Directory domain services (AAD DS). Another use case is if you already have traditional on-premises AD DS and you want to use same domain user to authenticate cloud-based application/devices, then you can sync on-premises AD DS with Azure AD and use the on-premises identity for cloud as well.

Although the three Active Directory–based identity solutions share a common name and technology, they are designed to provide different customer needs.

The following are the three different identity solutions Microsoft provides:

•\    Active Directory Domain Services (AD DS): This is a traditional Lightweight Directory Access Protocol (LDAP) server that provides key features such as identity and authentication, computer object management, Group Policy, and trusts. AD DS is a service available in Windows Server, and many organizations are already using it as the central component in their on-premises datacenter. Azure Virtual Desktop supports an on-premises ADDS service, and you can either directly sync on-premises AD DS with Azure AD or extend it in Azure and then sync it with Azure AD to avoid authentication and sync traffic going over VPN/ER. Extended AD DS server in Azure can be used for domain joins and AVD desktop authentication as well.

•\    Azure Active Directory (Azure AD): Azure AD is a cloud-based identity and mobile device management (MDM) provider that gives the ability to create user account and authenticate services for resources such as Microsoft 365, the Azure portal, and software-as-a-service applications. On-premises AD DS can be synchronized with Azure AD to provide a single-user identity across the organization. Azure AD is required for authentication, but it needs to be synced with on-premises AD DS or Azure AD DS. •\      Azure Active Directory Domain Services (Azure AD DS): Azure AD DS consists of managed domain services the same as traditional AD DS with features such as domain joins, Group Policy, LDAP, and Kerberos/NTLM authentication with a minimal amount of administrative overhead (but limited admin permission; refer to Azure AD DS). Azure AD DS integrates with Azure AD, which itself can synchronize with an on-premises AD DS. This ability extends central identity use cases. Azure AD DS is one of the best options supported by Azure Virtual Desktop if you don’t have any directory solution in place or if you want to set up isolated AVD POC.

Differences Between Azure AD DS and Self-Managed AD DS – Design for User Identities and Profiles

Differences Between Azure AD DS and Self-Managed AD DS

There are two ways to provide AD DS traditional authentication mechanisms (Kerberos or NTLM) in the cloud for cloud-based applications and services:

•\    Managed domain (Azure AD DS): Microsoft manages the required resources for Azure AD DS, and you can still use all the traditional AD DS features such as domain joins, Group Policy, LDAP, and Kerberos/ NTLM authentication. You don’t deploy, manage, patch, and secure the Azure AD DS infrastructure for components such as Windows Server OS or domain controller (DC) VMs. See Figure 3-3.

Figure 3-3.  Azure Active Directory Domain Services (AAD DS) for Azure Virtual Desktop

•\    A self-managed domain (AD DS service on VM): You can create and configure traditional AD DS on Azure virtual machines (VMs) with Windows Server guest OS, and you can use Active Directory Domain Services (AD DS) to extend your on-premises AD DS to the cloud or use on-premises AD DS as is for cloud as well. There’s additional maintenance overhead with a self-managed AD DS environment, but you have ability to do additional tasks such as extend the schema or create forest trusts. See Figure 3-4.

Figure 3-4.  On-premises AD DS for Azure Virtual Desktop

Common deployment models for a self-managed AD DS in cloud include the following:

•\    Standalone cloud-only AD DS: This option is mostly used when you don’t have on-premises AD DS and just want to create new self-managed AD DS for the Azure cloud. Azure VMs can be configured as domain controllers to create a cloud-only AD DS environment.

•\ Resource forest deployment: This option is mostly used when you have an on-premises AD DS forest and just want to create a new AD DS domain in an existing on-premises forest for the Azure cloud. Azure VMs can be configured as domain controllers and AD DS domains as part of the existing on-premises forest. A trust relationship is then configured to an on-premises AD DS environment so that other Azure VMs can domain-join to this resource forest in the cloud. User authentication runs over a VPN/ExpressRoute connection to the on-premises AD DS environment.

•\    Extend on-premises domain to Azure: This option is mostly used when you have an on-premises AD DS domain and forest and just want to add a cloud-based domain controller in an existing on-premises domain. An Azure virtual network needs to be connected to an on-premises network using a VPN/ExpressRoute connection for this model as well. Azure VMs connect to this Azure virtual network, which lets them domain-join to the on-premises AD DS environment.

Table 3-3 outlines the differences between a managed Azure AD DS domain and a self-managed AD DS domain.

Table 3-3.  Differences Between a Managed Azure AD DS Domain and a Self-­Managed AD DS Domain

Creating a Virtual Network for AVD- 2 – Implement and Manage Networking for Azure Virtual Desktop

\ 19.\ Once an NSG is updated with the correct rules, then you have to attach it to subnets so that the rules will take effect. Go back to the AVD virtual network you created at the start and go to the subnet option from the left pane. Now click the subnet name and attach the NSG from the right-side pane. See Figure 4-20.

Figure 4-20.  AVD NSG assignment

\ 20.\ Select the network security group from the drop-down in the subnet pop-up. See Figure 4-21.

Figure 4-21.  AVD NSG assignment on subnet

\ 21.\  Select the correct NSG name and click the Save button. See Figure 4-22.

Figure 4-22.  AVD NSG assignment page

\ 22.\ You can attach a route table to force-tunnel all traffic to the Azure firewall or third-party firewall in the cloud or on-premises firewall. Select the routing table from the drop-down to attach it to the subnet. See Figure 4-23.

Figure 4-23.  AVD NSG assignment page- route table

\ 23.\ Make sure you have the correct port/IP address open on the firewall/NVA when you are force-tunneling all AVD traffic. Additionally, the routing table must have the correct route. Refer to the route table in Figure 4-24.

Figure 4-24.  AVD routing table to force-tunnel traffic to the firewall

\ 24.\ Once you have updated the NSG and route table, then create peering with the hub VNet so all traffic to on-premises/the other VNet can go through the hub VNet. Go to the hub VNet, click Peering in the left pane, and then click the Add option in the right pane. See Figure 4-25.

Figure 4-25.  AVD virtual network peering to hub virtual network

\ 25.\ Enter the names for peering from the hub to AVD and vice versa. Additionally, select the target virtual network in the drop-down to peer with. Most important, allow all traffic as well as gateway transit so that the gateway will be used for on-premises traffic. The “Gateway transit” option will be available when you have a gateway in the hub for a site-to-site VPN or ExpressRoute. Click the Add button once you select all the options on the peering page. See Figure 4-26.

Figure 4-26.  AVD virtual network peering to hub vnet, adding peering

\ 26.\ The peering status will be visible on the same page. Wait until the peering status is connected. See Figure 4-27.

Figure 4-27.  AVD virtual network peering to hub vnet, Overview page

\ 27.\ The next step is to update the DNS settings on AVD VNet. Go to AVD VNet and click the DNS Servers option in the left pane. See Figure 4-28.

Figure 4-28.  AVD virtual network, DNS server setting

\ 28.\ Select the Custom option in the right pane and enter the DNS server’s IP address. Additionally, you must make sure the DNS port and IP address are open on all firewalls and NSGs so that the session host can reach the DNS server on port 53. Once the IP address is added, then click the Save button to save the configuration. See Figure 4-29.

Figure 4-29.  AVD virtual network, custom DNS server setting

How Can You Filter the Network Traffic? – Implement and Manage Networking for Azure Virtual Desktop

How Can You Filter the Network Traffic?

You can filter the network traffic between subnets using either or both of the options including Network Security Group (NSG), and application security groups. NSG’s can contain multiple inbound and outbound security rules that permit you to filter traffic to and from resources by source and destination IP address, port, and protocol. Another option is a network virtual appliance (NVA), which is a VM that performs a network function, such as a firewall, WAN optimization, or other network function.

How to Route Network Traffic in Azure?

Azure routes traffic between subnets, connected virtual networks, on-premises networks, and the Internet, by default. You can implement a route table or Border Gateway Protocol (BGP) route. Both options override the default routes that Azure creates.

By using route tables, you can create custom route tables with routes that control where traffic is routed to for each subnet. If you connect your virtual network to your on-premises network using an Azure VPN Gateway or ExpressRoute connection, you can propagate your on-premises BGP routes to your virtual networks.

Virtual Network Integration for Azure Services

Integrating Azure services to an Azure virtual network enables private access to the service from virtual machines or compute resources in the virtual network. You can integrate Azure services in your virtual network with the following options:

•\   If deploying dedicated instances of the service into a virtual network, the services can then be privately accessed within the virtual network and from on-premises networks.

•\   Using a private link to access a specific instance of the service privately from your virtual network or from on-premises networks.

•\   You can also access the service using public endpoints by extending a virtual network to the service, through service endpoints. Service endpoints allow service resources to be secured to the virtual network.

No inbound ports are opened. In this version, the gateway acts as an intelligent reverse proxy. The gateway manages all session connectivity, with nothing but pixels reaching the client.

Azure Virtual Desktop hosts client sessions on the session hosts running on Azure. Microsoft manages portions of the services on the customer’s behalf and provides secure endpoints for connecting clients and session hosts. The diagram above (Figure 4-32) gives a high-level overview of the network connections used by Azure Virtual Desktop.