vCenter UI Inaccessible and STS service crashing

Products

• VMware vCenter Server

Issue/Introduction

• vCenter Server Appliance (VCSA) UI is inaccessible or hangs indefinitely during login.
• Active Directory (AD) integrated users cannot authenticate.
• System service vmware-stsd fail to start or remain in a 'Starting' state.
  
  
• In the /var/log/vmware/sso/websso.log:
  YYYY-MM-DDTHH:MM:SS.MSSZ WARN websso[83:tomcat-http--45] [CorId=####-####-####-####-####] [com.vmware.identity.interop.ldap.LdapErrorChecker] Error received by LDAP client: com.vmware.identity.interop.ldap.OpenLdapClientLibrary, error code: -1
YYYY-MM-DDTHH:MM:SS.MSSZ websso[83:tomcat-http--45] [CorId=####-####-####-####-####] [com.vmware.identity.idm.server.ServerUtils] cannot bind connection: [ldap://192.0.2.1:389, <SERVICE_ACCOUNT>]
YYYY-MM-DDTHH:MM:SS.MSSZ ERROR websso[83:tomcat-http--45] [CorId=####-####-####-####-####] [com.vmware.identity.idm.server.ServerUtils] cannot establish ldap connection with URI: [ldap://192.0.2.1:389] because [com.vmware.identity.interop.ldap.ServerDownLdapException] with reason [Can't contact LDAP server] therefore will try to attempt to use secondary URIs, if applicable|


• Logs at /var/log/vmware/sso/vmware-identity-sts.log contain:
  Throwing InvalidTimeRangeException! The requested token start time differs from the issue instant more than the acceptable deviation (clock tolerance) of 600000 ms.

Cause

This issue occurs when the vCenter Security Token Service (STS) attempts to bind to a configured Active Directory Identity Source that is unreachable via the network or DNS.

Because the LDAP client hangs while attempting to connect to the offline Domain Controller, the authentication request processing time exceeds the default 10-minute (600,000 ms) clock tolerance threshold. This causes the STS service to reject the SAML token generation with an InvalidTimeRangeException, even if the actual system clocks are synchronized.

Resolution

To resolve this issue, the connection to the Identity Source must be restored or reconfigured:

1. Validate Network Connectivity: curl -v telnet://<DC_FQDN>:389 (or 636 for LDAPS) from the VCSA shell to confirm the path is open.
2. DNS Verification: Ensure the VCSA can resolve the Domain Controller FQDN correctly using nslookup
3. Update Identity Source: If the primary Domain Controller is permanently offline, log in as [e-mail] (via the /etc/hosts workaround if necessary) and update the Identity Source to point to a reachable, highly available Domain Controller.
4. Remove Workarounds: Ensure any temporary entries in /etc/hosts are removed once the network path is corrected.

Workaround

If immediate UI access is required to modify Identity Source settings:

1. SSH into the VCSA via root user
2. Edit the hosts file: vi /etc/hosts
3. Map the unreachable Domain Controller's FQDN to the local loopback address: 127.0.0.1 <DC_FQDN>
4. Restart the STS service: service-control --restart vmware-stsd