SSO stands for Single Sign-On – it is a core component of vSphere which provides authentication by means of Security Tokens.
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:
- The user, sitting at the management station, browses to https://<web-client-IP-Address>:9443 and inserts the credentials (1a)
- 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).
- 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)
- The SSO confirms the credentials which are matched against existent privileges (3)
- 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 192.168.1.228.
Let’s try connect via the web-client using the default admin account created during the installation – firstname.lastname@example.org; 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:
- vsphere.local – this is the default SSO authentication context created when installing the SSO service
- vvcenter01 – the vCenter Server authentication context; in reality this is the localhost authentication context (in this case, the local windows users)
- home.cm – 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.