When you enable Identity Provider Federation in vCenter Server environments using enhanced linked mode, authentication and workflows continue to work as before.

If you use Enhanced Linked Mode configuration, note the following when logging in to vCenter Server using federated authentication.

  • Users continue to see the same inventory, and can perform the same actions, based on the vCenter Server permissions and roles model.
  • vCenter Server hosts in enhanced linked mode are not required to have access to each other's identity providers. For example, consider two vCenter Server systems A and B, and that use enhanced linked mode. After vCenter Server A authorizes a user, then the user is authorized on vCenter Server B as well.

Enhanced Link Mode and AD FS

The following figure shows the authentication workflow when using AD FS with enhanced linked mode.

Figure 1. Enhanced Linked Mode and AD FS Identity Provider Federation
This figure shows how vCenter Server systems using enhanced linked mode interact with AD FS.
  1. Two vCenter Server nodes are deployed in Enhanced Linked Mode configuration.
  2. The AD FS setup has been configured on vCenter Server A using the Change Identity Provider wizard in the vSphere Client. Group memberships and permissions have also been established for AD FS users or groups.
  3. vCenter Server A replicates the AD FS configuration to vCenter Server B.
  4. All Redirect URIs for both vCenter Server nodes are added to the OAuth Application Group in AD FS. Only one OAuth Application Group is created.
  5. When a user logs into and is authorized by vCenter Server A, the user is also authorized on vCenter Server B. If the user logs in to vCenter Server B first, the same holds true.

Enhanced Linked Mode Configuration Scenarios with AD FS

vCenter Server enhanced linked mode supports the following configuration scenarios for AD FS. In this section, the terms "AD FS settings" and "AD FS configuration" refer to the settings that you configure in the vSphere Client using the Change Identity Provider wizard, and any group memberships or permissions that you have established for AD FS users or groups.

Enable AD FS on an Existing Enhanced Linked Mode Configuration

High-level steps:

  1. Deploy N vCenter Server nodes in Enhanced Linked Mode configuration.
  2. Configure AD FS on one of the linked vCenter Server nodes.
  3. The AD FS configuration is replicated to all other (N-1) vCenter Server nodes.
  4. Add all Redirect URIs for all N vCenter Server nodes to the configured OAuth Application Group in AD FS.

Link a New vCenter Server to an Existing Enhanced Linked Mode AD FS Configuration

High-level steps:

  1. (Prerequisite) Set up AD FS on a vCenter Server N-node Enhanced Linked Mode configuration.
  2. Deploy a new independent vCenter Server node.
  3. Repoint the new vCenter Server to the N-node AD FS enhanced linked mode domain, using one of the N nodes as its replication partner.
  4. All AD FS settings in the existing Enhanced Linked Mode configuration are replicated to the new vCenter Server.

    The AD FS settings that are in the N-node AD FS enhanced linked mode domain overwrite any existing AD FS settings on the newly linked vCenter Server.

  5. Add all Redirect URIs for the new vCenter Server to the existing configured OAuth Application Group in AD FS.

Unlink a vCenter Server from an Enhanced Linked Mode AD FS Configuration

High-level steps:

  1. (Prerequisite) Set up AD FS on an N-node vCenter Server Enhanced Linked Mode configuration.
  2. Unregister one of the vCenter Server hosts in the N-node configuration and repoint it to a new domain to unlink it from the N-node configuration.
  3. The domain repointing process does not preserve SSO settings, so all AD FS settings on the unlinked vCenter Server node are reverted and lost. To continue using AD FS on this vCenter Server unlinked node, you must reconfigure AD FS from the beginning or you must relink the vCenter Server to an Enhanced Linked Mode configuration where AD FS is already set up.

Enhanced Linked Mode and Okta, Microsoft Entra ID, or PingFederate Identity Provider Federation

The following figure shows the authentication workflow when using Okta, Microsoft Entra ID, or PingFederate with enhanced linked mode.

