Episode 55 - AVD Security Uncovered, how secure is your Azure Virtual Desktop?

Summary

The episode explains how to secure Azure Virtual Desktop (AVD) by treating it as a distinct environment—not simply as a server or personal desktop—and applying security controls across identity, session hosts, networking, and user data.

AVD architecture and management

• Microsoft manages AVD’s control plane. Users connect to the service over HTTPS through a browser, Windows app, or another supported client. Session hosts connect to the control plane using reverse connect, so they do not need public IP addresses or customer-managed gateway and broker servers.
• Customers remain responsible for the virtual network, session hosts, images, and data storage.
• AVD supports full desktops and published remote applications, as well as multi-session Windows 11 hosts. Multiple session hosts can share an image, and automation can scale down unused hosts to reduce costs.

Identity and session-host security

• Secure identity first with Microsoft Entra ID and Conditional Access. Policies can restrict access by location or IP, require Intune-managed devices, and apply sign-in controls. Because AVD access involves separate service identities, administrators should ensure relevant Conditional Access policies cover them.
• Give users standard access rather than local administrator rights. Use Azure RBAC and Privileged Identity Management (PIM) for elevated access, with just-in-time, time-limited permissions where possible.
• Avoid applying Windows Server hardening policies wholesale to Windows 11 multi-session hosts, as some settings may interfere with the user experience.
• Other recommended controls include the Microsoft AVD security baseline, Microsoft Defender for Endpoint, Azure Policy to prevent public IP creation, and avoiding unnecessary local administrator accounts. LAPS can also be used to manage local accounts.

Network and data protection

• Keep session hosts off public IPs. Azure Firewall and AVD fully qualified domain name (FQDN) tags can help control allowed traffic. Use private connectivity for storage and configure RDP Shortpath appropriately.
• Treat device and resource redirection as potential data-loss paths. Clipboard, drive, printer, and USB redirection can allow information to leave the session. Disable these by default or limit them—for example, by allowing text-only clipboard use—and agree on exceptions with customers.
• Conditional Access and redirection settings can be layered. In the demonstration, the guest showed clipboard and drive redirection being blocked, then changed the clipboard setting to allow text transfer after a host reboot. He also demonstrated an Azure Policy that denied public IP creation for the session-host resource group.
• For FSLogix profile storage on Azure Files or Azure NetApp Files, configure appropriate NTFS permissions and Kerberos, disable storage keys where applicable, use private endpoints, disable public access, and enable encryption at rest, potentially with customer-managed keys.

Maintenance and learning guidance

• Rather than relying on the usual Windows Update approach for session hosts, the guest describes Microsoft’s recommended approach as rebuilding or replacing hosts with an updated image. FSLogix keeps user profiles separate from the hosts, allowing users to retain their profiles when hosts are replaced.
• For newcomers, the advice is to create a host pool and experiment with its settings. Start with Conditional Access, then decide which capabilities—such as clipboard, microphone, or watermarking—to enable based on data governance and user needs.
• The guest refers to a planned three-part blog series on AVD security and a GitHub repository containing the Azure Policy example used in the demonstration.

Main speakers

• Dean van der Kolk — host; cloud security architect at IT Impressive.
• Alex van der Kolk — guest; Azure Local and Azure Virtual Desktop specialist at RapidCircle, and a Microsoft MVP.