Now you understand what vCenter Single Sign-On (SSO) provides, as you start to design or upgrade to your vSphere 5.1 environment, particular attention needs to be given in the planning stages around the placement and configuration of the SSO server. This will always be the first component to be installed; regardless of fresh install or upgrading from a previous version. The SSO server can be deployed in a number of configurations and I will explain these options and too why you may use each option.

During the installation process you will be presented with the below screen which is a key decision on which deployment method of SSO you would like to deploy. It is very important that you have planned your SSO deployment as changing this configuration later is possible but not an easy achievement. The two main configurations presented here are:

Basic vCenter Single Sign-On:

  • Most common deployment option (VMware recommended)
  • This is a single standalone instance of the SSO server that supports the connectivity of Active Directory, OpenLDAP, Local Operating System and SSO embedded users and groups.
  • This typically would be local to the vCenter Server
  • Used by the vCenter Server Simple Install option.
  • Preinstalled with the vCenter Server Appliance

When to use basic vCenter Single Sign-On:

  • If you have a single vCenter server of any supported inventory size (up to 1,000 hosts / 10,000 VMs).
  • If you have multiple geographically dispersed locations each with a local vCenter servers and have no requirement for a single pane of glass view provided by vCenter Linked Mode.
  • You are using the vCenter Server Appliance (VCSA).

Basic Node configuration of vCenter Single Sign-On server will meet the requirements of most vSphere 5.1 customers and typically maintains the same architecture of previous vCenter server environments.

Create a Primary Node for a vCenter Single Sign-On Installation:

  • This is a single SSO server instance configured as a Primary within an advanced configurations like vCenter Single Sign-On server High Availability (SSO HA) or same SSO security domain placement in geographically separated locations (SSO Multisite).
  • Requires the installable version of SSO (Windows Only).
  • Supports the connectivity of Active Directory, OpenLDAP and SSO embedded users and groups. Does not support the use of local operating system user accounts.
  • Only one Primary node can exist in a single SSO environment

The Primary configuration allows for further configuration options to support the vCenter Single Sign-On high availability and remote site architectures.

High Availability

  • This is a SSO server instance that connects to an SSO primary server and provides local failover of the SSO server when both the primary server and high availability. servers are placed behind a network load balancer (e.g. Apache HTTPD or vCNS).
  • Supports Failover only, does not load balance requests between SSO nodes.
  • SSO HA can only support the primary SSO server or SSO Multisite server with one HA Backup server.
  • Requires the installable version of SSO (Windows Only).
  • Supports the connectivity of Active Directory, OpenLDAP and SSO embedded users and groups. Does not support the use of local operating system user accounts.
  • High availability backup nodes share the same database as configured when installing the primary node.
  • Does not provide failover or redundancy of SSO database

When to use the High Availability Backup vCenter Single Sign-On server

  • If you have multiple vCenter servers within the same physical location and plan for a centralized SSO environment.
  • High Availability of the vCenter Single Sign-On server is required and does not plan to use vSphere HA or vCenter Server Heartbeat (preferred).

I have found the SSO HA configuration to be complex, with the updating of certificates, using a third party network load balancer for failover and then provide no protection for the database to why I do not recommend it when discussing with customers. A standalone basic SSO service with vSphere HA or vCenter Server Heartbeat will provide a simple centralized solution with added functionality of database protection (if local to the standalone SSO server) in this scenario.


  • This is a single SSO server instance that is used to provide a local copy of the primary SSO server instance at remote sites for local authentication. WAN authentication is not recommended with SSO.
  • Requires the installable version of SSO (Windows Only).
  • Supports the connectivity of Active Directory, OpenLDAP and SSO embedded users and groups. Does not support the use of local operating system user accounts.
  • Does not provide site redundancy of the SSO solution, if one SSO site fails you do not get redirected to another site for authentication.
  • Manual export/import of the database tables is required (scripts provided) between all SSO Multisite instances to manually maintain database synchronization. This is required whenever an update of any SSO Multisite server instances receives SSO configurations, SSO policies or embedded users/groups updates. This typically is not an everyday or every week task.
  • Local Multisite SSO server instances must be a member of the same Active Directory / OpenLDAP domain that the primary SSO server is a member of and have a local domain controller available.
  • By default SSO Multisite will only provide local resource visibility, and not a single pane of glass view across multiple vCenter Servers that are geographically separated and running SSO Multisite.

When to use the Multisite vCenter Single Sign-On server

  • If you are using Linked Mode.
  • If multiple vCenter Servers require the ability to communicate with each other.
  • If you are required to have one single vCenter Single Sign-On server security domain throughout your organization.

In general SSO Multisite removes the risk of slow WAN based authentications however with all the manual steps required to maintain SSO synchronization, I would only recommend the use SSO Multisite if you are using vCenter Linked Mode of which SSO Multisite is a requirement.

I hope this information has helped you understand the different configurations of vCenter Single Sign-On and to when you would use each configuration.

vCenter Single Sign-On – Part 1: What is vCenter Single Sign-On?
vCenter Single Sign-On – Part 3: Availability
vCenter Single SIgn-On – Part 4: Pre Install Requirements


About the Author

Justin King

Justin King has been involved with the IT industry for over 17 years where he has held various roles and responsibilities from administration to architecting solutions. Since joining VMware in 2009, Justin has supported sales teams as a sales engineer, evangelized VMware technologies as part of the Technical Marketing team and currently installs confidence by designing and testing end to end reference architectures for VMware's SDDC Suite solutions. Follow vCenterGuy on Twitter for news and information on anything vCenter Server related