VMware Horizon True SSO with UAG SAML

Last Modified: Feb 29, 2024 @ 3:59 pm

Navigation

Change Log

Overview

To configure SAML on Unified Access Gateway (UAG) you must have the following versions:

  • UAG 3.8 or newer
  • Connection Servers 7.11 or newer
  • For Windows 10 version 2004, deploy Horizon 2103 (8.2) or newer.

True SSO is optional.

  • SAML does not provide the user’s password to Horizon, which means that Horizon cannot perform single sign-on to the Horizon Agent machine and thus the Horizon Agent machine will prompt the user to login again. This usually means the user has to login twice.
  • To eliminate the second logon on the Horizon Agent machine, implement True SSO, which generates certificates for each user and then uses those certificates to automatically sign into the Horizon Agent machine.

Horizon Enrollment Servers ask Microsoft Certificate Authority servers to generate the SSO certificates for each user. This is an identity operation and thus the Horizon Enrollment Servers should be treated like Domain Controllers.

When you use Horizon Client to connect to a UAG that is SAML-enabled:

  1. It opens the default browser and prompts the user to sign into your SAML Identity Provider. If the user is already signed in then the user won’t see any sign-in prompt.
  2. After sign-in, the browser will then prompt the user to open VMware Horizon Client.
  3. If the user locks the desktop then the user will need to know the local Active Directory password to unlock it.

Certificate Authority

Horizon Enrollment Servers can use a Microsoft Certificate Authority that already exists. Or you can install Microsoft Certificate Authority on the Horizon Enrollment Servers. If you have two Enrollment Servers, then install Microsoft Certificate Authority on both of the servers.

  1. Install Microsoft Certificate Authority from Server Manager > Manage > Add Roles and Features.
  2. Select Active Directory Certificate Services.
  3. The only Role Service needed for True SSO is Certification Authority.

The Microsoft Certificate Authority must be an Enterprise CA.

  1. After role installation, click the flag icon and then click the link to Configure Active Directory Certificate Services.
  2. In the Setup Type page, select Enterprise CA.
  3. In the CA Type page, if you already have a Root CA, then you can select Subordinate CA. Otherwise, you need at least one Root CA in your environment.

After Microsoft CA is installed, run the following commands:

certutil -setreg DBFlags +DBFLAGS_ENABLEVOLATILEREQUESTS
certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE
sc stop certsvc
sc start certsvc

If you just built a new Certificate Authority server then True SSO won’t work until you run gpupdate /force on all of your Domain Controllers and Horizon Agent machines. Or wait several hours for group policy to update.

Certificate Template

  1. On the Certificate Authority machine, from Start Menu, run Certification Authority.
  2. Right-click the Certificate Templates node and click Manage.
  3. Right-click the Smartcard Logon template and click Duplicate Template.
  4. On the Compatibility tab, change the drop-down for Certification Authority to Windows Server 2008 R2.
  5. Change the drop-down for Certificate recipient to Windows 7 / Server 2008 R2.
  6. On the General tab, name it True SSO or similar.
  7. Change the Validity Period to 1 day or similar.
  8. On the Request Handling tab, change the drop-down for Purpose to Signature and smartcard logon.
  9. Check the box next to For automatic renewal of smart card certificates, use the existing key if a new key cannot be created.
  10. On the Cryptography tab, change the drop-down for Provider Category to Key Storage Provider.
  11. On the Server tab, check the top box for Do not store certificates and requests in the CA database.
  12. Uncheck the bottom box for Do not include revocation information in issued certificates.
  13. On the Issuance Requirements tab, check the box next to This number of authorized signatures and enter 1 as the value.
  14. Change the drop-down for Policy type required in signature to Application policy.
  15. Change the drop-down for Application policy to Certificate Request Agent.
  16. At the bottom, change the selection to Valid existing certificate.
  17. On the Security tab, add your Horizon Enrollment Servers computer objects. This can be an AD group instead of individual servers.
  18. For each Enrollment Server computer object, on the bottom, check the Allow box for the Enroll permission. Click OK when done.
  19. Back in the Certificate Templates Console, right-click the Enrollment Agent (Computer) template and click Properties.
  20. On the Security tab, add your Horizon Enrollment Servers computer objects. This can be an AD group instead of individual servers.
  21. For each Enrollment Server computer object, on the bottom, check the Allow box for the Enroll permission. Click OK when done.
  22. Close the Certificate Templates Console.
  23. Back in the Certification Authority Console, with Certificate Templates highlighted on the left, if your environment has multiple CAs but this CA is dedicated to True SSO, then delete all templates from the right. Note: Domain Controllers must have certificates installed so make sure you have at least one other CA that is issuing Domain Controller certificates.
  24. Right-click Certificate Templates and click New > Certificate Template to Issue.
  25. Select Enrollment Agent (Computer) and click OK.
  26. Issue another certificate template but this time select the True SSO template.
  27. Your CA should now show the two templates.
  28. If you have a second CA, and if it is dedicated to True SSO, then delete all templates from that CA. Then configure it to issue the same two templates.

