SOLVED

AVD Virtual Machines "Domain to join"

Copper Contributor

Hi All,

 

When creating an Azure Virtual Desktop host pool on the second step "Virtual Machines" it is required to select domain to join. 

 

 azure-ad-join

Could someone please correct me if I'm wrong.

1) Active Directory here means on-premises Active Directory Domain Services

2) Azure Active Directory here means Azure Active Directory Domain Services

 

Thanks.

9 Replies

Hi @Cloud_Geek_82,

You are right,

  1. Active Directory here means on-premises Active Directory Domain Services: it refers to an on-premises Active Directory Domain Services (AD DS). Choosing this option means that the virtual machines in the host pool will join your existing on-premises Active Directory domain, allowing them to be managed alongside your other on-premises resources.

  2.  Azure Active Directory here means Azure Active Directory Domain Services: it refers to Azure's cloud-based identity and access management service. By selecting this option, the virtual machines in the host pool will join your Azure AD domain, enabling you to manage access and authentication for cloud-based resources and applications.

    Azure AD join for Azure Virtual Desktop - Azure Architecture Center | Microsoft Learn



    Please click Mark as Best Response & Like if my post helped you to solve your issue.
    This will help others to find the correct solution easily. It also closes the item.


    If the post was useful in other ways, please consider giving it Like.


    Kindest regards,


    Leon Pavesic

Hi @LeonPavesic,

Thanks for your prompt reply.
If AVD host pool virtual machines are joined to a domain in Azure Active Directory then is clear how it works.
However, I don't understand how virtual machines in Azure can be joined to on-premises Active Directory. How Azure might know about on-premises Active Directory?

Thanks.
best response confirmed by Cloud_Geek_82 (Copper Contributor)
Solution

Hi @Cloud_Geek_82 

Just a point of clarification here.
There are three types of directories you can join. Each is different and worth some time reading the documentation on each to understand. 1. Active Directory aka Active Directory Domain Services (AD DS), Azure Active Directory Domain Services (ADD DS), and Azure Active Directory (AAD)
1. Active Directory. This is the top option in the drop down. This uses the acronym of AD DS. This is a traditional Virtual Machine based Active Directory Domain Services. i.e., VM's running the Domain Controller AD service. The AVD session hosts need network line of sight to wherever you choose to place those AD DC VMs. That could be in Azure on the same Virtual Network as the session hosts or on a separate vNet that has peering enabled. Or it could be back on-premises, but for this you will need some private network connectivity such as ExpressRoute or a Site to Site VPN, (there are plenty of docs on the learn site to show how to do this). You need to specify the DNS servers assigned to the vNet that your session hosts are on in order for the DNS lookup to work to find the DC and do the domain join during the deployment of your session hosts.
2. Azure Active Directory Domain Services. This is also the top option in the drop down. This uses the acronym of ADD DS. This is an optional PaaS based managed Active Directory service that is tied to your Azure Active Directory (AAD). (By the way Azure Active Directory has been renamed to Entra ID). With AAD DS Microsoft will create two Domain Controllers and manage those i.e., you can’t access them locally or see them as VM's in your subscription. But you can consume the AD DS service that they provide. This option is designed for customers that don’t have or don’t want to use their existing AD, but still need Directory Services in Azure for application control etc. You also need to specify the IP’s of the 2 DC’s that get created in the DNS settings of the vNet to enable DNS and Domain Join to this directory.
3. Azure Active Directory – now Entra ID. This is the second option in the drop down. This uses the acronym AAD. This is true native Azure Active Directory services, not to be confused with AD DS or AAD DS mentioned above. This is a cloud only directory located in the Microsoft cloud. You can now join Windows natively to AAD and sign with AAD credentials only. Optionally you can replicate you existing on-prem user objects from AD to AAD to maintain single identities in the cloud as well as on-prem.

HTH
Tom

@Cloud_Geek_82 

Yes, your understanding is correct

@TomHickling 

 

Thank you very much for such a comprehensive explanation. 

Now this section is clear for me and I wish Microsoft would give the same clarity regarding "Domain to join" in the articles related to Azure Virtual desktop.

If you don't mind one more question.

When a Remote App Group is created one of the steps is Assignment where it is required to specify which users are allowed to access that Remote App Group.

