Forum Discussion
WVD setup with Azure AD DS and Multiple Custom Domains
Multiple Custom Domains is different from Azure AD Domain Services. Custom domains are DNS domain names that you have associated with your Azure tenant. Azure AD Domain Services is an Active Directory domain name hosted for you by Microsoft. It provides legacy authentication like LDAP, Kerberos, and NTLM. It also provides domain join capabilities ( not Azure AD Join) that is common with on-premises Active Directories. The users created in the managed domain (Azure AD Domain Services) arrive through a one-way synchronization from Azure AD. All the users and groups in your tenant are synced in the managed domain and have the same user principal name as they do in Azure. So, it doesn't matter if they are from alpha, beta, or gamma domains. If the user has been created in your Azure AD Tenant (cloud user) or synced from your on-premises domains and forests through AAD Connect, then the user can authenticate to the managed domain (you just need to ensure those users have RDP access to the virtual machines or WVD sessions).
Hope that helps
Mike Stephens
Senior Program Manager
Azure Identity
IAM Core | Domain Services
Mike Stephens , I fully understand what you are saying but for me, it just does not work..
I have setup as described, multiple domains (a.com , b.com and c.com ) in Azure and Azure AD Domain Services (with only domain "a.com" in there)
The VM's are joined to a.com and users with sign-in name in Azure with @a.com can work just fine, however, users with @b.com or at @c.com can sign on to WVD but, when they get the second (rdp) authentication prompt, they cannot sign in, no matter what they try (entering upn, sam account name, domain\username ,etc...)
When I look at the groups on the VM, users are in there and are allowed to RDP into the machine.
Anything I can check ?
Mike Stephens , Hmm, just figured out it does work after a password reset on Azure.
I now entered a more complex password.
Could it be that the password complexity policy of AAD DS was not met ? Is there even one set as default ?
Deleted Newly created cloud users do not sync to the managed domain until the user has changed their password. In Azure, when you create a new user, the user is assigned a default password and is forced to change it on the next sign-in. AAD DS will not sync the user until they change their password. Password complexity is entirely handled on the Azure AD side.
- Hi Mike,
I have a question on similar set up that we have a AADDS with xyz.com and AVD sessions hosts are joined to it. we have custom domains with a.com, b.com and c.com so on each custom domain is for each customer of ours and we have different hostpools for each of them assignments also done according to their relative custom domain name ID. now the question is we do not want user of company a be able to check the Azure AD or list Azure AD users from even PowerShell, I did conditional access policy by which I could completely block access but can we do a scope by which the users of company A can only see their users may be by PowerShell and for company B user he can only see their company B users. Let me know if this is making sense or a Tenant each for one company would be ideal.
P.S. Company users are external users.
Deleted I think existing users in Azure AD before provisioning of the ADDS would need to perform the password reset so that their identities are synced 'correctly' in the DC, for newly created user accounts (post ADDS provisioning) it works without any issue.
To be precise in terms of why the password reset is required - I think it is because of the fact that the Azure ADDS relies on the password hash format that supports NTLM and Kerberos password hash and until Azure ADDS is not deployed, the Azure AD does not store password hashes in these formats so the password reset is the only solution or workaround to get these hashes generated so that Azure ADDS can start using those and for newly created users (post Azure ADDS deployment) those are auto-generated and hence no need to reset passwords of those accounts.
