VMware SSO install, when done wrong or when architected the wrong way, can put your infrastructure into a fragile state where SSO can became the single point of failure (SPOF). Before introduction of SSO in vSphere 5.1, there was a vCenter considerations when it comes to resiliency and protection. With the introduction SSO it's like an additional key component to think of when it comes to resiliency and protection. And even if it greatly simplifies the user experience, it adds additional complexity to vSphere deployments. The SSO works with vSphere 5.1 and higher versions of vSphere. It's automatically installed within the vCSA.
The SSO server is responsible for interoperability between vSphere solutions. SSO will support requests to authenticate for vCenter server, vCloud Director, vCenter orchestrator and others. So multiple authentication services gets consolidates into single login. SSO provides tokens to hand back and forth between the different components of vSphere infrastructure allowing you to login only once. This is the principal benefit for the end user, but can become a headache for the IT admin.
In my post on creating an SQL 2012 database for SSO server, where I prepared also vCenter and VUM databases, created users, roles and privileges before installing all the vCenter components on Windows Server 2012 (supported since vSphere 5.1 U1), I have installed a basic SSO type of installation. With no particular resiliency. It's certainly crucial to have a solid backup solution for that SQL server, as well as for vCenter server.
VMware SSO Install.
Concerning the VMware SSO install, there are three options, and you can do a basic or more resilient (clustered), or installation for other types of architectures:
- Basic – single instance of SSO server (a standalone install). Multiple vCenters can use this SSO server. In case of failure – no vCenter access, but ESXi hosts continue to function.
- HA cluster – two or more instances of SSO server are installed in cluster. Single Primary and one or more secondaries. Single DB is used by multiple SSO nodes. In case one node fail, the other nodes continue to provide SSO functions.
- Multisite – For different geographically located datacenters (and vCenter servers), the SSO server instance is installed on each geographically located site. In single or clustered mode. If there is a requirement to administer all those datacenters through single vSphere Web client, than the vCenter servers instances must be configured in Linked Mode. More details. See also the Multisite Single Sign-On deployment best practices.
The identity sources for SSO can be various : Active directory, Open LDAP or local OS users. You can add an additional identity source after installation by going through the configuration options through vSphere Web client only by going to:
Home > Administration> Single Sign On And Discovery > Configuration
There you can add an additional identity source (in addition of those already present). But you don't have to use AD or Open Ldap. It is not a hard requirement, but usually you already have some kind of authentication services implemented in your company. So hooking up SSO server into it is just logical. The SSO Server has its own internal user store. It's possible to assign vCenter Server privileges to users and groups from this internal datastore as well.
Further good read:
- vCenter Single Sign-On – Part 1: What is vCenter Single Sign-On?
- vCenter Single Sign-On – Part 3: Availability
- vCenter Single Sing-On – part 2: Deployment options
- vCenter Single SIgn-On – Part 4: Pre Install Requirements
- Troubleshooting VMware Single Sign-On configuration and installation issues in a Windows server
- Configuring vCenter Single Sign On for High Availability
This is really useful tips for everyone who can use the SSO. In vSphere versions before vSphere 5.1, vCenter Server was installed in a single operation that also silently installed the Inventory Service on the same host machine.