While going through official documentation, watching video and checking myself in Azure portal I noticed that this steps is always the same "+ Add Azure AD users or user groups".

 

Screenshot 2023-07-19 212046.jpg

Unfortunately, I don't have a chance to check it in some sandbox so just wondering if my host pool virtual machines are joined to Active Directory Domain Services (AD DS) or Azure Active Directory Domain Services (AAD DS) would I get the list of AD DS \ AAD DS users or at this stage I would have a choice of only Azure Active Directory users?

"You can quickly deploy Azure Virtual Desktop with the getting started feature in the Azure portal. This can be used in smaller scenarios with a few users and apps, or you can use it to evaluate Azure Virtual Desktop in larger enterprise scenarios. It works with existing Active Directory Domain Services (AD DS) or Azure Active Directory Domain Services (Azure AD DS) deployments, or it can deploy Azure AD DS for you. Once you've finished, a user will be able to sign in to a full virtual desktop session, consisting of one host pool (with one or more session hosts), one application group, and one user. To learn about the terminology used in Azure Virtual Desktop, see Azure Virtual Desktop terminology. Joining session hosts to Azure Active Directory with the getting started feature is not supported. If you want to want to join session hosts to Azure Active Directory, follow the tutorial to create a host pool." https://learn.microsoft.com/en-us/azure/virtual-desktop/getting-started-feature?tabs=new-aadds Azure AD Join Device https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-join
Since users must be discoverable through Azure Active Directory (Azure AD) to access the Azure Virtual Desktop, user identities that exist only in Active Directory Domain Services (AD DS) aren't supported. This includes standalone Active Directory deployments with Active Directory Federation Services (AD FS).

https://learn.microsoft.com/en-us/azure/virtual-desktop/authentication
In this context whenever you look up users for App groups the user objects you are seeing are the Azure Active Directory users. THe actual user objects could be "cloud only" I.e. created natively in AAD, or sync'ed from Active Directory.

@TomHickling 

Does Entra ID connect is a must for running AVD on Azure Stack HCI 23H2 using Local AD DS? 

 

I encounter Gateway error in my recent POC deployment.

 

Regards,

Kho 

1 best response

Accepted Solutions
best response confirmed by Cloud_Geek_82 (Copper Contributor)
Solution

Hi @Cloud_Geek_82 

Just a point of clarification here.
There are three types of directories you can join. Each is different and worth some time reading the documentation on each to understand. 1. Active Directory aka Active Directory Domain Services (AD DS), Azure Active Directory Domain Services (ADD DS), and Azure Active Directory (AAD)
1. Active Directory. This is the top option in the drop down. This uses the acronym of AD DS. This is a traditional Virtual Machine based Active Directory Domain Services. i.e., VM's running the Domain Controller AD service. The AVD session hosts need network line of sight to wherever you choose to place those AD DC VMs. That could be in Azure on the same Virtual Network as the session hosts or on a separate vNet that has peering enabled. Or it could be back on-premises, but for this you will need some private network connectivity such as ExpressRoute or a Site to Site VPN, (there are plenty of docs on the learn site to show how to do this). You need to specify the DNS servers assigned to the vNet that your session hosts are on in order for the DNS lookup to work to find the DC and do the domain join during the deployment of your session hosts.
2. Azure Active Directory Domain Services. This is also the top option in the drop down. This uses the acronym of ADD DS. This is an optional PaaS based managed Active Directory service that is tied to your Azure Active Directory (AAD). (By the way Azure Active Directory has been renamed to Entra ID). With AAD DS Microsoft will create two Domain Controllers and manage those i.e., you can’t access them locally or see them as VM's in your subscription. But you can consume the AD DS service that they provide. This option is designed for customers that don’t have or don’t want to use their existing AD, but still need Directory Services in Azure for application control etc. You also need to specify the IP’s of the 2 DC’s that get created in the DNS settings of the vNet to enable DNS and Domain Join to this directory.
3. Azure Active Directory – now Entra ID. This is the second option in the drop down. This uses the acronym AAD. This is true native Azure Active Directory services, not to be confused with AD DS or AAD DS mentioned above. This is a cloud only directory located in the Microsoft cloud. You can now join Windows natively to AAD and sign with AAD credentials only. Optionally you can replicate you existing on-prem user objects from AD to AAD to maintain single identities in the cloud as well as on-prem.

HTH
Tom

View solution in original post