This page describes the service's support for using an Active Directory environment configured for LDAPS with your cloud plane tenant.

Starting with service release 2201, the service supports use of Active Directory (AD) domain environments that are configured for using LDAPS. To have use of this feature, your tenant must be explicitly enabled for it and the pods in the pod fleet must consist solely of Horizon Cloud pods running the v2201 release's manifest level. To request enablement of this feature, you can file a support request as described in VMware KB article 2006985.

Brief Introduction to this Feature

As a VDI-providing service, the service requires the ability to perform lookups in your AD domain using a domain bind account. When your AD environment is configured for LDAPS, the service needs the domain controller's root CA certificates and optionally the intermediate CA certificates. You use the Horizon Universal Console to collect and save the certificates to the system.

The service provides two methods for providing your trusted CA certificates to the system — autodiscovery and manual upload. Those methods are described further in this page.

Key Points and Requirements

Before registering an LDAPS-configured AD domain, review these important points and requirements.

  • Self-signed certificates are not supported.
  • The service requires that your DNS have SRV records for the domains configured to use LDAPS. Choosing to use LDAPS for a domain implicitly mandates the use of SRV records.
  • As a strong recommendation, your AD environment should be configured to enforce channel binding. Enforcing channel binding is a vital part of correctly securing LDAPS, especially to avoid man-in-the-middle (MITM) attacks.
  • In the service's domain registration workflow, if you want to specify preferred domain controllers for the service to use, they must be specified using their fully-qualified DNS host names. When entering those preferred domain controllers into the Horizon Universal Console, the console will prevent entry of IP addresses. A best practice is to specify at least two (2) preferred DCs.
  • If you do not specify preferred DCs in the console's Domain Bind wizard, the DCs that the service discovers using DNS must be reachable by every pod.
  • Your firewall configuration must allow outbound connections from every pod to your domain controllers with the following ports and protocols:
    • Port 88/TCP - Kerberos authentication
    • Ports 636/TCP and 3269/TCP - LDAPS communication
  • You must have a HTTP revocation endpoint defined for all certificates in the trust chain except for the root certificate and that endpoint must be reachable by the pods over HTTP. This requirement includes the following points:
    • LDAP must not be used for revocation endpoints.
    • The service will perform revocation checks using the OCSP or CRL HTTP URLs that are defined in your certificates.
    • The service cannot perform a revocation check if a certificate does not define an OCSP or CRL endpoint for the HTTP protocol. In that case, LDAPS connectivity will fail.
    • Every pod must have line of sight to your revocation endpoints. Your firewalls must not block outbound traffic going from the deployed pods to your revocation endpoint over HTTP.

Autodiscovery - Microsoft CAs

If you are using Microsoft CAs to issue domain controller certificates, the Horizon Universal Console provides an auto-discovery mechanism. This mechanism will automatically locate all root and intermediate certificates from your Active Directory environment and display them in the console for your confirmation and approval for their use with the system. The choices are to either accept all of the auto-discovered certificates or none of them. Partial approval is not supported.

Upon approval in the console, the system stores the approved certificates for subsequent use for all domains from the same forest. When you go through the autodiscovery process with one domain and register that domain with the service, and then later on, you are registering another domain from the same forest, you will be required to accept the auto-discovered certificates displayed in the console, even though the prior domain from the same forest is already registered. This flow provides a way to discover at the time of that new domain registration whether any new certificates were created in the forest or certificates have been deleted in the time between registering the previous domain and the next one from the same forest.

The console provides this autodiscovery path to you within the following locations:

  • In the Domain Bind portion of the AD domain registration flow, in the Protocol step. When LDAPS is selected for the protocol, the Autodiscover choice and button are available to autodiscover the certificates and have you approve their use.
  • On the AD Certificates page, at Settings > AD Certificates > Autodiscovered. The console makes this page available when your tenant has at least one existing registered AD domain. The page displays the autodiscovered certificates so that you can see which ones have been authorized and to allow you to clean up the set by deleting certificates that are not in use.

Manual Upload - Non-Microsoft CAs or Microsoft CAs

If you are using a non-Microsoft CA to issue domain controller certificates or you are using AADDS, which does not support enterprise CAs, the Horizon Universal Console provides a manual upload path for providing the CA certificates to the system. In this case, you must manually upload your PEM-encoded root and intermediate CA certificates using the console.

Even when your environment is using Microsoft CAs, you can choose to use the manual upload way if you want.

