Azure virtual desktop (AVD) has seen a couple of important improvements over the past years, driven by microsoft’s push towards a fully EntraID joined setup. While joining session hosts into your EntraID tenant has a couple of great benefits, there are also quite some important considerations. In this post I will discuss the need-to-know’s when it comes to EntraID joining your Azure Virtual Desktop environment, helping you decide if this approach will satisfy your needs.

EntraID portal as you already know it

EntraID, recently rebranded from AzureAD, is a well-known product for everyone running workloads in Azure. Making use of EntraID, which is already setup for existing Identity and device management surrounding your cloud environment, will seamlessly integrate your session hosts within the familiarity of your current EntraID setup.

Managing users through the azure native tenant is nothing new. There are a lot of options when it comes to conditional access, role assignment, etc., which can all now be used to secure an Azure virtual desktop environment. Joining Session Hosts to your EntraID tenant will allow you to leverage the various security controls provided through EntraID and allow your cloud native accounts to log in to these session hosts and use the AVD environment from a cloud-only perspective.

This cloud-only scenario only covers the most basic setups though. Configuring AVD as described above will not allow you to include user profiles through FSLogix, mounting file shares with NTFS permissions or deploying applications through MSIX AppAttach. Whenever there are more complex requirements like these, some more thought needs to be put into designing an EntraID joined setup.

Roaming profiles in Shared pools and Centralized profile storage

When deploying a classic Virtual Desktop environment, usually FSLogix comes to mind for trying to provide roaming user profiles. There are 2 main scenarios in which using external profile storage through FSLogix becomes very useful.

• Shared host pools:  When providing a shared host pool, it is unknown on which session host the user will land. For this reason, it is not possible to store the user profile on the session host itself, as this will cause sync issues when starting a session on another session host. The better option is to store the user profile externally on a file share. FSLogix will mount the correct user profile from this file share, allowing the user to shift between session hosts without losing profile data.
• Centralised profile storage for backup purposes: In any AVD setup (shared or personal), it might be desirable to backup user profiles. Having the profile data stored in an external file share will make backing up this data a lot easier as all data is stored in a centralised location. FSLogix is also required in this architecture to load the correct profile whenever a user logs on.

When EntraID-joining the session hosts, an azure storage account can be used to provide the file share in which profile data is stored. This file share will have to be EntraID joined as well, in order to provide the required user authentication.

The main caveat in the FSLogix story is that this will only work for hybrid EntraID accounts, meaning regardless of your setup, using FSLogix without a regular Active Directory (or AD Domain Service) will NOT work.

Azure virtual desktop user accounts will have to originate from an AD source, and be synced to EntraID in order to make use of FSLogix profiles. When trying the roaming profile solution with a cloud-only account, you’ll be running into network issues when attempting to mount the profile disk to the session host.

There are workarounds for this, allowing cloud-only accounts to use FSLogix, however, these require the storage key to be stored on the session host itself, making use of a connection string to authenticate against the storage account. This would decrease the overall security posture of this setup, limiting the access restriction possibilities when it comes to the file share. If you do not have a regular AD configured in your environment and still want to make use of roaming profiles for your AVD environment, this can definitely offer a solution, but be mindful of the security trade-off this would entail.

Application deployment through MSIX AppAttach

Currently, app streaming through AppAttach is not supported in an EntraID joined setup. Because AppAttach would be using a storage account to stream the applications from, the same issues are present as with FSLogix. The main difference though, FSLogix has already been updated to support EntraID joined storage accounts, while AppAttach has not. Microsoft is working on this support as can be seen from the recent advancements for FSLogix and the general push towards EntraID.

When using EntraID for joining the session hosts though, we can make use of the already integrated Intune solution to deploy applications to the hosts. It is relatively easy to setup a dynamic security group to include all session hosts. In intune, applications can be pushed to this group to provision apps on all session hosts at once. Intune provides a very useful one-stop-shop for managing applications, while also allowing for OS patching of the machines. Furthermore, policies can be implemented via intune, which can (for example) be leveraged to limit access to the session host’s own OS and disk.

Intune enabling session hosts might be the easiest part of the AVD setup, as it’s simply checking a single box when EntraID-joining a machine. Whether it’s via the Azure portal or the “AADLoginForWindows” extension, makes little difference, both methods will enroll the machine in intune without (besides intune itself) any further configuration required.

