SOLVED

[Announcement] Connectivity issues from synchronized users to VMs joined to AAD DS

Microsoft

Hi everyone, thanks for the continued testing of WVD. We’ve seen multiple connection errors with UPN when connecting to VMs joined to Azure AD Domain Services. We’ve done some preliminary investigations and figured out which scenarios are currently affected and which scenarios should continue to work.

 

Works

Logging into VM joined to Azure AD DS instance with Azure AD user sourced from Azure Active Directory (aka, New user created just in Azure AD).

 

Does not work (and investigating fix)

Logging into VM connected to Azure AD DS with Azure AD user sourced from Windows Server AD (aka, synchronized to Azure AD through Azure AD Connect).

 

You will see an error in the Diagnostics similar to below:

ErrorSource : RDBroker
ErrorOperation : OrchestrateSessionHost
ErrorCode : -2146233088
ErrorCodeSymbolic : ConnectionFailedUserSIDInformationMismatch
ErrorMessage : OrchestrateAsync: SID value in the database is different than the value returned in the
orchestration reply from the agent for user ≤user1@contoso.com≥ with Id
54a45a4c-41ad-4374-5e41-08d6e4d9acde. This scenario is not supported - we will not be able to
redirect the user session.
ErrorInternal : False
ReportedBy : RDGateway
Time : 7/16/2019 3:17:24 PM

 

Workaround

If your setup matches the description but you would still like to test, we suggest creating cloud users in Azure Active Directory for the time being.

 

Resolution

No current ETA, but working towards a fix.

 

How to check where your user is sourced from

You can navigate to the Azure AD portal or the Azure Active Directory blade in the Azure portal, then go to users:

Locate where the Azure AD user is sourced.Locate where the Azure AD user is sourced.

79 Replies

@Marcel A' Campo - external users can't work with WVD because they are not replicated via Azure AD Domain Services to the managed AD domain.

@Christian_Montoya

 

This issue a showstopper for us.  We're trying to roll out VDI for thousands of users globally.... but the inability to automate handling of multiple security identifiers is a bit deal.

 

Glad I encountered this now, instead of 2 months from now when a single user identity will exist in AADDS, AzureAD, and ADDS.  

 

@DubC85 @jeffb8 @Marcel A' Campo @Roel Everink @pau_pedroza @MrTbone_se @cititechs / All :

 

To provide an update, we're still working on this fix. As alluded to before, the fix is 2 steps:

1. To create and populate the fields

2. To adjust the logic to use these fields

 

We've completed step #1 completely and #2 is what we're implementing/validating now. We expect this to complete and rollout within the next month.

 

This may still seem like a long time out, but we do want to be more cautious on the rollout and ensure we don't break user connections like the changes we made that landed here. There is always an option to push straight to production, but that also doesn't help us if there's another case that we missed and if we did quick validation.

 

Ultimately, we realize that this has led to the inability to quickly test out the service using Azure AD DS. Once the fix is live, you should be quickly unblocked, re-start efforts to evaluate the product as you need, and hope to see continued feedback as you have been so far on TechCommunity so far.

 

We will post back here as we progress further in the fix and when we have this available in the validation pools to test.

@Christian_Montoya 

 

Another month - alright.  Still paying for the actual resource (that doesn't work)...have been for several months now.  This has become very disappointing.  Standstill - Business Units waiting on the solution - complaining about chargebacks for the resource (that doesn't work) will be the next thing.

 

Please guys - get this fixed.

Hi @christianmontoya , is there any news on this?

This is a hard block for us as well!

@Christian_Montoya

Can you share some technical details on what these fields are and how they are used? Any details that would inspire confidence in the solution you’ve designed would be helpful.

@Christian_Montoya thanks for the update. 

 

We are waiting to deploy WVD with Azure AD DS and if I understand correctly it will be possible once the second fix is rolled out? We have host pools set as "Validation" host pools, can we hope to get the fixes out sooner to these hostpools?

 

Cheers,

Joakim

@Joakim Westin - I wouldn't count on this fixing the underlying issue. From the description of the fix, it sounds like it will just work around it for some situations.

@jeffb8 : 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.

I don’t understand how this will resolve the underlying issue, which is as simple to reproduce as deleting and recreating a user. Or deleting an AAD DS domain and recreating it. It seems that would still be broken after this fix.

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...

@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.

@Christian_Montoya do you have any updates on when we can expect to see the fix rolled out for us?

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.

@Arthur GERARD 

That's not helpful to those of us who would rather not have to deal with ADDS and AD Connect unnecessarily.   

@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 months

 

to : 


On-prem AD + AADConnect + On-prem AD extended to Azure vNet (WVD VM being joined to AD)
-> everything worked on the first try

@Arthur GERARD 

 

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.

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.

@rhythmnewt If you look at this link, it looks that we will have to wait a little bit longer. I am pretty sure this Note has been added recently.

image.png

 
So now it's officially not supported :(

@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.