User in Child Domain gets Connection Denied when connecting to WVD Session Host

[Michael Hines]

Feeling like I'm missing something really obvious here, but the error is too generic to find the result I need.

Most of our WVD users are in our primary/parent domain. We have two users in a child domain that need to access the WVD environment, however they are getting a generic "The connection was denied because the user account is not authorized for remote logon" error. No problem subscribing to the feed, but can't hit the desktop.

In regular RDP/RDS environments, this typically means the user isn't a member of the "Remote Desktop Users" group, or the security policy needs to be modified to allow that specific user/group. WVD doesn't seem to follow this method for access control. Instead, it seems like the WVD management service dynamically controls the Remote Desktop user group on the host machines. 

Anyone have thoughts or experience to share?

[#2 · Accepted solution]

You are spot on. Let me give you some context.

1) we automatically add users to the RD user group on the host machine
2) this happens during orchestration (orchestration = establish connection)
3) when user connects there are two sets of authentication
- one for Azure ad (to get the feed)
- second to the AD DS (session host permissions)
4) in the case the Azure AD works fine, the AD DS does not work because when we ask the DC for those users we do not get "correct" resoponse

Few assumptions
1) I am assuming that the child domain users are synched to Azure AD
2) Does the DNS support the look up of the child domains
3) VMs are joined to the parent domain (work around maybe to create a host pool where VM is joined to the child domain)

[#3]

Thanks for getting back. Here are my replies to your suggestions.

1) Yes.
2) Yes. I have verified DNS resolves and the VM can contact the child domain's DC.
3) Yes. Joined to the parent. Prior to WVD, we had these users all accessing the App on RDS via RemoteApp. We had no issue adding the child domain users in that environment. In fact, I think our Help Desk is recommending turning that back on to accommodate these users as a work around.

At the end of the day, this isn't a major issue for me, as it only affects a small subset of users and the App they are using will be retired later this year. But it seems like there should be a solution. I'm also surprised it doesn't seem to have come up, or at least not as regularly as I would assume.