Administration, deployment, user support of Azure Windows Virtual Desktop (WVD) needs permission in Azure. But these permissions are depending on the task a group of users/administrators have to do. For example, if the help desk has to log off and send messages to users, they need fewer permissions than the administrator building session hosts.

In the first step, the permission for the different groups can be given using the build-in roles in Azure and assigning them to the groups and specific resources. But this doesn't allow us to assign granular permissions to fulfill the least privileges approach. To do that, we have to go with custom roles. Custom roles allow combining specific permission for different resource types to a new role. Luckily, Azure Windows Virtual Desktop has many additional permissions per resource type (host pool, app group, workspace, etc.).

I combined the permission from WVD/AVD and from other resource types (like Microsoft Compute) to build eight roles I often use in projects to assign the least permission as needed for the different administrator. These roles can be used to assign them to users, groups, and even service principals (important for WVDAdmin). In my opinion, the best way is to assign these roles on a resource group level and not to a subscription level.

Before I describe the different new roles, I have to mention one "Specialty": Assigning users to an app group in Azure Windows Virtual Desktop needs that you have "Owner Permission" (or more precisely: Microsoft.Authorization/roleAssignments/write) to the app group. While Azure doesn't have the ability to assign owner permission in a role to a specific resource type, I didn't add this permission to the roles. So, you can easily use the new roles on a resource group level, and you can be sure that the user only has the least permission, but you have to assign appropriate admins as an owner to (only) the app groups. Owner permission on resource groups causes that the user can do and rollout anything in these groups.

Note: In a real-world scenario where the least privileges approach for a specific group of admins is not necessary, owner permissions are given to the resource groups containing the WVD/AVD resources (especially the app groups).

My common WVD/AVD roles:

WVD - User Session Reader

Allows to read the user session and host pool properties of Windows Virtual Desktop.

WVD - VM Start-, Stop- and Restarter

Allows to start, stop and restart virtual machines and VM Scale Set instances

WVD - User Session Contributor

Allows to work with the user session and read host pool properties of Azure Windows Virtual Desktop host pools, including to send messages to users and logoff/disconnect user sessions

WVD - Infrastructure Reader

Allows to read all properties of a WVD infrastructure: Host pools, session hosts, workspaces, app groups, and user sessions.

WVD - Infrastructure Contributor

Allows to read and write all properties of a WVD infrastructure but doesn't allow to delete resources: Host pools, session hosts, workspaces, app groups, and user sessions.

WVD - Infrastructure Administrator

Allows to read and write all properties of a WVD infrastructure and allows to delete resources: Host pools, session hosts, workspaces, app groups, and user sessions.

WVD - Infrastructure Administrator & VM Manager

Allows to read and write all properties of a WVD infrastructure and allows to delete resources: Host pools, session hosts, workspaces, app groups, and user sessions. Additionally, the power state of all hosts and VMs can be changed.

WVD - Template and Session Host Administrator

Allows to create/modify/delete Virtual Machines, images, rollout new session hosts into host pools, and attach them to a vnet.

WVD - Full Administrator

Allows to create/modify/delete Virtual Machines, images, rollout new session hosts into host pools, attach them to a vnet, and all permissions from the role 'WVD - Infrastructure Administrator & VM Manager'.

I'm happy about feedback and give me a ping if you want to have the 'Microsoft.Authorization/roleAssignments/write' inside the contributor roles (but that doesn't prevent users from getting higher permissions on the resource group).

Feel free to roll out these WVD roles into your own subscription (ignore the location, the roles are available in the subscription independent from the location - or take a look into the deployment script):