Identity Scenarios for AVD
Azure Virtual Desktop supports three identity models: traditional AD DS, cloud-native Entra ID, and managed Entra Domain Services. Choosing the right one determines how session hosts join, how users authenticate, and how your VNet is configured.
Why identity matters in AVD
Think of identity as the guest list at a building entrance.
Before anyone sits down at a virtual desktop, the system needs to know who they are. There are three ways to check the guest list:
- AD DS — The classic office security desk. Your own guards, your own badge system, running in your own building. You maintain everything.
- Entra ID — A cloud-based badge system. No office needed. Everyone scans in from anywhere and the cloud verifies them.
- Entra Domain Services — A managed security desk Microsoft runs for you. It understands the old badge system (AD DS protocols) but you do not have to maintain the guards or the building.
Each approach changes how your session host VMs “join” the organisation and how users log in.
The three identity models
1. Active Directory Domain Services (AD DS)
This is the traditional model most organisations already have. Domain controllers run either on-premises (connected via VPN or ExpressRoute) or as VMs in Azure.
How it works:
- Session hosts are AD DS joined (traditional domain join)
- Users authenticate to Entra ID first, then the session host validates credentials against AD DS
- Requires Entra Connect to sync on-premises AD users to Entra ID
- Domain controllers must be reachable from the session host VNet (DNS and network connectivity)
🏛️ JC at the Federal Department uses AD DS because the government has a 15-year-old Active Directory forest with thousands of Group Policy Objects. “We have 3,000 staff and 400 GPOs. Ripping out AD DS is not happening this decade. Our domain controllers run on Azure VMs in the same region as our session hosts, connected to on-prem via ExpressRoute.”
Requirements:
- Domain controllers reachable from session host subnet (VNet peering or same VNet)
- DNS servers on the VNet must resolve the AD DS domain name
- Entra Connect syncing users to Entra ID
- A user account with permissions to join computers to the domain (or an OU-scoped join account)
- Line of sight from session hosts to a domain controller on ports 389, 636, 88, 53, 445
2. Microsoft Entra ID (cloud-native join)
The newest and simplest model. No domain controllers at all. Session hosts join Entra ID directly.
How it works:
- Session hosts are Entra ID joined (cloud-native)
- Users authenticate entirely through Entra ID
- No domain controllers, no Entra Connect sync required (if users are cloud-only)
- Supports single sign-on (SSO) so users do not see a second credential prompt
🌐 Priya at NomadTech went fully cloud-native. “We are a 200-person remote company with no offices and no on-prem servers. Our users are all cloud-native Entra ID accounts. Entra ID join was the obvious choice — no domain controllers to manage, no VPN, no sync headaches.”
Requirements:
- Session hosts must run Windows 11 Enterprise (single or multi-session) or Windows Server 2022 or later
- Intune enrolment is recommended (Group Policy is not available without AD DS)
- If users need to access on-premises file shares, you still need hybrid identity (Entra Connect) or alternative access methods
- FSLogix profiles work with Azure Files when using Entra ID-based authentication
Exam tip: Entra ID join OS requirement
This is a favourite exam question. Entra ID join for AVD session hosts requires Windows 11 Enterprise or Windows Server 2022 at minimum. If the scenario mentions Windows 10 or Server 2019, Entra ID join is NOT an option — the answer must be AD DS join or Entra Domain Services.
3. Microsoft Entra Domain Services (managed domain)
A managed domain that provides traditional AD protocols (LDAP, Kerberos, NTLM) without you managing any domain controllers.
How it works:
- Microsoft provisions and manages domain controllers in the background
- Session hosts are domain-joined to the managed domain
- Supports Group Policy (but with some limitations compared to full AD DS)
- Users and groups sync one-way from Entra ID into the managed domain
- You cannot extend the schema or create forest trusts (it is a standalone managed forest)
🏢 Raj at TerraStack considered Entra Domain Services for a new subsidiary that has no existing AD DS. “The subsidiary has 200 users who need domain-joined session hosts for legacy apps that require Kerberos auth. But they do not have domain controllers. Entra Domain Services gave us domain services without building new infrastructure.”
Requirements:
- Entra Domain Services must be provisioned in the same VNet (or a peered VNet) as the session hosts
- A dedicated subnet for the managed domain (Microsoft recommends /24)
- DNS settings on the VNet must point to the managed domain’s IP addresses
- Password hash sync must be enabled in Entra ID (for cloud-only users, this happens automatically; for synced users, you must enable password hash sync in Entra Connect)
Deep dive: Why Entra Domain Services needs password hashes
Entra Domain Services provides Kerberos and NTLM authentication, which require password hashes stored in the managed domain. For cloud-only users, Entra ID already stores the right hash formats. For users synced from on-premises AD via Entra Connect, you must enable password hash synchronisation — otherwise those users cannot authenticate to the managed domain.
This is a common gotcha in both the exam and real deployments. If hybrid users cannot log in to Entra Domain Services-joined session hosts, check that password hash sync is enabled in Entra Connect.
Session host join types at a glance
| Join Type | Identity Provider | Domain Controller Needed | Group Policy | Windows Version |
|---|---|---|---|---|
| AD DS join | On-prem or IaaS AD DS | Yes | Full GPO support | Any supported Windows |
| Entra ID join | Microsoft Entra ID | No | Intune policies only | Win 11 or Server 2022+ |
| Hybrid Entra join | AD DS + Entra ID | Yes | Full GPO + Intune | Any supported Windows |
| Entra DS join | Managed domain | No (Microsoft manages) | Limited GPO | Any supported Windows |
The identity decision matrix
Use this flowchart when the exam gives you a scenario:
- Do you have existing AD DS infrastructure you must keep?
- Yes, and users need full Group Policy: AD DS join or hybrid Entra join
- Yes, but moving toward cloud management: Hybrid Entra join (transition path)
- Is the deployment cloud-only with no legacy AD dependencies?
- Yes: Entra ID join
- Do you need domain services (Kerberos, LDAP) but have no domain controllers?
- Yes: Entra Domain Services
- Do the session hosts run Windows 10 or Server 2019?
- Yes: Entra ID join is not available — must use AD DS or Entra DS
| Capability | AD DS (Traditional) | Entra ID (Cloud-Native) | Entra Domain Services (Managed) |
|---|---|---|---|
| Domain controllers | You deploy and manage | None needed | Microsoft manages |
| Group Policy | Full GPO support | Intune only (no GPO) | Limited GPO support |
| Kerberos / NTLM | Yes | No (token-based auth) | Yes |
| LDAP access | Yes | No | Yes (read-only LDAP) |
| Forest trusts | Yes | N/A | No |
| Schema extensions | Yes | N/A | No |
| Minimum OS for session hosts | Any supported | Windows 11 / Server 2022+ | Any supported |
| Profile storage auth | AD DS or Kerberos for file shares | Entra ID-based Azure Files | Kerberos for Azure Files |
| Best for | Existing AD environments | Cloud-native orgs | Lift-and-shift without DCs |
| Network requirement | DCs reachable from VNet | Internet access to Entra ID | Managed domain in same/peered VNet |
| Entra Connect needed | Yes (sync to Entra ID) | No (cloud-only users) | No (syncs from Entra ID) |
DNS considerations by identity model
DNS is the silent deal-breaker in AVD identity. Get it wrong and session hosts cannot join.
| Identity Model | DNS Configuration |
|---|---|
| AD DS | VNet DNS must point to your domain controllers (so hosts can find the domain). Azure DNS alone will NOT work. |
| Entra ID | Azure-provided DNS is fine. No domain to resolve. |
| Entra Domain Services | VNet DNS MUST point to the managed domain IP addresses (shown in the Entra Domain Services blade in the portal). |
| Hybrid join | VNet DNS must resolve both on-prem AD and Azure resources. Typically domain controller IPs plus Azure DNS forwarder. |
Common mistake: Leaving VNet DNS as “Azure-provided” when using AD DS join. The session hosts will never find the domain controller and the domain join will fail.
Exam tip: DNS for Entra Domain Services
If a question describes Entra Domain Services and session hosts failing to join, check the DNS configuration first. The VNet custom DNS settings must point to the two IP addresses of the managed domain — not Azure DNS, not an on-prem DNS server.
Real-world scenarios
🏛️ JC — Government with strict compliance: AD DS join with hybrid Entra join for Conditional Access. Domain controllers on Azure VMs in a government-accredited region. ExpressRoute to on-prem for legacy app servers.
🌐 Priya — Remote-first startup: Entra ID join. No servers, no VPN. Intune for policy management. Azure Files with Entra ID authentication for FSLogix profiles.
🏢 Raj — Enterprise Citrix migration: Hybrid Entra join for the main campus (existing AD DS), Entra Domain Services for the new subsidiary. Both peered to the same hub VNet.
Priya is deploying AVD for NomadTech. They have no on-premises infrastructure, all users are cloud-native Entra ID accounts, and they use Intune for device management. The session hosts will run Windows 11 Enterprise multi-session. Which identity model should she use?
JC is deploying AVD session hosts for the Federal Department. They have an existing AD DS forest with 400 Group Policy Objects, and the security team requires full GPO support. The session hosts will run Windows 10 Enterprise multi-session. Which join type can JC use?
Raj is setting up Entra Domain Services for a subsidiary's AVD deployment. The managed domain is provisioned, but hybrid users synced from on-premises AD cannot authenticate. Cloud-only users work fine. What is the most likely cause?
🎬 Video coming soon
Identity Scenarios for AVD
Next up: RBAC, Conditional Access and SSO — how to control who can manage AVD, enforce security policies on connections, and eliminate the double sign-in prompt with SSO.