vSphere 5.1 introduces the vCenter Single Sign On service as part of the vCenter Server management infrastructure. This change affects vCenter Server installation, upgrading, and operation.

Authentication by vCenter Single Sign-On makes the VMware cloud infrastructure platform more secure by allowing the vSphere software components to communicate with each other through a secure token exchange mechanism, instead of requiring each component to authenticate a user separately with a directory service like Active Directory.

For information about configuring vCenter Single Sign On, see vSphere Security.

In vSphere versions before vSphere 5.1, vCenter Server was installed in a single operation that also silently installed the Inventory Service on the same host machine.

For small vSphere deployments, vCenter Server 5.1 provides a vCenter Server Simple Install option that installs vCenter Single Sign-On, Inventory Service, and vCenter Server on the same host or virtual machine.

Alternatively, to customize the location and setup of each component, you can install the components separately by selecting the individual installation options, in the following order: vCenter Single Sign-On, Inventory Service, and vCenter Server. Each component can be installed in a different host or virtual machine.

For the first installation of vCenter Server with vCenter Single Sign-On, you must install all three components, Single Sign-On Server, Inventory Service, and vCenter Server, in the vSphere environment. In subsequent installations of vCenter Server in your environment, you do not need to install Single Sign-On. One Single Sign-On server can serve your entire vSphere environment. After you install vCenter Single Sign-On once, you can connect all new vCenter Server instances to the same authentication server. However, you must install a Inventory Service instance for each vCenter Server instance.

When you upgrade to vCenter Server 5.1, the upgrade process installs vCenter Single Sign-On first and then upgrades vCenter Server.

In upgrades to vCenter Server versions earlier than vCenter Server 5.1, both the local operating system users and Active Directory users that are registered with vCenter Server before the upgrade continue to work with the upgraded vCenter Server. This behavior changes in vCenter Server 5.1.

In vCenter Server 5.1, if vCenter Single Sign-On is running on a virtual machine or physical machine that is joined to an Active Directory domain, Single Sign-On will automatically discover the existing Active Directory domain and add it as an identity source during the Single Sign-On installation process. If Single Sign-On is not running on a virtual machine or physical machine that is in the same domain as Active Directory, you must use the vSphere Web Client to log in to vCenter Server and add the Active Directory domain to Single Sign-On.

If you install vCenter Single Sign-On and vCenter Server on the same physical machine or virtual machine, Single Sign-On recognizes existing local operating system users. After the upgrade, you can log in to vCenter Server with a registered local operating system user ID.

If you install vCenter Single Sign-On and vCenter Server on different hosts or virtual machines, the former local operating system users who managed login access to vCenter Server are not available to Single Sign-On.

When you install vCenter Single Sign-On in multisite mode or clustered high availability mode, all pre-upgrade permissions for local operating system users are lost. In vCenter Server 5.1, the term "local operating system users" refers to those local users in the Single Sign-On host machine instead of the vCenter Server host machine or virtual machine.

After the upgrade, if no super administrator remains (the administrative user or group for the root folder), you must provide a valid user or group to be used as super administrator during installation. This situation can occur due to changes in user stores from pre-5.1 to 5.1 versions of vSphere.