Has anyone ran into issues setting up SSO for VMWare vCenter Server.

Question

Has anyone ran into issues setting up SSO for VMWare vCenter Server.

Troy Marshall 0

I have 2 different vCenter servers running version 8.0.3 and on one I have sso working without any issues. On the second server it is configured exactly the same and I keep getting Access Denied when trying to log in. I've setup the scim and that's working. Within vCenter I have the same permissions setup as I do on the other vCenter, but don't know what I'm missing.

Sridevi Machavarapu 26,355 Reputation points Microsoft External Staff Moderator

2026-04-07T18:45:05.8066667+00:00
Hello Troy Marshall,

Yes, this has been observed with VMware vCenter Server integrated with Microsoft Entra ID, especially when one instance works and another returns Access Denied.

Based on your scenario, authentication is likely successful and the issue is with access mapping in vCenter.

Verify Global Permissions (Administration → Access Control) and ensure the correct Entra ID user or group has the required role with propagation enabled

Note that SCIM only provisions users and groups; access still needs to be assigned within vCenter

Check the Identity Source settings and confirm the domain configuration aligns with the working instance

Validate that the expected group claim is being sent and matches the group configured in vCenter

Test by assigning a user directly with an Administrator role to confirm whether the issue is related to group mapping

Perform a side-by-side comparison of both environments to identify any configuration differences

This usually indicates a mismatch in permissions or claim mapping rather than an issue with SSO itself.
Troy Marshall 0 Reputation points

2026-04-07T18:54:44.2366667+00:00

I have compared both vCenters and I have not found a mismatch in any of the configurations. How would I check the group claim is being sent and matches the group in vCenter?
Sridevi Machavarapu 26,355 Reputation points Microsoft External Staff Moderator

2026-04-07T19:30:44.2766667+00:00

Hello Troy Marshall,

You can verify this from the SAML token issued by Microsoft Entra ID during sign-in.

First, go to your Enterprise Application → Single sign-on → Attributes & Claims and confirm that a Groups claim is configured.

Then open an InPrivate/Incognito browser session and sign in to VMware vCenter Server. Capture the SAML response using browser developer tools (Network tab) and copy the token. Paste it into a tool like jwt.ms to decode it.

In the decoded token, check for the groups claim and verify the Object ID (GUID). This should match the group assigned in vCenter, as vCenter uses the Object ID rather than the display name.

If no groups are present, or if you see _claim_names instead of actual group values, it indicates the group claim is not being sent as expected (commonly due to group overage).
mr jhon smite 0 Reputation points

2026-04-07T20:20:08.9633333+00:00

I’m seeing a similar issue with vCenter 8.0.3 SSO works on one server but gives Access Denied on another, even with the same permissions and SCIM setup. Has anyone figured out what might be missing in these cases?
Sridevi Machavarapu 26,355 Reputation points Microsoft External Staff Moderator

2026-04-08T23:07:28.3666667+00:00
Hello mr jhon smite,

Yes, this does come up with VMware vCenter Server and Microsoft Entra ID, even when both setups look identical.

In most cases, authentication succeeds but vCenter can’t map the user to a role.

Things worth checking:

The group claim – confirm the group ID in the token matches what’s added in vCenter (it should be the Object ID, not the display name)

SCIM may provision the group, but it still needs to be assigned in Global Permissions with propagation enabled

If the token shows _claim_names instead of actual groups, it indicates a group overage scenario

Check for small differences in how the group or domain was added in vCenter

As a quick test, assign a user directly in vCenter with an Administrator role and try logging in. If that works, it points to a group/claim mapping issue.

Comparing the group Object ID in the token with what’s configured in vCenter usually helps identify the gap.

1 answer

Your answer

Sridevi Machavarapu 26,355 Reputation points Microsoft External Staff Moderator

2026-04-07T18:45:05.8066667+00:00

Hello Troy Marshall,

Yes, this has been observed with VMware vCenter Server integrated with Microsoft Entra ID, especially when one instance works and another returns Access Denied.

Based on your scenario, authentication is likely successful and the issue is with access mapping in vCenter.

Verify Global Permissions (Administration → Access Control) and ensure the correct Entra ID user or group has the required role with propagation enabled

Note that SCIM only provisions users and groups; access still needs to be assigned within vCenter

Check the Identity Source settings and confirm the domain configuration aligns with the working instance

Validate that the expected group claim is being sent and matches the group configured in vCenter

Test by assigning a user directly with an Administrator role to confirm whether the issue is related to group mapping

Perform a side-by-side comparison of both environments to identify any configuration differences

This usually indicates a mismatch in permissions or claim mapping rather than an issue with SSO itself.
Troy Marshall 0 Reputation points

2026-04-07T18:54:44.2366667+00:00

I have compared both vCenters and I have not found a mismatch in any of the configurations. How would I check the group claim is being sent and matches the group in vCenter?
Sridevi Machavarapu 26,355 Reputation points Microsoft External Staff Moderator

2026-04-07T19:30:44.2766667+00:00

Hello Troy Marshall,

You can verify this from the SAML token issued by Microsoft Entra ID during sign-in.

First, go to your Enterprise Application → Single sign-on → Attributes & Claims and confirm that a Groups claim is configured.

Then open an InPrivate/Incognito browser session and sign in to VMware vCenter Server. Capture the SAML response using browser developer tools (Network tab) and copy the token. Paste it into a tool like jwt.ms to decode it.

In the decoded token, check for the groups claim and verify the Object ID (GUID). This should match the group assigned in vCenter, as vCenter uses the Object ID rather than the display name.

