OKTA OIDC Login in vCenter 8.x Fails with Access Denied User Not Found
search cancel

OKTA OIDC Login in vCenter 8.x Fails with Access Denied User Not Found

book

Article ID: 444455

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

  • Login to vCenter an Okta account fails with the error: "Access denied. Unable to authenticate the user".

  • The federation service logs on the Identity Broker appliance indicates that OIDC authentication succeeds, but the backend directory mapping fails with a USER_NOT_FOUND error

var/log/vmware/vc-ws1a-broker/federation-service.log:

yyyy-mm-ddThh:mm:ss WARN  <vCenter_name>:federation (ForkJoinPool-2-worker-89) [CUSTOMER;-;10.XXX.XX.XX;e99c9789-1c20-4f5f-9166-XXXXXXXXXXX;-;472ee5fc-bc73-4141-9275-XXXXXXXXXXX] com.vmware.vidm.federation.login.processor.AuthResponseUserResolver - User fetching exception with nameId 00u1s8vrd1dKSs#####, nameIdFormat ExternalId, and domains [domain.com], user not found
yyyy-mm-ddThh:mm:ss INFO  <vCenter_name>:federation (federation-business-pool-0) [CUSTOMER;-;10.XXX.XX.XX;e99c9789-1c20-4f5f-9166-XXXXXXXXXXX;-;472ee5fc-bc73-4141-9275-XXXXXXXXXXX] com.vmware.vidm.federation.login.LoginEventServiceAspect - Failing login. contextUuid: 472ee5fc-bc73-4141-9275-XXXXXXXXXXX, exception: com.vmware.vidm.federation.login.AccessDeniedException: Access denied with reason code: USER_NOT_FOUND, isAuthenticationForced: false
yyyy-mm-ddThh:mm:ss INFO  <vCenter_name>:federation (federation-business-pool-0) [CUSTOMER;-;10.XXX.XX.XX;e99c9789-1c20-4f5f-9166-XXXXXXXXXXX;-;472ee5fc-bc73-4141-9275-XXXXXXXXXXX] com.vmware.vidm.federation.utils.MetricsPublisherUtil - Login failed due to reason: USER_NOT_FOUND
yyyy-mm-ddThh:mm:ss INFO  <vCenter_name>:federation (federation-business-pool-0) [CUSTOMER;-;10.XXX.XX.XX;e99c9789-1c20-4f5f-9166-XXXXXXXXXXX;-;472ee5fc-bc73-4141-9275-XXXXXXXXXXX] com.vmware.vidm.federation.exception.handler.LoginExceptionHandler - Access denied for login context: 472ee5fc-bc73-4141-9275-XXXXXXXXXXX

 

Environment

VMware vCenter Server 8.x
Okta OIDC Identity Provider

Cause

This is a token claim mismatch between the Okta payload and the vCenter user directory.

vCenter primarily uses the OIDC sub (subject) claim as the immutable identifier to map the authenticated user to the SCIM-provisioned account. There is no supported UI in vCenter 8 U3 to configure an arbitrary custom claim (such as externalId) for this mapping.

When Okta hands the user off to vCenter after a successful authentication, it sends a specific nameId claim in the OIDC token. Okta is sending its internal system string (00u1s8vrd1dKSs73z1d8) as the ExternalId rather than a standard username. Because the user account synchronized into the vCenter database does not possess this exact alphanumeric string mapped to its profile, vCenter cannot link the authentication token to a known local user entity and denies the login.

  1. SCIM Provisioning
    • Creates the user in vCenter.
    • Stores an identifier such as externalId.
  2. OIDC Login
    • The Identity Provider (Okta or another authorization manager) sends claims in the ID token (for example sub, NameID, or another unique identifier).
    • vCenter attempts to match the incoming claim with the SCIM-provisioned user's externalId.

If these values differ, vCenter cannot associate the authenticated user with the existing account.

For example:

SCIM-created userOIDC token
externalId = 00u1s8vrd1dKSs#####sub = john.doe@example.com
Result: No matchLogin or account mapping fails

Test your authorization server configuration - https://help.okta.com/oie/en-us/content/topics/security/api-config-test.htm 

Resolution

To resolve this, you must align the identity payload Okta sends with the identity structure vCenter expects. You can achieve this using one of the following methods:

Option 1: SCIM Provisioning Alignment (Based on your deployment architecture), you have to check with OKTA support on this. (Not feasible when configuring for large number of users)

If you are dynamically populating vCenter users via a SCIM REST API script, the JSON payload that creates the user in vCenter must explicitly include the Okta NameID.

You must update your SCIM provisioning script to ensure the externalId field perfectly matches the Okta user ID (e.g., 00u1s8vrd1dKSs#####) so vCenter can map the incoming OIDC token to the SCIM-created account.

Option 2: Instead of modifying the SCIM provisioning process to write a different externalId, you can configure the Authorization Manager (or IdP) to send the identifier that vCenter expects.

If you are using a custom SCIM integration in Okta:

  1. Open the SCIM application in the Okta Admin Console.
  2. Go to Provisioning → To App.
  3. Open the Attribute Mappings (sometimes under Profile Editor depending on the app type).
  4. Locate the mapping for externalId.
  5. Map it to the Okta attribute that corresponds to the identifier used for OIDC login.

Option 3: (Check with OKTA support on this)

The Authorization Manager is acting as a centralized Identity Provider for many applications, each relying on the existing claim format. Changing a claim such as sub or NameID globally could break authentication or user mapping for those other applications.

So changing the IdP output was not an acceptable option.

We can use an on-premises provisioning agent with a proxy/transformation layer.

The proxy intercepted or transformed the provisioning data so that the externalId stored in vCenter matched the identifier that the Authorization Manager was already sending.

Refer: https://help.okta.com/en-us/content/topics/provisioning/opp/opp-architecture.htm

Additional Information

Similar issue on vCenter 9.x - Okta OIDC Login in vCenter 9.x Fails with Access Denied User Not Found

Similar issue on Azure AD in vCenter 8.x - Login to vCenter Server with Entra ID user fails with USER_NOT_FOUND

Powered by Wolken Software