Azure Virtual Desktop – External (B2B) User Fails to Connect with OrchestrationResponseError 10009 (E_PROXY_TENANT_CANNOT_FIND_USER_IN_ACTIVE_DIRECTORY)

abdullah 5

We are experiencing an issue where an external (B2B guest) user is unable to connect to Azure Virtual Desktop (RemoteApp).

The connection reaches the orchestration stage but fails with the following error:

DisconnectReason: OrchestrationResponseError Code: 10009
Received status 400 for the orchestration POST request
Error:
E_PROXY_TENANT_CANNOT_FIND_USER_IN_ACTIVE_DIRECTORY
Exception:
Microsoft.RDInfra.RDAgent.Service.AddUserToLocalGroupAdErrorNoSuchMemberException

Environment Details

OS: Windows 11 Enterprise multi-session

Version: 24H2

OS Build: 26100.7840

Session hosts: Entra ID joined

Host pool type: Pooled

Per-user access pricing: Enrolled (external users scenario)

RemoteApp deployment

Authentication: Entra ID (B2B guest user)

SSO configured

What is Working

Feed discovery succeeds (HTTP 200)

RDP file downloads successfully (HTTP 200)

Authentication succeeds

User is visible in Entra ID as Guest

User is assigned to the Application Group

Subscription is enrolled for per-user access pricing

Observed Behavior

Connection progresses to orchestration phase, then fails with:

OrchestrationResponseError (10009)

HTTP 400 from orchestration POST

Exception indicates failure while attempting to add user to local group

Error suggests the user cannot be found in Active Directory during orchestration

Question

What could cause E_PROXY_TENANT_CANNOT_FIND_USER_IN_ACTIVE_DIRECTORY during orchestration for an external B2B user on Windows 11 24H2 Entra-joined session hosts?

Specifically:

Are there additional RBAC roles required beyond Application Group assignment?

Is "Virtual Machine User Login" required at VM/RG scope for B2B users?

Are there additional cross-tenant access settings that must be configured?

Does this indicate a session host agent issue resolving the guest object?

Any guidance would be appreciated.

If you want, I can also give you a more technical version that sounds deeper/engineering-level (sometimes gets faster responses from Microsoft engineers).

Environment Details

OS: Windows 11 Enterprise multi-session
Version: 24H2

OS Build: 26100.7840

Session hosts: Entra ID joined

Host pool type: Pooled

Per-user access pricing: Enrolled (external users scenario)
RemoteApp deployment
Server is entra domain services joined.

SSO configured

What is Working

Feed discovery succeeds (HTTP 200)

RDP file downloads successfully (HTTP 200)

Authentication succeeds

User is visible in Entra ID as Guest

User is assigned to the Application Group

Subscription is enrolled for per-user access pricing

Observed Behavior

Connection progresses to orchestration phase, then fails with:

OrchestrationResponseError (10009)

HTTP 400 from orchestration POST

Exception indicates failure while attempting to add user to local group

Error suggests the user cannot be found in Active Directory during orchestration

Question

What could cause E_PROXY_TENANT_CANNOT_FIND_USER_IN_ACTIVE_DIRECTORY during orchestration for an external B2B user on Windows 11 24H2 Entra-joined session hosts?

Specifically:

Are there additional RBAC roles required beyond Application Group assignment?

Is "Virtual Machine User Login" required at VM/RG scope for B2B users?

Are there additional cross-tenant access settings that must be configured?

Does this indicate a session host agent issue resolving the guest object?

Any guidance would be appreciated.

VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-03-02T23:01:14.58+00:00
Hi Abdullah,

The error is occurring during the orchestration phase on the session host, when the AVD agent attempts to resolve the signed‑in user and add them to the required local groups. Authentication succeeds, but the session host cannot resolve the external (B2B) user in the directory context it expects, which results in:

E_PROXY_TENANT_CANNOT_FIND_USER_IN_ACTIVE_DIRECTORY AddUserToLocalGroupAdErrorNoSuchMemberException

1.Are there additional RBAC roles required beyond Application Group assignment?

Yes. For Microsoft Entra ID–joined session hosts, Application Group assignment alone is not sufficient. Users must also be granted the Virtual Machine User Login RBAC role at the VM, resource group, or subscription scope. This role is required for the session host to authorize the user locally during orchestration.

https://learn.microsoft.com/en-us/azure/virtual-desktop/azure-ad-joined-session-hosts

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-desktop/troubleshoot-azure-ad-connections

2.Is “Virtual Machine User Login” required at VM/RG scope for B2B users?

Yes. This requirement applies to all users, including external (B2B) guest users, when connecting to Entra ID–joined AVD session hosts. Assigning this role at the resource group level (covering all session hosts) is the recommended approach for pooled host pools.

3.Are there additional cross‑tenant access settings that must be configured?

Possibly. If inbound Cross‑Tenant Access policies are restrictive, external users may authenticate successfully but fail during VM sign‑in/orchestration. Ensure inbound policies allow the external tenant and do not block required applications such as Azure Virtual Desktop and Azure Windows VM Sign‑In for external identities.

