Single Sign-On 2.0 has a completely new architecture, and has only a few components which are retained from the original system for legacy support (specifically the Admin Service and Lookup Server). The below figure shows the architecture of SSO in vSphere 5.5
image
The original two services from SSO 5.1 have been replaced by a very different set of services. We now have a series of services presented in the Windows Service Manager, each with a specific role:
 1. VMware Directory Service
 2. VMware Certificate ServiceVMware Secure Token Service
 3. VMware Identity Management Service
 4. VMware Kdc Service
    5. VMware Secure Token Service

 

What about a Database?

You will often hear it asserted that SSO 5.5.0 does not require a database. This is not entirely true, but what they are suggesting is that SSO 5.5 does not require an external or preconfigured SQL database.
SSO 5.5 does have a database which it uses to store configuration details regarding its running state: identity sources, system domain users, principal associations, replication agreements, and other configuration details. Instead of using a standard SQL relational database server, SSO 5.5 uses a built-in VMware solution which is new for vSphere 5.5: VMware Directory Service. This service is an LDAP server implementation, which will run on the same host machine as the Single Sign-On services.

Deployment Modes

There are three options which the user is presented with during installation:
 1. SSO for the first vCenter Server
 2. SSO for an additional vCenter Server in an existing site
 3. SSO for an additional vCenter Server with a new site
Functionally, these three options are the same as Primary, High Availability, and Multisite, respectively.

Authentication

SSO 5.5 still supports the option to use Active Directory via LDAP for authentication, but it also has a much more powerful system available: Active Directory (Integrated Windows Authentication).
One major advantage to this system is that we need only to add a single domain to communicate with all domains within that forest. This should eliminate many of the challenges we faced when using LDAP.
When adding an Identity Source using Integrated Active Directory, we can choose to join the Domain using the Machine Account or a Service Principal Name (SPN). An SPN is a special account which needs to be manually created in Active Directory prior to adding the identity source.
The SSO system domain still exists, however here it is known as vsphere.local. The default super-user has been changed to administrator@vsphere.local.
vTip: When migrating from vSphere 5.1 to 5.5, the credentials and permissions of admin@System-Domain will be automatically migrated to the new administrator@vsphere.local.
vTip: The concept of a Master Password is not applicable for vSphere 5.5
In subsequent posts, I will try writing about the various services in detail.