iTranslated by AI
Switching from ADJ to MEHJ to enable SSO in AVD
TL;DR
- I want to enable SSO for AVD.
- To achieve this, I want to change from ADJ, a common AVD deployment method, to MEHJ.
- I'm happy that SSO was achieved without introducing additional components like AD FS.
Introduction
A basic deployment method for Azure Virtual Desktop (AVD) is the Active Directory joined (AD joined, ADJ) configuration.
However, as stated in Configure single sign-on for Azure Virtual Desktop using Microsoft Entra ID authentication, achieving single sign-on (SSO) requires Microsoft Entra joined (MEJ) or Microsoft Entra hybrid joined (MEHJ).
Assuming an existing AD joined state, I will describe the steps to change the environment to MEHJ and ultimately achieve SSO for AVD.
As shown in the table of contents, the general procedure is as follows:
- Change the AVD session host from ADJ to MEHJ
- Change settings on the AVD control plane side
- Add settings for SSO on the AD server
- Connect from the Remote Desktop client
Changing from ADJ to MEHJ
Changing from an AD joined configuration to MEHJ is typically done via Microsoft Entra Connect configuration.
Since this procedure is a bulk deployment method for large-scale environments and I have only tested individual deployments for single machines, this part is based on documentation.
The documentation can be found at Configure Microsoft Entra hybrid join -- Managed domains.
The method I actually tested allows for per-machine application, as described in Targeted deployment of Microsoft Entra hybrid join.
By using Group Policy Objects (GPOs) and creating/linking an Organizational Unit (OU) containing the target computers on the AD server, you can proceed with the migration to MEHJ in stages.
For smaller-scale scenarios, assuming you have administrative privileges, you can also modify the registry directly using gpedit or the command line.
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD" /v TenantId /t REG_SZ /d "0ctenant-id0" /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD" /v TenantName /t REG_SZ /d "0ctenant-name0" /f
You can find 0ctenant-id0 and 0ctenant-name0 in the Azure Portal or other sources.
For 0ctenant-name0, using the initially assigned domain like xxxxxxx.onmicrosoft.com worked fine even if a custom domain was available.
Afterward, the status changes to MEHJ after restarting the machine a few times.
There are several ways to verify the status.
-
Verify with
dsregcmd /statusThis is a reliable method that can be executed on the client device.
Although using older terminology, ifAzureAdJoinedandDomainJoinedare both set toYES, you can determine that it is in the MEHJ state. Troubleshooting methods are described in Troubleshooting devices using the dsregcmd command. In my case, I ran into an error because I tried using Cloud Sync instead of Microsoft Entra Connect Sync, which resulted in device information not being synchronized. A feature comparison between Connect sync and Cloud sync can be found in What is Microsoft Entra Cloud Sync? -- Comparison between Microsoft Entra Connect and Cloud Sync. -
Verify in the Portal
You can verify the specific machine information from a portal where device information is available, such as the Azure Portal or the Microsoft Intune Admin Center. Since this requires specific permissions, it is primarily a verification method for administrators.
Enable Microsoft Entra authentication for RDP
Regarding this part, I didn't get lost because it was exactly as described in the docs.
Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications
Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"
$MSRDspId = (Get-MgServicePrincipal -Filter "AppId eq 'a4a365df-50f1-4397-bc59-1a1564b8bb9c'").Id
$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id
After that, first confirm that it is false.
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId
Then, change it to true and check again.
If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId) -ne $true) {
Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId -IsRemoteDesktopProtocolEnabled
}
If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId
Configure target device groups
Regarding this part described in the docs, it was about hiding the dialog that users are first asked when logging in with SSO, so I have omitted it for now.
Create a Kerberos server object
This part is tricky, but I suspect that when you log in with SSO using Microsoft Entra ID authentication, issues occur when accessing resources that require Kerberos authentication because AD authentication hasn't been performed.
Follow the steps described in Passwordless security key sign-in to on-premises resources -- Create a Kerberos server object to create a corresponding object.
There were four types of examples and I wasn't quite sure, but in the end, it worked by executing what was likely the second procedure on AD.
This step is unnecessary if the session host is MEJ instead of MEHJ.
For example, if you are building a new AVD environment and do not use or have connectivity to file servers that use AD authentication—meaning all authentication is Microsoft Entra ID authentication—you can skip this step.
Configure the host pool to enable single sign-on
This part is simple: just select the relevant host pool in the Azure Portal and configure the corresponding item in the RDP properties.
Connecting from the Remote Desktop client
Now, let's try connecting.
If successful, you should be able to connect by double-clicking the AVD resource without being prompted for a password.
If you are prompted for a password, you might have skipped a step, the settings might not have been reflected yet, or network connectivity to the required destinations might not be maintained.
In my case, it didn't work when I skipped the Kerberos server object creation, thinking it probably wasn't necessary...
Summary
I have described the steps to enable SSO by migrating from the basic AVD deployment environment, ADJ, to MEHJ.
I think it's quite convenient to be able to use SSO without specific requirements for the local machine (such as needing to be Microsoft Entra Registered (MER) or MEJ).
When AVD first came out, there were discussions about setting up Active Directory Federation Services (ADFS) just to enable SSO for AD authentication, but I'm relieved that a proper cloud-native solution is now correctly provided.
References
- Configure single sign-on for Azure Virtual Desktop using Microsoft Entra ID authentication
- Tried configuring Microsoft Entra Hybrid Join (formerly HAADJ)
- Configure Microsoft Entra Kerberos authentication for SSO to on-premises resources
- Configure Microsoft Entra hybrid join -- Managed domains
- Targeted deployment of Microsoft Entra hybrid join
- Initial investigation method for Hybrid Azure AD Join failure (Managed Edition)
- How Microsoft Entra device registration works
- Troubleshooting devices using the dsregcmd command
- Passwordless security key sign-in to on-premises resources -- Create a Kerberos server object
Update log
- Added general procedure - 2024/05/04
- Added links to some great blog posts - 2024/05/04
Discussion