AD Users Cannot Sign In to vCenter After a Domain Controller Certificate or Server Change

Direct answer: if AD users suddenly get "invalid credentials" at the vCenter sign-in page while the local SSO administrator still signs in, and the identity source is Active Directory over LDAP using LDAPS, the usual cause is that vCenter no longer trusts the certificate the domain controller now presents. LDAPS identity sources hold copies of the certificates you uploaded. When a domain controller renews its certificate, is replaced, or a load balancer in front of the domain controllers changes certificate, and what vCenter holds was the old leaf certificate rather than the issuing CA chain, the TLS handshake fails and vCenter reports a credential error. Confirm it by comparing what the identity source stores with what each configured server presents on port 636 or 3269, check the bind account and the server list, then correct the identity source with the current CA chain (root and intermediates). The change is small but it touches the sign-in path for every AD user, so take the snapshots Broadcom recommends and keep the local SSO administrator available before you start.

Why it matters

vCenter sign-in failure for AD users is rarely just an inconvenience. Broadcom notes that backup jobs authenticating with AD accounts fail too (KB 418361), and so can any automation, monitoring or third-party integration that signs in with a domain service account. The failure often appears days or weeks after the change that caused it. KB 448143 describes a case where vCenter kept working on cached, long-running LDAPS sessions until a Machine SSL certificate replacement restarted the Single Sign-On services. Only then did a fresh TLS handshake against the domain controller fail, because the identity source was pinned to a domain controller's leaf certificate. The person replacing the vCenter certificate is therefore not always the person who caused the problem. The domain controller's certificate may have been renewed long before.

There is also a deadline for some sites. Broadcom KB 314324 states that Integrated Windows Authentication (IWA) was deprecated in vSphere 7.0 and is removed in the first major release after vSphere 8.0 Update 3 (vSphere 9.0). The upgrade pre-check blocks until vCenter has left the domain. Many organisations are moving from IWA to AD over LDAPS for that reason, and will meet LDAPS certificate maintenance for the first time.

How it works

vCenter Single Sign-On supports several identity source types. The ones relevant here are:

• Active Directory (Integrated Windows Authentication): vCenter joins the domain. It is deprecated, and removed in 9.0 per KB 314324. That KB also notes that IWA uses unsigned LDAP for user and group searches behind the scenes.
• Active Directory over LDAP: vCenter binds to named domain controllers or Global Catalog servers with a service account. With LDAPS (ports 636 or 3269) the connection is TLS-protected, and you upload certificates that vCenter uses to verify the server.
• Identity federation: vCenter trusts an external identity provider such as AD FS or Microsoft Entra ID. KB 314324 lists it alongside LDAPS as a supported alternative. It is not covered here; see the hardening article in Related articles.

For an LDAPS identity source, Broadcom KB 316596 sets several requirements that matter when something changes:

• The host name in the primary and secondary server URLs must be in the domain controller certificate's subject alternative name, even if you provide the root certificates.
• "Any domain controller in the domain" must not be used with LDAPS. The servers are named explicitly, so retiring a named domain controller silently removes one of vCenter's paths.
• Only one identity source can exist for a domain, so an existing source for the same domain is removed before a new one is added. The KB states that updating or replacing the certificate means removing and re-adding the source. KB 448143 (written for 8.0 U3) instead shows editing the identity source to upload the root and intermediate CA certificates, with delete-and-add as the fallback when editing is not possible. Expect either path depending on build, and plan for the re-add.
• In Enhanced Linked Mode, configure it on one vCenter only; the identity source replicates to the others.
• If the bind account is locked out, disabled or has an expired password, AD sign-ins fail. The bind account must not be a member of Protected Users.

What decides whether a domain controller renewal breaks sign-in is which certificate you uploaded. If the identity source trusts the issuing CA chain, a renewed domain controller certificate from the same CA keeps validating. If it holds only the domain controller's leaf certificate, any renewal breaks trust. KB 448143 gives that leaf pinning as the cause and the root plus intermediate chain as the fix. A change of issuing CA, or a load balancer presenting its own certificate, breaks sign-in only when the chain now presented no longer validates to the certificates the identity source trusts, when a pinned leaf no longer matches, or when the server URL's host name is not in the new certificate's subject alternative names. A new intermediate under an already trusted root, for example, may still validate. Compare the actual chain presented with what is stored rather than assuming every change needs new trust.