If you have published your third-party, non-Microsoft, CA certificates into your Active Directory domain using a utility like certutil, then the autodiscovery method will work to discover those CA certificates.

The console provides this manual upload path to you within the following locations:

  • In the Domain Bind portion of the AD domain registration flow, in the Protocol step. When LDAPS is selected for the protocol, the Upload choice and button are available to upload the certificates.
  • On the AD Certificates page, at Settings > AD Certificates > Uploaded. The console makes this page available when your tenant has at least one existing registered AD domain. On that page, use the Upload button to upload each certificate.

Revocation Checks

The service performs checks for certificate revocation using what is defined in the certificates: OCSP or CRL http:// URLs. The service prefers checking by OCSP. If the endpoint is not reachable, the service gracefully attempts a check using CRL.

Stapled OCSP responses are supported.

Remember: As stated in the preceding Key Points and Requirements section, the CA must be configured to serve either OCSP or CRLs or both using HTTP. The service checks will not work if you do not meet that requirement.

New Issued CA Certificates - Need to Update the Domain Registration

When you issue a new CA certificate, as soon as possible, you must update the system to make it aware of that newly issued CA certificate. Use one of the following ways to get CA certificates into the system

When manual upload is used in the domain registration
As soon as CA certificates are newly issued, you must upload them to the system. Go to Settings > AD Certificates > Uploaded and use the Upload.
When autodiscovery is used in the domain registration
When using this method, the system automatically detects the existence of such newly issued CA certificates. When the system detects new CA certificates, it generates a notification and displays it with the console's standard notifications display. This notification is meant to alert you to the need to save new CA certificates to the system. For domain forests, this notification is generated for one domain per forest, rather than for every domain in the forest — because updating one domain's registration will satisfy the action for all the forest's domains.

To update the domain registration, start the console's Domain Bind wizard, and repeat the autodiscovery process with the Autodiscover button on the wizard's Protocol step.

When DC Certificates Near Expiry Times - Remediate As Soon As Possible

When the service detects that domain controller (DC) certificates are nearing their expiry times, a notification is created and displayed in the console with the console's standard notifications display. The first notification appears 21 days prior to the expiry time.

Important: VMware recommends that administrators take action on these notifications as soon as possible.
  • Take remedial action to reissue DC certificates that are nearing expiry.
  • If the remedial action involves issuing a new CA certificate, the new CA certificate must be saved to the system before that CA is used to issue a new DC certificate. The instructions about saving new CA certificates to the system are in the preceding section.
Example of the expiring certificates notification
The following screenshot illustrates one of these notifications. For domain forests, this notification is generated for one domain per forest, rather than for every domain in the forest — because updating one domain will satisfy the action for all the forest's domains. Clicking the hyperlink takes you to that domain's configuration, and you can initiate the Domain Bind wizard from there.
Screenshot that depicts one of the expiring certificate notifications

Support for Switching Between LDAP and LDAPS

When your tenant meets this feature's criteria as described at the top of this page, and after registering an AD domain using one protocol, you can use the console to update that existing domain bind configuration to switch to the other protocol. For example, when you have configured the domain bind to use the LDAPS protocol and need to switch to LDAP, or vice versa, you can go to Active Directory > Domain Bind and edit the domain bind information to select the other protocol. When you start editing Domain Bind, the console opens the Domain Bind wizard. Then you complete the wizard, entering the required information and stepping through to make the change from the current protocol choice to the other.

Deleting Certificates from the Service's Saved Collection

The console displays all of the certificates that are currently saved to the service. To give you the ability to clear out certificates from the console's display that are no longer needed, the console's Settings > AD Certificates page provides a Delete action on both the Autodiscovered and Uploaded certificates displays.

Domain Bind Wizard When Your Tenant is Enabled for the LDAPS Support

