Issue with AD Sync in vRA 7.3.1 and 7.4

I have recently come across an issue in our vRA 7.3.1 environment where the AD sync started failing all of a sudden.

The error message looks as in the screenshot below:

AD Sync Error

This error basically means that vRA is not able to communicate with the Active Directory (Lets say my Domain is dallas.com and my vRA appliance hostname is dc1-vcf-vra-01.dallas.com) to update the AD groups and Users for authentication.

The error also means that the vRA is complaining that the connector hostname (in this case it is dc1-vcf-vra-01) doesn’t match the Common Name (CN) in the certificate which is the FQDN (dc1-vcf-vra-01.dallas.com).

Opened a ticket with VMware support and here are the troubleshooting steps recommended so far by them:

1.	     /usr/java/jre-vmware/bin/keytool -v -list -keystore /opt/vmware/horizon/workspace/conf/tcserver.keystore 
                 Check the The Common Name  in the self signed cert. It will be set to node hostname.
2.	     mkdir /root/tmp-bkp
3.	     mv /usr/local/horizon/conf/flags/fips* /root/tmp-bkp		( No file named fips or starting with fips in the flags directory as FIPS is not enabled in our environment)
4.	     /usr/local/horizon/scripts/secure/wizardssl.hzn
                 Install Self Signed Cert and update the keystore
5.	     mv /root/tmp-bkp/fips* /usr/local/horizon/conf/flags		(had to skip it as I was not able to execute the above fips* command)
6.	     service horizon-workspace restart

Will update this post with more steps once VMware support comes back to resolve this issue.

UPDATE

VMware support confirmed that the Common Name (CN) in the self signed Certificate has the FQDN and to follow the steps in the KB article https://kb.vmware.com/s/article/2145268 to check the postgres database for the connector and there we found the issue and rectified it.

From the KB 2145268, I followed the below steps:

Log in to each appliance and type hostname.
If the hostname is shortname and not FQDN, update it from VAMI.

Ensure that the following tables display all the appliances with the FQDN.
Connect to the database by running this command:

su - postgres /opt/vmware/vpostgres/current/bin/psql vcac

Set schema as SaaS by running this command:

set schema 'saas';

Verify the appliances hostnames in the ServiceInstance table by running this command:

select * from "ServiceInstance";

If the hostnames in the table are short, update the hostnames to FQDN by running this command:

update "ServiceInstance" set "hostName"='<new_hostname>' where "id"='<row_id>';

Verify the appliances hostnames in the Connector table by running this command:

select * from "Connector";

If the hostnames in the table are short, update the hostnames to FQDN by running this command:

update "Connector" set "host"='<new_hostname>' where "id"='<row_id>';

I had to substitute new_hostname as the FQDN of my vRA appliance (my case dc1-vcf-vra-01.dallas.com) and the row_id is the ID of the row in which the host name is displayed.

Once I made the modifications in the ‘ServiceInstance’ and ‘Connector’ and restarted the vRA appliance, my AD Sync started to Sync.

SQL Connectivity Issue with vRA 7.4

Hello Peeps, Recently I was configuring vRA 7.4 at a customer’s place and came across an issue where the vRA appliance tries to talk to the external SQL server and fails with an error.

Here is the error:

SQL_Config_Issue01

After digging into the logs on both vRA and on the SQL server, here is what was determined as the issue

The SQL server has TLS 1.0 disabled and the vRA appliance was trying to communicate to the SQL server using TLS 1.0 instead of TLS 1.2 as the client has disabled TLS 1.0 on all its windows servers.

SQL_Config_Issue02

Troubleshooting steps tried:

Tried enabling TLS 1.0 and its Ciphers on the SQL server with no success

Checked with the Firewall team and they said that there is no firewall between the vRA appliance and the SQL server

Tried this in a different environment and it worked fine, just doesn’t work in this particular environment.

Conclusion:

 

Looks like the issue was with the SQL server and its Service Pack. SQL Server 2012 needs SP3 or higher to accept TLS 1.2 protocol. As soon as I upgraded my SQL server to SQL 2012 SP4, the communication worked fine and the vRA appliance was able to talk to the SQL server!!

Hope this helps in case you come across this issue.