vCenter 8.x and 9.x raise an alarm, "Identity source LDAP Certificate is about to expire", 90 days before a stored LDAPS server certificate expires (KB 396118). KB 414991 confirms that vCenter cannot renew those certificates automatically. They are managed by the domain administrator, and short-lived certificates make the alarm appear more often.

Read-only checks

None of these was run for this article. They read state and change nothing. Run them from the vCenter appliance shell or an administrator workstation, as noted.

1. Prove the scope of the failure. Sign in as the local SSO administrator (for example administrator@vsphere.local). If local accounts work and every AD account fails, suspect the identity source rather than individual users. If only some AD users fail, check those accounts in AD first. A failure limited to accounts with expired passwords or lockouts is an account problem, not a certificate problem.

2. Record the identity source configuration. In the vSphere Client open Administration > Single Sign-On > Configuration > Identity Sources and record: - the source type; - the domain name and alias; - the base DN for users and groups; - the primary and secondary server URLs; - the bind user name.

Take screenshots. KB 418361 asks for exactly this before any removal, because the same values must be re-entered. From the appliance shell, as root, Broadcom's expiry check uses:

/opt/vmware/bin/sso-config.sh -get_identity_sources

KB 396118 uses this to view the stored LDAPS certificate details, including their expiry. Treat the output as configuration data and do not paste it into tickets wholesale.

3. Read the authentication log. On the appliance, /var/log/vmware/sso/websso.log records the failed bind. KB 383112 and KB 448143 quote the patterns to search for:

grep -E "cannot bind connection|cannot establish ldap connection|Server SSL certificate (verification failed|not trusted)|Can't contact LDAP server" /var/log/vmware/sso/websso.log | tail -20

"Server SSL certificate not a trusted certificate nor signed by a trusted certificate" points to trust. "Can't contact LDAP server" without a certificate message points to name resolution, routing, firewall or a retired server.

4. See what each configured server presents now. For each host name in the server URLs, from the appliance or another host that can reach port 636 (or 3269 for Global Catalog):

echo -n | openssl s_client -connect dc01.example.local:636 -showcerts 2>/dev/null | openssl x509 -noout -subject -issuer -enddate
openssl s_client -connect dc01.example.local:636 -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9] s:|^ *i:"

The first shows the leaf certificate's subject, issuer and expiry. KB 396118 uses this to compare against the stored certificate. The second lists the chain the server sends. These commands are for inspection only. -showcerts prints whatever the server presents, s_client continues past verification errors, and 2>/dev/null hides those errors, so nothing here establishes that the certificates are trustworthy. Names in a certificate are its own claims and can be copied. Also check that the host name you connected to appears in the certificate's subject alternative names:

echo -n | openssl s_client -connect dc01.example.local:636 2>/dev/null | openssl x509 -noout -ext subjectAltName

The -ext option needs OpenSSL 1.1.1 or later. On older builds, use -text and read the Subject Alternative Name section.

5. Check the servers still exist. Confirm that each host name in the identity source resolves and is still a domain controller. A secondary server URL that points at a decommissioned domain controller hides until the primary fails. Then every AD sign-in fails.

6. Check the bind account in AD. From an AD administration workstation, confirm the bind account is enabled, not locked out, its password has not expired, and it is not in Protected Users (KB 316596). Read the account state; do not reset anything yet.

Interpreting the results

Decision guidance

Correct the certificates (most common fix). Collect the current root and any intermediate CA certificates that issued the domain controller certificates, in PEM format, from the certificate authority owner. Do not trust a chain because it came off the wire with openssl s_client -showcerts, even though KB 316596 shows that extraction: subject and issuer names can be reproduced by anyone. Use certificates delivered by the CA owner through an authenticated channel, or compare the SHA-256 fingerprint of each extracted certificate with a value the CA owner confirms through a separate trusted channel. Then check that the chain validates from the domain controller certificate up to the root, and that each server URL's host name is in the leaf's SAN. Prefer the CA chain to a leaf, so the next domain controller renewal does not repeat the outage.

