"A vCenter Single Sign-On service error occurred", Unable to add or create an AD over LDAP Identity source with SSL protection enabled in vCenter Servers

Products

• VMware vCenter Server

Issue/Introduction

Symptoms:

• The vSphere Web Client displays this error:

A vCenter Single Sign-On service error occurred

• After an upgrading vCenter Server 6.0 to 6.5 editing a AD over LDAP or OpenLDAP Identity source fails if SSL protection is selected.
• The AD over LDAP or OpenLDAP Identity source has connect to any domain controller in the domain selected or two LDAPS servers are provided.
• With a single LDAPS server the issue does not occur.
  
  Note: If a loadbalancer is used with multiple LDAPS servers the issue may occur as well.
• After a fresh installation of vCenter Server 6.5 adding a AD over LDAP or OpenLDAP Identity source fails if SSL protection is selected.
• In the ssoAdminServer.log file, there are entries similar to:

[<YYYY-MM-DD>T<time>.849Z pool-9-thread-6 opId=########-####-####-####-########91c4 ERROR com.vmware.identity.admin.server.ims.impl.IdentitySourceManagementImpl] Exception occurred: 'com.vmware.identity.idm.</time>
InvalidArgumentException: 'IdentityStore certificates' value should not be empty'; stack='com.vmware.identity.idm.InvalidArgumentException: 'IdentityStore certificates' value should not be empty
at com.vmware.identity.idm.server.ServerUtils.getRemoteException(ServerUtils.java:121)
at com.vmware.identity.idm.server.IdentityManager.addProvider(IdentityManager.java:9479)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
 

Resolution

This is a known issue affecting vCenter Server 6.5 & 6.7.
This issue is resolved in:

• vCenter Server 6.5 U2d, 
• vCenter Server 6.7 U1 

Workaround:

To workaround this issue:

1. Disable SSL support for LDAP. This works with two LDAP servers with the option connect to any domain controller in the domain.
   
   Note: Disabling SSL may impose a security risk as all information is transmitted in plain text.
    
2. Configure the Identity source to use non-encrypted LDAP using these settings:
    
   • To use any available domain controller in your domain:
     1. Select "Connect to any domain controller in the domain"
     2. Do not tick "Protect LDAP communication using SSL certificate (LDAPS)"
   • To use 2 dedicated domain controllers in your domain:
     1. Select "Connect to specific domain controllers".
     2. As Primary and Secondary server URL use:
     3. If the domain controller is a Global Catalog Server: LDAP://<domain_controller1_fqdn>:3268
     4. If the domain controller is not a Global Catalog Server: LDAP://<domain_controller1_fqdn>:389
     5. Do not tick "Protect LDAP communication using SSL certificate (LDAPS)”
         
3. Only provide a single LDAPS server. This requires that the LDAP server is manually provided (rather than using the option "connect to any domain controller in the domain").
    
   1. Select "Connect to specific domain controllers".
   2. As Primary server URL use:
      1. If the domain controller is a Global Catalog Server: LDAPS://<domain_controller_fqdn>:3269
      2. If the domain controller is not a Global Catalog Server: LDAPS://<domain_controller_fqdn>:636
   3. Do NOT provide a Secondary server URL.
   4. Tick "Protect LDAP communication using SSL certificate (LDAPS)"
   5. In "3 Provide certificates" provide the SSL certificate of the domain controller used.
   6. Run the command to gather the SSL certificate information from any Domain Controller desired: # openssl s_client -connect <domain_controller_fqdn>:636 -showcerts
   7. When the openssl connect command completes, the full contents of the SSL certificate are displayed. The certificate chain appears similar to:
      
      Certificate chain
      0 s:/CN=DC3.example.com
      i:/DC=com/DC=example/CN=cn
      -----BEGIN CERTIFICATE-----
      MIIFyjCCBLKgAwIBAgIKYURFHAAAAAAABDANBgkqhkiG9w0BAQUFADBCMRMwEQYK
      ..........
      ...snip...
      ..........
      TmqX6OuznopBJKNW5Z5LbHzuUCfY8ryBhYZhHKsf9CmZa12j/ODfznFtAgbPNw==
      -----END CERTIFICATE-----
      1 s:/DC=com/DC=example/CN=cn
      i:/CN=BRM-ROOT-CA
      -----BEGIN CERTIFICATE-----
      MIIFkjCCBHqgAwIBAgIKYSn5HgAAAAAAAjANBgkqhkiG9w0BAQUFADAWMRQwEgYD
      ..........
      ...snip...
      ..........
      N4C2CAlLaR3sXlHBRNlfsLO+rZo45hwW8Xw3rLD+ETtgKMmAVUI=
      -----END CERTIFICATE-----
       
   8. The top most certificate in this chain is the certificate of the domain controller.
   9. Copy the complete string including -----BEGIN CERTIFICATE----- until (including) -----END CERTIFICATE----- into a text file.
   10. Remove any additional characters after -----END CERTIFICATE-----.
   11. Save that file as .cer.
   12. Add this file to the identity source.

Additional Information

Reference: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-authentication/GUID-B23B1360-8838-4FF2-B074-71643C4CB040.html 

Connect to	Domain controller to connect to. Can be any domain controller in the domain, or specific controllers.
Primary Server URL	Primary domain controller LDAP server for the domain. You can use either the host name or the IP address. Use the format ldap://hostname_or_IPaddress:port or ldaps://hostname_or_IPaddress:port. The port is typically 389 for LDAP connections and 636 for LDAPS connections. For Active Directory multi-domain controller deployments, the port is typically 3268 for LDAP and 3269 for LDAPS. A certificate that establishes trust for the LDAPS endpoint of the Active Directory server is required when you use ldaps:// in the primary or the secondary LDAP URL.
Secondary server URL	Address of a secondary domain controller LDAP server that is used when the primary domain controller is unavailable. You can use either the host name or the IP address. For every LDAP operation, vCenter Server always tries the primary domain controller before falling back to the secondary domain controller. This can lead to Active Directory logins taking some time, and even failing, when the primary domain controller is unavailable. Note: When the primary domain controller fails, the secondary domain controller might not take over automatically.
Certificates (for LDAPS)	If you want to use LDAPS with your Active Directory LDAP Server or OpenLDAP Server identity source, click Browse to select a certificate that was exported from the domain controller specified in the LDAPS URL. (Note that the certificate used here is not a root CA certificate.) To export the certificate from Active Directory, consult the Microsoft documentation. You can browse for and select multiple certificates. Tip: When browsing for and selecting multiple certificates, they must be located in the same directory. vCenter Server only trusts certificates directly signed by a registered and trusted certificate authority. vCenter Server does not trace a path up to a registered CA certificate and only checks if the certificate is signed by a registered and trusted certificate authority. As long as your certificate is signed by a publicly trusted certificate authority, or is self-signed, no further action is necessary. However, if you create your own internal certificates (that is, you use a private certificate authority), you might need to include those certificates. For example, if your organization uses Microsoft Enterprise Root Certificate Authority to generate the LDAPS certificate, you must also select the Enterprise Root Certificate to add it to vCenter Server. In addition, if you use intermediate certificate authorities between the LDAPS certificate and the Enterprise Root certificate, you must also select those intermediate certificates to add them to vCenter Server.