Categories
ITOps

Azure Virtual Secure Administration Workstation – Part 1 – VDI Environment

Azure Secure Admin Workstation posts:


Context

We have numerous clients and our own systems that require:

  • Access only from appropriately hardened and monitored hosts
  • Inbound and outbound network security including the ability to ‘AllowList’ and ‘BlockList’ based on IPs/URLs/Hostnames/other ‘NGFW‘ methods… although this can be achieved with host-based only controls… does not seems like a very layered defence.
  • Idempotent deployment solution (deployment code can be run regularly and if no changes to code, no changes to deployment)
    • PowerShell is not ideal for doing idempotency proper… but it can, will see how I go for time.

In the interest of enabling source control and potentially automation, the deployment is conducted using PowerShell commands. In this example I am using Azure CloudShell, for manual and exploratory activities it is handy as it is secure, includes all required modules, removes any authentication faff.

At this stage I am not sure how much additional protection / value adding Azure Firewall to the environment will add… will add it for now and find out! Microsoft’s doc doesn’t make the benefits very clear for me:

  • A host pool is a collection of Azure virtual machines that register to Azure Virtual Desktop as session hosts. These virtual machines run in your virtual network and are subject to the virtual network security controls. They need outbound Internet access to the Azure Virtual Desktop service to operate properly and might also need outbound Internet access for end users. Azure Firewall can help you lock down your environment and filter outbound traffic. (Use Azure Firewall to protect Azure Virtual Desktop | Microsoft Learn)
  • The diagram below shows a suggested architecture, going to try avoid getting stuck without a required component later and stay somewhat close to this. Though it should be noted that a potentially valid architecture is just a SAWVnet as inbound connectivity is managed by Azure (via the AVD Instructure: Users connecting to Azure Virtual Desktop securely establish a reverse connection to the service, which means you don’t need to open any inbound ports. (Azure Virtual Desktop | Microsoft Learn)

Reference Material

Key Terms

  • Resource groups: Logical containers that you use to group related resources in a subscription. Each resource can exist in only one resource group. Resource groups allow for more granular grouping within a subscription. They’re commonly used to represent a collection of assets that are required to support a workload, application, or specific function within a subscription.
  • Host pools: A host pool is a collection of Azure virtual machines that register to Azure Virtual Desktop as session hosts when you run the Azure Virtual Desktop agent. All session host virtual machines in a host pool should be sourced from the same image for a consistent user experience. You control the resources published to users through application groups. A host pool can be one of two types:
    • Personal, where each session host is assigned to an individual user. Personal host pools provide dedicated desktops to end-users that optimize environments for performance and data separation.
    • Pooled, where user sessions can be load balanced to any session host in the host pool. There can be multiple different users on a single session host at the same time. Pooled host pools provide a shared remote experience to end-users, which ensures lower costs and greater efficiency.
  • Application groups: An application group is a logical grouping of applications installed on session hosts in the host pool. An application group can be one of two types:
    • RemoteApp, where users access the applications you individually select and publish to the application group. Available with pooled host pools only.
    • Desktop, where users access the full desktop. Available with pooled or personal host pools.
    • NOTE: We don’t support assigning both the RemoteApp and desktop application groups in a single host pool to the same user.
  • Workspaces: 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 desktops and applications published to them.
  • Desktop Virtualization User: Built-in Azure RBAC roles Azure Virtual Desktop | Microsoft Learn

Out of scope

Deployment procedure

Stage 1 – Create Azure Virtual Desktop Environment

  • This section provides context for the PowerShell commands are below… strongly suggest reviewing description of steps first.

Azure Virtual Desktop Environment

  1. Prerequisites for Azure Virtual Desktop | Microsoft Learn
  2. Launch the Azure Cloud Shell in the Azure portal with the PowerShell terminal type
  3. Create a Resource Group
    • Parameters:
      • Name, Location
  4. Create a Host Pool
    • Use the New-AzWvdHostPool cmdlet with the following examples to create a host pool. More parameters are available; for more information, see the New-AzWvdHostPool PowerShell reference.
    • Parameters:
      • Location: must be one of LocationNames Class (Microsoft.Azure.Documents) and match your Resource Group
      • HostPoolType: can be one of two types:
        • Personal, where each session host is assigned to an individual user. Personal host pools provide dedicated desktops to end-users that optimize environments for performance and data separation.
        • Pooled, where user sessions can be load balanced to any session host in the host pool. There can be multiple different users on a single session host at the same time. Pooled host pools provide a shared remote experience to end-users, which ensures lower costs and greater efficiency.
        • See also: Azure Virtual Desktop terminology – Azure | Microsoft Learn
  5. Create a workspace
    • Parameters:
      • Name, Location, ResourceGroupName
  6. Create an Application Group
    • Name, ResourceGroupName, Location
    • HostPoolArmPath: Azure Resource Manager Path
    • ApplicationGroupType: As above, RemoteApp / Desktop
  7. Add Application Group to Workspace
  8.  Create Entra User Group if it doesn’t exist
  9. Assign Entra Group to an Application Group

Next Steps:

PowerShell Script


Sundry

Upload and Run PowerShell script in CloudShell

  1. Configure CloudShell
  2. Open CloudShell – https://portal.azure.com/#cloudshell
  3. Upload your script using the upload button
    • File is now persistent in your CloudShell home dir

Rules for Azure FW protecting Azure Virtual Desktop


Leave a Reply

Your email address will not be published. Required fields are marked *