vCenter ‘Cannot complete login due to an incorrect user name or password’: SSO failures

The “Cannot complete login due to an incorrect user name or password” string is the exact message operators see in the vSphere Client, in PowerCLI sessions, and in API responses when SSO authentication fails. The text is misleading: the cause is rarely a typo. For a single user it is usually a credential or permission problem. For every account at once it is an SSO/STS infrastructure failure.

The first triage question is scope: does the local SSO administrator account ([email protected]) still work? If yes, the STS signing certificate and token service are healthy, and the problem is in an identity source (AD/LDAP) or a service account. If [email protected] also fails, the STS infrastructure itself is broken: expired STS signing certificate, clock skew rejecting SAML tokens, or STS memory pressure.

This page covers the infrastructure-failure case. The failure is loud in logs and silent in the UI, which shows only the generic login string. The diagnostic work happens in /var/log/vmware/sso/, the certificate stores, and the NTP configuration.

What this means

vCenter authentication is a chain. The browser or API client hands credentials to the reverse proxy (rhttpproxy), which forwards them to the Security Token Service (vmware-stsd, STS). For local SSO users, STS validates against vmdir (the embedded LDAP directory) and issues a SAML token. For AD/LDAP users, STS forwards the bind to the configured identity source. Every link in that chain has its own failure mode, and almost every failure surfaces to the user as the same generic login string.

The web client emits that string whenever the underlying STS call returns an authentication error. It tells you nothing about which link failed. The job is to find the failing link before users escalate.

Two failure shapes dominate. The first is total SSO failure: every account fails, including [email protected]. The STS signing certificate has expired, the STS service is in a crash loop, or the appliance clock is far enough off that SAML token validation rejects everything. The vSphere Client may also show “503 Service Unavailable”, “no healthy upstream”, or “[500] An error occurred while fetching identity providers”. VAMI on port 5480 may report “certificate verify failed: certificate has expired”. The second shape is identity source failure: [email protected] still works, but AD/LDAP users fail. Domain controllers are unreachable, clock skew exists between VCSA and DCs, the LDAPS certificate on the identity source was rotated without re-adding the source, or a service account password has expired and is flooding the logs.

A third, noisier variant is worth separating. A single expired or locked service account can generate thousands of LOGIN_FAILED entries per minute in vmware-sts-idmd.log. The UI works for humans, but the log volume is alarming and can fill /storage/log if left uncorrected.

flowchart TD
    A[Login fails for many users] --> B{[email protected] works?}
    B -- No --> C[STS infrastructure broken]
    B -- Yes --> D[Identity source broken]
    C --> C1{STS cert expired?}
    C1 -- Yes --> C2[Run vCert Option 6]
    C1 -- No --> C3{Clock skew on tokens?}
    C3 -- Yes --> C4[Fix NTP / chrony]
    C3 -- No --> C5[STS heap or GC pressure]
    D --> D1{Single principal flooding?}
    D1 -- Yes --> D2[Service account locked or expired]
    D1 -- No --> D3{DC reachable from VCSA?}
    D3 -- No --> D4[DNS / firewall / DC down]
    D3 -- Yes --> D5{LDAPS cert rotated?}
    D5 -- Yes --> D6[Remove and re-add source]
    D5 -- No --> D7[Clock skew vs DC]

Common causes

Quick checks

Run from the VCSA shell as root. These are read-only.

# Service health
service-control --status --all

# STS signing certificate dates - the cert that breaks everything when expired
# <!-- TODO: verify alias name for STS_INTERNAL_SSL_CERT store across versions -->
/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store STS_INTERNAL_SSL_CERT \
  --alias __MACHINE_CERT 2>/dev/null | openssl x509 -noout -dates

# Machine SSL cert - the one the browser sees, different lifecycle
echo | openssl s_client -connect localhost:443 2>/dev/null | openssl x509 -noout -dates

# NTP state - clock skew breaks SAML token validation
chronyc tracking

# Failed logins in the last hour, grouped to spot the noisy principal
grep -E "LOGIN_FAILED|Authentication.*failed" /var/log/vmware/sso/vmware-sts-idmd.log \
  | awk '{print $1, $2}' | sort | uniq -c | sort -rn | head -20

