The WVD Log in process and Active Directory topologies explained
Working at Microsoft as a Windows Virtual Desktop Global Black Belt, a couple of question that I often get asked is "what Active Directory topologies does Windows Virtual Desktop support?", and "how does the user login process work"? This article should hopefully answer both for you.
The TL DR answer is that WVD does not impose any specific Active Directory topology requirements of its own, and will work in any supported topology that you have deployed. However, there are some things that you need to consider when designing a WVD deployment.
As it stands today, access into the Windows Virtual Desktop service and onto the WVD session host, requires authenticating firstly against Azure Active Directory (AAD) and secondly against either Active Directory (AD DS) or Azure Active Directory Domain Services (AAD DS). In addition, there is a service called the "Identity Matching" service that ensures that the actual user is the same person logging in at both points.
The highest level requirement is that the user accounts need to be in both AD and AAD.
In order to get the user identities from Active Directory into Azure Active Directory then the recommended approach is to deploy Azure Active Directory Connect. This will provision user objects from AD up into AAD. Hence, the requirement becomes: user accounts for which you want to consume WVD, need to be in the AD and the AAD that are connected via AAD Connect. These are still two separate authentication requests. This is not Single Sign On, but Same Sign On.
How do we then ensure that it is the same user account signing into the VM that has signed into AAD? That is where this new “Identity Matching” service that is part of the WVD Broker service comes in.
As you are probably aware, Windows Virtual Desktop is a management service owned and operated by Microsoft for our customers. This is an evolution and extension of the pre-existing RDS Roles that ran on top of Windows Server. You have probably seen this graphic before of the WVD management service, but now showing this Identity Matching service:
The Identity Matching service is a component of the Windows Virtual Desktop Broker role which is part of the overall WVD Management service.
The Identity Matching service is there to check the user authenticating to AAD is the same user account signing into the VM and authenticating against Active Directory Domain Services or Azure Active Directory Domain Services. The Identity Matching service integrates with AAD and the WVD Agent running on the session host.
The end to end logon process consists of, the user authenticating against AAD, which will return to the client device an OAUTH JWT Token. That token has three claims: User GUID, UserPrincipalName and on-premise's SID. This token is then used in all subsequent API calls. This token is forwarded to the Broker, where it extracts the UPN and SID (AD does not understand the GUID object). At this point the user is authenticated to AAD but not to AD.
Secondly the token is forwarded to the local WVD agent, as the user authenticates to Active Directory. The service firstly checks, the users UserPrincipalName object. If this matches then access is provided to the WVD session host. If this fails for any reason, then it will fall back to checking the SID. The WVD agent asks the Domain Controller to do a reverse lookup on the users on-prem SID. If this matches then the user object is added to the local Remote Desktop Users group and access is granted onto the Session Host.
This service is dependent upon the user objects existing in both Active Directory and Azure Active Directory. As mentioned the recommended method to provision the Active Directory user objects to AAD is to use Azure Active Directory Connect, however if a third party product is being used then it is important to ensure that the objects mentioned above are part of the synchronisation.
So, what about what that looks like in terms of on-premises Active Directory topologies in particular, multiple domains with trusts?
As mentioned above there is nothing specific about the domain topology, as long as the requirement is met that users exist in a domain that’s synchronised with AAD, and the WVD Session host VM’s have at least line of sight of the domain controllers.
Typically most organisations have their User and Computer objects in the same Active Directory. However many customers would like to have a separate domain/forest located in Azure. This new domain contains the computer objects whilst the original domain contains the user objects, and so creates a level of separation. This type of domain topology does require there to be trusts in place so that the Identity Matching service is able to check the user object properties correctly. Without trusts there is no way to support the user authentication.
This topology looks like the below. The second domain is part of the existing forest and is referred to as a child domain and inherits the "parent" domain name.
The trust relationship is a 2-way transitive trust of type “Child”
The second topology is the tree domain. This is a separate domain effectively in parallel to the existing domain with a separate naming convention but is still part of the same Forest.
The trust relationship is a 2-way transitive trust of type “Tree Root”
The final topology is a separate domain as above but also part of a separate forest.
The trust relationship is of type “External” and there are two directions of trust depending on who you want to trust whom. The minimum for this topology is to have a 1-way incoming, (in the context of the domain with user objects) non-transitive trust.
In terms of Windows Virtual Host pool deployment options for the domain join part of the marketplace of template deployment you can specify either a child domain UPN directly:
Or a root domain UPN with the reference to the child domain FQDN in the “Domain to Join” field
The final piece that always needs to be repeated is to ensure that DNS is configured and functioning correctly, in particular you will need to set the Custom DNS Settings on the virtual network in Azure. If deploying the multiple Forest topology then Conditional Forwarding needs to be configured correctly upon which all of this depends in order to enable this to work correctly.