Forum Discussion
Solved
AVD Virtual Machines "Domain to join"
Hi All, When creating an Azure Virtual Desktop host pool on the second step "Virtual Machines" it is required to select domain to join. Could someone please correct me if I'm wrong. ...
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
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.
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.
TomHickling
Microsoft
MicrosoftJust 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
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
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".
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?
- TomHicklingIn 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.
- 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
