Different between Windows Virtual Desktop and Client Application Assignments in Azure AD

[stevenzelenko]

Can someone explain the difference of these two apps in AD?  It seems like at some point today something changed and I have to set my test users to be Tenant Creators in the Windows Virtual Desktop Application to use the web URL.  Adding users to the client app seems to do nothing.  We've had no issue with the windows and mac RDP apps using the web feed URLs.  Unless this is what we have to do for the time being but it just seems a little confusing.

And I don't know if I'm missing something but I can only deploy apps and desktops per UPN and cannot apply a security group.  Would be nice to have the app groups set up to look for a security group and simply adding the users to the group in AD and when things sync up, you have your apps.

[#2]

@stevenzelenko : Thanks for the testing so far! To address some of your questions:

• Difference between apps: the Windows Virtual Desktop app is for the management of the service, and includes granting permission for the service to call your Azure AD for user validation, service principal validation, etc. The Windows Virtual Desktop client app is for the end-user login, where you can control MFA/Conditional Access policies. I agree that we should highlight this a bit more with some examples.
• Correct, right now you can only assign users through Add-RdsAppGroupUser by individual user UPNs and not a security group. We're working on this.

[#3]

@Christian_Montoya got it, thank you.  Is there a reason why all my test users have to be assigned TenantCreator roles in the Windows Virtual Desktop app to even use the service?  It seems like adding a user to the client app as a user role fails to log them in with an error stating they are not assigned the app.  When I add them as a tenant creator all is well.

[#4]

@stevenzelenko The only user that needs to be assigned the TenantCreator role is the one who wants to run "New-RdsTenant". Otherwise, standard users shouldn't have to be assigned.

If you did the admin consent on both apps (Windows Virtual Desktop and Windows Virtual Desktop client), there should be nothing else you need to do to get the standard users working. What exactly do you mean by "When I add them as tenant creator all is well"? 

[#5]

@Christian_Montoya. I have allowed admin and client rights using my global admin account in azure. When I add a user to the WVD client app, going to the website attempts to log them in but kicks them back out. Same with the desktop client. In order to get them access, I have to add them as a tenant creator in the WVD application in Azure. Actually, I can only add them as tenant creators.

[#6]

@stevenzelenko : And when you say "going to the website", which website are you referring to? Can you post the link?

[#7]

@Christian_Montoya the rdweb link here https://rdweb.wvd.microsoft.com/webclient

but it doesnt matter. Even when using the wvd desktop client, every user has to be a tenant creator in the WVD app in Azure.  If they are only assigned to the WVD client app in Azure, they have no access.  Everything works fine but the permissions seem backwards.  

I've added some screen caps of what I'm talking about.  You can see, all users marked as Tenant Creators in the WVD app have access.  All users in the WVD client app set with a role of default access cannot log into the web URL nor the WVD client app.  If I move them to creators, they have access without issue.

[#8]

@stevenzelenko : Can we follow up in a Private Message? It's really strange that you're hitting this and would like to get to the bottom of this. Although you are seeing this behavior, you should not have to be adding users to the TenantCreators role to access their desktops or applications, so I just want to better understand your environment.

[#9]

@Christian_Montoya of course. Thanks for helping me through this.

[#10]

@stevenzelenko 

Did you ever get this resolved? Im running into the exact same issue, if i make them tenant

[#11]

@Feffen not yet.  We have an azure ticket open and they captured the fiddler trace.  Might have something soon.

@Christian_Montoya looks like another admin has our same issue.

[#12]

@stevenzelenko 

Thanks for the quick reply. Seeing exactly what you are, unless i add them as a tenantcreator in the Windows Virtual Desktop app after adding the user via Add-RdsAppGroupUser, they cannot login. The WVD website just keeps kicking you to the login page (i see something in the address bar quickly about access denied), and the RD app says it cannot authenticate the user. 

The Windows Virtual Desktop Client app doesnt seem to do anything. 

Once i add the user as tenantcreator, everything works fine. Definitely dont want to do this for users.

[#13]

@Feffen Exactly the same thing we see.  You will have an error in the WVD client app of this too I bet:

Sign-In error code:

50105

Failure reason

The signed in user is not assigned to a role for the signed in application. Assign the user to the application. For more information: https://docs.microsoft.com/en-us/azure/active-directory/application-sign-in-problem-federated-sso-ga....

@Christian_Montoya is on top of this issue.

[#14]

@stevenzelenko same issue here... glad I found this link.  

[#15]

@Rob Blankers Thanks for reporting this.  @Christian_Montoya looks like we have another one.  Just reporting it to Microsoft so we can have some ammunition to get down to the bottom of this.

[#16]

@stevenzelenko 

Wow, glad I saw this post too - thanks Steven.  See mine below - ignore all the older posts.  Same situation, except I though it had something to do with the fact that my Tenant Creator user didn't have MFA while the regular user account who is in the Desktop Application Group does have MFA enabled.

I just did what you guys have done - added the regular user to the Tenant Creator role in the Windows Virtual Desktop application and tried the RD Client again.  I can see my pool now....

https://techcommunity.microsoft.com/t5/Windows-Virtual-Desktop/Error-deploying-WVD-to-a-subscription... 

@Christian_Montoya- this is messed up 🙂 .  Following this post closely now too.  Thanks - have a good day, all.

[#17]

@jaycrumpgp @stevenzelenko : Oh man, yes, this is definitely still an error. Let me followup with the team and get back to you to see how we can address/resolve this. Full disclosure, I definitely want to get to the bottom of this because I don't want this error happening in the future, especially GA.

Let me get back to you, but definitely thank you both for reporting.

[#18]

@Christian_Montoya 

So there are 2 enterprise apps created in AAD: Windows Virtual Desktop and Windows Virtual Desktop Client.  In my experience adding a user to my app group using the PowerShell cmdlet does not add the user to either enterprise app.  At least you can't see them in the AAD GUI.  I've used the following:

Add-RdsAppGroupUser -TenantName <tenant> -HostPoolName <hostpool> -appgroupname "Desktop Application Group" -UserPrincipalName 

Manually adding a user to only the "Windows Virtual Desktop Client" app does not work.  Users get stuck in a login loop, with a message in the URL advising the user "is not assigned to a role for the application".  The application ID presented in this error is the ID for the "Windows Virtual Desktop" app.  If I add the user to that app, it works.  But, if I then remove the user from the "Windows Virtual Desktop Client" group, I get the same error, referencing the app ID for it. 

Currently I need to add users to both Enterprise Applications in AAD for them to successfully access a session.  

[#19]

@Rob Blankers I'm bumping this again.  We still have this issue.  Microsoft told me that they would escalate internally but haven't heard anything yet.  @Christian_Montoya Do you know anything?  Everything else is fine but this issue seems weird.  Attaching the error we are still seeing again if it helps.

Date
8/6/2019, 9:23:38 AM
Status
Failure
Sign-in error code
50105
Failure reason
The signed in user is not assigned to a role for the signed in application. Assign the user to the application. For more information: https://docs.microsoft.com/en-us/azure/active-directory/application-sign-in-problem-federated-sso-ga....
Client app
Mobile Apps and Desktop clients

[#20]

@stevenzelenko Still happening here as well. Have to make users tenant creators and manually add to the desktop users group via powershell before they can login. Really not fun to Admin this thing.