Azure Virtual Desktop Domain Join: AD DS vs. Entra ID

Can Azure Virtual Desktop Join a Corporate Windows Active Directory Domain?

Yes. Azure Virtual Desktop session hosts can be joined to an organization’s existing Windows Server Active Directory Domain Services environment.

This is a common architecture for organizations that want users working from Azure-hosted virtual desktops to continue accessing:

Corporate file shares
Legacy applications
Windows-integrated applications
Network printers
SQL Server databases
Internal websites
Group Policy settings
Kerberos- or NTLM-based resources

However, several Microsoft identity services are involved, and their names are easily confused. It is important to distinguish among:

Active Directory Domain Services, or AD DS
Microsoft Entra ID, formerly Azure Active Directory
Microsoft Entra Domain Services
Microsoft Entra Connect
Microsoft Entra Kerberos

These services perform different functions.

Understanding the Basic Architecture

An Azure Virtual Desktop environment consists of one or more Azure virtual machines called session hosts. These session hosts provide the Windows desktops and applications that users access remotely.

For Azure Virtual Desktop, two identity decisions must be made:

How users authenticate to the Azure Virtual Desktop service.
How the session-host virtual machines are joined and managed.

Microsoft Entra ID is always used to authenticate users to Azure Virtual Desktop. The session hosts themselves can then be joined to:

A corporate Active Directory Domain Services domain
Microsoft Entra ID
Microsoft Entra Domain Services

Microsoft documents these supported models in the Azure Virtual Desktop prerequisites.

Option 1: Join the Azure Virtual Desktop Hosts to Corporate AD DS

In the traditional hybrid model, the Azure Virtual Desktop session hosts are joined to the same Active Directory domain used by the organization’s on-premises computers and servers.

The domain controllers can be located:

In an on-premises data center
On Azure virtual machines
In both locations for availability and disaster recovery

The Azure virtual network containing the session hosts must have network connectivity to the domain controllers. This connectivity is commonly provided through:

Site-to-site VPN
Azure ExpressRoute
SD-WAN
Azure Virtual WAN
Network virtual appliances

The session hosts must also use DNS servers that can locate the Active Directory domain and its domain controllers.

How Identity Synchronization Works

In this model, user accounts are normally created and managed in the corporate Windows Server AD DS environment.

Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync then synchronizes the required user identities and attributes to Microsoft Entra ID.

The architecture therefore looks like this:

Identity source: Corporate Windows Server AD DS
Cloud identity: The AD DS identities are synchronized to Microsoft Entra ID
Azure Virtual Desktop authentication: Microsoft Entra ID
Session-host join: Corporate AD DS
Traditional resource access: Kerberos or NTLM through AD DS
Management: Group Policy, configuration-management tools, and optionally Intune through hybrid join

Users authenticate to Azure Virtual Desktop with their Microsoft Entra identity. Once connected, they can use their corresponding AD DS identity to access domain-based resources.

Advantages of Corporate AD DS Join

Joining the session hosts to the existing corporate domain provides the highest compatibility with traditional Windows environments.

It supports:

Existing Group Policy Objects
Kerberos authentication
NTLM authentication where still required
AD-based software deployment
Existing service accounts
Traditional Windows file servers
Domain-based application authentication
Existing organizational units and administrative policies
Legacy applications that depend on domain membership
Machine authentication using an AD computer account

This is often the simplest migration path when virtual desktops must behave like existing corporate workstations.

Requirements

The design requires:

Network connectivity from Azure to the domain controllers
Correct DNS resolution
Appropriate firewall rules
Reliable connectivity to AD DS
Synchronized user identities in Microsoft Entra ID
Sufficient permissions to join the session hosts to the domain
Time synchronization for Kerberos
Resilient domain-controller placement

If the session hosts depend entirely on on-premises domain controllers, a VPN or ExpressRoute outage could affect user sign-in and resource access. Many organizations therefore deploy additional domain controllers on Azure virtual machines.

Option 2: Join the Session Hosts Directly to Microsoft Entra ID

An organization does not have to join Azure Virtual Desktop session hosts to a traditional AD DS domain. The session hosts can instead be joined directly to Microsoft Entra ID.

This is called Microsoft Entra join. It was previously called Azure AD join.

This model is useful for organizations that:

Are moving toward cloud-native identity
Do not require extensive Group Policy
Manage devices through Microsoft Intune
Primarily use cloud applications
Want to reduce dependence on traditional domain controllers
Use Microsoft Entra Conditional Access
Are modernizing legacy application and file services

