Forum Discussion
Clarification on Azure AD DS domain suffix vs on-prem Domain syncing?
MicrosoftSeizeThaNight : To answer your questions:
- 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.
- There's some Azure AD DS guidance here, so I would rather defer to that team's guidance than misspeak.
- Ultimately, Windows Virtual Desktop has two primary authentication prompts:
- 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.
- 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!
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 first.last@someothedomain.onmicrosoft.com or whatever, nor having to map their corp creds to different creds for SAML assertion.
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. sub.domain.com\first.last where your AD user is typically first.last@domain.com).
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.
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?
John.Doe@domainA.com syncs to Azure AD as John.Doe@domainA.com.Why does it have to be John.Doe@sub.domainA.com on the second sync to Azure AD DS? That's not a true "sync" as I understand it...?
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 domain.com. 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:
https://blog.ciaops.com/2020/01/09/moving-to-the-cloud-part-3/
