General support for VMware Horizon 7 ends April 30, 2023, impacting all versions up to and including VMware Horizon 7.13. Read this blog to understand why and how to upgrade to Horizon 8 now: “Top 8 Reasons to Upgrade to VMware Horizon 8.”
In a previous blog, we saw how to deploy VMware Horizon 7 True SSO in a lab environment. The diagram below is a recap of the deployment:
Now, let us discuss what to consider for deploying True SSO in a production environment. The discussion will only focus on the VMware Horizon Environment aspect of the above diagram.
VMware recommends deploying two VMware Enrollment Servers and two Microsoft Certificate Authorities (CA) for True SSO in a production environment. Configure these so that the Horizon Connection Server uses both VMware Enrollment Servers, and each VMware Enrollment Server uses both CAs.
Enrollment Server Deployment Scenarios
For each domain, we can configure two Enrollment Servers (primary and secondary) in a Horizon 7 environment. The 2 Enrollment Servers add redundancy which allows IT to conduct maintenance, upgrades etc. without any disruptions for end users.
By default, the Connection Server always prefers the primary Enrollment Server for generating certificates. The secondary Enrollment Server is used when the primary Enrollment Server is unresponsive or is in erroneous state. The Connection Server uses the primary Enrollment Server as soon as it recovers.
True SSO can also be configured for high availability. When configured, Connection Server distributes the load of generating Certificates by alternating between the two Enrollment Servers. If an Enrollment Server becomes unresponsive, the Connection Server routes all requests via the other one until it recovers.
For high availability, VMware recommends:
- Co-host Enrollment Server with a CA on the same machine.
- Configure Enrollment Server to prefer the local CA.
- Configure Connection Server for load balance between the configured Enrollment Servers.
1. Configure Connection Server to load balance between two Enrollment Servers (requires editing LDAP).
- Login to the console of a Connection Server on the POD and launch “ADSI Edit” from “Control Panel > Administrative Tools”
- From menu, select “Action > Connect to”
- Connection Settings:
- Connection Point: dc=vdi,dc=vmware,dc=int
- Computer: localhost:389
- Expand the connection tree to “OU=Properties > OU=Global” and double click on the object named “CN=Common” on the right pane
- From the properties window, find and double click the attribute named “pae-NameValuePair”
- In the Multi-valued string editor window, add : “cs-view-certsso-enable-es-loadbalance=true”
2. Configure the Enrollment Server to prefer the local CA when co-hosted (requires editing registry).
- Login to the console of an Enrollment Server
- Registry location: HKLM\SOFTWARE\VMware, Inc.\VMware VDM\Enrollment Service
- Add Value Name: “PreferLocalCa”, Value data: “1”
- Needs to be repeated for each Enrollment Server individually
True SSO in a Complex Domain Environment
VMware supports deploying True SSO in multi-domain environment provided they have two-way trust.
Let us take an example where we have two Domain trees (A & X) in the same forest.
Here we see two domain trees, Domain A and Domain X. Each of the domain trees has transitive trusts between all domains. Moreover, Domain A tree and Domain X tree have two-way, transitive trust relationship between each other.
VMware supports True SSO in this scenario, and the two Enrollment Servers can be placed at any domain.
Let us consider another example:
Here, we see two forests each containing its own domain trees. Moreover, the two forests have two-way, forest-level trust set up, as well.
VMware supports True SSO in this scenario, as well. Like before, the two Enrollment Servers can be placed within any domain of any forest.
More about domain and forest trusts can be found at technet.microsoft.com/en-us/library/cc770299.aspx.
For best performance, it is important to plan the deployment of the CAs and the Enrollment Servers. For generating certificates, the Enrollment Server needs to communicate with the CA and the CA needs to communicate with the Domain Controller. Therefore, it is always a good idea to place the CA as close as possible to the Domain Controller. Likewise, place the Enrollment Server as close as possible to the CA. By placing them in close vicinity, we aim to reduce the network hops. As such, we will get optimal performance by co-hosting the CA and the Enrollment Server on the same VM.
When deploying Enrollment Servers and CAs, we would also need to consider administrational roles. If “Domain admin” or “CA admin” is responsible for managing the CAs and “View admin” is a separate role responsible for managing the View deployment, then we need to consider setting up CA and Enrollment Server on separate VMs, so each component is managed by the assigned roles.
Out-of-the-box settings will suit most users. If required, there are some advanced settings provided for admins.
- Settings for Virtual Desktop: All the required settings are provided via VMware Horizon View Agent admin GPO template (vdm_agent.adm).
- Settings for Enrollment Server: All the required registry are provided via registry and is created under: “HKLM\SOFTWARE\VMware, Inc.\VMware VDM\Enrollment Service”.
- Settings for Connection Server: All the required settings are provided via LDAP under attribute “pae-NameValuePair” as discussed in earlier section.
|This combination of settings adjusts the maximum time for generating a certificate on behalf of a user (includes retrying once on failure).
Typically, admins would want to tweak these settings when they find certificates arriving after SSO has timed out waiting for one.
All three settings need to be adjusted accordingly.
Typically, the values would be:
Enrollment Server < Connection Server < Virtual Desktop.
|Certificate wait timeout
Default: 40 sec
Range: 10 secs – 120 secs
Default: 35 sec
Range: 10 sec – 60 sec
Default: 25000 millisecond
Range: 9500 milliseconds – 59000 milliseconds
|The Enrollment Server caches details, like AD info, CAs, Templates, etc., about the Windows environment. By default, the Enrollment Server will attempt to access all domains. In a complex environment, you may want to limit the domains that the Enrollment Server monitors.
Below settings can be set as required
A. Automatically monitor the domains specified.
B. Do not automatically monitor the domains specified.
If a Connection Server references any of the listed domains via configuration, the Enrollment Server will try to connect to it and monitor.
C. Automatically monitor all domains in the forest.
D. Automatically monitor all explicitly trusting domains or domains with incoming trusts.
Default: 1 (True)
Values: 0 (False) or positive number (True)
Default: 1 (True)
Values: 0 (False) or positive number (True)
|At times, CAs may take an unusually long time while generating certificates. It is marked as “Degraded” by the Enrollment Server when that happens.
The Enrollment Server measures how long a CA takes to generate a certificate, and it is marked Degraded if it takes more than 1,500 milliseconds by default.
Default: 1500 milliseconds
Range: 500 milliseconds – 5000 milliseconds
|This setting allows admins to disable True SSO on any specific desktop.
|Disable True SSO
Default: 0 (False)
|This setting defines the minimum key size to be used for True SSO.
The generated Certificate is protected via public/private RSA key pair, which is securely stored on the Virtual Desktop.
This defines the minimum bar for the key size. For example, keys will have to be at least of the size defined by this value.
|Minimum key size
Range: 1024 – 8192
|This setting specifies a list of key sizes.
When generating RSA key pair, the size must be defined in the list.
The list can hold a maximum of five sizes.
|All sizes of keys that can be used.
|This setting specifies the number of RSA key pairs that will be pre-created.
Generating RSA key pairs can be time consuming. Not to add to the logon time, we pre-create a number of key pairs and pick one from the cache when required for True SSO.
This setting is only valid on Remote Desktop Session Host (RDSH) environments.
|Number of keys to pre-create
Range: 1 – 100
|This setting specifies the duration a certificate needs to be valid to be considered to be re-used for True SSO.
A user may be disconnected from his or her session. If the user tries to connect back while the session is still active, he/she will reconnect to the session. While reconnecting, True SSO will log the user back into the desktop. Since a session already exists, True SSO will try to reuse the Certificate associated with the session provided it is still valid. The validity will be determined by determining if the certificate is at least valid for a duration defined by this setting ie. the expiration period is less than what is specified via this setting.
|Minimum validity period required for a certificate.
Default: 10 minutes
Range: Minimum 5 minutes
We observe the following log lines in the Horizon Connection Server logs:
- 2016-03-17T17:07:43.359Z WARN (0484-009C) <SocketAuthenticateThread> [MessageFrameWork] AuthCERTSSL: incoming issuer ‘4b81f0b2-baab-4273-bbff-48ac36f8bcaa.certsso.vdi.vmware.com’ cert is self signed but not in our store.
- 2016-03-17T17:07:43.359Z WARN (0484-009C) <SocketAuthenticateThread> [MessageFrameWork] Unable to accept connection, authentication failed, reason=authCertSsl
Cause: This indicates that the “Enrollment Service Client Certificate” has not been copied from the Connection Server to Enrollment Server.
Resolution: Please deploy the “Enrollment Service Client Certificate” from the Connection Server to the Enrollment Server, so that the Enrollment Server can establish a secure connection between the two.
After setting up True SSO, it is advisable to check its status on the Horizon Connection Server administrator dashboard.
If everything is configured correctly and all components are working well, we would observer True SSO status as below on the Dashboard:
- The domain for which True SSO is configured will be displayed under “True SSO,” and it will be green.
- The trust relationship will be green under “Domains.”
Below is a list of issues that may disrupt True SSO:
1. Issue: The domain name is not displayed in the dashboard.
Cause: True SSO configuration information for that domain is missing or not setup correctly.
Resolution: Please verify that True SSO was configured correctly using the “vdmUtil” tool and/or reconfigure.
2. Issue: The domain name displayed in the dashboard under “True SSO” is not green.
Cause: True SSO configuration information may not be accurate, or some component required for True SSO to work is not working or setup correctly.
Resolution: True SSO status for a domain may indicate okay (green), error (red) or warning (amber) on the dashboard.
To diagnose a problem, admins can click on the domain name, which will pop up a dialog displaying a warning or error message relating to the issue.
The table below describes the meaning of various error/warning messages that can be displayed via the pop-up dialog:
|Failed to fetch True SSO health information.||This message is displayed when no health information is available for the dashboard to display.
The most likely cause is Enrollment Server has not reported back any status updates as yet.
If this message lasts more than a minute, please verify the Enrollment Server is turned on and is reachable from the Connection Server.
|Connection Server to Enrollment Server Connection Status|
|The <FQDN> enrollment server cannot be contacted by the True SSO configuration service.||This message is displayed if True SSO configuration information is not refreshed by the Connection Server for a long time.
In a Horizon POD environment, all Enrollment Servers receive True SSO configuration information from a single Connection Server and are also responsible to refresh it every minute.
This could happen if the specific connection server responsible for updating the configuration information lost connectivity to the reported Enrollment Server.
|The <FQDN> enrollment server cannot be contacted to manage sessions on this connection server.||This message is displayed if a Connection Server cannot connect to the Enrollment Server.
There is a known limitation in Horizon 7. Instead of being displayed for all Connection Servers in the POD, this info is only displayed for the Connection Server the admin has logged into.
To check connection status of all Connection Servers and Enrollment Servers, an admin would need to individually login to each connection server and check the status on the Dashboard.
|This domain <Domain Name> does not exist on the <FQDN> enrollment server.||This message is displayed if True SSO is configured for a domain but the Enrollment Server has not received any configuration information from the Connection Server as yet.
If this message lasts for more than a minute, please check all the Connection Servers in the POD are working as expected and supports True SSO.
|Enrollment Server to Active Directory Connection Status|
|The <FQDN> enrollment server’s connection to the domain <Domain Name> is still being established.||This message is displayed if True SSO is configured for the Domain, but the Enrollment Server is yet to connect to the Domain Controller.
If the message lasts for more than a minute, please verify the Enrollment Server has network connectivity, can resolve the name of the Domain and can reach the Domain Controller.
|The <FQDN> enrollment server’s connection to the domain <Domain Name> is stopping or in a problematic state.||This message is displayed if the Enrollment Server encounters problem reading PKI information from the Domain Controller.
Please check the specific Enrollment Server’s log file which will provide more info related to the specific Domain Controller.
It might be caused by:
a. Some issue with the Domain Controller itself.
b. DNS not being configured properly.
|The <FQDN> enrollment server has not yet read the enrollment properties from a domain controller.||This message could be displayed because
a. The Enrollment Server has not connected to the Domain Controller yet, as it is most likely just starting up.
b. It is a new domain and was just added to the environment. Therefore, the Enrollment Server has not connected to the Domain Controller, yet.
If this message lasts for more than a minute, please check the following:
a. The network connectivity might be extremely slow.
b. The Enrollment Server is having difficulties accessing the Domain Controller.
|The <FQDN> enrollment server has read the enrollment properties at least once, but has not been able to reach a domain controller for some time.||This message is displayed when the Enrollment Server cannot poll the Domain Controller for PKI-related environment changes.
An Enrollment Server reads the full PKI configuration from the Domain Controller when it connects to it for the first time and polls for incremental changes every two minutes.
This message may not indicate True SSO failure.
As long as the Certificate Authority servers are able to access the Domain Controller, the Enrollment Server will be able to issue Certificates for True SSO.
|The <FQDN> enrollment server has read the enrollment properties at least once, but either has not been able to reach a domain controller for an extended time or another issue exists.||This message is displayed if the Enrollment Server is not able to reach the Domain Controller for an extended period of time. During this time, the Enrollment Server will try to discover an alternative Domain Controller for that domain.
If a CA Server is able to access a Domain Controller, the Enrollment Server will still issue certificates for True SSO, else it will result in Enrollment Server failing to issue Certificates for True SSO.
|A valid enrollment certificate for this domain’s <Domain Name> forest is not installed on the <FQDN> enrollment server, or it may have expired.||This message is displayed when a valid Enrollment Certificate is missing for the domain from the Enrollment Server.
Most likely, the Enrollment Certificate is:
a. Not installed on the Enrollment Server.
b. Invalid or expired.
The Enrollment Certificate is issued by an Enterprise CA of the domain. On the Enrollment Server, the Certificate can be verified by:
a. Opening Certificate Management snap-in for the local computer store in MMC.
b. The Enrollment Certificate can be found in the “Personal” certificate container and can be verified it exists and is valid.
Alternatively, the Enrollment Server’s log file can provide additional information regarding the state of all the certificates that were located.
To resolve the issue, please follow the View Admin Guide and re-deploy the Enrollment Certificate on the Enrollment Server.
|Enrollment Certificate Status|
|The template <Name> does not exist on the <FQDN> enrollment server domain.
|This message is displayed if the Certificate Template configured to be used for True SSO is not setup correctly or the Template name was misspelled during True SSO configuration.
To resolve the issue, please follow the View Admin Guide and setup the Certificate Template correctly on the Enterprise CA and check the configuration of True SSO using the “vdmUtil” tool
|Certificate Template Status|
|Certificates generated by this template can NOT be used to log on to Windows||This message is displayed when the Certificate Template configured for True SSO is missing certain options required for it to work.
To resolve this issue, please follow the View Admin Guide and setup the Certificate Template correctly on the Enterprise CA.
|The template <Name> is smartcard logon enabled, but cannot be used.||This message is displayed when the Certificate Template configured for True SSO is missing certain options required for it to work.
To resolve this issue, please follow the View Admin Guide and setup the Certificate Template correctly on the Enterprise CA.
|The certificate server <CN> of <CA> does not exist in the domain.
|This message is displayed if the Common Name for the CA is not configured correctly.
Please verify that the Common Name (CN) specified for the CA in the True SSO configuration is accurate and is spelled correctly.
|Certificate Server Configuration Status|
|The certificate is not in the NTAuth (Enterprise) store.||This message is displayed if the CA is not a member of the forest.
To resolve the issue, please manually add the CA Certificate to the NTAuth store of the forest in question.
|The <FQDN> enrollment server is not connected to the certificate server <CN> of <CA>.||This message is displayed if the Enrollment Server is not connected to the CA.
This might be a transitional state and may occur when the Enrollment Server has just started or the CA was recently added/configured for True SSO.
If the message lasts for more than a minute, it indicates that the Enrollment Server failed to connect to the CA.
To resolve the issue, please verify the Enrollment Server can resolve the name of the CA, check the network connectivity between the Enrollment Server and the CA and the system account for the Enrollment Server has permissions to access the CA.
|Certificate Server Connection Status|
|The <FQDN> enrollment server has connected to the certificate server <CN> of <CA>, but the certificate server is in a degraded state.||This message is displayed if the CA has dramatically slowed down while issuing certificates.
If this message persists for extended time, please check if the CA or the Domain Controller(s) is overworked. Once the issue is resolved and the CA resumes as normal, this message will not be displayed.
|The <FQDN> enrollment server can connect to the certificate server .<CN> of <CA>, but the service is unavailable.||This message is displayed if the Enrollment Server is connected to the CA, but unable to issue any certificates for True SSO.
This is a transitional state and will update rapidly. If the CA does not recover or does not become able to issue certificates, the state will be updated to “Disconnected.”
To resolve the issue, please check the CA is up, the Enrollment Server can reach it and the CA is properly configured for True SSO.
3. After successfully setting up True SSO, we see logon attempts failing, and the following error is reported in the logs:
LogonUI] cred::ReportResult(): Reported authentication failure. Status=0xC00000BB (WinErr=50) and subStatus=0x00000000 (WinErr=0).
This is PKI environmental issue, preventing smartcard logon to be successful using
the certificates generated by the CA. The following steps should fix the issue. VMware recommends following one step at a time and then testing to see if the issue is fixed. If not, then proceed to the next.
1. In the majority of cases, this is due to a problem with the Domain Controller certificate and the resolution is to refresh it, or to install if not already present. The Domain Controller certificate must be generated using one of these templates: ‘Domain Controller’, ‘Domain Controller Authentication’ or ‘Kerberos Authentication.’ Only one of these should be present, we will refer to it as ‘Domain Controller certificate’ below. To refresh:
- Load the Certificates MMC and then target it at the computer account: ‘Start’ -> ‘Run’ -> ‘MMC’ -> ‘File’ -> ‘Add/Remove Snap-in’ -> ‘Add’ -> ‘Certificates’ -> ‘Add’ -> ‘Computer Account’ -> ‘Next’ -> ‘Finish’ -> ‘Close’ -> ‘OK’
- Expand: ‘Certificates (Local Computer)’ -> ‘Personal’ -> ‘Certificates’
- Right click on the ‘Domain Controller certificate’ -> ‘All tasks’ -> ‘Renew/Request Certificate with New Key’
- Restart Domain Controller.
2. Deploy the CA root certificate via the domain GPO to Trusted Root Certification Authorities. Perform this step on all domain that users may be logging on to using True SSO. Refer to microsoft.com/en-us/library/cc772491(v=ws.11).aspx.
3. Make sure the template used by True SSO does not have “Do not include revocation information in issued certificate” selected. Refer to vmware.com/euc/2016/04/true-sso-setting-up-in-a-lab.html section: Adjust the settings of various properties of the new template as marked in screenshot.
This concludes our blog post on what to consider for setting up True SSO in a production environment, as well as various configuration options. We also talked about domain/forest trust scenarios where VMware supports True SSO. Finally, we reviewed some advanced settings that might allow admins to tweak True SSO if it does not work as expected out of the box. We also reviewed troubleshooting guidelines for some common issues related to True SSO and discussed the various warning/error messages that can be displayed on the Dashboard for True SSO.
Because you liked this blog: