WVD & Internal AD Domains

Copper Contributor

A WVD use case that my customer wants to implement is access to their development domains.  For various reasons, these domains are not exposed to Azure AD for remote access.  The concept of operations here is to authenticate to the WVD service with your production credentials that will give you access to one or more desktops in your assigned development environments.

 

I was able to successfully build a host pool and deploy session hosts and have them join the DEV domain but I'm running into an issue with accessing the desktop via WVD.  The problem seems to be that the WVD workstation in the development domain that is isolated from the production domains cannot resolve the user who has logged on to the WVD service with their production account. 

 

I understand that we are trying to do something a little different, but is there a way that we can tell the remote desktop services to skip whatever it is trying to pass with the production user and just present an authentication dialog so that the user can log on with their development domain credentials?  

 

[Window Title]
Remote Desktop

[Content]
An error occurred while accessing this resource. Retry the connection or contact your system administrator.

[^] Hide details [OK]

[Expanded Information]
Error code: 0x3000047
Extended error code: 0x0
Timestamp (UTC): 2021-01-05T15:41:17.638Z
Activity ID: 4d6555d3-0616-4df4-9746-9b5da7b70000

 

 

Some errors and warnings from the Remote Desktop Services log:

 

Log Name: RemoteDesktopServices
Source: Microsoft.RDInfra.RDAgent.Service.RDInfraAgent
Date: 1/5/2021 4:11:20 PM
Event ID: 0
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: DEVWVD1.DEV.Domain
Description:
OrchestrateSessionAsync failed for user '≤upn@production.domain≥' status=O_ERROR_NO_SUCH_MEMBER ex=Microsoft.RDInfra.RDAgent.Service.AddUserToLocalGroupAdErrorNoSuchMemberException: Could not resolve UPN from SID ---> System.ComponentModel.Win32Exception: No mapping between account names and security IDs was done
at Microsoft.RDInfra.Shared.Common.TaskUtilities.<CallNativeFuncWithTimeout>d__2`1.MoveNext() in S:\src\Shared\Common\src\TaskUtilities.cs:line 124
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.RDInfra.RDAgent.Service.UserSecurity.<GetUpnFromSidImplAsync>d__13.MoveNext() in S:\src\RDAgent\src\Service\UserSecurity.cs:line 217
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.RDInfra.RDAgent.Service.Services.NativeOrchestrationService.<AddUserToLocalGroupAndResolveSidAsync>d__10.MoveNext() in S:\src\RDAgent\src\Service\Services\NativeOrchestrationService.cs:line 163
--- End of inner exception stack trace ---
at Microsoft.RDInfra.RDAgent.Service.Services.AgentOrchestrationService.<OrchestrateSessionAsync>d__32.MoveNext() in S:\src\RDAgent\src\Service\Services\AgentOrchestrationService.cs:line 436
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.RDInfra.RDAgent.Service.RDInfraAgent.<OrchestrateSessionAsync>d__39.MoveNext() in S:\src\RDAgent\src\Service\RDInfraAgent.cs:line 506

 

 

Log Name: RemoteDesktopServices
Source: Microsoft.RDInfra.Messaging.MessagingDispatcherMiddleware
Date: 1/5/2021 4:11:20 PM
Event ID: 0
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DEVWVD1.DEV.Domain
Description:
MessagingDispatcherMiddleware Exception=Microsoft.RDInfra.Shared.Common.RestError.RestException: Could not resolve UPN from SID ---> Microsoft.RDInfra.Shared.Common.RestError.InnerRestException: Could not resolve UPN from SID ---> Microsoft.RDInfra.Shared.Common.RestError.InnerRestException: No mapping between account names and security IDs was done
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
at Microsoft.RDInfra.RDAgent.Service.RDInfraAgent.<OrchestrateSessionAsync>d__39.MoveNext() in S:\src\RDAgent\src\Service\RDInfraAgent.cs:line 548
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.RDInfra.RDAgent.Service.RDInfraAgent.<Dispatcher>d__27`2.MoveNext() in S:\src\RDAgent\src\Service\RDInfraAgent.cs:line 0
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.RDInfra.RDAgent.Service.RDInfraAgent.<<InitializeCallbacks>b__26_1>d.MoveNext() in S:\src\RDAgent\src\Service\RDInfraAgent.cs:line 137
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.RDInfra.Messaging.MessagingDispatcherMiddleware.<Invoke>d__5.MoveNext() in S:\src\Shared\Microsoft.RDInfra.Messaging\src\Microsoft.RDInfra.Messaging\MessagingDispatcherMiddleware.cs:line 43

3 Replies

I'm having this exact problem, got excited to see what I'm experiencing detailed so precisely only to find no replies :cry:

Seems like this should be possible since I've seen other threads indicating that people are able to connect to resources that aren't joined to any domain at all through WVD portal.

This issue was resolved for me after found that we had to disconnect our AzureAD from our old connected on-prem AD domain for authentication. This was due to recent AD migrations.
Hope this hint helps.

@josephdurnal 

 

I thought considering 'jump host' for the case should be the right direction in view of segregation