SSO deployment options or how to achieve single pane of glass using the VCSA 5.5
And another twitter question leading up to a blog post.
@fbuechsel do you know of any articles on using vCSA with external SSO for a ‘single pane of glass’?
— Andrew Dauncey (@daunce_) 22. Juni 2014
Actually I do not, so why not write one myself then. For those who attended the SSO GSS webinar or have seen me present at VMUGs or customer days will already know what I am talking about on a high level, this will fill the information with a little bit more detail.
As everyone should know by now Linked Mode is not supported when using the VCSA (as it relies on the AD LDS replication which is a Windows only feature).
There is another option though which will allow you to control several vCenter Servers with a single Web Client (unlike Linked Mode this method does not work with the C# client and we will get into the why in just a second). You will lack the enhanced Linked Mode features though (replication of roles and licensing sharing across multiple vCenter Server instances), on the upside you are not limited to 10 vCenter Servers with this method.
The answer is a bit hidden in the Documentation but can be found using the following link.
An instance of vCenter Single Sign-On runs on the vCenter Server Appliance. By default, the vCenter Server Appliance uses the embedded Single Sign-On instance, but you can point to an external instance of vCenter Single Sign-On that is running on another system.
So now you know the 2 options to register the appliance against a Single Sign-On server. And you basically should instantly rule out one of these options as you will create a dependency. If you are using the embedded SSO of another appliance it would need to be available 24/7 or other systems won’t be able to authenticate user logins when they are pointed to that particular SSO.
What about the other choice, installing vCenter Server Single Sign-On on an external Windows machine. This initially would also introduce a single point of failure during Windows patches or on system crashes. But by using a Windows machine you are no longer bound to the 1 deployment option of SSO in the appliance. You now have the choice of all 3.
Deployment option 1 “, vCenter Single Sign-On for your first vCenter Server”, option 2 “vCenter Single Sign-On for an additional vCenter Server in an existing site” and option 3 “vCenter Single Sign-On for an additional vCenter Server with a new site”.
Out of these 3 options 2 will provide you with a single pane of glass view. Namely option 1 and 2.
As mentioned above option 1 will create a single point of failure but is easier to deploy and manage. Option 2 will cause you some initial headaches on deployment, as you will need a load balancer for this to be supported which means you will also need to replace certificates and do some internal repointing for the Single Sign-On server but it does provide more reliability as you now can shut down a single instance for maintenance and redirect the traffic to the second node using the load balancer (which indeed should be a pair as otherwise this is a single point of failure as well).
So why is option 3 not viable? It does work perfectly fine for the Windows Linked Mode deployment, doesn’t it? The reason is that we do replication of the AD LDS instance which includes basically all licensing options, web url options for each vCenter Server, health data and much more. As the VCSA does not have this service we cannot rely on it to replicate the vCenter Server information.
So what are we doing instead when choosing install option 1 or 2. We are installing a single “authentication site”. Pretty similar to the site ID used by SSO 5.1 in multisite and HA deployments.
And here is the wonderful part now. As long as each vCenter Server is registered against the same “authentication site” you will be able to see it in the vSphere Web Client, as long as the user your are logging in with does have permissions on that vCenter Server, as they will be registered against the same lookupservice component of vSphere Single Sign-On.
You will not be able to do the same with the C# client as mentioned above, and this has to do with the mechanism the C# client actually pulls the inventory from. It does not leverage the Inventory Service to do so but goes straight into the database. As the database does have a 1:1 relation for vCenter Server it will not be aware of any other vCenter Server instances. Therefore you will only see one vCenter Server when logged in into the C# client.
What’s the difference using the Web Client now?
Simply put the vSphere Web Client will follow the following steps when you hit the submit button on the page.
- Send a request to the Single Sign-On server to authenticate the user
- Initialize the GUI after successful authentication (even if the user does not have permissions to anything he/she will be able to login into the Web Client and simply see nothing)
- Next a lookup in the lookupservice of Single Sign-On is done to see exactly which solutions are registered to the SSO node, all vCenter Servers that are registered against that “authentication” site the lookupservice belongs to are pulled
- vCenter Server in conjunction with the Inventory Service will check permissions and will fill the Inventory Tree in the Web Client with everything the user is authorized to see, additionally SSO also checks the internal groups to see if the user is an administrator in the vsphere.local space to display configuration options for SSO.
So because of the lookupservice registration of each vCenter Server in the same “authentication site” (and it needs to be the same lookupservice and not a different one) we are able to see several vCenter Servers in the Web Client without the use of Linked Mode.