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

      • jeffb8's avatar
        jeffb8
        Brass Contributor
        Sep 05, 2019

        @christianmontoya 

         

        With each day that passes with no meaningful reply on this issue, I become more skeptical that the right team (one with extensive experience in distributed, AzureAD based authentication and authorization) is working on this product. I also wonder if the lack of/delay in reply is indicative of the team taking a pause to re-evaluate if they can successfully develop this solution...?

         

        Is there any information you can provide that might alleviate this concern? 

Resources