4.Does this indicate a session host agent issue resolving the guest object?

In most cases, no. This is typically a configuration or identity resolution issue, not an agent defect. Common causes include:

Missing Virtual Machine User Login RBAC assignment [learn.microsoft.com]

Session host join‑type mismatch (for example, hosts joined to Entra Domain Services or mixing join types in the same pool). For Entra authentication with SSO, session hosts must be Microsoft Entra ID joined, and host pools should not mix join types.
abdullah 5 Reputation points

2026-03-03T17:37:04.3233333+00:00

My AVD session hosts are Entra Domain Services–joined. Can they remain joined to Entra DS and still be accessible to external users?
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-03-03T19:55:43.12+00:00

abdullah For Azure Virtual Desktop access by external (B2B) users, Microsoft requires the session hosts to be Microsoft Entra ID–joined. Session hosts joined to Microsoft Entra Domain Services aren’t supported for external identities, because the guest user can’t be resolved during orchestration, which leads to error 10009.

https://learn.microsoft.com/en-us/azure/virtual-desktop/authentication
abdullah 5 Reputation points

2026-03-03T20:06:11.7533333+00:00

I need to configure NTFS permissions on a folder for different users, including external users. Is it possible to do this with Entra ID–joined machines? This was the main reason we chose Entra Domain Services.
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-03-03T20:32:58.9033333+00:00

abdullah Yes, NTFS permissions can be configured on Microsoft Entra ID–joined machines, including for external (B2B guest) users. On Entra ID–joined Windows VMs, Entra users and groups (including guests) can be added directly to local NTFS ACLs on folders. Microsoft Entra Domain Services is only required when you need traditional AD DS features such as Kerberos/NTLM for SMB shares or legacy domain‑based applications, not for local NTFS permission management.
abdullah 5 Reputation points

2026-03-03T21:38:04.8533333+00:00

Is it a new feature or has been there for some time. As when I first configure it a year ago this was not supported. I want to give access to a folder in drive D: to differnt entra ID groups and users not the local users of the machine.
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-03-03T21:59:43.2966667+00:00

abdullah This is not a new feature. On Microsoft Entra ID–joined Windows machines, it has been supported for some time to assign NTFS permissions on local folders (for example, D:) directly to Entra ID users and groups, not just local machine accounts. What was not supported earlier was using Entra ID–only identities for network file access (SMB / Azure Files / FSLogix), which is why Entra Domain Services was commonly chosen. That limitation applied to file shares, not to local NTFS folders on the VM itself.

If you need any further assistance or would like to discuss this in more detail, please share your available timing via private message.
abdullah 5 Reputation points

2026-03-04T12:51:22.5666667+00:00

I am unable to find the location to set so the user can be located from the entra id
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-03-04T13:38:53.9033333+00:00

abdullah please share your available timing via private message.
abdullah 5 Reputation points

2026-03-04T16:30:55.07+00:00

I have shared. Please confirm when can we connect
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-03-11T16:20:14.23+00:00

abdullah could you please let me know if you need any additional assistance on this.
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-03-13T14:56:30.9666667+00:00
abdullah Thanks for your patience. We reviewed this internally and I want to clearly explain what is supported and why you are seeing this behavior.

What is happening in your scenario

Your session host is Microsoft Entra ID–joined, and you are trying to assign NTFS permissions on a local drive (D:) directly to an Entra ID user. The “Name not found” message indicates that Windows cannot resolve this identity for local NTFS access control.

This behavior is by design and depends on how Windows NTFS permissions work.

Important clarification about NTFS and Entra ID

NTFS permissions on local disks (C:, D:) rely on Windows security identifiers (SIDs) that are issued and resolved through:

Local machine accounts, or

Active Directory–compatible domain services

Microsoft Entra ID is a cloud identity provider and does not act as a directory authority for local NTFS authorization on Entra ID–joined machines. As a result:

Entra ID users may not always resolve in the NTFS permission picker

Entra ID groups are not supported for local NTFS permissions

External / guest users are not supported for local NTFS permissions

This is why the user lookup fails when you try to add the Entra ID user directly.

Regarding Microsoft Entra Domain Services

Microsoft Entra Domain Services only enables NTFS permissions if the session host itself is joined to the managed domain (AAD DS), not merely Entra ID–joined.

Even in that case:

NTFS permissions apply only to managed domain users and groups

External / B2B guest users are not supported

Entra ID–only identities still cannot be used directly

So Entra Domain Services does not enable NTFS permissions for Entra ID users on an Entra ID–joined VM.

Why this seems confusing

Recent updates introduced Entra Kerberos authentication for Azure Files, which allows NTFS‑style permissions for Entra ID users on Azure File Shares. However, this support is limited strictly to Azure Files and does not apply to local disks on session hosts.

No changes were made to NTFS behavior on local drives.

Supported options going forward

To meet your requirement, one of the following supported approaches is required:

Domain‑join the session host to Entra Domain Services

Use managed domain users/groups only No external users supported

Use Azure Files with Entra

Full support for Entra ID users

