Azure Virtual Desktop Identity Scenarios: A Practitioner’s Guide

If you’ve ever sat in a design workshop and had someone ask “so which identity model should we use for AVD?”, you know it’s rarely a one-line answer. Identity is the foundation every other AVD decision sits on top of — FSLogix profile containers, MFA policy, Conditional Access, session host domain join, even how Single Sign-On behaves for the end user. Get it wrong at the design stage and you end up re-architecting the whole environment later.

Microsoft currently supports six identity scenarios for AVD. They differ in two dimensions: where the session host is joined, and where the user account lives. Once you separate those two questions, the whole table becomes much easier to reason about.

The Six Supported Scenarios

Let’s break down what each of these actually means in practice.

Scenario 1 & 2: Entra ID + AD DS (the classic hybrid model)

This is still the most common pattern in large enterprises with a mature on-prem AD footprint — think regulated industries, legacy line-of-business apps, or environments where GPO is doing heavy lifting. Users exist in AD DS and are synced to Microsoft Entra ID via Entra Connect.

The distinction between scenario 1 and 2 is where the session host itself is joined:

• Scenario 1 — session hosts are traditionally domain-joined to AD DS. This is the “lift and shift” pattern many organizations start with, since it preserves existing GPO, SCCM/Intune co-management, and legacy app compatibility.
• Scenario 2 — session hosts are Microsoft Entra joined, but users are still synced AD DS accounts. This is a popular modernization step: you get Entra-native host management (Intune, Conditional Access on the device) while user identity and FSLogix profile authentication still rely on the synced AD account.

In my engagements, scenario 2 is usually the sweet spot for customers migrating off Citrix who want to shed on-prem domain controller dependency for the compute layer without a full identity re-platform in one go.

Scenario 3 & 5: Entra ID + Microsoft Entra Domain Services

Microsoft Entra Domain Services (formerly Azure AD DS) gives you a managed, domain-join-capable AD-compatible service without the burden of running your own domain controllers. This is attractive for customers who need traditional Kerberos/NTLM domain join (for FSLogix, legacy apps, or Group Policy) but don’t want the operational overhead of AD DS VMs.

• Scenario 3 — session hosts joined directly to Microsoft Entra Domain Services.
• Scenario 5 — session hosts joined to Microsoft Entra ID, with users synced into Entra ID and Microsoft Entra Domain Services.

This model is common for greenfield deployments or smaller/mid-size environments that want AD-like functionality (for FSLogix profile share auth, for example) without inheriting an on-prem AD estate.

Scenario 4: The three-way hybrid

This one’s a bit more nuanced — session hosts join Microsoft Entra Domain Services, but the actual user accounts are managed in on-prem AD DS and synced through to Entra ID. You’d typically land here during a phased migration: on-prem AD stays the source of truth for identity governance (perhaps due to compliance or an existing IAM process), while the session host layer moves off traditional AD DS onto Entra Domain Services to reduce infrastructure footprint.

Scenario 6: Microsoft Entra-only (the cloud-native model)

This is where the industry is heading, and it’s the one I get asked about most often now. Session hosts are Microsoft Entra joined, users exist purely in Microsoft Entra ID — no AD DS, no Microsoft Entra Domain Services, no synced accounts at all. This scenario also uniquely supports external identities (B2B guest users), which makes it relevant for organizations onboarding contractors or partner-org users into AVD sessions.

Entra-only removes domain controller dependency entirely, which simplifies networking (no more requirement for line-of-sight to DCs from every session host subnet) and aligns well with a Zero Trust posture. The trade-off: FSLogix profile containers on Entra-joined-only hosts require Entra Kerberos configuration (cloud Kerberos trust) for profile share authentication, and certain legacy line-of-business apps that expect classic Kerberos/NTLM may need validation before you commit to this model.

How to Actually Choose

A few practical filters I use when advising customers:

• Heavy legacy app estate + existing AD investment → Scenario 1 or 2
• Want to retire self-managed DCs but still need AD-compatible domain join → Scenario 3 or 5
• Mid-migration, AD DS is still your identity source of truth → Scenario 4
• Greenfield, cloud-native, Zero Trust priority, or need B2B guest access → Scenario 6

One more thing worth flagging: SSO behavior and MFA enforcement differ across these scenarios, particularly around whether Conditional Access can evaluate device state at the session host layer versus the user session layer. That’s a big enough topic to deserve its own post, but it’s worth checking Microsoft’s documentation on supported identities and authentication methods before finalizing a design, since the SSO story is evolving quickly as Entra-only becomes the default recommendation for new deployments.

Have you moved an AVD environment to Entra-only, or are you still running a hybrid model? I’d be curious to hear what’s driving that decision in your environment — drop a comment or reach out.