Identity: VIDM / Workspace ONE Access → VCF Identity Broker

A companion to the Overview. VCF 9 replaces VMware Identity Manager (VIDM) / Workspace ONE Access with VCF Identity Broker (VIDB) as the fleet identity layer. This is a distinct workstream, not a step in the core upgrade sequence – run it after the core upgrade, in parallel with the Aria → VCF component migration.

Applies whenever VIDM / Workspace ONE Access is present (typically because the Aria / operations stack authenticates through it).

9.0.x source: Identity Broker network transition (before Phase 1)

A different, unrelated prerequisite for fleets already on VCF 9.0.x (where Identity Broker already exists, rather than being freshly deployed from VIDM): if that existing Identity Broker 9.0.x sits on an NSX overlay network, the VCF Operations upgrade (Phase 1) fails outright unless it is first moved to the VCF management network.

• Condition. Only applies if Identity Broker is on an NSX overlay. If it is already on the VCF management network, skip this.
• Procedure. Deploy a new Identity Broker on the management network, reusing the existing certificate and FQDN; re-point DNS to it.
• Impact. Service-disruptive – plan its own maintenance window, separate from the main upgrade window, and do it before Phase 1 starts.

Status: partial. The 9.1.0.0 release notes state “Support for script-based migration of data from VMware Identity Manager to identity broker”, but Broadcom has not published a prominent standalone procedure for it. What is documented is the Access Control group import (below). Treat the “script” as a thing to confirm against the current 9.1 identity guide or a KB before relying on it.

The short version

• No in-place upgrade for VIDM. Identity Broker 9.1 is deployed fresh as part of VCF Management Services (Overview Phase 3). VIDM is not consumed by VCF 9.
• Parallel run. Identity Broker is an additional authentication source alongside VIDM and each component’s native auth. Keep VIDM running until every component that uses it has been re-pointed.
• Users and groups can be brought across. The upstream identity source (AD / LDAP / SAML IdP) itself is unchanged – only the broker layer moves.
• Everything else is rebuilt by hand.

What does NOT carry – rebuild on Identity Broker

• The directory / identity-provider connection (AD / LDAP / OIDC).
• Federation / SAML to the upstream IdP.
• End-user authentication policies and MFA configuration.
• Custom branding.
• Workspace ONE Access-specific flows (for example Aria Automation CCI).
• Role and scope assignments – re-mapped after the user/group import.

Prerequisites

• Identity Broker 9.1 deployed (comes with VCF Management Services).
• The upstream identity source (AD / LDAP / SAML IdP) reachable.
• VIDM still running – it is the import source.
• The account doing the work has ‘All Objects’ scope in VCF Operations (Administration → Control Panel → Access Control → User Accounts / User Groups).
• If the upgrade produced an embedded Identity Broker and an HA cluster is wanted, that is a separate migration – see Do not confuse.

Procedure

1. Configure Identity Broker against the upstream IdP

Re-create the directory / IdP connection on Identity Broker pointing at the same AD / LDAP / SAML IdP that VIDM fronts today. Push the configuration to vCenter and NSX first and test SSO login there before touching the Aria / VCF Automation tier.

2. Import the VIDM user groups

VCF Operations → Administration → Control Panel → Access Control → User Groups tab → the ellipsis next to ADD → Import → source = VMware Identity Manager.

Select the groups (or the header check box for all) → Next → Finish. Groups already imported do not appear in the list. After import, edit each group and assign a role and a scope – imported groups have neither.

Supported import sources on the same dialog: VMware Identity Manager, VMware Single Sign-On, Active Directory, LDAP.

3. Re-point the components

For each component still authenticating through VIDM – vCenter, NSX, VCF Operations, VCF Automation – switch the identity source to Identity Broker, re-map role assignments, and re-test login.

4. ELM break (if applicable)

Deactivate Enhanced Linked Mode once every vCenter in the ring is on 9.1 – the Identity Broker SSO model requires it.

5. Retire VIDM

Once every component logs in through Identity Broker and nothing depends on VIDM, decommission the VIDM appliance(s). Review VIDM-fronted integrations, runbooks, and monitoring hooks for retarget or removal.

Do not confuse: embedded → instance

A separate migration – “Migration of Identity Broker Embedded to Identity Broker Instance” – moves a vCenter-embedded Identity Broker to the three-node HA cluster. It is not the VIDM → VIDB transition. If the upgrade deployed an embedded Identity Broker and HA is wanted, that migration is its own step.

Known issues

Seen on real upgrades – full detail in Field notes → Identity Broker / VCF SSO:

• Encryption-key desync between Identity Broker and the vCenter database (mac check in GCM failed, 401 invalid_client on the token call) – fix is KB 377519 (recover_ws1b.sh + Rotate_WS1B_secrets.sh).
• NTP clock skew on the Identity Broker expires SAML tokens (InvalidTimingException); fix NTP first, but it alone will not clear a key-desync.
• ELM drift after breaking Enhanced Linked Mode – check the SDDC Manager API for drift status and re-run drift remediation; the management vCenter is the one that tends to hold out.

Open items to confirm

• The script-based migration from the 9.1.0.0 release notes: its name, where it runs, whether it does more than the Access Control group import, and whether a clustered VIDM 3.3.x source is supported.
• Whether the directory can be synced (SCIM / JIT provisioning / LDAP sync) rather than imported once.

Sources