Azure AD join for Azure Virtual Desktop
Azure Active Directory (Azure AD) provides many benefits for organizations, such as modern authentication protocols, single sign-on (SSO), and support for FSLogix user profiles. Azure Virtual Desktop virtual machine (VM) session hosts can join directly to Azure AD. Joining directly to Azure AD removes an earlier need to use Active Directory Domain Services (AD DS) domain controllers.
Originally, Azure Virtual Desktop domain join needed both Azure AD and AD DS domain controllers. Traditional Windows Server AD DS domain controllers were on-premises machines, Azure VMs, or both. Azure Virtual Desktop accessed the controllers over a site-to-site virtual private network (VPN) or Azure ExpressRoute. Alternatively, Azure Active Directory Domain Services platform-as-a-service (PaaS) provided AD DS in Azure and supported trust relationships to existing on-premises AD DS. Users had to sign in to both Azure AD and AD DS.
Applications, Server Message Block (SMB) storage, and other services that Azure Virtual Desktop hosts consume might still require AD DS. But Azure Virtual Desktop itself no longer requires AD DS. Removing this requirement reduces cost and complexity.
Azure AD domain join for Azure Virtual Desktop provides a modern approach for smartcards, FIDO2, authentication protocols like Windows Hello for Business, and future capabilities. Azure AD domain join also opens up the possibility of decommissioning Active Directory, since Azure Virtual Directory host pools no longer require Active Directory.
This article describes how to configure Azure AD domain join for Azure Virtual Desktop, along with some troubleshooting tips. For most Windows Azure Virtual Desktop clients, the Azure AD join configuration consists of two steps, deploying the host pool and enabling user access. For non-Windows Azure Virtual Desktop clients and other cases that need further configuration, see Protocol and client options.
Prerequisites
Azure Virtual Desktop Azure AD domain join has some limitations:
Azure AD join is only supported on Azure Virtual Desktop for Azure Resource Manager. Azure Virtual Desktop Classic isn't supported.
Azure Virtual Desktop supports Azure AD join for both personal and pooled host pools, except when using FSlogix with an Azure Files account that is also joined to the same Azure AD.
Azure Files now supports Azure AD as a Kerberos realm. This allows you to create an Azure Files share to store the FSLogix profiles and to configure it to support Azure AD authentication. FSLogix is the technology that enables and manages roaming user profiles in a pooled host pool scenario. The added support for FSLogix profiles combines the cost optimization of using a pooled environment shared among users with the key benefits of Azure AD-joined VMs. There is no line-of-sight to a domain controller, it's a simplified deployment, and you get enhanced management with Intune.
The new Azure AD functionality leveraged in this solution allows Azure AD to issue Kerberos tickets to access Service Message Block (SMB) shares. This removes the need to have access to a domain controller from the session host VM and network share. You can now store your FSLogix user profiles on Azure Files shares and access them from Azure AD-joined VMs. This functionality currently requires you to have hybrid identities, managed in Active Directory.
The session hosts must be Windows 10 Enterprise version 2004 or later.
Step 1: Deploy an Azure AD join host pool
To deploy an Azure AD host pool, follow the instructions in Create a host pool. On the Create a host pool screen, on the Virtual Machines tab, under Domain to join, select Azure Active Directory.
To see an option to enroll VMs with Intune, select Azure Active Directory. Select Yes if you want to enroll the VM with Intune.
Intune can apply policies, distribute software, and help you manage VMs. For more information about Intune as part of Microsoft Endpoint Manager, see Getting started with Microsoft Endpoint Manager.
During deployment, a new extension called AADLoginForWindows creates Azure AD join and Intune enrollment, if it's selected.
You can also add session hosts to an existing host pool. Then you can have them Azure AD joined and Intune enrolled.
After you create host pool VMs, you can see the VMs by going to Azure AD and selecting Devices.
To confirm Azure AD registrations, go to Azure Active Directory > Devices > Audit Logs and select Register device.
VMs also appear in the MEM portal, in the Devices section.
If a VM doesn't appear or you want to confirm enrollment, sign in to the VM locally. Then open a command prompt app to run the following command:
dsregcmd /status
The output displays the VM's Azure AD join status.
Azure AD registration logs are in Event Viewer on the local client. You can view them by navigating to Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin.
Note
In earlier AD DS scenarios, you were able to manually deploy session host VMs in all types of subscriptions, even when they were connected to different Azure ADs. VMs had no dependency on Azure AD. They only needed network line of sight to AD DS domain controllers that synchronized user objects to Azure Virtual Desktops' Azure AD.
With Azure AD join, be sure to create VMs in the same subscription as your other Azure Virtual Desktop objects. Host VMs automatically join the subscription of the Azure AD that deploys them and they inherit the Azure AD as their identity providers. This means they that have the same user identities as the Azure AD. There's no way to specify a different Azure AD for host VMs. VMs also automatically enroll in the Intune tenant associated with Azure ADs.
Step 2: Enable user access
In the next step, you enable sign-in access to the VMs. These VMs are Azure objects, and the authentication mechanism is Azure AD. You can manage user sign-in permission through Azure role-based access control (RBAC).
Users must be in the Azure Virtual Desktop Desktop application group to sign in to VMs. For Azure AD join, the same users and groups that are in the Desktop application group must also be added to the Virtual Machine User Login RBAC role. This role isn't an Azure Virtual Desktop role, but an Azure role with Log in to Virtual Machine DataAction permission.
Choose the scope for this role.
- Assigning the role at the VM level means you have to assign the role for every VM that you add.
- Assigning the role at the resource group level means the role automatically applies to all VMs within a resource group.
- Assigning the role at the Subscription level means users can sign in to all VMs within a subscription.
Setting roles once at the resource group level might be the best option. This approach eliminates the need to assign roles for every VM. It also helps you avoid assigning roles at the top level of subscriptions.
To assign the Virtual Machine User Login role:
In the Azure portal, go to your chosen scope, for example the resource group, and select Access control (IAM).
At the top of the screen, select + Add > Add role assignment.
Under Role, select Virtual Machine User Login, and under Select, select the same user group that's assigned to the Desktop Application Group.
The user group now appears under Virtual Machine User Login.
If you don't assign this role, users get an error message when they try to sign in via the Windows client.
Web client users get an error that looks different.
Local Admin access
To give a user local administrative access to a VM, add the user to the Virtual Machine Administrator Login role. This role has a Log in to Virtual Machine as administrator DataAction permission that enables administrative access.
Protocol and client options
By default, host pool access only works from the Windows Azure Virtual Desktop client. To access host pool VMs, your local computer must be:
- Azure AD-joined or hybrid Azure AD-joined to the same Azure AD tenant as the session host.
- Running Windows 10 version 2004 or later, and also Azure AD-registered to the same Azure AD tenant as the session host.
Host pool access uses the Public Key User-to-User (PKU2U) protocol for authentication. To sign in to the VM, the session host and the local computer must have the PKU2U protocol enabled. For Windows 10 version 2004 or later machines, if the PKU2U protocol is disabled, enable it in the Windows registry as follows:
Navigate to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\pku2u.
Set AllowOnlineID to 1.
If your client computers use Group Policy, also enable the Group Policy Option:
Navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.
Under Policy, set Network security: Allow PKU2U authentication requests to this computer to use online identities to Enabled.
If you're using other Azure Virtual Desktop clients, such as Mac, iOS, Android, web, the Store client, or pre-version 2004 Windows 10, enable the RDSTLS protocol. Enable this protocol by adding a new custom RDP Property to the host pool, targetisaadjoined:i:1. Azure Virtual Desktop then uses this protocol instead of PKU2U.
Now you have an Azure Virtual Desktop host pool where session hosts are joined only to Azure AD. You're a step closer to modern management for your Azure Virtual Desktop estate.
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
Principal author:
- Tom Hickling | Senior Product Manager, Azure Virtual Desktop Engineering
Other contributor:
- Grace Picking | Senior Product Manager, Azure Active Directory Engineering
To see non-public LinkedIn profiles, sign in to LinkedIn.
Next steps
- Azure Virtual Desktop documentation
- Deploy Azure AD-joined virtual machines in Azure Virtual Desktop
Related resources
Feedback
Submit and view feedback for