Using Intune to manage applications and OS Patching will also drastically reduce the need for Image management. Session hosts can be setup from an empty Windows 11 – Multi-session image, with no apps built in. All further management is done through intune. Managing golden images comes with quite some overhead (definitely when updating OS and apps through Intune), which could in this case be avoided.

Azure RBAC and API Permissions

We already touched on the topic of EntraID joining storage accounts to enable the FSLogix capability. One step, which is required for the connection to this storage account to work, is little documented and quite often overseen when configuring the virtual desktop environment. After enabling Azure AD Kerberos as “Active Directory Source” on the file share, an App Registration will be created in your EntraID tenant. This App Registration will be named after this specific storage account. It is important you grant admin consent to the API permissions which are assigned to this entity, as without consent, it won’t be able to authenticate any hybrid user accounts, thus failing to load the users profile.

With the target audience for the virtual desktop environment being known in EntraID (as they are hybrid users or cloud-only users), role assignments based on RBAC can be made to assign access. Besides assigning the user to an application group, they also need permission to log in to the Session Host Virtual Machine instance. For this the “Virtual Machine User Login” RBAC role is required. It is advised to assign this role to the resource group containing the session hosts, as more VMs might be deployed for scaling purposes.

When using file shares for FSLogix, the AVD users also need to be assigned access to the file share itself in order to be able to read and modify data within their share. For this the “Storage File Data SMB Share Contributor” role is required. This assignment is referred to as  “Default share-level permission”, which makes sense as this is the highest scope of role assignment on which the service will fall back if nothing more specific is assigned.

For these more specific role assignments, NTFS permissions will need to be set. For this however, there are some prerequisites. First of all, the machine from which these NTFS permissions will be configured, requires line-of-sight towards the regular AD domain controller. Furthermore, a hybrid account with “Storage File Data SMB Share Elevated Contributor” RBAC role (on the file share) needs to perform the configuration.

Session configuration and Cleanup

When making use of shared pools, it’s highly likely you’ll come in contact with scaling plans. These schedules are meant to scale your host pool according to specific predefined rules. The scaling plan will look at the amount of sessions per session host, and deallocate the session host when the load doesn’t justify the machine being up. There is a sidenote to be made here though: Scaling plans will only act on signed-out sessions, and consider “disconnected” sessions as active. Meaning that if you don’t clean up disconnected sessions, the scaling plan will not do anything.

In the classic way of configuring an Azure Virtual Desktop environment, cleaning up sessions is done through GPO’s, stating sessions can only be active for X amount of time, users can only be idle for X hours or disconnected sessions should only stay signed in for a certain period. These GPO’s have to be configured within the Active Directory, and scope to the computer object of the Session Host. Joining these hosts in EntraID will not give you access to GPO’s, as these are not supported in EntraID, meaning another way of cleaning up sessions is required.

There is the possibility to use registry keys in the session host virtual machine itself to set these session settings. Registry keys need to be added anyway, for example to support Kerberos forwarding or setting FSLogix configuration. In this case we can add 4 more registry entries for this use case:

• HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\RemoteAppLogoffTimeLimit (DWord)
• HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\MaxDisconnectionTime (DWord)
• HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\MaxConnectionTime (DWord)
• HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\MaxIdleTime (DWord)

Configure these 4 registry entries with time intervals according to your specific use case. You’ll notice that disconnected sessions are removed after the specified time period, and your scaling plan is able to downscale the host pool accordingly. Keep in mind to configure these registry keys on all session hosts, it might be useful to incorporate this configuration in your session host deployment script or enforce these settings through Intune.

Hurdle, but worth the effort

When considering an EntraID joined virtual desktop environment, it is important to note these specific requirements. When using any extended features (most AVD setups have), some more complex configuration is imminent. Furthermore, the “EntraID only” setup will not be what it’s called, as an AD instance is still required for certain capabilities.

However, when the setup is running though, it is a lot easier to manage, as there is no more need to maintain the machines via an on-premises AD instance. You will be able to seamlessly integrate with EntraID’s strong security features such as Conditional Access including MFA, Identity Protection and modern authentication protocols (smartcards, FIDO2, Windows Hello for Business, …), all while allowing your users to use Single Sign-on provided by Azure. When optionally deciding to utilize EntraID’s device management implementation (Intune), you’ll notice that managing the session hosts and applications running on them is much easier than maintaining a fully built golden image.

The progression towards an “EntraID Only” Azure Virtual Desktop environment is well underway and looks very promising for what’s to come. Considering this as an option for future proofing your setup might even be a no-brainer down the line!