Use SSO to provide a common service, both internally and externally.

Use a supported IdP from VMware.

The SAML assertion must contain attributes that vCloud Director can interpret.

vCloud Director and the IdP must be time synchronized to within a few seconds.

vCloud Director and the IdP must have valid endpoint certificates.

Use consistent hostname (or IP address) when registering with the LookupService.

If the SSO Server is not accessible and the accessibility issue cannot be resolved, use the SSO repoint tools that are that are packaged with SSO clients such as vCenter and the Web client.

Consider the following identity sources: OpenAM, Active Directory Federation Services, Shibboleth.

Provide a highly available SSO service.

Deploying vCenter Single Sign-On as a cluster means that two or more instances of vCenter Single Sign-On are installed in high availability (HA) mode. vCenter Single Sign-On HA mode is not the same as vSphere HA. All instances of vCenter Single Sign-On use the same database and must point to the same identity sources. vCenter Single Sign-On administrator users, when connected to vCenter Server through the VMware vSphere Web Client, see the primary SSO instance. In this deployment scenario, the installation process grants admin@System-Domain vCenter Server privileges by default, and the installation process creates the user admin@System-Domain to manage vCenter Single Sign-On.

ESXi 5.1 is not integrated with vCenter Single Sign-On, and you cannot create ESXi users with the vSphere Web Client. You must create and manage ESXi users with the vSphere Client. vCenter Server is not aware of users that are local to ESXi, and ESXi is not aware of vCenter Server users. However, you can configure vCenter Single Sign-On to use an Active Directory domain as an identity source, and configure ESXi to point to the same Active Directory domain to obtain user and group information.