Enrollment Server

Horizon Enrollment Server must be installed on dedicated machine(s) that don’t have any other Horizon components installed.

  1. Login to the new Horizon Enrollment Server that has at least 4 GB of RAM.
  2. Run certlm.msc.
  3. Expand Personal, then right-click Certificates, expand All Tasks, and click Request New Certificate.

    1. In the Before You Begin page, click Next.
    2. In the Select Certificate Enrollment Policy page, click Next.
    3. In the Request Certificates page, check the box next to Enrollment Agent (Computer) and then click Enroll.
    4. In the Certificate Installation Results page, click Finish.
    5. Notice the expiration date on the Enrollment Agent certificate. Make sure you renew it before it expires.
  4. Go to the downloaded Horizon software and run VMware-Horizon-Connection-Server-x86_x64.exe.
  5. In the Welcome to the Installation Wizard for VMware Horizon Connection Server page, click Next.
  6. In the License Agreement page, select I accept the terms in the license agreement and click Next.
  7. In the Destination Folder page, click Next.
  8. In the Installation Options page, change the selection to Horizon Enrollment Server and click Next.
  9. In the Firewall Configuration page, click Next.
  10. In the Ready to Install the Program page, click Install.
  11. In the Installer Completed page, click Finish.
  12. If Microsoft CA is installed on the Enrollment Server, then run regedit.
    1. Go to HKLM\Software\VMware, Inc.\VMware VDM.
    2. Create a new Key named Enrollment Service.
    3. Under Enrollment Service, create a new String (REG_SZ) value named PreferLocalCa and set it to 1.
    4. Also add string values for UseKerberosAuthenticationToCa = false and UseNTLMAuthenticationToCa = true
  13. If you have two Enrollment Servers, then repeat this entire section on the other server. This includes requesting the Enrollment Agent certificate, installing the Enrollment Server software, and setting the PreferLocalCa registry value.

Trust

  1. Log in to a Connection Server and run certlm.msc.
  2. On the left, expand VMware Horizon View Certificates and then click Certificates.
  3. On the right, find the certificate with the Friendly Name vdm.ec, right-click it, expand All Tasks, and then click Export. All Connection Servers have the same certificate so you only need to export from one of the Connection Servers.
  4. In the Export Private Key page, select No, do not export the private key, and then click Next.
  5. In the Export File Format page, leave it set to DER, and then click Next.
  6. Save the certificate to a file that you can access from your Enrollment Server(s).
  7. Log in to an Enrollment Server and run certlm.msc.
  8. On the left, right-click VMware Horizon View Enrollment Server Trusted Roots, expand All Tasks, and click Import.
  9. In the Welcome to the Certificate Import Wizard page, click Next.
  10. In the File to Import page, browse to the certificate that you exported from the Connection Server and then click Next.
  11. In the Certificate Store page, VMware Horizon View Enrollment Server Trusted Roots should already be selected so just click Next.
  12. In the Completing the Certificate Import Wizard page, click Finish.
  13. Repeat the certificate import process on the other Horizon Enrollment Server.