An important terminology distinction is that the session host is not being joined to an “Azure AD domain.” Microsoft Entra ID is a cloud identity and access-management service, not a conventional Windows Server AD domain.

Does Entra Join Prevent Access to On-Premises File Shares?

No. Joining a session host to Microsoft Entra ID does not automatically prevent access to on-premises file servers.

Microsoft Entra-joined Windows devices can obtain single sign-on to AD DS-based file shares and applications when:

The user has a hybrid identity synchronized from AD DS
Microsoft Entra Connect or Cloud Sync synchronizes the necessary attributes
The device has network connectivity to the domain controllers
DNS can locate the domain and resources
Kerberos or NTLM requirements are satisfied
The application relies on user authentication rather than AD machine authentication

Microsoft confirms that Entra-joined devices can access UNC paths and other AD DS resources when the required identity synchronization and domain-controller connectivity are available. Microsoft Entra SSO to on-premises resources

However, applications that require the computer itself to possess an AD DS computer account may not work from an Entra-only joined session host.

Therefore, moving to Entra join does not necessarily require every on-premises file share to be reproduced in Azure. It depends on the application, authentication method, network connectivity, and whether machine authentication is required.

Option 3: Join the Session Hosts to Microsoft Entra Domain Services

Microsoft Entra Domain Services is a Microsoft-managed domain service.

It provides traditional domain capabilities such as:

Domain join
Kerberos
NTLM
LDAP
Group Policy
Organizational units

Microsoft operates and maintains the underlying domain controllers. The customer does not directly manage or patch them.

Users and groups are synchronized from Microsoft Entra ID into the managed domain.

This option can be useful when applications require traditional domain protocols but the organization does not want to deploy or manage Windows Server domain controllers in Azure.

However, Microsoft Entra Domain Services is not simply another name for Microsoft Entra ID. It is a separate managed service that provides AD-compatible domain functionality.

Accessing Corporate File Shares from Azure Virtual Desktop

There are two broad file-share scenarios:

Accessing an existing Windows file server
Accessing an Azure Files SMB share

The identity and network requirements differ between them.

Accessing an Existing On-Premises Windows File Server

An Azure Virtual Desktop session host can access an on-premises SMB file share if it has:

Network connectivity to the file server
DNS resolution for the file server and AD domain
Appropriate routing and firewall rules
A valid user identity recognized by AD DS
Required Kerberos or NTLM connectivity
File-share and NTFS permissions

Corporate AD DS-joined session hosts usually provide the most straightforward experience because both the user and computer participate directly in the domain.

Microsoft Entra-joined hosts can also provide user-based single sign-on to on-premises file shares when the user has a synchronized hybrid identity and the session host has line-of-sight connectivity to an AD DS domain controller.

Accessing Azure Files from Azure Virtual Desktop

Azure Files provides managed SMB file shares hosted in an Azure storage account. These shares can be mapped in Windows much like a conventional network drive.

Azure Files supports three identity sources for SMB access:

Active Directory Domain Services
Microsoft Entra Domain Services
Microsoft Entra Kerberos

Only one identity source can be enabled for identity-based SMB authentication on a particular storage account at a time. Azure Files identity-based authentication overview

Azure Files with Corporate AD DS Authentication

In this model, the storage account is represented in the corporate AD DS environment.

Users authenticate to Azure Files using their AD DS identities. Domain controllers may be located on-premises, on Azure virtual machines, or in both locations.

Requirements generally include:

AD DS synchronized with Microsoft Entra ID
Network connectivity to the domain controllers
DNS resolution
Hybrid user identities
Share-level authorization
Directory- and file-level permissions

Microsoft recommends domain-joining client machines or virtual machines for the most seamless user experience. Clients that are not domain joined may still work in supported scenarios if they have unrestricted connectivity to the appropriate domain controllers and users provide valid credentials.

Azure Files with Microsoft Entra Domain Services

Azure Files can use Microsoft Entra Domain Services for Kerberos-based SMB authentication.

The most straightforward design is to join the Azure Virtual Desktop session hosts to the Microsoft Entra Domain Services managed domain.

Microsoft also documents limited access from non-domain-joined virtual machines when they have uninterrupted network connectivity to the managed domain controllers, usually through appropriate VNet connectivity or VPN. Domain join remains the more conventional configuration. Microsoft Entra Domain Services with Azure Files

Azure Files with Microsoft Entra Kerberos

