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

@Christian_Montoya 

I know before the post that Cloud ID only is working but that is not valid for our production POC

i been testing with cloud ID only and that works , further more the issue with synced account, it looks like recently (because this was working before) you doing  SID check between the azure synced account and the account in azure DS and that will not match. i'm wondering if the scenario without azure DS , i mean extending AD to the cloud and join the virtual desktop machines to the same domain will have the same issue or not for synced user account.

@ashro2 : Thanks for the clarifying question, but no, the issue will not replicate if you have a hybrid setup and are joining your virtual machines to the domain that is syncing up the users with Azure AD Connect. The primary issue lies in the SID check, and that Azure AD DS creates a new SID (by design) for the users that it creates on the managed domain services instance.

@Christian_Montoya 

Thanks   i came to the same conclusion when looking ate the object SID in AAD and Azure DS and the Mismatch. i have 2 comments 

1. this check was introduced recently because this scenario was working before , is it possible to trun off this check of the SID? I saw the feedback on the form suggested moving the pool to validation pool where you deployed a fix for the issue but looks like that is not working as well. so is there a way to trun off this check i can do in my side?

 

2. is there a way to modify the Azure DS object SID to match AAD ? we don't have much control over the object in Azure DS I realized ?

 

it will be great if we can manually turnoff this SID check manually at least for testing

@ashro2 : Unfortunately, it's not quite as simple as turning off the check since this check was implemented to stabilize the reconnection scenarios so that users get redirected back to a previously existing session (as opposed to get a new session).

 

I'm not sure if there's a way to manipulate the SIDs, but we're investigating all possible options right now.

 

Thank you for the feedback and dialogue though. We want to unblock testing, but also do not want to leave users in a bad state.

@Christian_Montoya So no workaround for this scenario since the SID check is active now and according to you no ETA too. that's a bit disappointing! 

I know the service is currently in preview, but i find the fact that this bug took multiple weeks to identify and acknowledge is a bit worrying for the state/future of AAD DS (that we rarely deployed before WVD).

Are there so few orgs using AAD DS ? Should we drop it and extend on-prem ADs to Azure LAN for WVD instead ?

@Bazam Chekrian Valappu : Yes, we solved one failing behavior but now it's hindering another, but definitely working to achieve both.

@Arthur GERARD : I wouldn't say that no one is using Azure AD DS or that it's not a viable solution. Primarily, understanding this failing scenario is an intersection of where customers are today and how they are piloting Windows Virtual Desktop with just cloud users (before trying to extend this with a full site-to-site on-prem infrastructure).

 

Between using Azure AD DS or extending existing domain structure to Azure, it depends on your scenarios you're targeting. You have much more flexibility by extending, since you can use Federation, Passthrough Authentication, or password hash (whereas AAD DS only works with password hash). Not sure if you've already seen this comparison article.

@Christian_MontoyaThat makes sense, thank you.

Is "Azure AD join" on the roadmap for WVD ? Or will AAD DS continue to be the lightest deployment for our SMB customers ?

@Arthur GERARD : Azure AD Join is definitely a scenario we want to support and we're in the initial investigation stages, as it's a larger change from how VDI/RDS has worked in the past. Unfortunately, this feature is not something that will make it into our initial GA. We will continue to update these forums and our Docs site as we have more information on this scenario, and other new ones.

Just checking if there's any ETA on the fix for the initial problem in this thread. Thanks.

@Christian_Montoya 

 

Hi Christian,

 

I seem to be experiencing the exact same error in a test environment. However, the user is sourced from Azure Active Directory.

 

I would be happy to help troubleshoot since I have clients looking forward to WVD. below is some info that might be relevant and if you need identifying tenant info I'll be happy to send via PM:

 

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 ≤username≥ with Id <id>. This scenario is
not supported - we will not be able to redirect the user session.
ErrorInternal : False
ReportedBy : RDGateway
Time : 7/28/2019 14:17:15

 

TenantName : IC-WVD2
TenantGroupName : Default Tenant Group
HostPoolName : Desktop
FriendlyName :
Description :
Persistent : False
CustomRdpProperty :
MaxSessionLimit : 999999
LoadBalancerType : BreadthFirst
ValidationEnv : True
Ring :

Hi,

We have just noticed the same problem in our test environment.

But a strange thing is that it only affects one of the 17 pilot users.

 

The users were synced from a local AD to Azure AD.

Azure AD connect sync was removed 1 year ago.

Azure AD services was setup to support the WVD environment.

Users envolved in pilot had to reset their passwords and could then logon.

 

But now, one user gets the error message:

SID value in the database is different than the value returned in the orchestration reply from the agent for user...

 

The Hostpool is in "validation" 

<#

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 ≤a.b@domain.se≥ with Id b663bb3d-3f67-42e9-f891-08d6fb3eb712. This scenario is not supported - we will not be able to redirect the user session.
ErrorInternal    : False
ReportedBy        : RDGateway
Time              : 2019-07-18 09:36:42
 
ErrorSource      : Client
ErrorOperation    : ClientRDPConnect
ErrorCode        : 2147965400
ErrorCodeSymbolic :
ErrorMessage      : Your computer can't connect to the Remote Desktop Gateway server. Contact your network administrator for assistance.
ErrorInternal    : True
ReportedBy        : Client
Time              : 2019-07-18 09:36:42

#>

 

 

@Christian_Montoya would be great to get an update on when this will be fixed - we were happily using this with this setup then in abruptly broke and we've been investigating on and off as time allowed ever since.

 

Now i stumbled across this issue (after finally figuring out how to debug what was going wrong). Do we have an ETA as this is now a total block on us using WVD.

 

I'm really disappointed as this is the 2nd major stumbling block - we've fully adopted Azure AD and the lack of support for Azure AD join is the other one.

 

This can be such a good solution it's just so frustrating.....

Is there a way to identify the public IP range used by azure virtual desktops to communicate with external resources such as O365

Services . this is required to apply some azure  access control policy

Thanks

@Christian_Montoya  Same issue for one of test Azure-born user, the second one (Azure-born as well) still works fine.

Any update on a resolution? This is a hard blocker for us.

The workaround only works with NEWLY CREATED users - meaning I cannot delete a Windows Server AD user, then recreate with the same username as an Azure AD sourced user. It seems like Windows Virtual Desktop permanently stores the upn and sid in its database....so deleting and recreating the user in Azure AD doesn’t help...

@jeffb8  @Richard Harrison @Integral-Consulting @rhythmnewt @Alex Ignatenko : Hi everyone, apologies for this thread going a bit quiet. We've done investigations and started implementing the fix, but will take time to roll into production. Once I get a better date, I will reach out here so you all can continue your testing!

 

Since we roll out in phases, I'd highly recommend setting up a host pool for validation, as this will be the first place to test.

 

Again, thanks all and we're definitely trying to get this fix rolled out as soon as we can.

1 best response

Accepted Solutions
best response confirmed by Eva Seydl (Microsoft)
Solution

@Christian_Montoya : A fix has been rolled out to production for this issue. 

View solution in original post