Forum Discussion

Christian_Montoya's avatar
Christian_Montoya
Icon for Microsoft rankMicrosoft
Jul 17, 2019
Solved

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

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 investigati...
cititechs's avatar
cititechs
Copper Contributor
Aug 21, 2019

Christian_Montoya  Any update on this  ? As others have reported we are at a stand still. 
Synced from on-premise aren't working.  I have tried validation pools and still no luck with Sync accounts. 

 

 

jeffb8's avatar
jeffb8
Brass Contributor
Aug 26, 2019
Seems like we’re in store for a repeat of Azure RemoteApp.
  • Christian_Montoya's avatar
    Christian_Montoya
    Icon for Microsoft rankMicrosoft
    Aug 26, 2019

    jeffb8 : Just to get more clarity, is it primarily this issue that you think will make it the next Azure RemoteApp? Is there other functionality that we're missing, should be focusing on, or should be fixing?

    • jeffb8's avatar
      jeffb8
      Brass Contributor
      Aug 29, 2019
      Christian_Montoya

      This issue specifically is **extremely** concerning - because this isn’t an edge case; this is a fundamental architecture/database design problem in how you uniquely identify users.

      You don’t need to get AAD Domain Services or any other complicated scenario in the mix to reproduce this problem. All you need to do is delete **any** user in **any** kind of environment and then create a new one with the same upn. And bam, that user is screwed...forever.

      Deleting and recreating the tenant doesn’t help any, which tells me that user registration data is stored independently of tenant data. This will lead down an avenue of problems with no end. There are alternative architectural approaches that would likely be more reliable.
      • Roel Everink's avatar
        Roel Everink
        Copper Contributor
        Sep 05, 2019

        jeffb8 Christian_Montoya 

         

        I can attest this! It seems like a flaw in design.

         

        What happend to me is the following:

        I had a user in my old Azure AD tenant. lets call it tenant A, with a UPN of user@domain.com and used WVD succesfully there.

         

        Now I moved my domain.com to another Azure AD tenant, tenant B. Setup Azure ADDS there and tried to login with a user with UPN user@domain.com, so the exact same UPN of the user that existed in tenant A. although offcourse it doesn't exists in tenant A anymore.

        What I saw when I logged in, was the WVD tenant with the published desktops that I created in my Azure AD tenant A! AND I saw my new WVD tenant with the published desktops that I created in my Azure AD tenant B.

         

        Now, when I tried to sign-in to the desktops from the new tenant B, I get the same error as everyone else, that the SID doesn't match with the one in the database. 

        Yes, I can understand that it doesn't match if you still saved the SID from the user in tenant A. But this is a completely new user in tenant B.

         

        Just like JeffN825 already concludes, this means that the user data is independent from the tenant data, which seems strange to me.

        Also, I would like some way to delete my old user with its SID from this backend database.

Resources