Azure Virtual Desktop (AVD) VMs must traditionally domain-join an Active Directory Domain Services (AD DS) environment because AVD relies on certain features and protocols that are deeply rooted in the way traditional AD DS works, which aren’t fully supported by Entra ID (formerly Azure Active Directory, AAD). Here are the key reasons:

1. Legacy Windows Authentication Protocols

  • Kerberos and NTLM Authentication: Many applications and services, including group policies and user profile management, rely on Kerberos and NTLM protocols, which require AD DS. Entra ID does not natively support these legacy protocols.
  • Group Policies: AVD VMs often require group policy objects (GPOs) for centralized management, which are a core feature of AD DS. GPOs allow for detailed management and configuration of Windows settings, security policies, software deployment, and more.

2. Session Host Compatibility

  • Remote Desktop Protocol (RDP): Azure Virtual Desktops are built on Remote Desktop Session Hosts (RDSH), which require domain-joined VMs to enforce user identity management, profile management, and access policies within a Windows Server domain. The integration with AD DS provides compatibility with these traditional Windows components.
  • Profile and Application Management: User profiles, roaming profiles, and folder redirection are often required in multi-session environments like AVD. These mechanisms generally depend on AD DS to manage access to resources such as file shares.

3. Hybrid Identity Scenarios

  • Hybrid Identity Integration: Many organizations use hybrid identity solutions, where their on-premises Active Directory is synchronized with Entra ID using tools like Azure AD Connect. Domain-joining the AVD VMs to AD DS ensures that users can seamlessly access both on-premises and cloud-based resources, such as file shares and printers, using the same set of credentials.
  • Seamless SSO: AD DS provides single sign-on (SSO) across many applications and services that may still rely on traditional AD authentication mechanisms. Entra ID, by itself, is not designed to manage these older systems, making AD DS necessary for environments with legacy needs.

4. Application Compatibility

  • Legacy Applications: Many line-of-business applications used in enterprise environments may require AD DS for authentication and directory services. These applications might not be compatible with Entra ID due to their reliance on on-premises directory services, Kerberos, or NTLM.
  • Application and Resource Access: Domain-joining ensures that AVD VMs can interact with legacy applications that require AD DS-based authentication or access control, ensuring full compatibility with existing infrastructures.

Why Entra ID Alone Can’t Fully Replace AD DS (Yet)

While Entra ID offers modern identity management features such as conditional access, Multi-Factor Authentication (MFA), and cloud-based directory services, it doesn’t yet provide full support for some legacy protocols and services. Microsoft Entra ID (Azure AD) is designed as a cloud-based identity platform that focuses on modern authentication protocols (such as OAuth2 and OpenID Connect) and doesn’t natively support older technologies such as:

  • Kerberos and NTLM
  • Group Policy Management
  • LDAP-based authentication for many applications

Additionally, many enterprises still rely on hybrid environments where on-premises Active Directory and cloud-based Entra ID work together, making the need for AD DS domain-joining necessary for full compatibility.

Looking Forward: Azure AD Join and Azure AD DS

  • Azure AD Join: In some modern scenarios, Microsoft has enabled support for Azure AD-joined VMs for single-session (personal) desktops. This removes the need for traditional AD DS in certain use cases where only modern cloud-native services are required.
  • Azure AD DS (Azure Active Directory Domain Services): Azure AD DS offers a managed domain in the cloud, which mimics many of the traditional AD DS features. This is helpful for organizations looking to migrate away from on-premises AD DS while maintaining support for legacy protocols and applications.

However, while Azure AD Join and Azure AD DS are improving, for multi-session desktops (which is common in AVD scenarios), a full AD DS domain join is still often necessary to ensure compatibility and full functionality.

Conclusion

Azure Virtual Desktop VMs need to domain-join AD DS primarily to support legacy Windows authentication protocols (like Kerberos and NTLM), group policies, and legacy applications that rely on AD DS. While Entra ID provides modern identity management and supports certain newer cloud-based features, it doesn’t fully replace the traditional Active Directory infrastructure in hybrid or legacy environments yet, especially for multi-session virtual desktops.