vCenter Single Sign-On allows vSphere components to communicate with each other through a secure token mechanism.

vCenter Single Sign-On uses the following services.
  • Authentication of users through either external identity provider federation or the vCenter Server built-in identity provider. The built-in identity provider supports local accounts, Active Directory or OpenLDAP, Integrated Windows Authentication (IWA), and miscellaneous authentication mechanisms (smart card and RSA SecurID).
  • Authentication of solution users through certificates.
  • Security Token Service (STS).
  • SSL for secure traffic.

vCenter Server Built-in Identity Provider

vCenter Server includes a built-in identity provider. By default, vCenter Server uses the vsphere.local domain as the identity source (but you can change the domain during installation). You can configure the vCenter Server built-in identity provider to use Active Directory (AD) as its identity source using LDAP/S, OpenLDAP/S, or Integrated Windows Authentication (IWA). Such configurations allow customers to log in to vCenter Server using their AD accounts.

vCenter Server and an External Identity Provider

In vSphere 7.0 and later, you can configure vCenter Server for an external identity provider using federated authentication. In such a configuration, you replace vCenter Server as the identity provider.

vSphere supports the following identity providers.

  • vSphere 7.0 and later: Active Directory Federation Services (AD FS)
  • vSphere 8.0 Update 1 and later: Okta
  • vSphere 8.0 Update 2 and later: Microsoft Entra ID (formerly called Azure AD)
  • Starting in vSphere 8.0 Update 3: PingFederate

When you configure vSphere to use an external identity provider, the external identity provider interacts with the identity sources on behalf of vCenter Server.

User Login with vCenter Server Identity Provider Federated Authentication

When you use an external identity provider to authenticate with vCenter Server, vCenter Server redirects the login request to the external identity provider. The external identity provider authenticates the user with its directory service then issues a token for vCenter Server to use to log in the user.

For example, the following figure shows a detailed look at the user login flow for vCenter Server Identity Provider Federation using AD FS.

Figure 1. vCenter Server User Login Using AD FS Identity Provider Federation

This figure shows the process flow of a user logging in to vCenter Server with AD FS Identity Provider Federation.

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

  1. The user starts on the vCenter Server landing page by entering a user name.
  2. If the user name is for a federated domain, vCenter Server redirects the authentication request to AD FS.
  3. If needed, AD FS prompts the user to log in with Active Directory credentials.
  4. AD FS authenticates the user with Active Directory.
  5. AD FS issues a security token with group information from Active Directory.
  6. vCenter Server uses the token to log in the user.
The user is now authenticated, and can view and modify any objects that the user's role has privileges for.
Note: Initially, each user is assigned the No Access role. A vCenter Server administrator must assign the user at least to the Read Only role before the user can log in. See the vSphere Security documentation.

In case the external identity provider is unreachable, the login process falls back to the vCenter Server landing page, showing an appropriate information message. Users can still log in using their local accounts in the vsphere.local identity source.

The interaction between vCenter Server and Okta, Microsoft Entra ID, or PingFederate is similar to that of AD FS, with the exception that vCenter Server uses VMware Identity Services. See VMware Identity Services Authentication Process.

User Login with the vCenter Server Built-In Identity Provider

The following figure shows the user login flow when vCenter Server acts as the identity provider.

Figure 2. User Login with the vCenter Server Built-In Identity Provider
When the user logs in to the vSphere Client, the Single Sign-On server establishes the authentication handshake.
  1. A user logs in to the vSphere Client with a user name and password to access the vCenter Server system or another vCenter service.
  2. The vSphere Client passes the login information to the vCenter Single Sign-On service, which checks the SAML token of the vSphere Client. If the vSphere Client has a valid token, vCenter Single Sign-On then checks whether the user is in the configured identity source (for example, Active Directory).
    • If only the user name is used, vCenter Single Sign-On checks in the default domain.
    • If a domain name is included with the user name (DOMAIN\user1 or user1@DOMAIN), vCenter Single Sign-On checks that domain.
  3. If the user can authenticate to the identity source, vCenter Single Sign-On returns a token that represents the user to the vSphere Client.
  4. The vSphere Client passes the token to the vCenter Server system.
  5. vCenter Server checks with the vCenter Single Sign-On server that the token is valid and not expired.
  6. The vCenter Single Sign-On server returns the token to the vCenter Server system, using the vCenter Server Authorization Framework to allow user access.
The user is now authenticated, and can view and modify any objects that the user's role has privileges for.
Note: Initially, each user is assigned the No Access role. A vCenter Server administrator must assign the user at least to the Read Only role before the user can log in. See the vSphere Security documentation.

Login for Solution Users

Solution users are sets of services that are used in the vCenter Server infrastructure, for example, vCenter Server extensions. VMware extensions and potentially third-party extensions might also authenticate to vCenter Single Sign-On.

Note: vCenter Server uses solution user certificates for internal communication only. Solution user certificates are not used for external communication.

The following figure shows the login flow for solution users.

Figure 3. Login for Solution Users
The handshake between a solution user, vCenter Single Sign-On, and other vCenter components follows the steps in the following text.
  1. The solution user attempts to connect to a vCenter Server service.
  2. The solution user is redirected to vCenter Single Sign-On. If the solution user is new to vCenter Single Sign-On, it has to present a valid certificate.
  3. If the certificate is valid, vCenter Single Sign-On assigns a SAML token (bearer token) to the solution user. The token is signed by vCenter Single Sign-On.
  4. The solution user is then redirected to vCenter Single Sign-On and can perform tasks based on its permissions.

    The next time the solution user has to authenticate, it can use the SAML token to log in to vCenter Server.

By default, this handshake is automatic because VMCA provisions solution users with certificates during startup. If your company policy requires third-party CA-signed certificates, you can replace the solution user certificates with third-party CA-signed certificates. If those certificates are valid, vCenter Single Sign-On assigns a SAML token to the solution user. See Replace Solution User Certificates with Custom Certificates Using the Certificate Manager.

Supported Encryption in vSphere

AES encryption, which is the highest level of encryption, is supported. The supported encryption affects security when vCenter Single Sign-On uses Active Directory as an identity source.

It also affects security anytime an ESXi host or vCenter Server is joined to Active Directory.