Figure 2. Enhanced Linked Mode and Okta, Microsoft Entra ID, or PingFederate Identity Provider Federation
This figure shows how vCenter Server systems using Enhanced Link Mode interact with Okta, Microsoft Entra ID, or PingFederate.
Note: When configuring Okta, Microsoft Entra ID, or PingFederate as an external identity provider, all the vCenter Server systems in an Enhanced Linked Mode configuration must run at least vSphere 8.0 Update 1 for Okta, vSphere 8.0 Update 2 for Microsoft Entra ID, and vSphere 8.0 Update 3 for PingFederate.
  1. Two vCenter Server nodes are deployed in Enhanced Linked Mode configuration.
  2. The Okta, Microsoft Entra ID, or PingFederate setup has been configured on vCenter Server A using the Change Identity Provider wizard in the vSphere Client. Also, group memberships and permissions have also been established for Okta, Microsoft Entra ID, or PingFederate users or groups.
    Note: Both vCenter Server A and B have VMware Identity Services enabled, but only the VMware Identity Services on vCenter Server A communicate with the identity provider server.
  3. The VMware Identity Services running on vCenter Server A enable vCenter Server B to access its endpoint.
  4. The Redirect URI for vCenter Server A is added to the OAuth Application in Okta, Microsoft Entra ID, or PingFederate. Only one OAuth Application is created.
  5. When a user logs into and is authorized by vCenter Server A, the user is also authorized on vCenter Server B. If the user logs in to vCenter Server B first, the same holds true.

Enhanced Linked Mode Configuration Scenarios with Okta, Microsoft Entra ID, or PingFederate

vCenter Server enhanced linked mode supports the following configuration scenarios for Okta, Microsoft Entra ID, and PingFederate. In this section, the terms "Okta settings" and "Okta configuration," "Microsoft Entra ID settings" and "Microsoft Entra ID configuration," or "PingFederate settings" and "PingFederate configuration," refer to the settings that you configure in the vSphere Client using the Change Identity Provider wizard, and any group memberships or permissions that you have established for Okta, Microsoft Entra ID, or PingFederate users or groups.

Enable Okta, Microsoft Entra ID, or PingFederate on an Existing Enhanced Linked Mode Configuration

High-level steps:

  1. Deploy N vCenter Server nodes in Enhanced Linked Mode configuration.
  2. Configure Okta, Microsoft Entra ID, or PingFederate on one of the linked vCenter Server nodes.
  3. The VMware Identity Services endpoint information is replicated to all other (N-1) vCenter Server nodes.

    The Okta, Microsoft Entra ID, or PingFederate configuration (shared client ID, and so on) information and user/group information is not replicated.

Link a New vCenter Server to an Existing Enhanced Linked Mode Okta, Microsoft Entra ID, or PingFederate Configuration

High-level steps:

  1. (Prerequisite) Set up Okta, Microsoft Entra ID, or PingFederate on a vCenter Server N-node Enhanced Linked Mode configuration.
  2. Deploy a new independent vCenter Server node.
  3. Repoint the new vCenter Server to the N-node Okta, Microsoft Entra ID, or PingFederate enhanced linked mode domain, using one of the N nodes as its replication partner.
  4. The VMware Identity Services endpoint information is replicated to all other (N-1) vCenter Server nodes.

    The Okta, Microsoft Entra ID, or PingFederate configuration (shared client ID, and so on) information and user/group information is not replicated.

Note: You can add a vCenter Server node with an existing VMware Identity Services configuration. In this scenario, the existing VMware Identity Services configuration is replaced with the VMware Identity Services Enhanced Link Mode configuration that it is joining.

You cannot add a vCenter Server node with an existing VMware Identity Services configuration to an ELM configuration that has not been configured with VMware Identity Services. In this scenario, first remove the existing VMware Identity Services configuration from the vCenter Server before adding it to the ELM configuration.

Unlink a vCenter Server from an Enhanced Linked Mode Okta, Microsoft Entra ID, or PingFederate Configuration

High-level steps:

  1. (Prerequisite) Set up Okta, Microsoft Entra ID, or PingFederate on an N-node vCenter Server Enhanced Linked Mode configuration.
  2. Unregister one of the vCenter Server hosts in the N-node configuration and repoint it to a new domain to unlink it from the N-node configuration.
  3. The domain repointing process does not preserve SSO settings, so all Okta, Microsoft Entra ID, or PingFederate settings on the unlinked vCenter Server node are reverted and lost. To continue using Okta, Microsoft Entra ID, or PingFederate on this vCenter Server unlinked node, you must reconfigure Okta, Microsoft Entra ID, or PingFederate from the beginning or you must relink the vCenter Server to an Enhanced Linked Mode configuration where Okta, Microsoft Entra ID, or PingFederate is already set up.
Note: You cannot unlink a vCenter Server with an active VMware Identity Services configuration.