Make vSphere more robust by backing up the SSO server

A failing SSO server will cause numerous problems in your vSphere environment. Here's how to set up a load-balanced SSO server to avoid a crisis.

As most VMware admins are aware, the single sign-on (SSO) server came with vSphere 5.1. For small sites, SSO is almost transparent as it works out of the box. For bigger or more complicated installations, a greater understanding of SSO and how it works is required.

Prior to vSphere 5.1, there was no supported method of providing alternative authentication schemes to Windows Active Directory. In effect, it was a limiting factor. With the vCenter Server appliance a limited authentication mechanism could prove to be a trouble spot. Therefore, SSO was developed to allow alternative authentication methods.

The purpose behind SSO

SSO is essentially a mechanism to tie together several authentication sources in addition to Microsoft Active Directory, including native LDAP. SSO acts as the gatekeeper between the authentication system -- such as LDAP or AD -- and the vSphere infrastructure. When a user or administrator successfully authenticates against an authentication source, the SSO grants a usage token to the user. Each usage of the token seamlessly reduces the token's time-to-live (TTL) by one. Once the TTL reaches zero, it expires and it has to reauthenticate against the authentication source in the background.

When installing a vSphere vCenter infrastructure from scratch, using the simple install, SSO is installed in a primary mode configuration. When set up in this fashion, it provides authentication for local infrastructure only. In vSphere 5.5, SSO supports a maximum of 10,000 guests and 1,000 hosts. The problem is, losing the SSO means no one can log in to the infrastructure. People can still directly authenticate to hosts using local credentials.

This simple configuration is fine for local infrastructure. Loss of SSO is just as painful as the loss of the vCenter Server; in a simple installation, they sit on the same guest. For larger sites and installations, it is advised that vCenter Server and SSO sit on separate guests. (In vSphere 6.0, SSO is part of the Platform Services Controller, which can be put on a separate server.) Putting SSO on another guest opens the way to more options, such as removing the single point of failure by using load balancing.

Avoiding a breakdown

Simply put, you can set up a HA backup node to take over SSO duties in the event of the primary SSO failure. This arrangement requires additional, but relatively inexpensive, infrastructure especially if virtualized. VMware demonstrates how to create a basic load-balanced SSO server group with Apache, which is free software. Setting up a load-balanced SSO infrastructure requires an in-depth understanding of certificates and load balancing.

Assuming that virtualized infrastructure is being used, any host failure on which the SSO server sits will restart as normal using HA or the backup node will take over. Of course, this doesn't rule out configuration errors. To counter that scenario, snapshots are extremely useful and can easily be rolled back, even if you should lose the SSO temporarily due to a configuration error. As to the question of is it worth the hassle, only you can decide, but even some of the largest estates I have worked in have not employed such a setup. With a correctly functioning HA setup, there is no need.

For those that run multiple sites and desire a single pane of glass, the methodology is a bit different. Installation for multiple sites includes choosing the multisite from the SSO installation drop-down. In essence, using multisite mode means setting up each site to have its own individual primary node in a multi-master configuration. The difference is that when you set up multisite mode there is one SSO server that links them.

One potential issue with this setup is the databases do not replicate amongst themselves. In real terms and for most sites, this won't matter. The databases will need to be replicated occasionally, but as long as you are using a separate authentication system, such as OpenLDAP or AD, the need for this is minimal.

Next Steps

What you need to know about cloud-based file sharing

VMware enters the world of microservices architecture

Dig Deeper on Securing a VMware environment