If no groups are present, or if you see _claim_names instead of actual group values, it indicates the group claim is not being sent as expected (commonly due to group overage).
mr jhon smite 0 Reputation points

2026-04-07T20:20:08.9633333+00:00

I’m seeing a similar issue with vCenter 8.0.3 SSO works on one server but gives Access Denied on another, even with the same permissions and SCIM setup. Has anyone figured out what might be missing in these cases?
Sridevi Machavarapu 26,355 Reputation points Microsoft External Staff Moderator

2026-04-08T23:07:28.3666667+00:00

Hello mr jhon smite,

Yes, this does come up with VMware vCenter Server and Microsoft Entra ID, even when both setups look identical.

In most cases, authentication succeeds but vCenter can’t map the user to a role.

Things worth checking:

The group claim – confirm the group ID in the token matches what’s added in vCenter (it should be the Object ID, not the display name)

SCIM may provision the group, but it still needs to be assigned in Global Permissions with propagation enabled

If the token shows _claim_names instead of actual groups, it indicates a group overage scenario

Check for small differences in how the group or domain was added in vCenter

As a quick test, assign a user directly in vCenter with an Administrator role and try logging in. If that works, it points to a group/claim mapping issue.

Comparing the group Object ID in the token with what’s configured in vCenter usually helps identify the gap.

Answer 1

For Azure VMware Solution vCenter, SSO with an external identity source (Microsoft Entra ID or Windows Server AD/LDAP) depends on a few AVS‑specific pieces that must be correct on each vCenter. Even if two vCenters look “the same”, a small difference in identity source configuration or permissions can cause Access Denied.

Use the following checks on the failing vCenter and compare directly with the working one:

Confirm the external identity source is actually registered and resolvable

In AVS, external identity sources (Windows Server AD via LDAPS or Entra ID) are added through Run command packages, not directly with native vCenter admin rights.
On the failing vCenter’s private cloud in the Azure portal, go to Run command → Packages → Microsoft.AVS.Identity and:
- Verify the identity source was created successfully (for LDAPS, via New-LDAPSIdentitySource).
- Use the command that lists all existing external identity sources and confirm the domain/identity provider entry matches the working vCenter (same DomainName, DomainAlias, URLs, etc.).
Ensure DNS resolution from AVS to the identity source works (NSX/DNS forwarder configured and pointing to the correct AD DNS servers), as required in the identity source setup.

If using Windows Server AD via LDAPS, validate all New‑LDAPSIdentitySource parameters On the failing vCenter, re‑open Microsoft.AVS.Identity → New‑LDAPSIdentitySource and compare each parameter to the working vCenter:

PrimaryUrl / SecondaryUrl: Correct ldaps:// hostnames and port (636) and reachable from AVS.
DomainName: Correct AD FQDN.
DomainAlias: Correct NetBIOS name (e.g., DOMAIN), used in logon format DOMAIN\user.
BaseDNUsers / BaseDNGroups: Correct DNs that actually contain the users/groups being used.
Credential: A valid domain account that can query the directory.
SSLCertificatesSasUrl: If used, points to the correct LDAPS certificate(s); otherwise, ensure the certificate that vCenter downloads automatically is valid. Any mismatch here can cause successful SCIM sync but failed interactive sign‑in.

If using Microsoft Entra ID as identity source, confirm vCenter privileges were granted via Run Command For Entra ID federation (vSphere 8.0 U2+), AVS CloudAdmin does not natively have the VcIdentityProviders.Manage privilege. AVS provides a Run Command to grant this:

Ensure Add‑VCenterCloudAdminRoleVcIdentityProvidersManagePrivilege was run on the failing vCenter before configuring the Entra ID identity provider.
If the identity provider was created without this step, remove and re‑add it using the documented Run Commands so that vCenter trusts Entra ID correctly.

Verify group membership and role assignment in vCenter Even with a valid identity source, Access Denied occurs if the user’s group/role mapping differs:

Sign in to vCenter on the failing instance as CloudAdmin.
Navigate to an inventory object (for example, the vCenter root or a datacenter), then Actions → Add Permission.
In Domain, select the external identity source (AD or Entra ID) and search for the same user/group that works on the other vCenter.
Confirm:
- The user is a member of the group configured in GroupName (for LDAPS) or the equivalent Entra group.
- The group is assigned the expected role (for example, CloudAdmin or another vCenter role) and Propagate to children is set as needed.
Compare the Permissions tab on both vCenters to ensure identical domain, group, and role assignments.

Check that the CloudAdmin emergency account is not being used for integration

The built‑in CloudAdmin account is intended only for break‑glass access.
Ensure the external identity integration (LDAPS or Entra ID) is configured using directory accounts/groups, not by trying to extend or reuse CloudAdmin beyond its supported scope.

Re‑run the identity source Run Commands in order If any doubt remains about the configuration sequence on the failing vCenter:

Follow the documented order of Run Commands for identity source setup (certificate export/upload if used, DNS, New‑LDAPSIdentitySource or Entra ID provider commands, then role assignment).
Run them one at a time and confirm each completes successfully.

If, after these checks, SCIM provisioning still works but interactive SSO fails only on one vCenter, focus on:

Differences in DomainAlias and BaseDNUsers/BaseDNGroups between the two vCenters.
Missing or different vCenter role assignments for the same groups.
Entra ID provider not created/managed via the AVS Run Commands on the failing instance.

References:

Share via

Has anyone ran into issues setting up SSO for VMWare vCenter Server.

1 answer

Your answer