Forum Discussion
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...
- Is that supported?
- When I create an Azure ADDS, will it match the same domain.com as my on-prem domain.com? If not, how will that interfere with user's logging in? Will they be able to use their @domain.com instead of some tenant domain name?
- 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?
- Christian_MontoyaMicrosoft
John Quile : 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!
- John QuileBrass Contributor
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.
I kinda answered some of this here:
https://blog.ciaops.com/2020/01/09/moving-to-the-cloud-part-3/
this is a good reference for domains:
I went cloud only but covered off some hybrid stuff that may help answer some questions.