Before vCenter Single Sign-On, each vCenter Server was recommended to be joined to an Active Directory domain – one such reason was for authentication purposes. Any member of the server’s domain could be granted the ability to perform vSphere related actions. Additionally, if you wanted to use a Linked Mode view – where multiple vCenter servers appeared within a single client – it was mainly just a matter of running the wizard.

Single Sign-On has changed things significantly. Administrators can now set up multiple identity sources within SSO for different LDAP or Active Directory domains. But there were new, complex challenges to solve with the 5.1 release when it came to clustering the SSO servers, especially if all you were looking for was a similar Linked Mode experience from the days of yore. With vCenter SSO 5.5, we’re required to create a single SSO authentication domain, which ultimately means answering the installer questions a little differently than you may have in the past. This post will walk through a simple two site SSO 5.5 installation for a fictitious Site A and Site B. We’ll make sure to create a single authentication domain across the two sites by walking through the installation steps.

Keep in mind that I’m focusing on SSO itself, not the other components and related design considerations for vSphere management (That can, and most likely will, fill up several blog posts). To add some visual splash, we will be talking about the green SSO portions of the diagram shown below:

The logical topology between Site A and Site B

Contents

Site A Configuration

At this point, SSO 5.5 does not exist at either site. We’ll start with Site A, which is running Windows Server 2012 and will be upgrading to vCenter Server 5.5u1. I’ve inserted the vCenter installation DVD as an ISO file and ran the installer menu as shown below. We’ll want to start by installing vCenter Single Sign-On (SSO).

As you walk through the wizard, pay attention to the Prerequisites Check page. It’s something new to the 5.5 install process and makes sure that you’ve done your homework regarding requirements for the domain and DNS. Many folks forget to make the A and PTR records for forward and reverse DNS lookups.

Note: Don’t just plow through the wizard. If something pops up with an error or failure, fix it! It’s 10x harder to repair later and often results in technical debt.

You can see that my machine passes the checks and can proceed:

The SSO server passes the prerequisite checks, which is vital

Next up is the deployment mode options. Because Site A is the first site to use SSO 5.5, I’ve selected vCenter Single Sign-On for your first vCenter Server. There are no other SSO 5.5 servers for me to add to my authentication domain site.

Enter a strong password for the [email protected] account used by SSO 5.5. It must contain a lowercase letter, an uppercase letter, a number, and a special character. Not all special characters work; I tend to use a “!” to avoid complications down the road.

Now it’s time to name the site where this SSO server is going to live. This is Site A, so I’ll just enter that. You could also call it the name of the city where the server lives or the type of environment if you use multiple SSO servers at a single physical location.

Finish the wizard and install SSO 5.5.

Site B Configuration

It’s now time to install SSO 5.5 at Site B, which runs Windows Server 2008 R2 SP1.

Why did I use different Windows Server versions? I mainly did this to show you the various interfaces across two Windows versions, not to encourage folks to run disparate versions of Windows across sites. However, using Server 2012 at a new site is becoming more and more of a reality as people begin shifting towards their Windows 2012 templates and shelving their 2008 templates. Perhaps I sparked your curiosity? 🙂

Most of the SSO 5.5 install at Site B will be the same wizard activities, so I’ll focus on covering the differences.

To begin, the deployment mode for Site B will be vCenter Single Sign-On for an additional vCenter Server with a new site. This allows the SSO domain to include a new server rather than creating islands of SSO instances.

It's an additional SSO server at a new site called Site B — It’s an additional SSO server at a new site called Site B

Because we’re adding an additional server to the SSO authentication domain, which is always vsphere.local, we’ll need to enter the information for a partner host. This will be used to pull the configuration and join the domain. Enter the partner host name, which is the SITEASSO.glacier.local server that was installed over at Site A, and the SSO administrator password as shown below:

Assuming you put in the correct password and the server can be reached, you’ll be asked to verify a SHA1 thumbprint to ensure that the server is who it says it is. Once completed, it’s time to name your new site. In my case, it’s Site B:

At the end of the wizard, you’ll get a review installation options screen as shown below. Let’s break down the selections:

New install – It’s a new installation of SSO, not an upgrade
Configured as additional server in domain – This means that we’re adding a new SSO server to the SSO authentication domain
Domain name is vsphere.local – This is a hard coded SSO domain name, so you should always see this
Partner name is siteasso.glacier.local – This is the pre-existing SSO server that was configured at Site A. We’re using this server information to join the SSO domain
HTTPS port is 7444 – This is the default port
Selected site name is Site B and partner site name is Site A – We’re installing an SSO instance at Site B and have chosen to partner with an SSO server in Site A

Review the configuration and then pull the trigger

Once the wizard is done installing you’re free to install or upgrade the other vSphere components.

Thoughts

Now that there is a single SSO authentication domain, any changes made to either site will be replicated to the other. This reduces the operational efforts for the IT organization. We’re also empowered to use vCenter Linked Mode to create one logical management point for any reasonable number of vCenter Servers.

We’ve touched the tip of the iceberg here. You could have many different sites, or multiple SSO instances at the same site, or a mixture of the two. I really enjoy how simple the installer is and the fact that the sites replicate with one another without any need for scripts or witch doctor rituals. Just make sure to use the vSphere Web Client 5.5 if you want to view or edit the SSO configuration and identity sources.