vCenter Server Identity Provider Federation Configuration Process Flow

To configure vCenter Server Identity Provider Federation effectively, you must understand the communication flows that take place.

You can configure vCenter Server Identity Provider Federation for AD FS, Microsoft Entra ID (formerly called Azure AD), Okta, or PingFederate.

vCenter Server Identity Provider Federation Configuration Process Flow for AD FS

The following figure shows the process flow that occurs when configuring vCenter Server Identity Provider Federation for AD FS.

Figure 1. vCenter Server Identity Provider Federation Configuration Process Flow for AD FS

vCenter Server, AD FS, and Active Directory interact as follows.

1. The AD FS administrator configures an AD FS OIDC Application for vCenter Server.
2. The vCenter Server administrator logs in to the vCenter Server using the vSphere Client.
3. The vCenter Server administrator adds an AD FS identity provider to vCenter Server, and also enters information about the Active Directory domain.

   vCenter Server needs this information to make an LDAP connection to the Active Directory domain of the AD FS server. Using this connection, vCenter Server searches for users and groups, and adds them to vCenter Server local groups in the next step. See the section titled "Searching the Active Directory Domain" that follows for more information.

4. The vCenter Server administrator configures authorization permissions in vCenter Server for AD FS users.
5. The AD FS Provider queries the VcIdentityProviders API to get the LDAP connection information for the Active Directory source.
6. The AD FS Provider searches Active Directory for the queried users or groups to finish the Authorization configuration.

Searching the Active Directory Domain

You configure AD FS as the external identity provider in vCenter Server by using the Configure Main Identity Provider wizard in the vSphere Client. As part of the configuration process, you must enter information about your Active Directory domain, including user and group distinguished name information. Configuration of AD FS for authentication requires this Active Directory connection information. This connection is necessary to search for and map Active Directory user names and groups to roles and permissions in vCenter Server, whereas AD FS is used for the authentication of the user. This step of the Configure Main Identity Provider wizard does not create an Active Directory Over LDAP identity source. Rather, vCenter Server uses this information to establish a valid search-capable connection to your Active Directory domain to find users and groups there.

Consider an example using the following distinguished name entries:

• Base distinguished name for users: cn=Users,dc=corp,dc=local
• Base distinguished name for groups: dc=corp,dc=local
• User name: cn=Administrator,cn=Users,dc=corp,dc=local

If the [email protected] user is a member of the [email protected] group, entering this information in the wizard allows a vCenter Server administrator to search for and find the [email protected] group and add it to the vCenter Server [email protected] group. As a result, the [email protected] user is granted administrative privileges in vCenter Server upon logging in.

vCenter Server also uses this search process when you configure global permissions for Active Directory users and groups. In both cases, either configuring global permissions, or adding a user or group, you select the domain you entered for your AD FS identify provider from the Domain drop-down menu to search for and select users and groups from your Active Directory domain.

vCenter Server Identity Provider Federation Configuration Process Flow Using VMware Identity Services

To configure Okta, Microsoft Entra ID, and PingFederate, you use VMware Identity Services. The following figure shows the process flow that occurs when configuring vCenter Server Identity Provider Federation using VMware Identity Services.

Figure 2. vCenter Server Identity Provider Federation Configuration Process Flow using VMware Identity Services

vCenter Server, VMware Identity Services, and Active Directory interact as follows.

1. The external IDP administrator configures an OIDC Application for vCenter Server.
2. The vCenter Server administrator logs in to the vCenter Server using the vSphere Client, adds an identity provider to vCenter Server, and also enters domain information.
3. The vCenter Server administrator gives the Redirect URI (obtained from the identity provider configuration page in the vSphere Client) to the identity provider administrator to add to the OIDC Application created in step 2.
4. The external IDP administrator configures a SCIM 2.0 Application.
5. The external IDP administrator assigns the users and groups to the SCIM 2.0 Application, and pushes users and groups to vCenter Server.
6. The vCenter Server administrator configures authorization permissions in vCenter Server for external IDP users.

External IDP Users and Groups

Because an external identity provider uses System for Cross-domain Identity Management (SCIM) for users and groups, those users and groups reside in your vCenter Server. When you search for users and groups in your external identity provider, for example, to assign permissions, the search happens locally on the vCenter Server.

vCenter Server also uses this search process when you configure global permissions for external IDP users and groups. In both cases, either configuring global permissions, or adding a user or group, you select the domain you entered for your identity provider from the Domain drop-down menu to search for and select users and groups from your domain.