vCenter Server Identity Provider Federation

In vSphere 7.0 and later, vCenter Server supports federated authentication to sign in to vCenter Server.

To enable federated authentication to vCenter Server, you configure a connection to an external identity provider. The identity provider instance that you configure replaces vCenter Server as the identity provider. Currently, vCenter Server supports Active Directory Federation Services (AD FS), Okta, Microsoft Entra ID (formerly called Azure AD), and PingFederate as external identity providers. vCenter Server supports AD FS in vSphere 7.0 and later, Okta in vSphere 8.0 Update 1 and later, Microsoft Entra ID in vSphere 8.0 Update 2 and later, and PingFederate starting in vSphere 8.0 Update 3.

Note: VMware encourages you to use federated authentication as vSphere moves towards token-based authentication. vCenter Server continues to have local accounts, for administrative access and error recovery.

How vCenter Server Identity Provider Federation Works

vCenter Server Identity Provider Federation enables you to configure an external identity provider for federated authentication. In this configuration, the external identity provider interacts with the identity source on behalf of vCenter Server.

vCenter Server Identity Provider Federation Basics

In vSphere 7.0 and later, vCenter Server supports federated authentication. In this scenario, when a user logs in to vCenter Server, vCenter Server redirects the user login to the external identity provider. The user credentials are no longer provided to vCenter Server directly. Instead, the user provides credentials to the external identity provider. vCenter Server trusts the external identity provider to perform the authentication. In the federation model, users never provide credentials directly to any service or application but only to the identity provider. As a result, you "federate" your applications and services, such as vCenter Server, with your identity provider.

vCenter Server External Identity Provider Support

vCenter Server supports the following external identity providers:

• AD FS (vSphere 7.0 and later)
• Okta (vSphere 8.0 Update 1 and later)
• Microsoft Entra ID, formerly called Azure AD (vSphere 8.0 Update 2 and later)
• PingFederate (starting in vSphere 8.0 Update 3)

vCenter Server Identity Provider Federation Benefits

vCenter Server Identity Provider Federation provides the following benefits.

• You can use Single Sign-On with existing federated infrastructure and applications.
• You can improve data center security because vCenter Server never handles the user’s credentials.
• You can use the authentication mechanisms, such as multi-factor authentication, supported by the external identity provider.

vCenter Server Identity Provider Federation Architecture

To establish a relying party trust between vCenter Server and an external identity provider, you must establish the identifying information and a shared secret between them. vCenter Server uses the OpenID Connect (OIDC) protocol to receive an identity token that authenticates the user with vCenter Server.

The high-level steps to configure an external identity provider with vCenter Server include:

1. Establishing a relying party trust between vCenter Server and the external identity provider by creating an OIDC configuration. For AD FS, you create an Application Group, or Application. For Okta, Microsoft Entra ID, and PingFederate, you create a native application with OpenID Connect as the sign-on method. The OIDC configuration consists of a Server application and a Web API. The two components specify the information that vCenter Server uses to trust and communicate with the external identity provider.
2. Creating a corresponding identity provider in vCenter Server.
3. Configuring group memberships in vCenter Server to authorize logins from users in the external identity provider domain.

The identity provider administrator must provide the following information to create the vCenter Server identity provider configuration:

• Client Identifier: The UUID string that is generated in AD FS when you create the Application Group (or Application) and that identifies the Application Group (or Application), or that is generated in Okta, Microsoft Entra ID, or PingFederate when you create the OpenID Connect application.
• Shared Secret: The secret that is generated in AD FS when you create the Application Group (or Application), or that is generated in Okta, Microsoft Entra ID, or PingFederate when you create the OpenID Connect application, and that is used to authenticate vCenter Server with the external identity provider.
• OpenID Address: The OpenID Provider Discovery endpoint URL of the external identity provider server, specifying a well-known address that is typically the issuer endpoint concatenated with the path /.well-known/openid-configuration. Here is an example OpenID address for an AD FS configuration:

  https://webserver.example.com/adfs/.well-known/openid-configuration

  Likewise, here is an example OpenID address for an Okta configuration:

  https://example.okta.com/oauth2/default/.well-known/openid-configuration

  Here is an example OpenID address for a Microsoft Entra ID configuration:

  https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/v2.0/.well-known/openid-configuration

  Here is an example OpenID address for a PingFederate configuration:

  https://pingfederate-fqdn-and-port/.well-known/openid-configuration

