Whether deploying VDI for the first time or troubleshooting existing Azure AD SSO issues for an existing environment, special consideration must be made for Microsoft Azure AD SSO and VDI.
When you implement and use Microsoft 365 and Office 365 in a VDI environment, you should have your environment configured to handle Azure AD SSO for a seamless user experience, and to avoid numerous login prompts when accessing these services.
Microsoft Azure Active Directory has two different methods for handling SSO (Single Sign On), these include SSO via a Primary Refresh Token (PRT) and Azure Seamless SSO. In this post, I’ll explain the differences, and when to use which one.
What does Azure AD SSO do?
Azure AD SSO allows your domain joined Windows workstations (and Windows Servers) to have a Single Sign On experience so that users can have an single sign-on integrated experience when accessing Microsoft 365 and/or Office 365.
When Azure AD SSO is enabled and functioning, your users will not be prompted nor have to log on to Microsoft 365 or Office 365 applications or services (including web services) as all this will be handled transparently in the background with Azure AD SSO.
For VDI environments, especially non-persistent VDI (VMware Instant Clones), this is an important function so that users are not prompted to login every time they launch an Office 365 application.
Persistent VDI is not complex and doesn’t have any special considerations for Azure AD SSO, as it will function the same way as traditional workstations, however non-persistent VDI requires special planning.
Please Note: Organizations often associate the Office 365 login prompts to activation issues when in fact activation is functioning fine, however Azure AD SSO is either not enabled, incorrect configured, or not functioning which is why the users are being prompted for login credentials every time they establish a new session with non-persistent VDI. After reading this guide, it should allow you to resolve the issue of Office 365 login prompts on VDI non-persistent and Instant Clone VMs.
Azure AD SSO methods
There are two different ways to perform Azure AD SSO in an environment that is not using ADFS. These are:
- Azure AD SSO via Primary Refresh Token
- Azure AD Seamless SSO
Both accomplish the same task, but were created at different times, have different purposes, and are used for different scenarios. We’ll explore this below so that you can understand how each works.
Fun fact: You can have both Azure AD SSO via PRT and Azure AD Seamless SSO configured at the same time to service your Active Directory domain, devices, and users.
Azure SSO via Primary Refresh Token
When using Azure SSO via Primary Refresh Token, SSO requests are performed by Windows Workstations (or Windows Servers), that are Hybrid Azure AD Joined. When a device is Hybrid Azure AD Joined, it is joined both to your on-premise Active Directory domain, as well registered to your Azure Active Directory.
Azure SSO via Primary Refresh token requires the Windows instance to be running Windows 10 (or later), and/or Windows Server 2016 (or later), as well the Windows instance has to be Azure Hybrid AD joined. If you meet these requirements, SSO with PRT will be performed transparently in the background.
If you require your non-persistent VDI VMs to be Hybrid Azure AD joined and require Azure AD SSO with PRT, special considerations and steps are required:
This includes:
- Scripts to automatically unjoin non-persistent (Instant Clone) VDI VMs from Azure AD on logoff.
- Scripts to cleanup old entries on Azure AD
If you properly deploy this, it should function. If you don’t require your non-persistent VDI VMs to be Hybrid Azure AD joined, then Azure AD Seamless SSO may be better for your environment.
VMware Horizon 8 2303 now supports Hybrid Azure AD joined non-persistent VDI, using Azure AD Connect, providing Azure AD SSO with PRT. Using Horizon 8 version 2303, no scripts are required to manage Azure AD Devices.
Azure AD Seamless SSO
Microsoft Azure AD Seamless SSO after configured and implemented, handles Azure AD SSO requests without the requirement of the device being Hybrid Azure AD joined.
Seamless SSO works on Windows instances instances running Windows 7 (or later, including Windows 10 and Windows 11), and does NOT require the the device to be Hybrid joined.
Seamless SSO allows your Windows instances to access Azure related services (such as Microsoft 365 and Office 365) and provides a single sign-on experience.
This may be the easier method to use when deploying non-persistent VDI (VMware Instant Clones), if you want to implement SSO with Azure, but do not have the requirement of Hybrid AD joining your devices.
Additionally, by using Seamless SSO, you do not need to implement the require log-off and maintenance scripts mentioned in the above section (for Azure AD SSO via PRT).
To use Azure AD Seamless SSO with non-persistent VDI, you must configure and implement Seamless SSO, as well as perform one of the following to make sure your devices do not attempt to Hybrid AD join:
- Exclude the non-persistent VDI computer OU containers from Azure AD Connect synchronization to Azure AD
- Implement a registry key on your non-persistent (Instant Clone) golden image, to disable Hybrid Azure AD joining.
To disable Hybrid Azure AD join on Windows, create the registry key on your Windows image below:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: "BlockAADWorkplaceJoin"=dword:00000001Conclusion
Different methods can be used to implement SSO with Active Directory and Azure AD as stated above. Use the method that will be the easiest to maintain and provide support for the applications and services you need to access. And remember, you can also implement and use both methods in your environment!
After configuring Azure AD SSO, you’ll still be required to implement the relevant GPOs to configure Microsoft 365 and Office 365 behavior in your environment.
Additional Resources
Please see below for additional information and resources:
- Microsoft: What is single sign-on in Azure Active Directory
- Microsoft: Plan your hybrid Azure Active Directory join implementation
- Microsoft: Configure Hybrid Azure AD join
- Microsoft: Azure Active Directory Seamless Single Sign-On
- Microsoft: Azure Active Directory Seamless Single Sign-On Technical Deep Dive
- Microsoft: Azure Active Directory Seamless Single Sign-On Quickstart
- Microsoft: Device identity and desktop virtualization
[…] Microsoft Azure SSO (via PRT or Seamless SSO) for Microsoft 365 and Office 365 Single sign-on […]
[…] Use Seamless SSO instead of Hybrid Azure AD join (click here for more information) […]
Thanks for the great post. Very informative. Just wondering if you have any suggestions with UAG and TrueSSO? At present that doesn’t work. The only way to get it to work is to force SAML and Passthrough. Internally it is fine.
Hi Fernando, I don’t have much experience with TrueSSO.
When you say it doesn’t work, is that because it’s unsupported, or is it supported?
Hi Stephen, So the TrueSSO and UAG work fine with doing passthrough for VDI.
But if the user is set to AD Auth in Azure and not ADFS, once they are on the VDI session, any access to Azure resources, i.e. Teams, Exchange, OneDrive etc, doesn’t do Passthrough. They need to reenter the username and password for that product.
doing a dsregcmd /status shows the PRT is missing.
If they lock the VDI session and then unlock it, the PRT is issued and logging into Azure Resources starts doing SSO/Passthrough.
[…] 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 […]
Hello Stephen!
I tested M365 apps on a horizon rdsh farm with hybrid joined machines. As soon as the machines are synchronised once by azure ad connector into entra (takes around 45 Min.) all works fine,
a user can start an office app without any sign in is prompted.
And that works also if we do a maintenance of the horizon farm and re-deploy the machines from master. I experienced that the computer accounts of the machines are retaining their validity in AD and in Entra.
The time delay caused by the AD Connector only comes into effect when new machines are added. That’s no huge problem at RDSH machines – different to the VDI floating machines.
So may questions:
Why do you think scripts for unjoin and cleanup are necessary here?
Do you see any possibility to do the hybrid join process of a machine without azure ad connector, initiated from a client machine – to reduce or skip the delay?
Hi Martin,
In your cause, I don’t think any scripts for cleanup are required if you use the “Re-Use Computer Account” setting, as it’ll re-use existing objects.
Additionally, in the latest version of Omnissa Horizon, version 2406, you can now have it wait to show as available until Hybrid Domain join completes.
Cheers,
Stephen