Skip to content

VMware — Identity & SCIM

Admin access to vCenter itself, gated by the same AD security group used everywhere else in the lab, plus the Entra ID integration that makes OIDC login actually resolve to a real vCenter principal. See Overview for how VCSA itself gets deployed and its other post-deploy automation (SSL, license, SSH trust), On-Prem Active Directory for how app-vcenter-admins itself is created and synced, and My Apps for the vCenter tile's own launch-URL fix.

Admin access via app-vcenter-admins — two coexisting paths

Both grant the same on-prem AD group Administrator at the vCenter root, just via different principal name formats vCenter expects per identity path — terraform/vsphere/base/vcenter-ad-permissions.tf:

Path Principal format Depends on Tradeoff
Classic Active Directory over LDAP identity source ad.devhome.cloud\app-vcenter-admins The shared LDAP bind account Real live LDAP bind/search — needs the DC reachable at login time, unlike OIDC's Password Hash Sync independence
Entra ID OIDC federation app-vcenter-admins@devhome.cloud SCIM provisioning, below No DC dependency at login time, but needs every user (and the group) already SCIM-provisioned first

administrator@vsphere.local remains the DC/Entra-independent break-glass path regardless of which of the above is in use.

The LDAP identity source itself is a one-time manual step

The PowerCLI SDK modules installed in this environment only support OIDC/OAuth2 identity provider federation (confirmed via Initialize-IdentityProvidersCreateSpec's ConfigTag ValidateSet, which only allows "Oauth2"/"Oidc") — the community VMware.vSphere.SsoAdmin module that supports classic identity sources isn't installed/vetted here. Add it via Administration → Single Sign-On → Configuration → Identity Sources → Add → "Active Directory over LDAP", domain ad.devhome.cloud, base DN DC=ad,DC=devhome,DC=cloud for both users and groups, server URL ldap://dc.ad.devhome.cloud:389, bind credentials from devhome/ldap-bind-account in Vault.

Entra ID integration via SCIM

This vCenter version does no JIT (just-in-time) user creation on OIDC login — a login fails with USER_NOT_FOUND unless the user (and the group used for permission assignment) already exist in vCenter's own usergroup store, matched by externalId = the real Entra object ID. Entra ID P1 would push this automatically via its provisioning agent; without it (this tenant is Free tier throughout), scripts/vcenter_scim_provision.py is the scripted substitute:

  1. Gets a Graph token via client-credentials grant (the same Graph management app terraform/azure uses).
  2. Reads the AD-synced group's current membership straight from Graph.
  3. For each member missing from vCenter's SCIM store (matched by externalId, idempotent), creates a SCIM User resource.
  4. Replaces the SCIM Group's member list to match Entra membership exactly, every run.
SCIM_BASE = f"https://{VCENTER_HOST}/usergroup/t/{SCIM_TENANT_SEGMENT}/scim/v2"

No API to generate the SCIM secret token — stays manual, ~18 months

The Secret Token on Administration → Single Sign-On → Configuration → Identity Provider → Microsoft Entra ID → User Provisioning → Generate has no Terraform-automatable path — the ServiceProviderConfig/Schemas SCIM discovery endpoints both 404 on this vCenter version, so there was no way to script its creation. It's long-lived per the token's own JWT exp claim, but a VCSA rebuild wipes the Identity Provider config entirely and needs a fresh one regardless — one manual step per rebuild, not per apply.

See Overview for Machine SSL certificate automation and the rest of VCSA's post-deploy rebuild automation (SSH key trust, root password policy, license) — that's deployment/lifecycle concern, kept alongside make deploy-vcsa rather than here with the identity/SCIM setup.