Clarification on Azure AD DS domain suffix vs on-prem Domain syncing?


I'm looking to setup WVD in Azure and have them connected to  Azure AD DS, and allowing users to connect via their AD credentials that originally are naturally syncing from on-prem AD to Azure AD to Azure AD DS...


  1. Is that supported? 
  2. When I create an Azure ADDS, will it match the same as my on-prem If not, how will that interfere with user's logging in? Will they be able to use their instead of some tenant domain name? 
  3. Our Azure redirects to Okta for SAML/SSO. Will Windows Virtual Desktop honor that authentication? Or will it require directly logging in with the synced credentials or require Azure login? 
8 Replies

@John Quile : To answer your questions:

  1. Yes, that is supported, as long as you enable Password Hash Synchronization (PSH), which allows the newly created Azure AD DS to verify credentials. If you do not want to enable PSH, then you can try out Azure AD DS's latest preview, which is resource forests.
  2. There's some Azure AD DS guidance here, so I would rather defer to that team's guidance than misspeak.
  3. Ultimately, Windows Virtual Desktop has two primary authentication prompts:
    1. Front-end Azure AD to download the feed / login to the client. If your Azure AD is set to federate, then authentication follows that. Everything would work like it normally would when challenged to Azure AD.
    2. Back-end Windows login. This is where it's important to set up the domain (or Azure AD DS correctly) so your users can enter those credentials to the VM like a normal RDP prompt, and so the VM can process those and perform the login.

Hope that all helps!

@John Quile 


I kinda answered some of this here:


this is a good reference for domains:


I went cloud only but covered off some hybrid stuff that may help answer some questions.

@Christian_Montoya ,

Thanks for your follow-up with that. So I definitely would want an easier logon process. For WVD I don't think we'd be seeing .rdp files or RDP connections but I may be wrong. But we have Okta and I believe they have a client that installs on systems to prompt for Okta MFA upon logging into an RDP session. 


As for the Azure AD DS hybrid approach. When I go to create an AD DS instance and network, is it going to let me pick the same domain as the on-prem AD one that it's ultimately syncing from? Or does it haev to be a different unique one that doesn't factor into a user's username and that users would never see? 

I wouldn't want users having to login as or whatever, nor having to map their corp creds to different creds for SAML assertion. 

@John Quile 

Yes you can use any domain like you can on prem but best practice is to use a sub domain of your on prem domain to avoid confusion and DNS issues. You login to AADDS as domain\user (i.e.\first.last where your AD user is typically


The domain you have on prem is a completely different domain from what AADDS uses. They are two separate domains with different user GUIDs. You sync to Azure AD, Azure AD syncs to AADDS but they don't share the same NTLM GUID.

@Robert Crane 

So does that mean a user logging into an Azure resource or WVD that's authenticating against Azure AD DS is having to type a different username?

What is the point of Azure AD Connect syncing to Azure AD and that syncing to Azure AD DS? syncs to Azure AD as 

Why does it have to be on the second sync to Azure AD DS? That's not a true "sync" as I understand it...?

@John Quile 

It means that WVD needs an NTLM style authentication. It gets this from a Domain Controller either as a VM or via on premises OR via Azure AD DS which is a DC as a service (i.e. a DC without you having to worry about physical or virtual infrastructure).


if you use Azure AD DS you need to get the users from somewhere as Azure AD DS doesn't manage identity, it simply provides 'domain services'. With Azure AD DS user identities come from Azure AD, which Azure AD DS connects to.


The reason you would use Azure AD Connect and sync users from on premises is so that they would appear in Azure AD which when enabled with Azure AD DS means that they are then also available there. Thus, you would sync users to Azure AD from on premises so you could use the name login/password with Azure AD DS. However, you could also readily use a site to site VPN from on premises to Azure to work with WVD. Doing so would mean you wouldn't need Azure AD DS as NTLM identity is then coming from on premises across the VPN.


Azure AD is not the same as Active Directory you find a with a Windows domain controller, When you link Azure AD DS to Azure AD you MUST establish a new NTLM domain, independent of any you have. When you create this new NTLM domain you could give it the same name as you have already BUT they are still not linked. Best practice is to make this new NTLM domain a sub domain of the one you are already using per the document I reference to avoid DNS issues.


For example, if you use Azure AD DS you MUST create a new NTLM domain. If you use the same name then when traffic gets routed via DNS does it routed to the name space of Azure AD, with your domain or the new NTLM Azure AD DS you created with exactly the same name? That is why it is best practices to make the new NTLM domain used with Azure AD DS different from any other domain you have in place. Again, it is a best practice not a requirement.


In essence is comes down to the fact that Azure AD is not the same as traditional NTLM domains you find on premises with Windows Active Directory. Unfortunately currently, WVD needs an NTLM domain to work. This then has to either come from on premises via a VPN (because the NTLM stuff is what is needed, Azure AD Connect doesn't sync all this NTLM stuff to Azure AD) or via Azure AD DS (which supports the NTLM stuff without you needing to spin up a Windows Server domain controller).


Another way to think about is back in the good old days, when you created an AD on prem MS recommended that you made the domain different from the domain you used on the Internet i.e. domain.local. That way, traffic inside the network went via domain.local and stuff to the internet went via Same kinda thing here.


It is kinda hard to explain here but at it's core, as I said, it is because Azure AD is not the same as Windows Server AD and WVD still needs the older style Windows Server AD to work. Thus, give WVD requires an NTLM domain to work best practice (although not a requirement) is to use a sub domain with Azure AD DS to prevent DNS issues.


If you are still having trouble try reading my blog post where I go into more details on all this:

@Robert Crane 

Ok thanks for all the helpful information and clarifying those topics for me.

It's obvious I need to just move forward and test it out since I'm spending too much time theorizing. I need to see how the AADDS Group Policy features are for example, as coming from a Citrix environment I can say powerful, flexible GPOs were extremely instrumental in having a solid Virtual desktop/app environment. If Group Policy is extremely limited on the Azure AD DS side, then I may indeed have to go back to the Site VPN option, which I'm not a fan of for reasons even stated in the Azure ADDS About page itself. 

@John Quile 

If you have complex GP requirements then Azure AD DS will not be suitable in most cases for that. It is designed an 'transitory' migration tool, not a complete on prem AD replacement. You therefore need to look at utilising an existing on prem domain via a site to site VPN I would suggest and not be concerned with Azure AD DS.