Which Users Can Sign In to AD DS-Joined AVD Hosts?

Plan and implement identity integration

Answer Correct answer: A — Only User1 can sign in because the session hosts are joined to the on-premises AD DS domain, which does not contain cloud-only or guest users.

Your on-premises network contains an Active Directory Domain Services (AD DS) domain named contoso.com. You have an Azure subscription that is linked to a Microsoft Entra tenant named contoso.onmicrosoft.com. Contoso.com syncs with contoso.onmicrosoft.com. You have a partner company that has a Microsoft Entra tenant named fabrikam.com. Contoso.onmicrosoft.com contains the resources shown in the following table. You deploy an Azure Virtual Desktop host pool named Pool1. Pool1 contains 10 session hosts that are joined to Contoso.com. You assign Group1 to the application group in Pool1. You need to identify which users will be able to sign in to the session hosts in Pool1. Which users should you identify? -

User1 only Correct Answer
User1 and User2 only
User1 and User3 only
User1, User2, and User3

Community Votes

62%

38%

62% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

AVD session hosts joined to an AD DS domain require users to exist in the on-premises AD DS, meaning cloud-only users in the synced tenant cannot authenticate.

For Azure Virtual Desktop session hosts domain-joined to an on-premises AD DS domain, only users synchronized from that AD DS can authenticate. This page confirms that cloud-only and guest users cannot sign in to AD DS-joined hosts.

Choosing User1 and User2 (Option B), assuming that any user in the Microsoft Entra tenant can sign in to a session host joined to the corresponding on-premises AD DS domain.

Community Discussion (7 comments)

belyo 👍 1 Selected: A

according to this https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/azure-virtual-desktop/eslz-identity-and-access-management#supported-identity-scenarios user 2 cannot as its not synced

hwoccurrence 👍 1 Selected: B

Since Pool1’s session hosts are joined to “contoso.com,” which is synchronized with the same “contoso.onmicrosoft.com” tenant, any user in that tenant can sign on—whether they originate on‐prem (synced) or are purely cloud‐only in the same Azure AD tenant. However, User 3 is a guest from a different tenant (“fabrikam.com”) and thus has no corresponding account in the “contoso.com” domain.

ClintC03 👍 1 Selected: A

The on-prem domain would know nothing of a cloud-only account so it has to be A.

sKostas 👍 2 Selected: A

I tried to my environment and it feeds the resources to the Remote desktop app but the user cannot connect.

Roee1 👍 1 Selected: A

Its A acording to Chat Gpt. The hosts are domain joined to the on premises AD DS so i only recognizes the users in the on permises active directory or the users that are synced to it, and since user 2 is a cloud only user, the host will not recognize it.

soysoliscarlos 👍 1

Its A. the only user domain joined is user 1

Korro 👍 2 Selected: B

It's either A or B in my opinion as: User1 -> works as the user is available in contoso.com and contoso.onmicrosoft.com due to the sync User2 -> is available in contoso.onmicrosoft.com but the Hosts are Domain joined just to contoso.com User3 -> is out in my opinion as it is only a Guest User https://learn.microsoft.com/en-us/azure/virtual-desktop/authentication https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/azure-virtual-desktop/eslz-identity-and-access-management 2nd link would say the following setup is supported Identity scenario Session hosts User accounts Microsoft Entra ID + AD DS Joined to AD DS In Microsoft Entra ID and AD DS, synchronized Microsoft Entra ID + AD DS Joined to Microsoft Entra ID In Microsoft Entra ID and AD DS, synchronized so I put my money on B

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

The session hosts in Pool1 are explicitly joined to the on-premises Active Directory Domain Services (AD DS) domain contoso.com. To authenticate to an AD DS domain-joined machine, a user principal must exist within that on-premises directory. User1 is synchronized from contoso.com to contoso.onmicrosoft.com, meaning User1 has an account in the on-premises AD DS and can successfully authenticate to the session hosts.

Why the Other Options Are Wrong

User3 is a guest user from fabrikam.com and does not have an account in the contoso.com domain, making Options C and D incorrect. User2 is a cloud-only user within contoso.onmicrosoft.com; because it is not synchronized from the on-premises AD DS, it has no corresponding account in contoso.com and cannot authenticate to the domain-joined session hosts, making Option B incorrect. As ClintC03 noted, "The on-prem domain would know nothing of a cloud-only account".

Community Comment Notes

The community correctly identifies that AD DS domain-joined hosts only recognize synced users, with belyo pointing out "user 2 cannot as its not synced". However, some users like Korro incorrectly assume that cloud-only users in the same tenant can authenticate, failing to recognize the boundary of an on-premises domain-joined machine which requires local AD DS presence.

Official Reference

https://learn.microsoft.com/en-us/azure/virtual-desktop/authentication

Exam Strategy

When evaluating AVD sign-in capabilities, always check the domain join type of the session hosts. If hosts are AD DS domain-joined, only users present in that on-premises AD DS (synced users) can sign in; cloud-only users require Microsoft Entra ID-joined or Microsoft Entra Domain Services-joined hosts.

Related Analysis

Practice All AZ-140 Questions

Access 64 questions with complete answers and detailed explanations.

View Full AZ-140 Practice Test →

← Back to AZ-140 Study Guide