This is an important key question before you start modernizing your on-premises Virtual Desktop infrastructure and moving workloads to Microsoft Azure. I have seen a lot of projects failing during the proof of concept because during the architecture phase of the environment there was no clear concept on how to handle the various machine identity options. Up front: There is no right or wrong, or as we consultants like to say: It depends.
Back in the days when Virtual Desktops or Remote Desktop Session Hosts have only been build on VMware, Hyper-V, XenServer or other hypervisor platforms we only had one option to take care of the machine identity. You had to domain-join your machines (Active Directory) otherwise the authentication for the users wouldn’t work, there would be no possible communication for the broker components, no accessible file shares for roaming profiles or profile container.
When a company thinks about moving Virtual Desktop workloads to Microsoft Azure, it is important to understand the options you have regarding the machine identities. It doesn’t matter if you want to go the full Azure Virtual Desktop road or aim for a hybrid scenario with Citrix DaaS or Parallels Remote Application Server.
Lets take a closer look on the machine identity options we have when working with Azure AD or Entra ID.
| Identity | Description |
| Azure AD | Your Virtual Machines are only joined to Azure AD. There is no session host connection to your Active Directory Domain. |
| Azure AD Hybrid-Join | Your Virtual Machines are joined to Azure AD and the existing on-premises Active Directory Domain. This requires connectivity to your datacenter(s) via ExpressRoute or VPN Gateway. |
| Azure Active Directory Domain Services (Azure AD DS) | Your Virtual Machines are joined to a “classic” Active Directory Domain. The big difference is in this case, that these Domain Controllers are managed by Microsoft (PaaS-Offering) and come with a lot if limitations especially for VDI deployments. |
The question you should ask yourself and the people who are working with you on project is: What is the use-case for building the environment? In most of the cases this is not an easy answer (depending on the size of the company). Maybe most of the employees working on the existing production VDI platform to access their daily needed line-of-business aps and the wish is to migrate this workload to Microsoft Azure to benefit of cloud capabilities like an OpEx model and the possibility of faster up and down scaling. In this case the handling of machine identities can be different compared to a solution for partners or contractors which allows them to access the infrastructure for providing an entry point into the datacenter. This provides the capability to reach needed web services (which are not published to the internet) or gives them the right to make Remote Desktop or SSH Connections to infrastructure systems they need to configure and maintain.
The following table will give you a summary of the features which are available depending on the chosen machine identity. Depending on your outcoming desires this should give a decision matrix which is the way you should take.
| Identity | Hybrid Join | Conditional Access | Intune Management | MSIX Support | ADMX Customizing | Schema Extensions | Domain-Trust | PKI Support | GPO Management | Windows 365 Support | NTLM/Kerberos | SSO AVD | SSO Windows 365 |
| Azure AD DS | No | No | No | No | No | No | Yes (One-Way only!) | No | Yes | No | Yes | No | No |
| Azure AD | Yes | Yes | Yes | Yes | No | No | No | No | No | Yes | Limited | Yes | Yes |
| Active Directory | Yes | Yes (Hybrid) | Yes (Hybrid) | Yes | Yes | Yes | Yes (Two-Way) | Yes | Yes | Yes | Yes | Yes (Hybrid) | No (Hybrid) |
To give you some further ideas and questions (based on the table above) how to decide on the right identity type.
- Always start with making an assessment of the used applications and their characteristics. Is there a co-existence to other infrastructure systems? What network ports are being used for the frontend client? How is the authentication working? Do you need Active Directory domain connectivity for making NTLM or Kerberos work? Is the application performance the same when running on Azure? Does the backend system (SQL, File Services) need to be re-hosted as well?
- Do you want to make use of Conditional Access when accessing services from inside the Virtual Desktop? Example: Provide Single-Sign-On to Enterprise Apps because the users are requesting the service from a trusted location.
- Is the modern workplace strategy to use Microsoft Intune to manage the Virtual Desktops? Keep in mind that you need to use Azure AD or a Azure AD Hybrid Joined device in this case.
- Do you want to make use of MSIX App-Attach?
- Do you rely on custom Active Directory schema extensions which are needed to host your workloads?
- Are you having multiple Active Directory domain-forest and you need to create two way trusts for making things work?
- Are you using Citrix Federated Authentication Service (FAS) or Parallels RAS Enrollment Server to provide a Single-Sign-On Experience (Smartcard Authentication) for the users? If this would be the case Azure AD DS would be out of question because you can not make use of the Active Directory Certificate Service.
- How do you want to handle the customization of the user environment? Should this be done with Microsoft Intune? Can it be done with Intune? Do you want stick to the good old Microsoft Group Policy Management? Maybe even use a 3rd party tool for this like the Citrix Workspace Environment Manager or VMware Dynamic Environment Manager? Is the used tool compatible with the machine identity type?
- Do you want to deploy Windows 365 (Cloud PC) for the users?
- Is Single-Sign-On to Azure Virtual Desktop (Session Hosts) and Windows 365 required? Please note that SSO is still in technical preview for both of the solutions when publishing this blog.
I hope this post will give you a better understanding of machine identities and the importance of doing homework before starting with the deployment of virtual desktops on Microsoft Azure. My personal opinion on the right identity is to work with an Azure Hybrid Join. This eliminates a lot of limitations and gives you the flexibility to make use of Group Policy Management, Intune Application Deployments and provide SSO to the users. On the other side I have seen companies who are trying hard to eliminate their Domain Controller infrastructure with every workload which has been moved to Azure. In most of the cases this are web services which are being containerized or rebuild from scratch to make use of Kubernetes and cloud native services. You just need to keep it mind, that VDI is still connected to a lot of legacy systems and I am sure that Active Directory will exist for at least two more decades.
If you have further points or feedback feel free to reach out via the comment section or Twitter and I will update the article.
Photo by Andrea Piacquadio: https://www.pexels.com/photo/man-showing-distress-3777572/
Hi there, good informations,
what do you mean by PKI support in the table ? Do you mean there is (or not) a native PKI solution available ?
Hi Stephane you are not able to install an Active Directory Integrated Certificate Authority into that domain which is needed for Citrix FAS or Parallels Enrollment Server.