# Clock skew errors against AD
grep -i "LW_ERROR_CLOCK_SKEW\|clock skew" /var/log/vmware/sso/vmware-sts-idmd.log | tail -20

# LDAP bind errors pointing at identity source trouble
grep -i "ldap.*error\|ldap.*timeout\|bind.*fail" /var/log/vmware/sso/vmware-sts-idmd.log | tail -20

# Disk space on the log partition - SSO failure loops fill it fast
df -h /storage/log

# STS Java heap pressure
# <!-- TODO: confirm process name; pidof java may pick the wrong JVM -->
jstat -gc $(pidof java | tr ' ' '\n' | head -1) 2>/dev/null

How to diagnose it

1. Confirm scope first. Try [email protected]. If it works, skip to step 4. If it fails, STS infrastructure is broken and you are in the expired-cert or clock-skew branch.

2. Check the STS signing certificate. This is the single most common cause of total login failure. The STS cert has a 10-year validity on vCenter 6.7 and later, long enough that nobody owns it. The machine SSL cert in the browser is a different certificate and may be fine while the STS cert is expired. vCenter 7.0 U1 and later sends weekly notifications starting 90 days before STS cert expiry.

3. Check the appliance clock. SAML tokens carry time bounds. If the VCSA clock is more than a few minutes off the domain controllers, STS rejects tokens and AD binds fail with LW_ERROR_CLOCK_SKEW. Run chronyc tracking on the VCSA and compare against a DC. NTP misconfiguration between VCSA and DCs is the usual root cause.

4. Check the identity source. If local admin works, test AD/LDAP directly from the VCSA shell with ldapsearch. A successful bind proves the network path; a failure isolates the problem to DNS, firewall, or the DC itself. If you recently rotated the SSL certificate on an LDAPS identity source, the source must be removed and re-added; vCenter does not pick up the new cert from a live update.

5. Inspect the log for the specific principal. A single expired or locked service account can produce thousands of failures per minute. Group the LOGIN_FAILED lines by principal and by source IP. A single account generating hundreds of entries per minute is almost always a password rotation that did not propagate to every integration.

6. Check STS heap and GC behavior. Intermittent failures across all users, with no certificate or NTP issue, often point at STS Java heap pressure. Frequent full GC pauses cause token validation timeouts that look random from the outside.

7. Check for post-patch regressions. vCenter 8.0 U3h enforced ADFS policies (MFA, geofencing) on password-grant API logins that were previously bypassed, breaking AD service accounts using ADFS as an identity source. Windows Server 2025 enables LDAP server signing and channel binding by default, which breaks plain LDAP identity sources with “Strong(er) authentication required”. If the failure started immediately after a patch or DC upgrade, treat this as the leading hypothesis.

Metrics and signals to monitor

Fixes

Expired STS signing certificate

This is the highest-impact fix and the one most likely to be needed outside business hours. The deprecated checkSTS.py script is no longer the supported path. Use the vCert script documented in VMware KB 385107 for all certificate replacement on vCenter 7.x, 8.x, and 9.x. For an already-expired STS cert, the documented recovery is vCert Option 6 (reset all certificates) run from an SSH session to the VCSA. This is disruptive. Coordinate with VMware support if you have not done it before.

After STS cert renewal, check solution user and extension certificates. Extensions such as EAM, RBD, and ImageBuilder can fail to log in with the same generic string after cert replacement until updateExtensionCertInVC.py is run for each one.

Clock skew

Fix NTP. On vSphere 7 and later the VCSA uses chrony. Confirm /etc/chrony.conf points at reachable, redundant sources, ideally the same sources the domain controllers use. Do not rely on VMware Tools time sync from the ESXi host for the VCSA; it can fight NTP. After correcting the configuration, allow chrony to slew the clock, or use makestep for an immediate correction if the offset is large.

Unreachable AD/LDAP identity source

Verify DNS resolution of the domain controllers from the VCSA, verify the firewall permits the relevant port (389 for LDAP, 636 for LDAPS), and verify the DCs themselves are healthy. For LDAPS, confirm the certificate on the DC is trusted by the VCSA. If you rotated the LDAPS certificate, remove and re-add the identity source; live updates are not sufficient.