Recommended for AVD and multi‑user environments

Use SharePoint or OneDrive Best option if you need Entra ID group and external user access.
abdullah 5 Reputation points

2026-03-13T18:51:55.4733333+00:00

Can we or can we not configure NTFS permission on entra id domain joined session host on local drives like D:
Sina Salam 31,456 Reputation points Volunteer Moderator

2026-03-15T12:00:13.2233333+00:00

Hello abdullah,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Azure Virtual Desktop - External (B2B) User Fails to Connect with OrchestrationResponseError 10009 (E_PROXY_TENANT_CANNOT_FIND_USER_IN_ACTIVE_DIRECTORY).

The failure occurs because session hosts joined to Entra Domain Services or AD DS cannot resolve B2B guest objects, which triggers directory lookup errors during AVD orchestration. Convert or redeploy the hosts as Entra ID–joined, assign the Virtual Machine User Login role, and keep the users assigned to the application group. Documentation: https://learn.microsoft.com/azure/virtual-desktop/authentication and https://learn.microsoft.com/azure/virtual-desktop/azure-ad-joined-session-hosts.

To enable external B2B access, rebuild the session hosts as Microsoft Entra ID–joined machines and enable Entra authentication for the host pool (Use Microsoft Entra authentication). Then assign users to the AVD application group and grant the RBAC role Virtual Machine User Login at the VM, resource group, or subscription scope. Reference: https://learn.microsoft.com/azure/virtual-desktop/azure-ad-joined-session-hosts and https://learn.microsoft.com/azure/virtual-machines/windows/login-using-aad.

On Entra-joined session hosts, NTFS permissions can be granted directly to Entra identities using the security principal format AzureAD\******@domain.com or AzureAD\GroupName. Add these identities through the folder Security > Edit > Add dialog so the OS resolves the Entra object locally for ACL enforcement. Reference: https://learn.microsoft.com/azure/virtual-machines/windows/login-using-aad.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-03-16T01:54:07.8366667+00:00

abdullah You can configure NTFS permissions on local drives (like D:) on a Microsoft Entra ID–joined session host, but only in a limited, local‑only way. An Entra ID user can be added to NTFS permissions only after that user has signed in to the session host at least once, so the local SID exists.

However, these permissions are host‑local, do not roam between session hosts, and Entra ID group‑based NTFS permissions are not reliably supported. Because of this, NTFS permissions on local drives are not supported or recommended for AVD multi‑session or shared access scenarios.

For supported access control, use Azure Files with Entra ID authentication, FSLogix, or SharePoint/OneDrive.
VEMULA SRISAI 13,900 Reputation points Microsoft External Staff Moderator

2026-03-20T17:48:15.83+00:00
Hello abdullah,

I discussed it with the Engineer team, below is the clear explanation for your scenario, please check.

Issue Overview:

You are attempting to connect an external (B2B) user to Azure Virtual Desktop (AVD) where the session hosts are joined to Microsoft Entra Domain Services (Entra DS). While authentication, feed discovery, and RDP file download complete successfully, the connection fails during session establishment with the following error:

Error: 10009 – E_PROXY_TENANT_CANNOT_FIND_USER_IN_ACTIVE_DIRECTORY

Explanation:

During the session establishment process, the AVD session host must resolve the user identity against the directory it is joined to Microsoft Entra Domain Services in order to add the user to required local security groups.

External (B2B) users exist only in Microsoft Entra ID and are not present in the Entra Domain Services managed domain. As a result, the session host is unable to resolve the user account, which causes the connection to fail during orchestration.

NTFS Permissions Clarification:

Regarding your question on NTFS permissions:

NTFS permissions on Entra Domain Services–joined machines work only with users that exist within that managed domain

External (B2B) users are not part of this domain, so they cannot be resolved or assigned NTFS permissions in this setup

Engineering team Validation:

This behavior has been reviewed and validated with the Microsoft engineering team, who confirmed that the observed behavior aligns with how Azure Virtual Desktop and Entra Domain Services operate together in this scenario.

Recommended Action

To enable successful Azure Virtual Desktop access for external (B2B) users, the session hosts must be Microsoft Entra ID–joined. This configuration allows proper identity resolution and is the supported approach for this use case.

Please let us know if you need any further assistance or have additional questions.
Rukmini 43,915 Reputation points Microsoft External Staff Moderator

2026-03-23T20:51:32.0233333+00:00

Hello abdullah,

Following up to see if the above provided information was helpful. If you have any further queries do let us know.
Raja Pothuraju 47,820 Reputation points Microsoft Employee Moderator

2026-04-06T07:44:53.3966667+00:00

@abdullah, Just checking in to see if below information was helpful. If you have any further updates on this issue, please feel free to post back.

Azure Virtual Desktop – External (B2B) User Fails to Connect with OrchestrationResponseError 10009 (E_PROXY_TENANT_CANNOT_FIND_USER_IN_ACTIVE_DIRECTORY)

Environment Details

What is Working

Observed Behavior

Question

Environment Details

What is Working

Observed Behavior

Question

Your answer