1. kubectl login to a guest cluster takes a 1-2 min and logs in successfully without issues.
2. Issue is seen with LDAP domain user accounts and not with local account (accounts ending with `@vsphere.local`)
$ kubectl vsphere login \
--server=<SUPERVISOR_CONTROL_PLANE_IP> \
--vsphere-namespace=<VSPHERE_NAMESPACE> \
--tanzu-kubernetes-cluster-name=<TKG_CLUSTER_NAME> \
--insecure-skip-tls-verify \
-v=10
DEBU[2025-10-02 11:23:25.100] User passed verbosity level: 10
DEBU[2025-10-02 11:23:25.100] Setting verbosity level: 10
DEBU[2025-10-02 11:23:25.100] Setting request timeout:
DEBU[2025-10-02 11:23:25.100] login called as: /usr/bin/kubectl-vsphere login --server=<IP> --tanzu-kubernetes-cluster-namespace=infra-service --tanzu-kubernetes-cluster-name=testcluster -v=10
DEBU[2025-10-02 11:23:25.100] Creating wcp.Client for 172.xx.xx.xx
DEBU[2025-10-02 11:23:25.119] Got response:
Username: username@domain
INFO[2025-10-02 11:23:33.392] Using username@domain username.
DEBU[2025-10-02 11:23:33.392] KUBECTL_VSPHERE_PASSWORD environment variable is not set
Password:
<<stuck about 30s>>
DEBU[2025-10-02 11:24:07.685] Got response: [{"namespace":...]
DEBU[2025-10-02 11:24:07.796] Got response: {"session_id":...}
INFO[2025-10-02 11:24:07.798] User has existing context; will not override.
DEBU[2025-10-02 11:24:07.798] Logging in to Tanzu Kubernetes cluster (clustername) (XXXXX)
DEBU[2025-10-02 11:24:07.944] Got response: {"session_id":...}
INFO[2025-10-02 11:24:07.950] Successfully logged in to Tanzu Kubernetes cluster 172.xx.xx.xx
DEBU[2025-10-02 11:24:07.958] Trying to login to 10.xx.xx.xx
DEBU[2025-10-02 11:24:07.958] Creating wcp.Client for 10.xx.xx.xx
<<stuck about 30s>>
DEBU[2025-10-02 11:24:38.160] Got response: {"session_id":...}
Logged in successfully.
Supervisor version v1.27.5 and above
In environments with multiple Domain Controllers (DCs) providing LDAP services, authentication delays may occur if the LDAP configuration only specifies the domain name rather than individual Domain Controllers.
When one of the domain’s Domain Controllers became unreachable, LDAP configured to use the domain name rather than explicitly listing DCs occasionally routed authentication attempts to that offline controller, resulting in intermittent login delays.
We can verify the time taken using wcp-auth proxy logs:
wcp-authproxy logs:
2025-06-11T13:51:01.085603988Z stderr F INFO:auth.filters:[140206217241472] User authenticated using basic token.
:
:(took 49 seconds to get cluster ID)
2025-06-11T13:51:49.831196531Z stderr F DEBUG:vclib.token:[140206217241472] Cluster UID (28550edf-f0f8-4f81-98ff-4f3fc335ac04), server (10.XX.XX.XX)
Check connectivity for domain controllers using the below command:
"curl -v -k <Identity-provider-url.domain.com>:636" (for ldaps) and "curl -v -k <Identity-provider-url.domain.com>:389" (for ldap).
To resolve the issue, the LDAP configuration should be updated to explicitly specify a reachable working Domain Controllers instead of relying solely on the domain name or fix the connectivity of domain controller with the issue.
When vCenter authenticates against LDAP/Active Directory:
vCenter connects to one of the configured Domain Controllers (DCs) via LDAP or LDAPS.
It performs a Bind operation using the credentials of the configured identity source.
If the first DC is unreachable, vCenter will try the next DCs in the list (if multiple are configured).
Successful bind → authentication succeeds; failure or timeout → vCenter may log an error.
If your identity source is just a domain name (no explicit DCs), vCenter relies on DNS to resolve the DCs. If DNS returns an unreachable DC first, it can cause delays or timeouts.
For log traces for LDAP connectivity issues, you can check below logs in vCenter:
/var/log/vmware/vpxd/vpxd.log
/var/log/vmware/sso/vmwate-sts-identity.log or websso.log
/var/log/vmware/vmdird/vmdird.log
You will find errors like:
LDAP connection to <DC> failed: java.net.ConnectException: Connection timed out
Also refer https://knowledge.broadcom.com/external/article?articleNumber=401758