In recent projects I've noticed more and more organizations wanting to simplify their Azure Virtual Desktop (AVD) deployments, and the availability of fully Microsoft Entra joined session hosts has a lot to do with that. The reasons are easy to see. Your hosts no longer need domain controllers, Intune management gets much simpler, and single sign-on comes closer to what users expect from cloud-first access. If you're starting fresh or trying to get rid of legacy dependencies, this is a real step forward.

Entra joined session hosts no longer depend on domain controllers

With Azure Virtual Desktop Entra joined, your session hosts don't need line of sight to on-premises domain controllers any more. They join Microsoft Entra ID (formerly Azure AD) directly, so you can skip hybrid join workarounds and VPN hacks. That makes scaling and adding new hosts a lot easier, particularly for smaller orgs or those already leaning heavily on the cloud. In my experience, new host pools go out noticeably faster, and Intune onboarding works out of the box.

User sign-in runs entirely through Entra ID, and you can turn on RDP Single Sign-On (SSO) so users get a much smoother experience. You do have to configure the "Windows Cloud Login" enterprise app and grant the necessary consent to users or device groups. Read the official instructions carefully, because some of the SSO steps are easy to miss.

Every AVD connection now runs through Conditional Access and MFA

For me, one of the biggest advantages of Entra joined hosts is proper Conditional Access and MFA enforcement for AVD access. Each connection goes through Entra authentication, whether it comes from the AVD client or the web portal. With Conditional Access policies you decide in detail who gets to which resources and from where. MFA is enforced by default for remote access, so the clunky workarounds and odd edge cases are gone. If you haven't settled on a Conditional Access baseline yet, have a look at /blog/conditional-access-entra-id-getting-started.

RDP SSO authenticates the user session against Entra ID, as long as the right services and licenses (Microsoft 365 E3/E5 or an AVD access license) are in place. Remember to grant the required consent for the Windows Cloud Login app in Entra, ideally to the relevant host or user group. The Microsoft docs cover the details well. Still, the consent step is the one I see people stumble over most often.

FSLogix profiles reach Azure Files through Entra Kerberos

Without a classic AD join, persistent user profiles (FSLogix) need another way to access the SMB share. That's where Azure Files with Entra Kerberos comes in. It lets session hosts that are joined only to Entra ID use Azure Files SMB shares for FSLogix profile storage, and the flow is cleaner than I expected:

flowchart TD
  User["User signs in"] --> Host["Session Host (Entra joined)"]
  Host --> Auth["Entra ID authentication"]
  Host --> Kerberos["Get Entra Kerberos ticket"]
  Kerberos --> AzureFiles["Azure Files SMB share"]
  AzureFiles --> FSLogix["FSLogix loads profile"]

Figure: Sign-in and profile loading with Entra Kerberos on an Entra joined AVD host

What matters is that your Azure Files shares are set up for Entra ID-based authentication. Microsoft's guide (Enable Azure Files authentication with Azure AD Kerberos for hybrid identities) is thorough. The first setup usually takes some fiddling, but once it runs, profiles tend to be stable.

Cloud-only users and legacy apps still hit hard limits

For all the cloud-first promise, Entra joined hosts still have rough edges. As of May 2024, Azure Files with Entra Kerberos only works for users synchronized from on-premises AD (hybrid identities). Pure cloud-only users, meaning accounts created directly in Entra ID, still can't access SMB shares for FSLogix. If your users are 100% cloud and you need FSLogix roaming profiles, you'll have to use a workaround (local profiles or a third-party product). Know this before you plan a migration, because it's a major limitation.

Legacy apps cause the usual headaches too. Some older applications need NTLM or classic Kerberos against an on-prem AD, and they won't run on Entra joined hosts unless you can modernize their authentication or put a bridge in place. Many organizations therefore run a mixed host pool for now and keep a few AD-joined hosts for those apps.

My advice: audit your user identities and legacy applications before you start. Find out which accounts are synced and whether any service accounts or apps still depend on on-prem authentication. Skipping this is one of the most common blockers I run into.

I roll out Entra joined AVD in five stages

This is the order that has worked for me when rolling out Azure Virtual Desktop Entra joined:

  1. Build a test environment with a handful of Entra joined hosts
  2. Set up Intune management, a Conditional Access baseline and MFA enforcement
  3. Configure and consent to the Windows Cloud Login app for SSO
  4. Set up Azure Files shares with Entra Kerberos and test with real users
  5. Migrate production pools gradually, after auditing legacy apps and identities

I've watched too many projects stall because someone skipped identity preparation or the legacy app inventory. A phased rollout with close feedback from pilot users is the safest route.

Entra joined hosts give you freedom if you accept the trade-offs

For many scenarios, Azure Virtual Desktop Entra joined is ready for production. You can finally drop the domain controllers, manage hosts with Intune and Conditional Access, and build new host pools without legacy baggage. If your users are entirely cloud-only or you still depend on legacy apps, though, some obstacles won't go away. Most hybrid or cloud-leaning organizations will see real benefits, as long as they go in knowing the limits. If you want to see how this fits into hybrid identity more broadly, read my post on Entra Cloud Sync vs Connect Sync.