Forum Discussion
Microsoft[Announcement] Connectivity issues from synchronized users to VMs joined to AAD DS
Christian_Montoya : A fix has been rolled out to production for this issue.
Microsoftjeffb8 : Ultimately, everything is mapped to a UPN so we know how to connect/reconnect them. Regardless of how you get your UPN, we map the resulting SID (that the domain understands relates to that user) back to the UPN.
Also, just to clarify, the Azure AD token is initially acquired by the user for the Windows Virtual Desktop Azure AD application, and we pass this through our system when we need to reference the incoming Azure AD user. We are not trying to silently get one.
Christian_Montoya do you have any updates on when we can expect to see the fix rolled out for us?
Yep, this works great, and has since the beginning (adding a hostpool that's actually on your on-prem domain and not AADDS joined). I didn't even add a DC out in the Azure vnet - just joined on-prem domain over the S2S tunnel.
I wish I could use that - I would be six months ahead now. The smaller attack surface of available users (filtered sync to AADDS) will be required for us.
DubC85 Maybe i wasn't clear but i went from :
On-prem AD + AADConnect + AADDS (WVD VM being joined to AADDS)
-> was stuck with this bug for several monthsto :
On-prem AD + AADConnect + On-prem AD extended to Azure vNet (WVD VM being joined to AD)
-> everything worked on the first tryThat's not helpful to those of us who would rather not have to deal with ADDS and AD Connect unnecessarily.
FYI, i just ditched AADDS and extended the on-premise AD through S2S VPN and DC VMs in Azure instead.
Re-used my TenantGroup, Tenant, and ServicePrincipal.
Template Deployment and user connexion went flawless on the first try.
I would recommend to forget about AADDS if you can.
