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 : Essentially, there are three pieces of information we need for processing the new or reconnecting user connection:
1. UPN in Azure AD token
2. SID in Azure AD token
3. SID that the on-premises domain sends back when it matches up the user
Everything is based according to the UPN, as that is provided in all tokens. The fixes will:
1. Update the SID for the UPN (accounts for user migration on premises or new instantiations of Azure AD DS for users sourced in Windows Server AD)
2. Update the SID that the on-premises domain sends back when it matches up the user, which is needed for manual/auto-reconnect scenarios.
We definitely hear feedback on "why SID?", but unfortunately that is needed for current logon APIs if we want to provide a consistent re-connect experience that can get triggered even if you lose Internet connectivity for a brief second or switch wireless networks.
Further, you say
“2. Update the SID that the on-premises domain sends back when it matches up the user, which is needed for manual/auto-reconnect scenarios.”
First - I assume you mean the RDSH agent? If so, how is the agent going to get the token for the current AAD user (which contains the SID you want)? If what you mean is that you’re going to try to silently acquire a token from the agent as the user...please don’t. The user could be subject to MFA policies which would muck you up even further...
Christian_Montoya Thanks.
- Christian_Montoya
Robin_Kluijt : Yes, this scenario is supported.
Christian_Montoya Hi Christian, hope you are all well? Came a cross this topic and was curious if the fix is already live? This thread is handeling the exact situation we have implemented. a combination of users sources from Windows server AD and Azure AD. Everything is working for us and both user types are able to login.
Before we go to production, could you confirm that this scenario is supported?
Christian_Montoya last day of the month. Any news?
I can add that this does not work with accounts sourced from local AD when converting users to cloud by disabling AD-connect either..
Christian_Montoya thank you for the update 🙂
- Christian_Montoya
rhythmnewt Olivier Debonne : Correct, the link was added in the past week and a half ago so that customers would not accidentally hit this scenario.
No worries though: once the fix is in and live, the scenario will be supported 🙂 We're on still on track for this month. I will post back here once we have it available for validation pools (host pools with "ValidationEnv" set to $true) so that we can confirm the fix before the broadest rollout.
- So now it's officially not supported 😞
rhythmnewt If you look at https://docs.microsoft.com/en-us/azure/virtual-desktop/overview, it looks that we will have to wait a little bit longer. I am pretty sure this Note has been added recently.
- Any timeline on the fix? Looks like WVD went GA today. I can see there are some options with VPN tunnels, but I would rather avoid re-configuring my WVD environment away from Azure ADDS.
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.Christian_Montoya do you have any updates on when we can expect to see the fix rolled out for us?
- Christian_Montoya
jeffb8 : 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.
