AVD and Azure Active Directory Domain Join public preview
On Wednesday July the 14th 2021 we announced the public preview of Azure Active Directory domain join for Azure Virtual Desktop.
This post discusses how to set this up and troubleshooting tips.
Let's, just start with some background.
Azure Active Directory Join for the Azure Virtual Desktop session hosts has been the number one feature request from customers from day one of Windows Virtual Desktop as it was known at launch, followed very closely by Microsoft Endpoint Manager - specifically Intune managing those session host Virtual machines.
This public preview brings both of those capabilities.
Why are we doing this?
Currently AVD requires both Azure Active Directory (AAD) as well as traditional Active Directory Domain Services (AD DS). AD DS can come in one of two formats:
- Traditional AD DS from Windows server. The AD DS domain controllers can either be located on-prem and accessed over a site-to-site VPN or ExpressRoute. Or they can be virtual machines located within Azure itself, or both. All AVD needs is network line of sight to a domain controller, to facilitate the VM domain join at deployment time and to perform the user authentication.
- Azure Active Directory Domain Services (AAD DS), which is a Microsoft managed PaaS service to provide AD DS inside of Azure. Customers do not manage the virtual machines for this service and was originally designed for just cloud only organisation but has had recent updates to support trust relationships to existing on-prem AD DS. This service has a number of limitations and hence is worth fully understanding these by reading the AAD DS documentation here
Firstly, AAD is used to authenticate users to the AVD service and present the user with a list of resources. Secondly as the session hosts are all AD DS joined and hence, we need AD DS and will prompt users to sign-in to AD DS as well as AAD. This is a standard Kerberos authentication.
You can save both the AAD credentials using the standard AAD process for this which will keep those credentials for 90 days, as well as the AD DS credentials in the local Credential Manager via the Windows Remote Desktop client. With both of these saved it appears to be Single Sign On (SSO) like, in that users will not be prompted for a password after the first authentications have completed. Caching the AD DS credentials is currently only supported in the Windows clients.
Having the ability to AAD Join (AADJ) the AVD Session host VMs only to AAD obviously stops the requirement to have AD DS Domain Controllers available at all (in this scenario). This will reduce your costs and complexity. However, AD DS may well still be required for other services that still depend on it such as applications, SMB storage services etc. These may well be being consumed from the AVD session hosts. However, for AVD itself, very specifically AD DS is no longer a requirement.
But that's not all, it will also introduce new modern authentication protocols such as Windows Hello for Business, Smartcards etc. and provide a more modern approach for the future. It will also in the future provide a wide range of addtional capabilities in this space.
Thats a brief background, lets now look how to set this up.
There are two, maybe three steps, depending on your existing configuration
Step 1: Deploy an AADJ host pool.
Firstly, there are a few limitations, namely:
- AADJ is only supported on AVD ARM, AVD Classic is not supported.
- Host pools must be in the validation environment.
- FSLogix is not yet supported.
- The session hosts need to be Windows 10 Enterprise 2004 or later.
Which AAD will these VMs join?
So that is how you deploy a host pool where the VMs are AADJ and enrolled in Intune. Everything else from an AVD perspective looks and behaves the same.
You can see these VMs in both AAD > Devices:
This now opens up all the capability in Intune to apply policies, distribute software etc. and manage these VMs. If you want to learn more on Intune as part of Microsoft Endpoint Manager then take a look at this getting started guide.
Whilst on the local client, the logs are within Event Viewer in: Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin
Step 2. Enabling User access
The next step is a new step, we have to enable access to logon to the VMs. These VM's are Azure objects, the authentication mechanism is Azure AD and hence the permission to allow the users to login is managed via Azure RBAC.
To enable users to login on to the VMs themselves they need to be added to the Desktop Application Group, as per normal. However you also need to add the same AAD group as you have added to the AVD Desktop Application group to the "Virtual Machine User Login" RBAC role.
This role has the following Data Action permission:AVD specific built-in role, but an Azure role.
You have three scopes you could assign it: the VM(s), the resource group that contains the VMs or the subscription.
Assigning at the VM will mean you need to do this multiple times for all the VMs you may end up with.
Assigning it at the resource group once means it will apply to all VMs in that resource group
Assigning it at the Subscription level once means users can login to all VMs in the subscription.
It may be best to set this once at the resource group as I typically see customers creating a host pool in its own resource group. This saves assigning it for every VM whilst not assigning it at the top level of the subscription.
To assign this role go to your scope i.e., the Resource Group and Select Access control (IAM)
At the top click on + Add > Add role assignment
Then in Role select Virtual Machine User Login and then in Select find your user group. This should be the same user group that is assigned to the Desktop Application Group.
If you do not assign this role the user will receive this error message when trying to login via the Windows client:
If using the Web client the error will look different:
If you wanted to give the user local admin access on the VM then add them to the "Virtual Machine Administrator Login" role.
Step 3: Protocol and client choice
Out of the box accessing the host pool by default only works from the Windows AVD client. This will be using the Public Key User to User (PKU2U) protocol for authentication.
This also requires that your local PC is either:
- Azure AD joined to the same Azure AD tenant as the session host.
- Hybrid Azure AD joined to the same Azure AD tenant as the session host.
- Running Windows 10 2004 or later and is also Azure AD registered to the same Azure AD tenant as the session host.
For historical reasons some customers disable the PKU2U protocol and this needs to be enabled on the session host and the local PC in this scenario, or you will not be able to login to the VM. To do this in the registry navigate to:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\pku2u -> confirm AllowOnlineID is set to 1
If your client computers are using Group Policy then this is the GPO to enable: