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).
Support for a Single Active Directory Domain
When you configure vCenter Server Identity Provider Federation, the Configure Main Identity Provider wizard prompts you to enter LDAP information for the 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.
vCenter Server Policies
When vCenter Server acts as the identity provider, you control vCenter Server password, lockout, and token policies for the vsphere.local domain. 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
VMware products integrated with vCenter Server (for example, vROps, 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, 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.
vCenter Server Management Interface
If the user is a member of the 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.