If you are still using Integrated Windows Authentication (IWA, the “Join Domain” method), plan the migration now. IWA is deprecated as of vSphere 7.0 and is removed in vSphere 9.0. The VCSA must leave the AD domain before a 9.0 upgrade or the pre-upgrade check will block it. AD over LDAPS or Identity Federation (Okta, Entra ID, ADFS) is the supported replacement.

Windows Server 2025 LDAP signing

Server 2025 enables LDAP server signing requirements and LDAP channel binding by default. Plain LDAP identity sources fail with “Strong(er) authentication required”. Either relax those policies on the DC (a security tradeoff) or migrate the identity source to LDAPS.

ADFS password grant (8.0 U3h and later)

If API logins for AD service accounts started failing with 400 Bad Request after patching to 8.0 U3h, the ADFS server must support the password grant type. The security fix enforces ADFS policies that were previously bypassed, including MFA and geofencing. Either reconfigure ADFS or move the affected service accounts to a different identity source.

Expired or locked service account

Identify the principal from vmware-sts-idmd.log, correct the account state at the AD level (unlock, reset password, update expiry), and update the credential in every integration that uses it. Log volume drops within seconds of the account being restored.

STS memory pressure

If STS heap is the bottleneck, restarting the STS service via service-control can clear the immediate pressure but does not fix the underlying sizing problem. Engage VMware support before changing Java heap parameters; the appliance ships with tuned values per deployment size.

Prevention

• Track every certificate, not just machine SSL. The STS signing certificate is invisible in the browser and has caused more total outages than any other cert.
• Standardize on vCert, not checkSTS.py. The older script is deprecated across vCenter 7.x, 8.x, and 9.x.
• Monitor NTP offset continuously. Five seconds is a minimum alert threshold; thirty seconds is the realistic danger zone for SAML token rejection.
• Alert on SSO failure rate, not just absolute counts. A rate spike without a corresponding login-attempt spike points at infrastructure, not typos.
• Watch per-principal failure counts. A single noisy service account is the most preventable log flood in vCenter.
• Plan the IWA migration before vSphere 9.0. The pre-upgrade check will block you otherwise.
• Monitor /storage/log headroom aggressively. SSO failure loops can take a 40%-full partition to 100% in hours.

How Netdata helps

• Per-second metric collection on the VCSA VM surfaces CPU, memory, and disk pressure that precede STS degradation.
• NTP offset and chrony source state are collected directly, so you can correlate a clock skew event with the exact minute SSO failures began.
• Disk utilization per /storage/* partition is tracked independently, so a log bomb from an SSO failure loop shows up as a steep slope on /storage/log.
• SSO log-derived counters such as LOGIN_FAILED rate and per-principal failure count can be piped into Netdata as custom metrics, turning the generic login error into a rate signal you can alert on.
• Anomaly detection on STS Java heap and GC frequency catches the silent degradation pattern where intermittent token validation failures precede a total outage.
• Correlation across the stack (VCSA guest metrics, ESXi host CPU ready and memory balloon on the VCSA VM, NTP, disk) collapses the “is it vCenter or the host it runs on” question into a single timeline.

Related guides

• vSphere active vs consumed vs granted memory: why the percentage lies
• vSphere CPU co-stop high (%CSTP): the SMP vCPU co-scheduling penalty
• vSphere CPU limit hit (%MLMTD): the forgotten MHz cap that silently throttles a VM
• vSphere CPU ready time high (%RDY): VMs starved while the guest looks idle
• vSphere datastore full: ‘No space left on device’, paused VMs, and power-on failures
• vSphere datastore IOPS and throughput: spotting storage saturation before latency bites
• vSphere datastore latency high: reading GAVG, DAVG, and KAVG
• vSphere dropped packets (%DRPRX/%DRPTX): ring buffers, CPU, and uplink backpressure
• vSphere DRS not balancing: affinity rules and reservations blocking placement
• vSphere DRS thrashing: vMotion churn with no stable placement
• vSphere storage latency cliff: the ’everything is slow’ incident that hits every VM at once
• vSphere HA host isolation and split-brain: when isolation response goes wrong