Before the change: - Take the snapshots Broadcom asks for: KB 316596 and KB 418361 call for offline (powered-off) snapshots of every vCenter in an Enhanced Linked Mode group, because the identity source replicates to all of them. The coordinated approach for linked vCenters is in KB 313886. For a single vCenter, a snapshot or a recent file-based backup is the minimum. If the vCenter runs vSphere Supervisor or VKS, KB 313886 warns that snapshot rollbacks will not work with the Supervisor Control Plane VMs; use a file-based backup, taken as part of the Supervisor backup and restore process, as the rollback point instead. - Confirm you know the local SSO administrator password and can sign in with it. Every later step depends on it. - Record the identity source settings (check 2). - Note which AD users and groups hold vCenter roles and global permissions. KB 418361 warns these may need re-adding after a remove and re-add. Keeping the domain name and alias identical preserves them in the IWA-to-LDAPS migration case described in KB 314324.

The change, signed in as the local SSO administrator: - Edit the identity source and upload the root and intermediate certificates (the KB 448143 path). - If editing is not possible, remove it and add it again as Active Directory over LDAP with the same domain name, alias, base DNs and server URLs, then browse to the certificates (the KB 316596 path).

Verification: - Sign in with a test AD account that has a known role. - Sign in with one real administrator account. - Run one AD-authenticated integration, for example a backup job's credential test. - Confirm websso.log no longer shows the trust errors. - Reset the expiry alarm, if it fired, after reconfiguration (KB 396118). - In Enhanced Linked Mode, test sign-in on every linked vCenter.

Rollback: if sign-in is worse after the change and cannot be corrected promptly, first try restoring the recorded identity source settings and certificates. If a full revert is still needed, revert to the snapshots taken for this change (or, with Supervisor or VKS, restore the file-based backup), following the same coordinated procedure for every linked node. A snapshot revert also reverses anything else that changed in the meantime. Keep the window short and delete the snapshots after you have verified.

Retiring a domain controller. Before demoting a domain controller named in an LDAPS identity source, update the primary or secondary server URL to a remaining domain controller whose certificate includes that host name in its SAN. Then test. The change has the same shape as the certificate correction: record the settings, take the snapshots, edit or re-add, verify. Do not change the server to "Any domain controller in the domain", which KB 316596 says must not be used with LDAPS.

Still on IWA. Treat migration to LDAPS or federation as a planned change before any upgrade to 9.0, not part of an incident fix. KB 314324 states that the upgrade requires leaving the domain first, and that keeping the same domain name and alias preserves permissions. It also notes that "use Windows session credentials" sign-in is removed.

Prevent the next occurrence: - Ask the AD or PKI owner to notify vSphere administrators before domain controller certificate template or CA changes. - Record the domain controllers named in each identity source in the decommissioning checklist. - Keep the expiry alarm enabled.

What not to do

• Do not switch to plain LDAP on port 389 to "get people back in". That sends the bind and directory traffic without TLS. It may also fail against domain controllers that require LDAP signing, and it creates a second problem to undo.
• Do not remove the identity source before recording its settings and confirming the local SSO administrator works. Removal ends every AD sign-in immediately.
• Do not use the bind account's password in a shell command, script or ticket for testing. The read-only checks above do not need it.
• Do not upload a certificate extracted from the network on the strength of its subject and issuer. Confirm it came from the CA owner or that its fingerprint matches a value confirmed through a separate trusted channel. If something in the path presents an unexpected certificate, trusting it hides the problem rather than fixing it.
• Do not snapshot only one node in an Enhanced Linked Mode group, or revert one node alone.
• Do not reset the bind account's password as a first step. If the certificate is the cause, it adds an AD change and a vCenter password update to the incident.

Limitations

• Exact screen wording and whether the identity source can be edited in place differ by vCenter build. KB 316596 describes remove and re-add, while KB 448143 (8.0 U3) shows an edit path. Follow the screens of your build.
• This article does not cover OpenLDAP identity sources, federation with AD FS or Entra ID, or IWA troubleshooting beyond its removal schedule.
• The domain controller certificate requirements themselves (templates, enhanced key usage, how domain controllers select a certificate) belong to Microsoft's documentation and your PKI owner. The SAN requirement stated here comes from Broadcom KB 316596.
• The openssl commands run from the appliance assume it can reach the domain controllers. From elsewhere they show what that host sees, which may differ through load balancers or firewalls.
• KB 448143 is written for 8.0 U3. Its description of cached LDAPS sessions explains a delayed failure, but the timing on other builds is not documented.

Acceptance checklist

• [ ] Failure scope confirmed: local SSO works, AD fails (or account-level cause ruled out)
• [ ] Identity source settings recorded with screenshots before any change
• [ ] websso.log errors identified as trust, reachability or account
• [ ] Each configured server's presented certificate, issuer, expiry and SAN checked
• [ ] Bind account state checked with the AD owner
• [ ] Root and intermediate CA certificates obtained from the CA owner, or fingerprints confirmed through a separate trusted channel; chain validates to the root and each server name is in the SAN
• [ ] Offline snapshots (Enhanced Linked Mode, all nodes) or snapshot and file-based backup (single vCenter) taken; with Supervisor or VKS, a file-based backup instead of snapshot rollback
• [ ] Identity source updated with the CA chain; domain name and alias unchanged
• [ ] Test AD account, a real administrator and one AD-authenticated integration verified on every linked vCenter
• [ ] Roles and global permissions for AD groups present
• [ ] Expiry alarm reset; snapshots removed after verification
• [ ] Domain controllers named in identity sources added to the decommissioning checklist

References

All accessed 2 November 2026. Broadcom knowledge base articles do not display a last-updated date.

• Broadcom KB 316596, Configuring a vCenter Single Sign-On Identity Source using LDAP with SSL (LDAPS): https://knowledge.broadcom.com/external/article/316596
• Broadcom KB 383112, AD authentication failure in vCenter due to LDAPS certificate mismatch: https://knowledge.broadcom.com/external/article/383112/ad-authentication-failure-in-vcenter-due.html
• Broadcom KB 418361, Active Directory logins to vCenter fail after LDAPS certificate renewal: https://knowledge.broadcom.com/external/article/418361/active-directory-logins-to-vcenter-fail.html
• Broadcom KB 448143, Active Directory users cannot log in after Machine SSL certificate replacement (leaf-pinned LDAPS identity source): https://knowledge.broadcom.com/external/article/448143/active-directory-users-cannot-log-in-to.html
• Broadcom KB 396118, "Identity source LDAP Certificate is about to expire" alarm: https://knowledge.broadcom.com/external/article/396118/identity-source-ldap-certificate-is-abou.html
• Broadcom KB 414991, Automatic renewal of LDAPS certificates for the identity source: https://knowledge.broadcom.com/external/article/414991/automatic-renewal-of-ldap-with-ssl-ldaps.html
• Broadcom KB 314324, Removal of Integrated Windows Authentication: https://knowledge.broadcom.com/external/article/314324/removal-of-integrated-windows-authentica.html
• Broadcom KB 313886, snapshot best practices for vCenter in Enhanced Linked Mode (offline snapshots of all nodes): https://knowledge.broadcom.com/external/article/313886

Related articles

• How to harden VMware without breaking operations or recovery
• DNS Changed but Users Still Reach the Old Application

• How to back up and rehearse recovery of the vCenter appliance

• vCenter Sign-In Fails After a Certificate Expires: Find the Store Responsible

• Before Enforcing LDAP Signing and Channel Binding: Find Every Unsigned Bind

Learning notes

1. LDAPS identity sources verify the domain controller with certificates you uploaded; trusting the CA chain survives domain controller renewals, and trusting a leaf does not.
2. "Invalid credentials" for every AD user while the local SSO administrator works points at the identity source, and websso.log tells you whether it is trust, reachability or the bind account.
3. A delayed failure after a Machine SSL replacement can be an old domain controller renewal surfacing when cached sessions drop.
4. Domain controllers named in an identity source belong on the decommissioning checklist, because LDAPS cannot use "any domain controller".
5. Record settings, keep the local administrator working and snapshot every linked node before editing or re-adding the identity source.