Microsoft Entra Kerberos allows Azure Files to authenticate hybrid or cloud-only identities using Kerberos tickets issued through Microsoft Entra ID.

This option is particularly useful for:

Microsoft Entra-joined Azure Virtual Desktop hosts
Cloud-native identity environments
FSLogix profile containers
Environments that want to reduce domain-controller dependency

For cloud-only identities, Azure Files no longer requires a traditional domain controller for user authentication and authorization. Supported clients must be Microsoft Entra joined or hybrid joined and must meet Microsoft’s operating-system and configuration requirements. Microsoft Entra Kerberos authentication for Azure Files

Azure Files Requires Two Levels of Authorization

Successful authentication does not automatically grant access to data. Azure Files generally requires permissions at two levels.

Share-Level Permission

Share-level access is commonly assigned through Azure role-based access control.

Examples include:

Storage File Data SMB Share Reader
Storage File Data SMB Share Contributor
Storage File Data SMB Share Elevated Contributor

Directory- and File-Level Permission

Within the share, Windows access control lists determine access to individual folders and files.

These permissions are similar to NTFS permissions on a traditional Windows file server and can include:

Read
Write
Modify
Full control
Inherited permissions
User- and group-specific permissions

A user must have sufficient permissions at both levels.

Can File Explorer Be Used to Assign Permissions?

Yes, Windows File Explorer can be used to configure directory- and file-level permissions in supported identity configurations.

An administrator can:

Mount the Azure file share.
Open the share in File Explorer.
Select a folder or file.
Open Properties.
Select the Security tab.
Add users or groups and assign the required permissions.

However, support depends on the identity model.

With AD DS authentication, the administrative workstation generally needs appropriate domain connectivity and permissions.

With Microsoft Entra Kerberos and hybrid identities, File Explorer can be used when the storage account is configured with the required AD domain information. For cloud-only identities, Microsoft currently documents limitations on using File Explorer to configure directory- and file-level permissions. Other supported tools and procedures may be required.

Comparing the Three Session-Host Join Options

Join model	Identity location	Traditional AD protocols	Group Policy	On-premises file-share access	Best suited for
Corporate AD DS join	AD DS synchronized to Entra ID	Yes	Yes	Most direct	Hybrid and legacy enterprise environments
Microsoft Entra join	Entra ID	Limited to supported SSO scenarios	No traditional domain GPO	Possible with hybrid identities and domain connectivity	Cloud-first and modern-management environments
Microsoft Entra Domain Services join	Entra ID synchronized to a managed domain	Yes	Yes, with limitations	Possible with required connectivity and identity design	AD-compatible applications without self-managed domain controllers

Which Option Should an Organization Choose?

Choose corporate AD DS join when:

Existing applications require domain-joined computers
Traditional Group Policy is heavily used
On-premises file shares remain important
Kerberos and NTLM compatibility is required
Existing administrative tools depend on AD DS
The organization wants the Azure desktops to operate like corporate workstations

Choose Microsoft Entra join when:

Applications are primarily cloud based
Devices are managed through Intune
The organization wants cloud-native identity
Traditional machine authentication is not required
Azure Files can use Microsoft Entra Kerberos
On-premises resources can support Entra-joined-device SSO

Choose Microsoft Entra Domain Services when:

Applications require LDAP, Kerberos, NTLM, or domain join
The organization does not want to manage domain-controller virtual machines
Users and groups already exist in Microsoft Entra ID
The limitations of the managed domain are acceptable

Summary

Yes, Azure Virtual Desktop session hosts can be joined to a corporate Windows Server Active Directory Domain Services domain.

In a typical hybrid configuration:

User identities originate in corporate AD DS.
Microsoft Entra Connect or Cloud Sync synchronizes the identities to Microsoft Entra ID.
Microsoft Entra ID authenticates users to Azure Virtual Desktop.
The session hosts are joined to corporate AD DS.
Users access file shares and legacy applications through Kerberos or NTLM.

The principal alternative is Microsoft Entra join, not “joining an Azure AD domain.” Entra-joined session hosts can still access many on-premises resources when hybrid identities, DNS, network connectivity, and supported authentication are properly configured.

Microsoft Entra Domain Services provides a third option for organizations that need traditional domain capabilities without operating their own domain controllers.

The right design depends on whether the environment requires legacy application compatibility, Group Policy, machine authentication, on-premises file shares, Azure Files, FSLogix profiles, or a fully cloud-native identity model.

Domain joining an Azure VDI to a corporate Windows Server AD