SSO stands for Single Sign-On – it is a core component of vSphere which provides authentication by means of Security Tokens. 

A security token is similar to a *master* key with a tag attached to it; it proves that the key belongs to you (the user/administrator). This master key will only open (authenticate) a specific set of doors (vSphere products) giving you access only to specific rooms (resources). Get it? I hope so!

So you may be wondering … Why use this fancy SSO service for that? Couldn’t we use Active Directory; couldn’t we use LDAP or even, local authentication! Yes, we could – but what if I wanted to add some flexibility so that users could authenticate via either of these sources!?

To allow this functionality, we would need to group all these authentication sources (called Identity Sources) within one single database. You guessed it;  this is what SSO really is!

So this is how it works, conceptually:


There will be 1:1 relationship between the vCenter Server & Inventory Services. This also means that in a multi-vCenter environment, you need to install Inventory Service component for each vCenter Server instance. For more information on each vCenter Server component, see my previous blog, The Basic vSphere components.
  1. The user, sitting at the management station, browses to https://<web-client-IP-Address>:9443 and inserts the credentials (1a)
  2. The web-client passes the credentials to the vCenter Server service (1b); in case the user is using the vSphere Windows Client, credentials are passed directly to the vCenter Server (1).
  3. At this stage, the vCenter Server service will have to interrogate the SSO service and verify the credentials against known, previously registered, Identity Sources (2)
  4. The SSO confirms the credentials which are matched against existent privileges (3)
  5. Data is passed back to the the management station according to assigned permissions (4)

Now, let’s see a practical example!



In my environment I now have a Windows Active Directory Domain Controller installed on one VM. I have created a new domain user called vsphere-admin.  Another VM is running Windows 2008 – I have installed on this VM the vCenter Server core components (SSO, Web-Client, Inventory Services & vCenter Server Service); this server has the IP address of

Let’s try connect via the web-client using the default admin account created during the installation – administrator@vsphere.local; this is the only account that has got full permissions. We will use this account to assign permissions to the new AD account I just created. But first …

Go to Administration -> Users & Groups:


What you see listed in the drop-down box is the identify sources:

  1. vsphere.local – this is the default SSO authentication context created when installing the SSO service
  2. vvcenter01 – the vCenter Server authentication context; in reality this is the localhost authentication context (in this case, the local windows users)
  3. – the Active Directory domain authentication context; this is available as a result of me joining the vCenter server to the AD domain

Go to Home -> vCenter -> vCenter Servers; next, select the vCenter server, click on the Permissions tab following by the “+” sign add administrative privileges to the AD user, vsphere-admin (in the screenshot you can see I have already done so).


This will allow you to connect to vCenter using the vsphere-admin AD account to fully manage the vSphere infrastructure, through the vCenter.

It is important you understand that each authentication context provides its own set of users & groups; this is the case even when all these services are configured on the same physical server (as it is in our case). At last, authentication contexts are completely separate from the local users & groups set on the ESXi hosts.

Go back to Index


Thank you,
View Rafael A Couto Cabral's profile on LinkedIn

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>