When this feature is enabled, the on-screen domain bind flow will look different than it does for the non-enabled case. When this feature is enabled, the steps are as follows.

  1. Log in to the console at
  2. If your tenant has zero AD domains registered — such as when your tenant and first pod are brand new — you start the domain bind flow from the only location that is accessible in that situation: the console's Getting Started > General Setup > Active Directory > Configure.

    If your tenant already has an AD domain registered — such that the console allows you access to its left-hand menu of pages — you can initiate entering domain bind information by going to the console's Settings > Active Directory page.

  3. When you perform step 2, the Domain Bind wizard appears. This wizard has three parts: Domain Bind, Protocol, Summary.

    The following screenshot illustrates that display and the three parts, starting with the Domain Bind part.

    Screenshot that shows what the console displays for the Domain Bind step at the first step of the flow.
  4. In this first wizard step, provide the requested information, and then click Next to save it and move to the next step. When typing in each bind account name, type the account name without the domain name, like the user logon name such asouraccountname. For information about what the service requires for these domain-bind accounts, see Domain Bind Account - Required Characteristics.
    Field Description
    NETBIOS Name The system displays a text box. Type in the NetBIOS name for the AD domain to which the pod has line of sight. Typically this name does not contain a period. For an example of how to locate the value to use from your Active Directory domain environment, see Obtain the NETBIOS Name and DNS Domain Name information.
    DNS Domain Name Type in the fully qualified DNS domain name of the AD domain you specified for NETBIOS Name.
    Bind Username and Bind Password Provide the credentials of the domain-bind service account for the service to use with the selected domain.
    Auxiliary Account #1 In the Bind Username and Bind Password fields, type a user account in the domain to use as the auxiliary LDAP bind account and its associated password.
  5. On the Protocol step, you select the protocol, optionally provide preferred domain controllers that the service should use to communicate with the AD domain you entered in the first wizard step, and additional information. In context of an AD environment configured for LDAPS, you provide the trusted CA certificates in this step of the wizard.

    The UI will reflect the Protocol selection. The following screenshot illustrates the LDAPS choice and the Autodiscover radio button selection.

    Screenshot that illustrates the console's Domain Bind - Protocol step of the wizard.

    These fields are all in context of the AD domain that you specified in the previous wizard step. The UI will change dynamically based on your selections.

    Field Description
    Protocol Choose either LDAPS or LDAP.
    Domain Controller Optional. You can use this text box to specify a comma-separated list of those DCs that you prefer the service use to access the AD domain specified in the first step. If this text box is left blank, the service uses any domain controller available for the AD domain.
    • When LDAPS is selected as the protocol, the DCs must be specified using their fully-qualified DNS host names.
    • When LDAP is selected as the protocol, either IP addresses or fully-qualified DNS host names can be used.
    Context Naming context for the AD domain. This text box is autopopulated based on the information that was specified for DNS Domain Name in the previous wizard step.
    Certificates Available when LDAPS is selected for the protocol. Select how you will provide the CA certificates to the system. As described earlier in this page, the system supports these two methods:
    • Autodiscovery of CA certificates. Refer to the section Autodiscovery - Microsoft CAs further above in this documentation page to see if your AD domain environment supports using this method.
    • Manually upload CA certificates. Select this method if your AD domain environment does not support using the autodiscovery method.

    After you have selected LDAPS for the protocol and selected one of the radio buttons in Certificates, perform one of the following steps, depending on the method selected for providing the certificates. In both cases, follow the on-screen prompts as the UI displays those.

    Click Autodiscover. As described in this page's preceding sections, the system detects the CA certificates in the environment specified by the AD domain and domain controller information that was entered into the relevant wizard fields. These CA certificates are displayed in the UI. Follow the on-screen flow. The UI will prompt you to accept all of the discovered certificates. You must accept the set of discovered certificates before the wizard can proceed to its final step.
    With this method, you must manually upload your PEM-encoded root and intermediate CA certificates. Click Upload to upload the CA certificate files from your local system. The UI will accept only files with a PEM file extension.

    When you see the wizard's Next button is ready for you to click, click it to move to the final step.

  6. On the Summary step, review the information and when satisfied, click Finish.

    The following screenshot illustrates the summary when the upload method was used to provide the certificates in the previous step. Eight (8) certificates were uploaded in this example.

    Screenshot that depicts the console's Domain Bind - Summary step.

At the end of this flow, the domain bind configuration for the AD domain is now saved into the system.

If you ran the above flow as part of registering the very first AD domain for your brand new Horizon Cloud tenant, the UI will subsequently prompt you to complete the Domain Join flow and the Add Administrators flow. For the information about those two flows, see the sections titled Domain Join and Add Super Administrator Role at Performing Your First Active Directory Domain Registration.

AD Certificates Page

After certificates are saved into the system, the console displays them on the AD Certificates page. You can use this page both to see which CA certificates are currently saved into the system and to delete certificates that you know are no longer in use. For illustration purposes only, the following screenshot depicts the case where an administrator uploaded certificates to the system.

Screenshot that depicts an example of what the console's AD Certificates page looks like when its Uploaded view has 6 uploaded certificates.