Resolving vCenter Entra ID Access Denied After VVF Ingestion into VCF 9.1

The situation

After ingesting one of my VMware vSphere Foundation environments into VMware Cloud Foundation 9.1, I could still log in to vCenter with the local SSO administrator account, but Microsoft Entra ID authentication stopped working.

Because the failure appeared immediately after the VVF-to-VCF ingestion, I initially suspected that something had changed with federation, VCF SSO, claim mapping, or the identity-provider integration.

The timing was misleading.
The ingestion and the authentication failure happened at nearly the same time, but the underlying issue turned out to be independent of the ingestion.

The Access Denied error

When I selected the Microsoft Entra ID login method, authentication ended on a Workspace ONE Access page with:

Access Denied
Access denied. Unable to authenticate the user.

Workspace ONE Access page showing Access Denied and Unable to authenticate the user — The initial symptom. The unique correlation ID from the real incident has been redacted in this published screenshot.

The useful part of this screen was the UUID displayed below the message. That value gave me a correlation ID I could follow through the federation logs on the vCenter appliance.

Using the correlation ID to trace the failure

I logged into the vCenter appliance and searched the Workspace ONE Access broker logs for the correlation ID from the error page:

grep -Rni --text '<CORRELATION-ID>' \
  /var/log/vmware/vc-ws1a-broker/ 2>/dev/null

The matching entries showed that the OIDC callback reached vCenter, but the broker could not retrieve tokens:

OidcAuthenticator - Exception occurred while retrieving oidc tokens
OidcAuthenticationException: Unable to get ID token and access token

LoginFlowService - Deny access ...
reason code: AUTH_FAILED

OIDC callback The browser returned to the expected vCenter federation endpoint.

Microsoft connectivity vCenter successfully established TLS to login.microsoftonline.com:443.

Failure stage The problem occurred while redeeming the authorization code for ID and access tokens.

The log entry that identified the root cause

I expanded the relevant section of federation-service.log:

sed -n '3555,3645p' \
  /var/log/vmware/vc-ws1a-broker/federation-service.log

That exposed the actual Microsoft Entra response:

Token endpoint failed ... invalid_client:
AADSTS7000222: The provided client secret keys for app
'<APPLICATION-ID-REDACTED>' are expired.

Caused by: ... invalid_client: AADSTS7000222
...
Unable to get ID token and access token

Root cause: the Microsoft Entra application registration used by vCenter had an expired OIDC client secret.

This also ruled out several other possibilities. The vCenter appliance had working DNS and network connectivity to Microsoft, the browser redirect was reaching the expected callback, and the failure occurred before user claim or SCIM mapping would have become the deciding factor.

Replacing the expired Microsoft Entra client secret

I opened the Microsoft Entra application registration used for the vCenter integration:

Microsoft Entra ID → App registrations → vCenter OIDC application → Certificates & secrets → Client secrets

The existing client secrets were expired, so I created a new client secret with a new expiration date.

Microsoft Entra client secrets page with sensitive values redacted — The Entra application after creating the replacement secret. Secret values and identifiers have been obscured.

Use the client secret Value, not the Secret ID.
The secret value is shown when the secret is created and is the value vCenter needs for the OIDC shared secret.

Updating the vCenter Identity Provider

In my environment, the existing Microsoft Entra identity provider was still editable directly from the vSphere Client. I logged in with the local SSO administrator and navigated to:

Administration → Single Sign On → Configuration → Identity Provider → Edit

I replaced the existing Shared Secret with the new Microsoft Entra client-secret value and saved the provider.

vCenter Microsoft Entra Identity Provider page showing Provider has been updated — vCenter after the Microsoft Entra provider was updated successfully. Tenant and application identifiers have been redacted.

Result: immediately after updating the shared secret, Microsoft Entra ID login to vCenter worked again. No vCenter reboot was required.

The Identity Provider page error I did not capture

During the provider update, the vSphere Client briefly displayed an error on the Identity Provider page. I did not capture that message before the provider ultimately updated successfully.

I found a related Broadcom example where a Microsoft Entra provider change fails while vCenter tries to obtain an access token. Broadcom KB 437622 shows the UI message:

Failed to get an access token on host <VC_FQDN> for tenant HWS

Important: I am treating that as a related UI example, not as proof that it was the exact transient message I saw. That KB documents a different underlying cause. The exact root cause in my incident is the AADSTS7000222 expired-client-secret response in the federation log.

OIDC shared secret vs. SCIM secret token

There are two different secrets in this integration, and it is easy to rotate the wrong one.

Credential	Purpose	Was it the problem?
Entra application Client Secret / vCenter Shared Secret	Used by vCenter during OIDC authentication to exchange the authorization code for ID and access tokens.	Yes. This was expired.
vCenter SCIM Secret Token	Used by Microsoft Entra provisioning to push users and groups into vCenter.	No. This is a separate credential with its own expiration lifecycle.

How I would troubleshoot this next time

Capture the correlation ID.
Copy the UUID displayed on the Workspace ONE Access “Access Denied” page.

Search the federation logs.
Start with /var/log/vmware/vc-ws1a-broker/federation-service.log.

Identify the failure stage.
USER_NOT_FOUND points toward identity mapping; Unable to get ID token and access token points toward the OIDC token exchange.

Read the nested Microsoft error.
AADSTS7000222 identifies an expired client secret. AADSTS7000215 commonly indicates an invalid secret.

Rotate only the affected credential.
Create a new Entra client secret and update the vCenter Identity Provider Shared Secret.

Retest and verify the log.
Use a fresh browser session and confirm the token-exchange error no longer appears.

Lessons from the incident

Do not let timing become the diagnosis.
The authentication failure appeared right after VCF ingestion, but the ingestion did not expire the Microsoft Entra application secret.

Correlation IDs are extremely useful.
The ID on the error page let me trace one failed login through the federation service without guessing.

Read one layer deeper than the wrapper exception.
“Unable to get ID token and access token” described the symptom; AADSTS7000222 identified the cause.

Track OIDC secret expiration.
An expired Entra client secret causes a hard authentication outage even when DNS, routing, TLS, vCenter, and the Entra sign-in page all appear healthy.

Know which secret you are rotating.
The OIDC client secret and the SCIM provisioning token are separate credentials with separate purposes and expiration dates.

The resolution

I generated a new client secret in the Microsoft Entra application registration and updated the vCenter Microsoft Entra Identity Provider with that new shared-secret value. Entra authentication immediately returned to normal.

No rebuild or identity-provider recreation was needed.
I did not need to recreate the provider, change claim mappings, regenerate the SCIM token, modify network connectivity, or reboot vCenter.

The most valuable troubleshooting path was the simplest one: capture the Workspace ONE Access correlation ID, trace it in vc-ws1a-broker, and follow the nested exception until Microsoft Entra tells you exactly why the token request failed.

References

Broadcom KB 390375 — Unable to log in to vCenter with Entra ID

Broadcom KB 407646 — Renewing the Azure Entra ID secret token in vCenter

Broadcom KB 437622 — Related Microsoft Entra Identity Provider change error example

Microsoft Learn — Microsoft Entra authentication and authorization error codes