Setting Up True Single Sign-On™ (True SSO™) in Horizon

[Ramesh V]

In the realm of virtual desktop infrastructure (VDI), seamless user experience and security are paramount. VMware Horizon, a leading VDI solution, offers True Single Sign-On™ (True SSO™) to enhance both aspects. True SSO allows users to authenticate once and gain access to their virtual desktops and applications without the need for re-entering credentials. This not only improves user convenience but also strengthens security by reducing the risk of credential theft.

Understanding True SSO

True SSO is an advanced feature in VMware Horizon that integrates with VMware Workspace ONE Access. It leverages smart cards, RSA SecurID, RADIUS, or third-party identity providers for authentication. Once users log in to Workspace ONE Access using these methods, they can launch virtual desktops or applications without providing their Active Directory credentials. This is particularly beneficial for users who access resources from untrusted domains or use devices outside the corporate network.

Prerequisites for True SSO

Before setting up True SSO, ensure that you have the following prerequisites in place:

• Microsoft Certificate Authority is set up, which is crucial for managing and issuing digital certificates.

• Certificate templates for True SSO are created, defining the rules and policies for issuing certificates.

• Horizon Enrollment server is installed and configured to manage the enrollment of users and devices.

• Horizon Enrollment service client certificate is exported and imported onto the enrollment server.

Configuring True SSO

The process of configuring True SSO involves several steps:

1. Set Up an Microsoft Certificate Authority: If you don't have an existing CA, you'll need to add the Active Directory Certificate Services (AD CS) role to a Windows server and configure it as an enterprise CA.

2. Create Certificate Templates Used with True SSO: Define the certificate templates that will be used to issue certificates for True SSO.

3. Install and Set Up an Enrollment Server: Deploy an Horizon Enrollment server to handle the enrollment process for users and devices.

4. Export the Enrollment Service Client Certificate: Export the client certificate from the Horizon Enrollment server for later use in the configuration process.

5. Configure SAML Authentication to Work with True SSO: Set up SAML authentication to integrate with VMware Workspace ONE Access, which is a prerequisite for True SSO.

6. Configure Horizon Connection Server for True SSO: Use the vdmutil command-line interface to configure True SSO on the connection server.

Advanced Configuration Settings

For more granular control over True SSO, you can manage advanced settings using Group Policy Objects (GPOs) on the Horizon Agent machine, registry settings on the Horizon Enrollment server, and LDAP entries on the Connection Server. These settings include configuring default timeouts, load balancing, and specifying domains to be included.

Troubleshooting True SSO

If True SSO stops working, users might see an "incorrect username or password" message. To troubleshoot, administrators can use the system health dashboard in Horizon Console to identify and resolve issues related to True SSO.

Conclusion

True SSO in VMware Horizon is a powerful feature that simplifies the authentication process for users while enhancing security. By following the steps outlined in this guide, you can set up True SSO in your Horizon environment, providing your users with a more seamless and secure experience. Remember to refer to the official VMware documentation for the most up-to-date information and best practices.

[Gerard Strouth]

With TrueSSO and Windows Hello for Business are you looking at adding more options than just certificate trust like cloud trust?

[StephenWagner7]

I'm also curious what the status is of TrueSSO being used with Hybrid Domain Joined Instant Clones, as last I heard it doesn't support Azure Parts (Primary Refresh Tokens).

TrueSSO with support for PRT would be AMAZINGGGGG 😎👌

[Sascha Warno]

Shared this internally, Engineering is validating from their side still before adding it to the KB. Also with instant clones you will always see delays until they are hybrid joined right?! The method was tested with persistent machines. But the underlying issue would be the same.

Quote

SSO using Azure PRT token with VDIs and TrueSSO
So I tested it in one env so far and need to replicate it still, but if somebody else wants to test you can try the following when using TrueSSO and a non federated EntraID/AzureAD together with Hybrid Entra/Azure join.
The issue is that with TrueSSO the login is based on a certificate/smartcard login and the login method is saved in the login information.
To get an Azure PRT the Windows Sign In uses the information against the active login endpoint. Without TrueSSO the user signs in with username/password and that info works against the active flow endpoint of Azure without issues because it offers that method.
When you use TrueSSO it will send the cert data to that active flow endpoint, which cannot validate it as this is not a default method in Entra. You should see non interactive Sign-In log entries for the user and the Windows Sign In service resulting in Failure and with the authentication method x.509 failing.
But since last year you can actually configure CBA for EntraID directly and with that give it an option to handle and validate the TrueSSO certificate information.
So what we did was activate CBA on the Entra tenant and configure it as authentication method with the Root CA certificate used by the Enrollment server.
https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-certificate-based-authentication
It will take some minutes for the settings to be applied, so be patient. It is correctly applied when it shows up in the sign in dialog under other ways to sign in or sign in with a certificate link.
Afterwards, when signing in with TrueSSO we can see the Windows Sign In using x.509 successfully, creating the Azure PRT for the user and adding the user under Settings > Accounts > Email & Accounts. SSO was tested with portal.office.com and picks up the PRT.

 

Edited June 14 by Sascha Warno

[StephenWagner7]

/Deleted

Edited June 14 by StephenWagner7
Deletion

[ramkumar]

On 6/14/2024 at 2:57 AM, Sascha Warno said:

Shared this internally, Engineering is validating from their side still before adding it to the KB. Also with instant clones you will always see delays until they are hybrid joined right?! The method was tested with persistent machines. But the underlying issue would be the same.

 

@Sascha Warno

Please disregard if this is a duplicate post. I am not sure if my first post got submitted.

I am not an Horizon expert but working with one of them closely from my organization to roll out Azure MFA for our VDI login using UAG with SAML SSO with Azure and the true SSO feature to seamlessly sign in to the VDI.

However, the PRT for Azure AD is not getting issued. We have enabled CBA in our Azure Tenancy exactly as mentioned in your quoted post and are struggling to get this working.

Not sure if we are missing anything. I am trying to see if there are any detailed articles that can guide us. 

Any assistance is greatly appreciated.

[StephenWagner7]

On 9/21/2024 at 11:36 PM, ramkumar said:

@Sascha Warno

Please disregard if this is a duplicate post. I am not sure if my first post got submitted.

I am not an Horizon expert but working with one of them closely from my organization to roll out Azure MFA for our VDI login using UAG with SAML SSO with Azure and the true SSO feature to seamlessly sign in to the VDI.

However, the PRT for Azure AD is not getting issued. We have enabled CBA in our Azure Tenancy exactly as mentioned in your quoted post and are struggling to get this working.

Not sure if we are missing anything. I am trying to see if there are any detailed articles that can guide us. 

Any assistance is greatly appreciated.

I know this was directed at Sascha, but thought I'd chime in quickly. We'll need more details to know what's not working...

Can you verify the OUs that contain the Instant Clones is sync'ed? Also, can you copy/paste a "dsregcmd /status" from one of your instant clones, removing any identifiable information.

[Gerard Strouth]

Yeah and which issue are we talking since you are talking about 2. Is it the sign in to the horizon desktop or the horizon desktop being hybrid joined? 

[ramkumar]

@StephenWagner7 / @Gerard Strouth

The true SSO into the VDI machine itself is working fine as expected. It is the SSO into Office 365 portal that is not happening after the user is logged into the VDI and is prompting users to sign into any of the office 365 apps with their credentials again. The PRT is not getting issued.

Yes, we did verify that the machine is synced in and is showing as HybridAD joined in Entra.

Here is the dsregcmd /status output. (removed information specific to our org).

 

DsrCLI: logging initialized.

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : YES
          EnterpriseJoined : NO
              DomainJoined : YES
                DomainName : xxx
               Device Name : xxx.xxx.xxx

+----------------------------------------------------------------------+
| Device Details                                                       |
+----------------------------------------------------------------------+

                  DeviceId : xxxxxxx
                Thumbprint : xxxxxx
 DeviceCertificateValidity : [ 2024-09-17 20:59:24.000 UTC -- 2034-09-17 21:29:24.000 UTC ]
            KeyContainerId : xxxxxxxx
               KeyProvider : Microsoft Software Key Storage Provider
              TpmProtected : xxxx
          DeviceAuthStatus : SUCCESS

+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+

                    NgcSet : NO
           WorkplaceJoined : NO
             WamDefaultSet : YES
       WamDefaultAuthority : organizations
              WamDefaultId : https://login.microsoft.com
            WamDefaultGUID : {xxxxxx} (AzureAd)

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+

                AzureAdPrt : NO
       AzureAdPrtAuthority : 
             EnterprisePrt : NO
    EnterprisePrtAuthority : 

+----------------------------------------------------------------------+
| Diagnostic Data                                                      |
+----------------------------------------------------------------------+

        AadRecoveryEnabled : NO
    Executing Account Name : xxxxx, xxxxx
               KeySignTest : PASSED

        DisplayNameUpdated : YES
          OsVersionUpdated : YES
           HostNameUpdated : YES

      Last HostName Update : NONE

+----------------------------------------------------------------------+
| IE Proxy Config for Current User                                     |
+----------------------------------------------------------------------+

      Auto Detect Settings : YES
    Auto-Configuration URL : 
         Proxy Server List : 
         Proxy Bypass List : 

+----------------------------------------------------------------------+
| WinHttp Default Proxy Config                                         |
+----------------------------------------------------------------------+

               Access Type : DIRECT

+----------------------------------------------------------------------+
| Ngc Prerequisite Check                                               |
+----------------------------------------------------------------------+

            IsDeviceJoined : YES
             IsUserAzureAD : NO
             PolicyEnabled : NO
          PostLogonEnabled : YES
            DeviceEligible : YES
        SessionIsNotRemote : YES
            CertEnrollment : none
              PreReqResult : WillNotProvision

For more information, please visit https://www.microsoft.com/aadjerrors

 

Edited September 23 by ramkumar

[Hans Kraaijeveld]

I think a colleague of mine solved (what I'm guessing is your) issue by implementing this, using the same CA that is responsible for issuing the TrueSSO user certificates:

https://learn.microsoft.com/en-gb/entra/identity/authentication/how-to-certificate-based-authentication

This is then coupled to the UPN of the user and when you allow Conditional Access Certificate Based Authentication, it should do the trick. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication

[ramkumar]

@Hans Kraaijeveld

Thanks, we got this to work. Had to play around with the CBA config in Azure. 

I had a question on the bindings. We had to use a low affinity binding to bind to the UPN. Is there anyway to implement high affinity bindings in Azure CBA? Since the Cert is dynamically generated for the user, the issuer serial number is the only thing i could think of as a potential candidate for high affinity binding