SAML to UAG

  1. Login to your SAML Identity Provider (IdP) and create an application for Unified Access Gateway.
  2. For Okta, see VMware Tech Zone.
  3. Azure AD has a gallery application to make configuration easier. Or use the following values:
    • Identifier = https://*.HORIZON_UAG_FQDN.com/portal
    • Reply URL (Assertion Consume Service URL = https://<HORIZON_UAG_FQDN>/portal/samlsso
  4. When done, it should look something like this:
  5. Download the Federation Metadata XML from your Identity Provider. The Metadata Url doesn’t seem to work.
  6. Login to your UAG admin page (https://<HORIZON_UAG_FQDN>:9443/admin).
  7. Select Configure Manually.
  8. Scroll down to the section named Identity Bridging Settings and click Upload Identity Provider Metadata.
  9. In Unified Access Gateway 2312 and newer, click Upload IDP Metadata.
  10. Click Select in the IDP Metadata row.
  11. Browse to the metadata .xml file and then click Save.
  12. At the top of the page, next to Edge Service Settings click SHOW.
  13. Next to Horizon Settings click the gear icon.
  14. At the bottom of the page, click More.
  15. At the top of the page, change the drop-down for Auth Methods to SAML.
  16. Change the drop-down for Identity Provider to the SAML Identifier in the Metadata that you just imported.
  17. At the bottom of the page click Save.
  18. Login to Horizon Console.
  19. In the left menu, go to Settings > Servers.
  20. On the right, click the tab named Connection Servers.
  21. Highlight a Connection Server that UAG talks to and click Edit.
  22. Switch to the tab named Authentication.
  23. Change the drop-down for Delegation of Authentication to VMware Horizon (SAML 2.0 Authenticator) to Allowed.
  24. Click the button named Manage SAML Authenticators.
  25. Click Add.
  26. Change the selection for Type to Static. Dynamic seems to only be valid for VMware Access (aka Identity Manager).
  27. Go to your Metadata .xml file and edit it with a text editor. Then copy its contents to your clipboard.
  28. Back in Horizon Console, in the SAML Metadata field, paste in the contents.
  29. Give your SAML 2.0 Authenticator a name and click OK.
  30. Click OK to close the Manage SAML Authenticators window.
  31. Edit other Connection Servers that UAG talks to and go to the Authentication tab.
  32. Set SAML 2.0 Authenticator to Allowed and then click the Manage SAML Authenticators button.
  33. The previously created SAML Authenticator should already be there so just click Edit.
  34. At the bottom, check the box next to Enabled for Connection Server and then click OK. Repeat on any other Connection Server that UAG talks to.
  35. In Horizon Console, if you go to Monitor > Dashboard and then click VIEW in the System Health section.
  36. On the left go to Other Components. On the right go to the tab named SAML 2.0. You should see your SAML Authenticator.

Enable True SSO

Login to one of the Connection Servers and open a Command Prompt as administrator. The commands in this section have case sensitive parameter names. These commands are vdmutil, not vdmadmin.

Run the following command to add each Enrollment Server. Notes:

  • For the --authPassword fields, you enter "*" (with quotes) to be prompted to enter the password instead of specifying it at the command line.
  • --authAs fields do not include the domain name since domain is a different field.
vdmUtil --authAs admin-username --authDomain domain-name --authPassword admin-user-password --truesso --environment --add --enrollmentServer enroll-server1-fqdn,enroll-server2-fqdn

Run the following command to see the available certificate authorities and certificate templates for a particular domain.

vdmUtil --authAs admin-username --authDomain domain-name --authPassword admin-user-password --truesso --environment --list --enrollmentServer enroll-server-fqdn --domain domain-fqdn

Run the following command to enable the Enrollment Servers for a particular domain. This syntax configures the Enrollment Servers as active/passive (failover). Note: certificateServer is the CA name from the previous command and not the server’s FQDN.

vdmUtil --authAs admin-username --authDomain domain-name --authPassword admin-user-password --truesso --create --connector --domain domain-fqdn --template TrueSSO-template-name --primaryEnrollmentServer enroll-server-fqdn --secondaryEnrollmentServer enroll-server-fqdn --certificateServer ca1-common-name1,ca2-common-name --mode enabled

Run the following command to see the SAML Authenticators configured in Horizon Console.

vdmUtil --authAs admin-username --authDomain domain-name --authPassword admin-user-password --truesso --list --authenticator

Run the following command to enable True SSO for a particular SAML Authenticator. Enter either ENALBED or ALWAYS.

vdmUtil --authAs admin-username --authDomain domain-name --authPassword admin-user-password --truesso --authenticator --edit --name authenticator-name --truessoMode {ENABLED|ALWAYS}

For more info, see Command-line Reference for Configuring True SSO at VMware Docs.

If you prefer to load balance your Enrollment Servers instead of active/passive, do the following:

  1. On a Connection Server, run adsiedit.msc.
  2. Change the Connection Point to dc=vdi,dc=vmware,dc=int.
  3. Change the Computer to localhost and then click OK.
  4. On the left, expand Properties, and then click Global.
  5. On the right, double-click Common.
  6. Find pae-NameValuePair in the list and Edit it.
  7. Enter cs-view-certsso-enable-es-loadbalance=true and then click Add.
  8. Click OK a couple times to close everything.

You can view the status of True SSO in Horizon Console.

  1. In Horizon Console, go to Monitor > Dashboard and on the right, in the System Health section, click VIEW.
  2. With Components selected on the left, on the right is a tab named TrueSSO.

194 thoughts on “VMware Horizon True SSO with UAG SAML”

  1. Hey Carl – we have True SSO successfully setup and working. One odd thing we’re seeing is when Edge is used as the default browser, we aren’t prompted for MFA after our initial login. Once we launch Horizon the Edge window pops up and then we are logged into Horizon without any input.

    When using Chrome as the default browser we’re prompted for MFA at every login. Have you seen this or have any thoughts as to why Edge is acting differently for us?

  2. Hey Carl – Love your guides and have been following them for years with our View Environment. I followed this guide and got everything working with TrueSSO and our internal PKI (not installed on the Enrollment servers like your example above). Prior to installing TrueSSO I was able to log in through my Azure UAG and was getting prompted for password again at the desktop which worked as expected, but now that TrueSSO is configured and enabled, I’m getting the following error message when selecting one of my VDI pools with static VDI machines:

    “The View agent reports that this desktop source is unable to accept connections. Please contact your system administrator.”

    The GUI logs indicate that the machine is not ready to accept connections, but the VM is idle with no user connected after a fresh restart. Any thoughts on why I’m getting this error? We’re currently on version 2306 in the environment.

    1. Does every Domain Controller have a certificate?

      Does the certificate configuration match exactly what is shown in this article?

      Can the Domain Controllers access the CRLs of the issuer of the True SSO certificates?

      Download the VDM debug log and see what it says.

      1. Thanks Carl – Yes the PKI has been turned up in our environment for several years now and working for dot1x auth on our endpoints. I did verify the certificate templates match exactly what you have and what the VMware documentation shows. Checking the logs I found the following (some details ommitted):
        (SESSION:93f0_***_f45b) [DOMAIN\USERNAME, Desktop=POOLNAME] (9ms): Attempted to start new managed session.

        (SESSION:93f0_***_f45b) [DOMAIN\USERNAME, Desktop=POOLNAME] (78ms): Application launch failed, exception was: The agent returned an error response [ERROR-CODE=AGENT_ERR_SSO_REQUIRED]

        2024-01-08T14:05:43.832-05:00 WARN (1AC4-0D94) [SessionEventData] UserDn is missing for session in connected state NONE

        2024-01-08T14:05:52.696-05:00 ERROR (1AC4-0D94) [JMSMessageSecurity] (type CHANGEKEY from anonymous) Message validation failure: Signature validation failed: Signature invalid for identity
        agent/1b05088e-8131-4761-aeb2-6b94a2ad0b25

        2024-01-08T14:05:52.696-05:00 WARN (1AC4-0D94) [DesktopTracker] CHANGEKEY message from agent/1b05088e-8131-4761-aeb2-6b94a2ad0b25 is discarded as it cannot be validated

        I found an article related to the [ERROR-CODE=AGENT_ERR_SSO_REQUIRED] where they point out a discrepancy in the Certificate Template, but after validation our template is set up correctly on our CA. Our TrueSSO status shows green in the Connection server dashboard as well. I’ll likely make a case with VMware regarding this to check our environment as I’ve followed your guide to the mark as far as I’m aware.

      2. After working with VMware support today, we changed the TrueSSO Template in our PKI to use 2048 key length instead of 4096 (what our PKI is set to issue). Once doing this TrueSSO worked flawlessly. VMware confirmed 2048 is a hard limit set on their end. I requested a feature request to increase the length supported but fat chance we’ll get that within the next few years!

        (Also, can you edit out my last name on the first post please and thanks!)

        1. Hi Devin, I also stumbled across the key length of 4096. Thanks for the TIP. Is there an official statement from VMware? What about the Enrollment Agent, is it allowed to work with a key length of 4096 or does it also have to be limited to 2048?

          1. We only changed the certificate template to 2048 that I recall. I didn’t have to re-issue our enrollment agent certificate from my recollection.

  3. Hi Carl,

    Thanks for this detailed configuration guide.

    We have setup TrueSSO for an on-prem Horizon pod with WorkspaceOne Access and Yubikeys for MFA. The POD resides behind F5 load balancers. I can login the WorkspaceOne Access with the Yubikey , but when we launch a desktop pool in WorkspaceOne we are not passed through to the desktop automatically. We are also prompted for a username and password before the desktop opens. Could this error be relevant to this issue?

    [RouterSSLEngineFactory] Certificate thumbprint verification failed, no stored thumbprints. Presented identity: agent/951d335d-a356-49f6-86c2-5783157b6962

    Also, all es_diag and vdmutil commands return successfully. and the TrueSSO results in the Horizon console are show a green status with no errors.

    1. Windows supports two authentication methods: Passwords, or certificates. Most modern authentication methods do not provide a password so True SSO is instead used to generate certificates that can log into Windows. If you are using custom certificates, make sure the CA is configured as the Enterprise Trust (NTAuth) for Smart Card authentication.

  4. Hi Carl,

    Thank you for your guides on Horizon, it has helped me a lot! I have gotten almost everything to work, but there seems to be some kind of issue with the passing of the TrueSSO certificate. I’m using Okta for SAML authentication, that works well, but once I have logged in to Horizon View via UAG and try to access the cloned desktop I get thrown this error:

    “Indicates a referenced user name and authentication information are valid, but some user account restriction has prevent successful authentication (such as time- of- day restrictions). The user account’s password has expired.”

    I have checked the user account settings in AD but there should be no time-of-day restrictions or password expiration enabled.

    Help much appreciated

    1. The SAML Assertion from Okta includes the same Name ID (user UPN) as what True SSO is using to generate the certificates?

      1. This could be the issue. Our organization have several domains which are different from the domain used in the horizon configuration (AD). I have set up the Okta directory integration to create users in AD using their Okta username + AD domain.

        For example, upon Okta propagation john.doe@example1.com would become john.doe@horizon.example.com in the directory. Is there a way to set up SAML Assertion to match john.doe in Okta with john.doe in AD while the domains in the UPN are fundamentally different?

        I tried the “include email name in subject name” in the SSO cert template but it didn’t help. The es_diag enrollment test works without any issues and TrueSSO status is green on the connection server.

        1. Ultimately this is Windows Smart Card so follow the Windows Smart Card guide on third party certificate requirements.

  5. Hi,Carl
    There are no certificate templates in vdmutil list in my HCS, it’s empty
    I checked certificate template security and All places that can be confirmed.
    But it still failed.

    C:\Users\administrator.VMWARE>vdmutil –authAs vdiadmin –authDomain vmware –authPassword –truesso –environment –list –enrollmentServer es01.vmware.local –domain vmware.local
    True SSO environment info
    Enrollment server: es01.vmware.local
    Domain: vmware.local
    Forest:
    Name: vmware.local
    Enrollment CertState: VALID
    Template(s):
    Certificate Authority(s):
    Name: CA01

    Environment:
    Horizon Version:2309
    CA:Win Server2019

    Is there anything else that needs to be checked?

    1. That usually means that the certificate template is missing a setting. Compare it with the configuration detailed in this guide and hopefully you can find what is missing. Also make sure the CA is configured to issue the certificate.

  6. is there any way to make horizon view unlock a session if the user locked is session instead of entering his password ?

  7. Thank you for your amazing guides! I have used and refer to them extensively over the years with great success. We are however currently facing an issue after we “upgraded” our root CA from 2012 R2 up to Server 2022. This was done in the usual manner, by exporting the CA config & registry, then shutting down old OS and rebuilding new server with same name & IP address & importing the CA config & exported registry keys. This all went smoothly for everything except our TrueSSO configuration on Horizon8. Now our CA is marked red in Horizon manager and it gives a message stating:

    The primary (and secondary) enrollment server is not connected to the certificate server csa1 (that’s our single root CA).

    I’ve gone through the last bits of the config with vdmUtil and deleted the connector, re-added the ES servers, and re-added pointing at the CA. All those commands are successful and don’t have errors when running. Yet something is still amiss, and I don’t know where to look … any suggestions appreciated!

      1. False alarm! Appreciate the fast response! While troubleshooting this afternoon, we determined that after I reconstructed the CA, someone came later and installed our standard AV tools and whatnot but mistakenly put the firewall in blocking mode. I realized I could no longer use it to issue ANY certs, taking Horizon totally out of the picture. Once we got the firewall off a few minutes ago, Horizon immediately went all green again and life is good.

  8. Hi Carl, how are you?

    I have an Workspace One Access using SAML (Azure Auth) with Horizon using UAG without TrueSSO (users should login twice).

    On Network ranges I configure to redirect to UAG exteral URL. On the UAG I configure Authentication Passthrough.

    On Horizon Connection Server I configure SAML on Allowed and the Dynamic Metadata for the Workspace one Access

    When users try to connect, They can Login Workspace One Access correctly, but when they try to access to VDI, this error appeared

    This horizon server expects to get your logon credentials from another application or server

    Any Ideas?

    1. Do you have more than one Connection Server? Is the SAML Authenticator enabled on each Connection Server?

      What do you see in the Connection Server debug log at C:\Programdata\VMware\VDM\logs?

      1. Hi Carl! sorry for the Delay!. Ive disabled the Replica Connection Server in order to make tests on the enviorment. SAML is enable on Allowerd mode (in both connections, but one is in disabled state) and have the WS1 Metadata with dynamic mode (already try on static mode).

        The Debug shows: Unable to connect to *WS1 Connector FQDN*, no address served
        Unable to connect *WS1 connector FQDN:32111″

        But Workspace One Access have that port allowed. Which component have to access to it?

  9. We implemented Horizon True SSO, which was a big hit with our Workspace One Access users, as it removed the password prompt after launching a desktop.

    However, we did have some unforseen issues with our Citrix hosted EMR application that is run from the Horizon VM. Citrix now sees the user as a Smart Card authentication and fails the pass through SSO the credentials to the back-end Citrix server. They successfully login to the Storefront, but now the Citrix session prompts with bad password.

    Has anyone successfully used True SSO in a scenario like this?

  10. Hi

    I suddently getting access denied errors truesso authentication

    if run es dig following out put but this work fine on connection server

    EnrollmentInterface::SendMsgToEnrollmentPlugin(SubmitRequest) begin
    Call to CertEnroll failed: Failed to locate a connected CA – ErrorCode = 2147944650 (0x00000000800708CA), 1
    EnrollmentInterface::SendMsgToEnrollmentPlugin(SubmitRequest) end
    SubmitRequest Failed
    Response ErrorCode = “-2147022646”
    ErrorText = “Failed to locate a connected CA”
    FailureReason = “SubmitFailureMayRetry”

    C:\Temp>es_diag.exe /enrollmenttest /esNAme:CPT2ENVM01 /certauth /domain:am.tsacorp.com /caserver:COV1CER03VM /requester:am\myuser /template:TrueSSO /LogToScreen
    Execute EnrollmentDiags::EnrollmentTest:
    Connect to the Enrollment Service: CPT2ENVM01
    2023-09-27T12:32:13.458+02:00 WARN (03F0-1B00) [es_diag] CERTSSL: Unable to open certificate store VMware Horizon View Certificates, error=5 (Access is denied.)
    2023-09-27T12:32:13.458+02:00 WARN (03F0-1B00) [es_diag] ConnectChannelByCertSsl cert not found
    Failed to connect channel: certificaste auth failed
    Failed to connect a channel to the Enrollment Service.
    The Certificate used to Authenticate to the ES may not be trusted.
    For more information please see the Horizon View log-file on this system and on the Horizon View Enrollment Server.

  11. Hi

    Thanks using you article , I successfully setup UAG and TrueSSO in POC setup.

    I had one query regarding same, I had 3 sites in different geographic location where around 700 + VDIs each sites and each have 3 different set LB and Connection Brokers. I know and VMware says we need different UAGs and enrollment servers for each site/setup. Can I used same True SSO and Enrollment agent certificate which I created for POC setup or need create three different templates for each sites. I can publish to locate CA to avoid delay of authentication

    1. I think that will work. Just add the Connection Server cert from each pod to the Enrollment Servers. Also run the vdmutil commands on each pod.

  12. Hi Carl,
    i enabled truesso in my environment and everything appears green in horizon and uag admin portals. I can connect to my uag via the horizon client and it gives me all the pools im entitled to but when i click on a pool it immediately tells me access denied. When i check the connection server logs I see “ERROR (1E80-07FC) [ESConnectionManager] CertSso: Certificate generation request failed … Error: 258, ErrorText: The Request timed out, Reason: (258), EsReason: SubmitFailureMayRetry”. My enrollment server is also my CA and i have the registry files to prefer local CA. I can telnet to port 32111 from the connection server to enrollment server

    Any help is appreciated!

      1. the failed requests in CA console is empty but i checked the logs of the enrollment server and i see this
        “MessageFrameWorkDispatch> [wsnm_certenroll] EnrollmentServices::SubmitRequest(): The Request timed out – ErrorCode = 258 (0x0000000000000102)
        2023-08-28T10:00:18.953-04:00 ERROR (056C-0818) [wsnm_certenroll] CertEnrollService::CertEnrollOperation::SubmitRequestHandler(): The Request timed out – ErrorCode = 258 (0x0000000000000102)
        2023-08-28T10:00:27.191-04:00 WARN (056C-0A78) [wsnm_certenroll] CertificateServer::Submit(): Request to was successful but slow – 33250 ms”

  13. Hi gents, I have a question: I have Horizon 7.13 installed as no FIPS mode. And I need to know if my linux desktops could have FIPS mode enabled and SSO will works? Somdoby knows if this configuration is possible?

  14. I’m struggling with the True SSO w/Horizon (not workspace one) passing through to the desktop. I get two different errors.
    The attempted logon is invalid. This is due to a bad username or authentication information. An untrusted certificate authority was detected while processing the domain controller certificate used for authentication.
    and
    The client has failed to validate the domain controller certificate for serverFQDN. The following error was returned from the certificate validation process: A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider.

    The es_diag tool lets me create a cert that looks valid and is signed by our internal MS CA. The chain goes root, sub, cert, and it all looks good. If I remove the domain controller authentication template from the domain controller. Yubikey logon works fine with certs signed by the same local CA and smart card logon on a physical PC. I’m not turning up many results for fixes and VMware support has been very slow. If anyone has seen this please reply.

    1. I finally found the issue.

      We have certificates set to auto enroll and the only reason we use those certs is for wireless access. At one point we were rolling certs out like it was nobody’s business when VDIs would spin up and reboot, so we turned off the auto enroll GPO for the VDI environment.

      This left our enterprise trust blank in “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates”

      I ended up adding a powershell script to the end of our onboarding postsync VDI script to include adding our Cas

      “certutil -enterprise -addstore NTAuth CAFile.cer”

      It appears disabling autoenroll breaks this and I only really stumbled on it by chance. The certs were in the appropriate places (trusted roots, etc) if you were looking in certlm.msc.

      https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store

  15. Hi Carl,
    I appreciate all that you do. I’ve been banging my head against this issue for a while now and every time I find someone else with the issue, the thread just dies, without a resolution.

    Our SSO through Azure is working, but like others, we are prompted to log in again to the VDI machine. It’s not actually doing the true SSO. In the CS, everything is green. I’ve run es_diag.exe /enrollmenttest and /testlogon and both come back successful.

    Enrollment Test
    C:\TEMP>es_diag.exe /enrollmenttest /esname:xxxx-01 /certauth /domain:xxxxxx.edu /requester:xxxxxx /template:TrueSSOCert /caserver:xxxxx-01-CA /certFile:TestCert
    Execute EnrollmentDiags::EnrollmentTest:
    Connect to the Enrollment Service: xxxxx-01
    Successfully connected to the Enrollment Server
    Configure the enrollment service for the selected domain
    Wait up to 30 seconds for the Active Directory to be read
    Send Cert-Request(s) to the enrollment service:
    Successfully requested a Certificate

    Requested : 1, Issued: 1, Failed: 0, Retry: 0
    Total Time: 0.023 sec to generate 1 certificates.
    Throughput: 43 certificates/second.
    Average : 0.023 sec to generate a certificate.

    Subject : dxxxxx
    UPN : dxxxxx@xxxxxx.edu
    SerialNo : 1B:00:00:00:05:EA:38:40:51:A3:3E:50:64:00:00:00:00:00:05
    UTC Time : 2023-06-07,14:42:57
    Valid From: 2023-06-07,14:32:57
    Valid To : 2023-06-08,02:32:57
    Validity : Certificate is valid
    Saved Certificate to file

    TestLogon (not /logontest)
    C:\TEMP>es_diag.exe /enrollmenttest /testlogon /esname:xxxxx-01 /certauth /domain:xxxx.edu /requester:xxxxx /template:TrueSSOCert /caserver:xxxxxx-01-CA /certfile:testcert
    Execute EnrollmentDiags::EnrollmentTest:
    Connect to the Enrollment Service: xxxxxxx-01
    Successfully connected to the Enrollment Server
    Configure the enrollment service for the selected domain
    Wait up to 30 seconds for the Active Directory to be read
    Send Cert-Request(s) to the enrollment service:
    Successfully requested a Certificate

    Requested : 1, Issued: 1, Failed: 0, Retry: 0
    Total Time: 0.139 sec to generate 1 certificates.
    Throughput: 7 certificates/second.
    Average : 0.139 sec to generate a certificate.

    Subject : dxxxxxx
    UPN : dxxxxxx@xxxxxx.edu
    SerialNo : 1B:00:00:00:06:9F:77:29:EA:F0:34:CB:54:00:00:00:00:00:06
    UTC Time : 2023-06-07,14:46:59
    Valid From: 2023-06-07,14:36:59
    Valid To : 2023-06-08,02:36:59
    Validity : Certificate is valid
    Attempting S4U X.509 Certificate logon
    Successfully performed S4U X.509 Certificate logon
    Saved Certificate to file

    In GPO I’ve set Windows Components/Remote Desktop Services/Remote Desktop Session Host/Security “Always prompt for password upon connection” to Disabled
    I’ve also set Local Policies/Security Options/Interactive Logon “Interactive logon: Do not require CTRL+ALT+DEL” to Enabled

    We’re between semesters, but people are still using VDI, so this is all going through a test UAG so I don’t impact production.

    Any suggestions other than blowing it all out and starting from scratch again?

    Thanks!

      1. Hi Carl,
        Thanks for that! For my test user, I was getting an error KDC_ERR_WRONG_REALM.

        Unfortunately, we had an architect that decided we had to have a root domain and multiple sub-domains(Staff, Students, Student Computers, etc)…Our plan is to flatten the domain, so all VDI was put on the root domain. So, only root domain users will be in the correct realm and get TrueSSO. I just tested successfully with my root domain test user.

        So I guess, now we have to decide if we’re gonna spread our VDI out throughout all of the subdomains. Unless there’s a way to pull the realm based on the Users domain…
        Thanks

        1. One forest? Or multiple forests? If multiple forests, is UPN suffix routing configured on the trust?

          I would have expected that Windows can traverse the trusts to find the user by UPN but maybe not.

          1. It’s a single forest. I’m looking into cross-realm trusts right now. It’s possible that whoever set all this up disabled it.

            I really appreciate how responsive you are and everything you are doing for the community!

          2. I finally see that when this was set up, they did not enable “The other domain supports Kerberos AES encryption”. I’ve requested a change in this for testing.

          3. Hi Carl,
            I finally figured it out. VMware does have a trueSSO architecture document

            https://docs.vmware.com/en/VMware-Horizon-7/7.13/horizon-administration/GUID-0770E530-6E8A-4242-893A-1920D60CB0F9.html

            This states that you need a CA on each domain/subdomain. I set this up, but this only worked for one sub domain (staff.xxx.edu). The student sub domain still didn’t work. The problem was the fqdn is student.xxx.edu while their email address is my.xxx.edu.

            I ended up modifying the TrueSSO Cert template to “Include email name in subject name” in the Subject Name tab. Now it seems to be working for all users.

            Thanks again for your help!

Leave a Reply to Tekwave Consulting LLC Cancel reply

Your email address will not be published. Required fields are marked *