VMware Identity Services and Federated Authentication

In vSphere 8.0 Update 1 and later, VMware Identity Services provides integration with external identity providers as a federated identity provider. You can think of the VMware Identity Services as a "slimmed" down version of VMware Workspace ONE that is built-in to vSphere.

When you either install or upgrade to vSphere 8.0 Update 1 or later, VMware Identity Services are activated by default on vCenter Server. When you configure Okta, Microsoft Entra ID, or PingFederate as an external identity provider, vCenter Server uses VMware Identity Services to communicate with your Okta, Microsoft Entra ID, or PingFederate server.

vCenter Server supports Okta, Microsoft Entra ID, and PingFederate as an external identity provider in an Enhanced Linked Mode configuration. Even though, in an Enhanced Linked Mode configuration, multiple vCenter Server systems are running VMware Identity Services, only a single vCenter Server and, its VMware Identity Services communicate with your external identity provider server. For example, if you have an Enhanced Linked Mode configuration of three vCenter Server systems, A, B, and C, and you configure the Okta external identity provider on vCenter Server A, vCenter Server A is the only system to handle all the Okta logins. vCenter Server B and vCenter Server C do not directly communicate with the Okta server. To configure VMware Identity Services on other vCenter Server in the ELM configuration to interact with your external IDP server, see Activation Process for External Identity Providers in Enhanced Linked Mode Configurations.

Note: When configuring Okta 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 Microsoft Entra ID, the requirement is at least vSphere 8.0 Update 2. For PingFederate the requirement is at least vSphere 8.0 Update 3.

Warning: When using an Enhanced Linked Mode configuration with Okta, Microsoft Entra ID, or PingFederate, you cannot remove the vCenter Server that runs the VMware Identity Services and that communicates with the identity provider from the ELM configuration.

VMware Identity Services Authentication Process

When you configure vCenter Server to use VMware Identity Services to communicate with your external identity provider, the following authentication process occurs:

1. A user logs in to vCenter Server with the vSphere Client.
2. vCenter Single Sign-On delegates the user authentication and redirects the user request to VMware Identity Services.
3. The VMware Identity Services process requests a token from the external identity provider to establish the user session.
4. The external identity provider authenticates the user (it can use Multifactor Authentication (MFA) or SSO credentials) and returns the token to VMware Identity Services.

   The token contains the user claims.

5. The VMware Identity Services process validates the identity provider token, generates a corresponding VMware Identity Services token, and sends the VMware Identity Services token to vCenter Single Sign-On.
6. vCenter Single Sign-On validates the token and grants the login request.

Note: AD FS does not use VMware Identity Services for federated authentication.

How vCenter Server Interacts with Users and Groups Pushed by SCIM

When you configure your external identity provider, vCenter Server uses System for Cross-domain Identity Management (SCIM) for user and group management. SCIM is an open standard for automating the exchange of user identity information. A SCIM application that you create on your external IDP server manages the users and groups on external identity provider that you want to push to vCenter Server. vCenter Server also uses SCIM when searching for users and groups to assign permissions to vCenter Server objects.

Note: An AD FS configuration searches the Active Directory by using LDAP. It does not use SCIM.

vCenter Server Identity Provider Federation Components

The following components comprise a vCenter Server Identity Provider Federation configuration:

• A vCenter Server
  • For AD FS: vCenter Server 7.0 or later
  • For Okta: vCenter Server 8.0 Update 1 or later
  • For Microsoft Entra ID: vCenter Server 8.0 Update 2 or later
  • For PingFederate: vCenter Server 8.0 Update 3
• An identity provider service configured on the vCenter Server
• An external identity provider (AD FS, Okta, Microsoft Entra ID, or PingFederate)
• An OpenID Connect (OIDC) configuration:
  • For AD FS: An Application Group (also called an Application)
  • For Okta, Microsoft Entra ID, or PingFederate: An OpenID Connect application
• A System for Cross-domain Identity Management (SCIM) application for user and group management (only for Okta, Microsoft Entra ID, or PingFederate)
• External identity provider groups and users that you map to vCenter Server groups and users
• VMware Identity Services enabled on vCenter Server (only for Okta, Microsoft Entra ID, or PingFederate)
• Optionally, for PingFederate, the SSL certificate, or certificate chain, of the PingFederate server, if this certificate was not issued by a well-known, public Certificate Authority. You import the PingFederate SSL certificate to the vCenter Server.

vCenter Server Identity Provider Federation Caveats and Interoperability

vCenter Server Identity Provider Federation can interoperate with many other VMware features.

As you are planning your vCenter Server Identity Provider Federation strategy, consider possible interoperability limitations.

Authentication Mechanisms

In a vCenter Server Identity Provider Federation configuration, the external identity provider handles the authentication mechanisms (passwords, MFA, biometrics, and so on).

AD FS and Support for a Single Active Directory Domain

When you configure vCenter Server Identity Provider Federation for AD FS, the Configure Main Identity Provider wizard prompts you to enter LDAP information for the single AD domain that contains the users and groups you want to access vCenter Server. vCenter Server derives the AD domain to use for authorization and permissions from the User Base DN that you specify in the wizard. You can add permissions on vSphere objects only for users and groups from this AD domain. Users or groups from AD child domains or other domains in the AD forest are not supported by vCenter Server Identity Provider Federation.

Okta, Microsoft Entra ID, and PingFederate Support for Multiple Domains

When you configure vCenter Server Identity Provider Federation for Okta, Microsoft Entra ID, or PingFederate, the Configure Main Identity Provider wizard enables you to enter LDAP information for the multiple domains that contain the users and groups you want to access vCenter Server.

Password, Lockout, and Token Policies

When vCenter Server acts as the identity provider, you control vCenter Server password, lockout, and token policies for the default domain (vsphere.local, or the domain name you entered when installing vSphere). When using federated authentication with vCenter Server, the external identity provider controls the password, lockout, and token policies for the accounts stored in the identity source such as Active Directory.

Auditing and Compliance

When using vCenter Server Identity Provider Federation, vCenter Server continues to create log entries for successful user logins. However, the external identity provider is responsible for tracking and logging actions such as failed password-entry attempts and user account lockouts. vCenter Server does not log such events because they are no longer visible to vCenter Server. For example, when AD FS is the identity provider, AD FS tracks and logs errors for federated logins. When vCenter Server is the identify provider for local logins, vCenter Server tracks and logs errors for local logins. In a federated configuration, vCenter Server does continue to log user actions post-login.

Existing VMware Product Integration with External Identity Providers

VMware products that are integrated with vCenter Server (for example, VMware Aria Operations, vSAN, NSX, and so on) continue to work as before.

Products That Integrate Post-Login

Products that integrate post-login (that is, they do not require a separate login) continue to work as before.

Simple Authentication for API, SDK, and CLI Access

Existing scripts, products, and other functionality that rely on API, SDK, or CLI commands that use Simple Authentication (that is, user name and password) continue to work as before. Internally, the authentication occurs by passing the user name and password. This passing of the user name and password compromises some of the benefits of using identity federation, because it exposes the password to vCenter Server (and your scripts). Consider migrating to token-based authentication where possible.

Accessing the vCenter Server Management Interface

If the user is a member of the vCenter Server Administrators group, accessing the vCenter Server Management Interface (formerly called vCenter Server Appliance Management Interface or VAMI) is supported.

Entering User Name Text on the AD FS Login Page

The AD FS login page does not support passing text to pre-populate the user name text box. As a result, during federated logins with AD FS, after entering your user name on the vCenter Server landing page and redirecting to the AD FS login page, you must reenter your user name on the AD FS login page. The user name that you enter on the vCenter Server landing page is necessary to redirect the login to the appropriate identity provider, and the user name on the AD FS login page is necessary to authenticate with AD FS. This inability to pass the user name to the AD FS login page is a limitation of AD FS. You cannot configure or change this behavior directly from vCenter Server.

Support for IPv6 Addresses

AD FS, Microsoft Entra ID, and Ping Federate support IPv6 addresses. Okta does not support IPv6 addresses.

VMware Identity Services Single Instance Configuration

By default, when you either install or upgrade to vSphere 8.0 Update 1 or later, VMware Identity Services are enabled on vCenter Server. When you configure Okta, Microsoft Entra ID, or PingFederate in an Enhanced Link Mode configuration, you use VMware Identity Services on a single vCenter Server system. For example, if you use Okta in an Enhanced Mode Link configuration that consists of three vCenter Server systems, only one vCenter Server its instance of VMware Identity Services is used to communicate with the Okta server.

Warning:

In an ELM configuration that uses VMware Identity Services, if the vCenter Server system that communicates with the external identity provider becomes unavailable, you can configure VMware Identity Services on other vCenter Server in the ELM configuration to interact with your external IDP server. See Activation Process for External Identity Providers in Enhanced Linked Mode Configurations.

Reconfiguring the Primary Network Identifier

Reconfiguring the Primary Network Identifier (PNID) of the vCenter Server requires that you update the external identity provider configuration as follows.

• AD FS: Add the new Redirect URIs to the AD FS server.
• Okta: Reconfigure Okta. See Configure vCenter Server Identity Provider Federation for Okta and follow the steps to create the identity provider on vCenter Server.
• Microsoft Entra ID: Reconfigure Entra ID. See Configure vCenter Server Identity Provider Federation for Microsoft Entra ID and follow the steps to create the identity provider on vCenter Server.
• PingFederate: Reconfigure PingFederate. See Configure vCenter Server Identity Provider Federation for PingFederate and follow the steps to create the identity provider on vCenter Server.

vCenter Server Identity Provider Federation Life Cycle

When managing the life cycle of vCenter Server Identity Provider Federation, there are some specific considerations.

You can manage your vCenter Server Identity Provider Federation life cycle in the following ways.

Migrating from Using Active Directory to an External Identity Provider

If you are using Active Directory as your identity source for vCenter Server, migrating to using an external identity provider is straight forward. If your Active Directory groups and roles match your identity provider groups and roles, you do not need to take any additional action. When the groups and roles do not match, then you must perform some additional work. If vCenter Server is a domain member, consider removing it from the domain as it is not needed or used for identity federation.

Cross-Domain Repointing and Migration

vCenter Server Identity Provider Federation supports cross-domain repointing, that is, moving a vCenter Server from one vSphere SSO domain to another. The repointed vCenter Server receives the replicated identity provider configuration from the vCenter Server system, or systems, to which it was pointed.

In general, you do not need to perform any additional identity provider reconfiguration for a cross-domain repoint, unless one of the following is true.

1. The identity provider configuration of the repointed vCenter Server differs from the identity provider configuration of the vCenter Server to which it was pointed.
2. This is the first time the repointed vCenter Server is receiving an identity provider configuration.

In these cases, some additional work is required. For example, for AD FS, you must add the vCenter Server system's Redirect URIs to the corresponding Application Group on the AD FS server. For example, if vCenter Server 1 with AD FS Application Group A (or no AD FS configuration) is repointed to vCenter Server 2 with AD FS Application Group B, you must add the Redirect URIs of vCenter Server 1 to Application Group B.

Users and Group Synchronization and vCenter Server Backup and Restore

Depending on when you synchronize your users and groups with vCenter Server and when you back up your vCenter Server, if you must restore your vCenter Server, you might need to re-synchronize your users and groups that were pushed by SCIM.

To restore a deleted user or group, you cannot simply push the user or group from the external identity provider to vCenter Server. You must update the SCIM 2.0 application on the external identity provider with the missing user or group. See Restore Deleted SCIM Users and Groups.