Modified vCenter Single Sign-On (SSO) Options in 5.5 Update 2

Chris Wahl · Posted on

If you’re installing a fresh vCenter, heads up! The vCenter Single Sign-On (SSO) menu has changed in the 5.5 Update 2 release (and newer). Now before everyone jumps out of their chair to point me towards this KB article – yes, I know … but it didn’t really grab my attention until I went to install a brand new vCenter Server using the 5.5 Update 2b media. My first thought was that I accidentally downloaded a vCenter 5.1 ISO, which triggered me to write the changes down here. 🙂

Here’s the previous SSO menu, which I verified is still present in 5.5 Update 1c (build 1945270) even though the KB I mentioned stops at 5.5 Update 1b.

old-sso-menu

The menu was a tad confusing, wasn’t it? Or at the very least it was quite wordy and neglected to call out how important a load balancer is if you go with the “existing site” option!

Here’s the new menu as of 5.5 Update 2 (build 2105955) and later. Same functionality with a fresh coat of grammatical paint and specific language around requiring a network load balancer if you choose to deploy multiple SSO servers within the same vSphere.local site.

sso-new

Let’s riff a bit on the various options.

Multisite Option

If you’re looking to build SSO servers that share the vSphere.local domain with one another – for linked mode or future use of vSphere 6 follow-the-sun vMotions – go with these steps:

  1. Install the first SSO site using the Standalone option.
  2. Install the rest of your SSO sites using the Multisite option.

The Multisite workflow will request the partner SSO details, much like the vCenter Single Sign-On for an additional vCenter Server option did in the previous menu style. The wording, however, is much more logical.

multisite-sso

Additionally, VMware states to use “this deployment mode when installing any additional vCenter Single Sign-On servers in your environment.” This means using unique site names or limiting yourself to one SSO server per site. Trying to add a Multisite SSO instance to an existing site fails.

already-exists

High Availability Option

The High Availability option also lets you choose a partner SSO server, but is intended to sit behind a load balancer and virtual node / IP address. It carries the same caveat as with the older option (that existing site install).

vCenter Single Sign-On does not automatically load balance nor does it automatically failover over using this deployment mode; a third-party load balancer is required for this form of availability. When this deployment mode is used and a third-party load balancer is not configured, a service dependency on the first vCenter Single Sign-On server exists, and any failure of that vCenter Single Sign-On server can cause all vCenter Servers to fail to start, as well as experience failures of authentication. (source)

Be warned. 🙂

Mike Brown had a particularly great blog post on setting up HA SSO servers with vCNS and F5 here. Definitely worth a read. I’m also curious how many folks are going down this route – I’ve yet to see it in the wild.