With the release of VMware Horizon 2303, VMware Horizon now supports Hybrid Azure AD Join with Azure AD Connect using Instant Clones and non-persistent VDI.
So what exactly does this mean? It means you can now use Azure SSO using PRT (Primary Refresh Token) to authenticate and access on-premise and cloud based applications and resources.
What else? It allows you to use conditional access!
What is Hybrid Azure AD Join, and why would we want to do it with Azure AD Connect?
Historically, it was a bit challenging when it came to Understanding Microsoft Azure AD SSO with VDI (click to read the post and/or see the video), and special considerations had to be made when an organization wished to implement SSO between their on-prem non-persistent VDI deployment and Azure AD.
Azure AD SSO, the old way
The old way to accomplish this was to either implement Azure AD with ADFS, or use Seamless SSO. ADFS was bulky and annoying to manage, and Seamless SSO was actually intended to enable SSO on “downlevel devices” (older operating systems before Windows 10).
For customers without ADFS, I would always recommend using Seamless SSO to enable SSO on non-persistent VDI Instant Clones, until now!
Azure AD SSO, the new way with Azure AD Connect and Azure SSO PRTs
According to the release notes for VMware Horizon 2303:
Hybrid Azure Active Directory for SSO is now supported on instant clone desktop pools. See KB 89127 for details.
This means we can now enable and use Azure SSO with PRTs (Primary Refresh Tokens) using Azure AD Connect and non-persistent VDI Instant Clones.
Azure SSO with PRT and Non-Persistent VDI
This is actually a huge deal because not only does it allow us to use the preferred method for performing SSO with Azure, but it also allows us to start using fancy Azure features like conditional access!
Requirements for Hybrid Azure AD Join with non-persistent VDI and Azure AD Connect
In order to utilize Hybrid Join and PRTs with non-persistent VDI on Horizon, you’ll need the following:
- VMware Horizon 2303 (or later)
- Active Directory
- Azure AD Connect (Implemented, Configured, and Functioning)
- Azure AD Hybrid Domain Join must be enabled
- OU and Object filtering must include the non-persistent computer objects and computer accounts
- Create a VMware Horizon Non-Persistent Desktop Pool for Instant Clones
- “Allow Reuse of Existing Computer Accounts” must be checked
When you configure this, you’ll notice that after provisioning a desktop pool (or pushing a new snapshot), that there may be a delay for PRTs to be issued. This is expected, however the PRT will be issued eventually, and subsequent desktops shouldn’t experience issues unless you have a limited number available.
*Please note: VMware still notes that ADFS is the preferred way for fast issuance of the PRT.
While VMware does recommend ADFS for performance when issuing PRTs, in my own testing I had no problems or complaints, however when deploying this in production I’d recommend that because of the PRT delay after deploying the pool or a new snapshot, to do this after hours or SSO will not function for some users who immediately get a new desktop.
Additional Considerations
Please note the following:
- When switching from ADFS to Azure AD Connect, the sign-in process may change for users.
- You must prepare the users for the change.
- When using locally stored identifies and/or cached credentials, enabling Azure SSO may change the login process, or cause issues for users signing in.
- You may have to delete saved credentials in the users persistent profile
- You may have to adjust GPOs to account for Azure SSO
- You may have to modify settings in your profile persistent solution
- Example: “RoamIdentity” on FSLogix
- I recommend testing before implementing
- Test Environment
- Test with new/blank user profiles
- Test with existing users
If you’re coming from an environment that was previously using Seamless SSO for non-persistent VDI, you can create new test desktop pools that use newly created Active Directory OU containers and adjust the OU filtering appropriately to include the test OUs for synchronization to Azure AD with Azure AD Connect. This way you’re only syncing the test desktop pool, while allowing Seamless SSO to continue to function for existing desktop pools.
How to test Azure AD Hybrid Join, SSO, and PRT
To test the current status of Azure AD Hybrid Join, SSO, and PRT, you can use the following command:
dsregcmd /statusTo check if the OS is Hybrid Domain joined, you’ll see the following:
+----------------------------------------------------------------------+
| Device State |
+----------------------------------------------------------------------+
AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : YES
DomainName : DOMAIN
As you can see above, “AzureADJoined” is “YES”.
Further down the output, you’ll find information related to SSO and PRT Status:
+----------------------------------------------------------------------+
| SSO State |
+----------------------------------------------------------------------+
AzureAdPrt : YES
AzureAdPrtUpdateTime : 2023-07-23 19:46:19.000 UTC
AzureAdPrtExpiryTime : 2023-08-06 19:46:18.000 UTC
AzureAdPrtAuthority : https://login.microsoftonline.com/XXXXXXXX-XXXX-XXXXXXX
EnterprisePrt : NO
EnterprisePrtAuthority :
OnPremTgt : NO
CloudTgt : YES
KerbTopLevelNames : XXXXXXXXXXXXXHere we can see that “AzureAdPrt” is YES which means we have a valid Primary Refresh Token issued by Azure AD SSO because of the Hybrid Join.
[…] VMware Horizon 8 2303 now supports Hybrid Azure AD joined non-persistent VDI, using Azure AD Connect…. Using Horizon 8 version 2303, no scripts are required to manage Azure AD Devices. […]
Without ADFS does means we still need to wait for the AD Sync Cycle causing issues with instant clones right?
When enabling, provisioning, or updating the snapshot, I noticed there is now a slight delay for PRTs to start working properly, but once they do everything should be fine.
Hey Stephen,
I’m seeing on my instant clones that there is a scheduled task which runs on user logon to unjoin the computer and then rejoin it to Azure AD. Example:
Automatic device join pre-check tasks completed. Details:
preCheckResult: LeaveThenJoin
deviceKeysHealthy: NO (transport key)
isJoined: YES
isDcAvailable: YES
isSystem: YES
keyProvider: undefined
keyContainer: undefined
dsrInstance: AzureDrs
elapsedSeconds: 0
resultCode: 0x0
After it leaves, it does try the rejoin operation, but it fails because the device no longer exists in Azure AD until AD Connect does another sync operation. My question is, did you see this in your testing, and I’m considered removing the scheduled task to run at user log on but I’m unsure if this task does anything for the user or not. Thanks
Hi Nathan,
You shouldn’t have to modify the scripts in any way. Once you create a VM image as per VMware’s specs, and the configure Azure AD Connect, and configure the “Allow computer account re-use”, it should be automatic.
Is there a chance there were modifications made to the default config? I didn’t see this issue in my testing.
Note, once you push an image or create a desktop pool, it does take some time for Azure SSO with PRTs to function properly.
Nathan,
We had the same issue with the precheck result performing a leavethenjoin action. It was due to multiple improperly packaged applications with App volume manager.
In our case the applications were captured on a domain joined machine. My best guess is that the capture grabbed data related to the PRT being refreshed or issued.
Every time the application would load via AVM it hosed our Hybrid join and consequently the refresh token. Repackaging our apps on a workgroup vm was the permanent fix we came up with.
Hi there, is the PRT token present in non-persistent VDIs only? I don’t see anything about persistan VDI catalogs. Thank you.
Hi Jose,
Persistent VDI (and normal workstations) should have a PRT for SSO if configured properly. PRTs are issued on any Hybrid domain joined Windows system if everything is configured properly and functioning.
Cheers,
Stephen
Hello
I don’t understand how you make it work with Azure AD Connect sync.
When connecting to the instant clone, it doesn’t work – at all – because the computer account is not yet synced => no Azure AD join, no PRT
So I figure out that instant clones computer accounts MUST be pre-existing and synced by AAD Connect for hybrid ad join and PRT to work properly : do you confirm ?
Hi Frederic,
Great question, I’ll review the process below:
1) Deploy snapshot to Instant Clone Pool
2) Instant Clones are created (Re-Use Computer account selected)
3) Computer objects created on Local AD
4) Computer objects synced to Azure AD / Entra ID
5) Login to Instant Clone, Hybrid domain joined, functioning
Re-Use is selected, so once the computer objects are created, they will be re-used. If you don’t re-use computer objects, then they will be destroyed and re-created, causing failures as it has to wait for Azure AD Connect to sync.
Cheers,
Stephen
So I think this works for the most part… However, I still am VERY hit or miss with Office apps working. OneDrive does not auto-sign in half the time and I have been getting Proxy errors when I try to manually sign in. I have tried all of the IE reset suggestions that are out there to correct that error, but that doesn’t help. I am unsure at this point if the failed sign-ins are related to a network configuration or if I get that because I am failing somewhere else with the hybrid join.
I guess my next question would be, although we can hybrid join non-persistent clones, is that the best option? Other next question is, are you basically dead in the water until the sync happens and brings the computers into Azure? Unless you have a giant pool with VMs waiting around, that doesn’t seem like a good option unless you can force faster syncs on specific OUs.
Hi John,
When implementing this, Office apps may have that behavior if there are issues with the PRT, cached passwords, pending MFA requests, or problems with conditional access. You also need to make sure you have the various applications configured properly with the
applicable GPOs for first-run configuration, and day to day operations.
In my opinion, once implemented properly and you work out all the environment specific bugs (clearing out the old methods), it should work great! 🙂
The AD/Entra ID Connect sync shouldn’t be a problem except for the first time you deploy the pool. After that you should be in pretty good shape, as long as you have the “Reuse Computer Accounts” enabled.
Cheers,
Stephen
In this VMware KB (https://kb.omnissa.com/s/article/89127) it mentions best practice within horizon admin console please uncheck the box for “Allow Reuse of Existing Computer Accounts” in a full clone desktop pool. It does not mention anything about Instant clone desktop pool.
Hi Stephen,
Since April this year we are finding that suddenly are instant clone VMs are not getting issued with an Azure PRT and device certificate after some users logon, even though they machines have already been provisioned are have sat for over an hour before someone logs in.
When this happens SSO to OneDrive and Teams stops working for end-users and running dsgregcmd /status shows that no PTR is present and that there is a hostname conflict with another device ID.
We are fairly certain that we have everything configured as it should be including office apps and FSLogix as we have been running with this configuration for well over a year without issues.
We’ve got a support case opened with VMware/Omnissa at the moment and they are suggesting that the option “Allow reuse of existing computer accounts” should only be used for full clone desktop pools not instant clones and have asked us to de-select this but I’m not sure as others within the EUC space seem to be suggesting otherwise?
Hi Gaurav,
The KB previously advised to use “Reuse computer account” before it was recently modified. When using Instant Clones, you’ll want to make sure you have “Reuse Computer accounts” checked as the Instant Clones will update existing objects, instead of re-creating (which will assist with the replication to Azure AD/Entra ID).
Cheers,
Stephen
Hi Greig,
For full clones, “Allow Reuse” should be unchecked. For Instant Clones, it should be checked. I would check to make sure that your Azure AD Connect is still sync’ing and verify that the OUs are syncing.
For troubleshooting purposes, you might want to schedule some downtime, DISABLE provisioning on the Desktop Pool, delete the Instant Clones, delete the Instant Clone computer objects, delete the Azure AD Instant clone computer objects. Once all the AD/AAD objects have been deleted for the Instant Clones, snap your base image, push the snapshot, and after clone prep has run, enable provisioning.
After you enable provisioning, you should see the IC’s get created, AD objects get created, and eventually the AD objects will sync to AAD. I would then test again to verify it’s working.
Cheers,
Stephen
Some strange behavior in recent weeks, while it worked well before. The replica computer account is also getting Hybrid Joined. All Desktops will get the same Azure DeviceID as the replica causing only one system to be visible within Azure. The weird part is that the SSO is still working. Have you also noticed different behavior in recent weeks?
Do we have to configure the GPO “Enable automatic MDM enrollment using default Azure AD credentials”(https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.MDM::MDM_JoinMDM_DisplayName) ? If yes which option?
I can not find any information about this.
what about windows hello? as soon as i have the VM hybrid joined and lock it via windows+l, it wants a windows hello login, although this is blocked by policy. in addition, the auto. login in the office apps does not work, what needs to be considered? the hybrid joined does not currently bring me any advantages, except that i would fulfill the requirement for microsoft soc.
That’s very odd that it’s prompting you for Windows Hello. It sounds like you have it enabled somewhere. Id recommend confirming and disabling it.
As for Hybrid Domain, if it’s working and the PRT tokens are being generated, login creds shouldn’t be required for office, unless you have an MFA requirement. If it is because of MFA, you’ll need to change or create a policy for that.
do you mean i need a conditional access policy for the hybrid joined instant clones that says “you may use office apps without mfa”?
If you require it, then you’ll be prompted. Creating a conditional access policy is one way to stop the prompt.