Merging SSO Domains in vCenter 5.5 part 1: Why?

Sometimes tasks that seem simple at first can become very complicated. When I was first tasked with upgrading a vCenter 5.5 environment to 6.0 I imagined mounting an ISO, clicking through the wizard, and voila, upgrade complete. This may work when you only have one vCenter server in a simple environment, however in an enterprise this is typically far from the optimal way to approach the upgrade.

Over the next couple of entries I will talk about my progress toward a vSphere 6 upgrade. Today’s entry will be the “why” behind merging Single Sign On (SSO) domains. In then next entry for the series I will talk about the “how”. That will include links and sample implementation documents. I could combine both into one article but I’d rather separate them out. Not only do I get extra entries for #vDM30in30 but explaining why I approached this methodically will make the implementation commentary more meaningful.

The first question I should answer is what is a SSO domain? In brief, a SSO domain controls authentication and secure token transfer between vCenter components. You configure the SSO server to authenticate against active directory or another LDAP provider to allow authorization to existing user accounts.

One of the great new features in vCenter 6.0 is Enhanced Linked Mode (ELM). Linked Mode existed in earlier editions of vCenter but it only replicated Roles and Permissions and only worked with Windows vCenter servers. ELM supports replication of more information (policies, tags, etc) and is compatible with VCSA or Windows servers. Most important to the discussion is that the business requires ELM be configured once vCenter is upgraded to 6.0.

A technical requirement to configure ELM is all vCenter servers must belong to the same SSO domain to pass credentials and privileges between vCenters server environments. An interesting fact that was shared in a conversation about this upgrade was that you can’t merge SSO domains after an upgrade from 5.5 to 6. The only way you can configure ELM after an upgrade is to configure a single SSO domain before the upgrade. Armed with that information I created a conceptual plan.

The sample environment I will feature in my posts consists of three independent vCenter environments. Each of those environments was made up of one SSO server, one vCenter server, one SQL server, and a number of accessory servers (VUM, syslog/coredump, vROPS, etc). Each environment was part of its own SSO domain and thus had no knowledge of any other vCenter environments.

Each silo represents a single SSO domain. I made the decision to choose SSO1 as the “master” SSO server. In the merge I wouldn’t be reconfiguring SSO1 or any of the vCenter services dependent on SSO1 (inventory, vCenter Server service, and Web Client). I also decided to be safe and deploy new SSO servers into the SSO2 and SSO3 environments. This afforded me a clean start but it also allows me an easy rollback plan. If I can’t authenticate after the merge I only need to set the scripts back to the old SSO server. Here is a conceptual diagram of the SSO domain after the merge is complete:

Please notice the name change to PSC2 and PSC3. This is to represent both that they are net new servers and also they are named for the vSphere 6.0 Platform Services Controller. This is the replacement service to SSO in the new vSphere version.

When I reinstalled Single Sign On service to the new servers I chose to add them as a new site to the SSO1 domain. SSO1, PSC2, and PSC3 all replicate and the roles and permissions flow through each vCenter environment. Each vCenter server itself only talks to its SSO server but the roles are replicated so you will be able to control VMs in any vCenter environment once the 6.0 upgrade is complete.

I hope this helps clear up the why behind merging SSO domains in vCenter 5.5 as a preparation step for a vSphere 6 upgrade. In the last part of this two part series I will detail how to do it and some special considerations.