Newly added Microsoft Entra ID users cannot sign in to vCenter Server (USER_NOT

Products

VMware vCenter Server

Issue/Introduction

You add a new user to a Microsoft Entra ID group that holds vCenter Server permissions, but the user cannot sign in to the vSphere Client. After the user completes Microsoft Entra ID sign-in and multi-factor authentication (MFA), the vSphere Client shows an error similar to:
```
Access denied. Unable to authenticate the user.
```
Users who were added earlier continue to sign in normally. Only recently added accounts fail.

In /var/log/vmware/vc-ws1a-broker/federation-service*.log, you see errors similar to:

WARN  ... AuthResponseUserResolver - User fetching exception with nameId <uuid>, nameIdFormat ExternalId, and domains [<your-domain>], user not found
INFO  ... LoginEventServiceAspect - Failing login ... AccessDeniedException: Access denied with reason code: USER_NOT_FOUND

When you export vCenter Server's provisioned user directory through the SCIM (System for Cross-domain Identity Management) API, the affected user is missing, while established users are present.

Additional symptoms reported:

The Add, Edit, Delete, Unlock, Enable, and Disable options under Administration > Single Sign On > Users and Groups are greyed out.
You cannot provide vSphere access to new teammates.

Environment

VMware vCenter Server 8.0 Update 3
Configured for Identity Federation with Microsoft Entra ID and SCIM user provisioning
Just-in-Time (JIT) provisioning is disabled

Cause

vCenter Server signs in a federated user only if that user already exists in its provisioned user directory. Identity Federation with Microsoft Entra ID uses a SCIM provisioning application to copy users and groups from Entra ID into that directory.

The SCIM provisioning application for the affected group is configured but has never run. In the Microsoft Entra admin center, its Last cycle completed time shows Never. As a result, accounts added to that group are never written into vCenter Server.

Because Just-in-Time (JIT) provisioning is disabled, an account that was never synchronized cannot sign in, and the login fails with USER_NOT_FOUND. Users added earlier still work because an earlier provisioning application already synchronized them.

Resolution

In the vSphere Client, go to Administration > Single Sign On > Configuration > Identity Provider and confirm the environment uses Identity Federation with Microsoft Entra ID.
In the Microsoft Entra admin center, open the enterprise application that provisions the affected group and select Provisioning. If Last cycle completed time shows Never, the application has not started.
Confirm the affected user belongs to a group that is in scope of that provisioning application. Provisioning scope is often set to Sync only assigned users and groups.
Select Start provisioning.
Select Provision on demand for the affected user, then allow a full synchronization cycle to finish. A cycle can take roughly 20 to 45 minutes.
Confirm the user now appears in vCenter Server's provisioned directory, then have the user retry the vSphere Client sign-in.

If the initial synchronization is quarantined:

After you start provisioning, the status may show Initial sync quarantined with error code SystemForCrossDomainIdentityManagementCredentialValidationFailure, and the validation request to the vCenter Server SCIM endpoint returns HTTP 401 Unauthorized. This means the SCIM secret token in Entra ID no longer matches the token in vCenter Server. The vCenter Server side can still show its token as valid; this is a mismatch, not an expiry.

In the vSphere Client, go to Administration > Single Sign On > Configuration > Identity Provider > User Provisioning > Secret Token and select Regenerate.
Copy the new token value into the SCIM provisioning application in Microsoft Entra ID and save it.
Confirm the provisioning connection validates, then repeat Provision on demand and the synchronization from the steps above.
Record the new SCIM token expiry date, because regenerating the token resets it.

If an affected account shows USER_IS_DISABLED instead of USER_NOT_FOUND:

The account exists in vCenter Server's directory but is marked disabled. This happens after an account is removed from, or drops out of scope of, the provisioning application in Microsoft Entra ID.

Confirm the account is enabled and in scope of the provisioning application in Microsoft Entra ID.
Select Provision on demand for the account and confirm it shows as active.
Have the user retry the sign-in.

Additional Information

For the token regeneration procedure, see Regenerate the SCIM token in vCenter Server.
This article covers the cause where the account was never written into the provisioned directory. If the account already exists in the directory but with a mismatched ExternalId, a different cause applies and the login fails with the same USER_NOT_FOUND error. For the directory validation and stale-record cleanup steps that address that different cause, see Login to vCenter Server with Microsoft Entra ID users fails with USER_NOT_FOUND.
For accounts that remain disabled after removal from Entra ID scope, see Microsoft Entra ID users removed from scope are retained as disabled in vCenter Server.
To avoid a recurrence, track and rotate two credentials before they expire: the OpenID Connect (OIDC) sign-in application client secret and the SCIM provisioning secret token. If the OIDC client secret expires, all Microsoft Entra ID sign-ins stop. If the SCIM token expires, provisioning of newly added users stops silently.