A week or so ago a mention was made on twitter of a soon to be released patch that would allow the use of an existing vCenter 5.5 SSO instance as an identity source for vCAC.
*Note: I’m making an assumption that the above mentioned patch will only apply to vCenter 5.5. I will update the post once the patch is released.
As you can see, Justin’s comment suggests that you should generally use your vCenter SSO over the vCAC ID Appliance. This got me to thinking about when and where you may want to consider different SSO options. Below is my attempt to work through some common scenarios.
__
1. Do you have an existing 5.5 SSO Environment?
vCAC 6 supports vCenter back to 4.1. This means that you may not always have the luxury of an existing 5.5 SSO environment to work with, so this is really the starting point for you to consider. There are many great reasons to upgrade to 5.5, but this is not the post to be discussing that.
2. Is this a Production instance of vCAC?
In short, I prefer to keep PoCs separate to production environments. I debated this with some of the team in the office, and while I’ll accept that others hold a different opinion to this, I’m not going to change my stance. After a PoC you should be able to pull out of an environment and leave no traces. This is why I have listed this as a decision point.
3. Do you need High Availability?
Before vCAC 6, SSO was the gateway to the management plane of our virtualisation environment. While availability was important, it wasn’t a component of an end user facing application (though vCD could cause objection to this). So while HA might have been acceptable in terms of providing uptime for Administrators, we may need to consider delivering High Availability through mechanisms that will give us even less downtime.
4. Are you Using the VCSA?
This becomes a critical question when in context of availability, as SSO is not currently supported to replicate between VCSAs and cannot separated out and deployed behind a Load Balancer.
Of course, this diagram could get even more complex. The vCAC ID VA is 1 vCPU so could be protected with FT (assuming you have Enterprise Plus). Alternatively, Windows SSO could be split onto a separate VM with 1 vCPU and protected with FT as well. This diagram is not meant to be exhaustive, but to provide a starting point for what you may need to consider for your own environment.
Finally, I did get a couple of people asking why we even need to consider this. There is one exceptionally good reason – we cannot simply assume that vCAC will be deployed in a greenfields environment where we have control over every decision has been made! We are likely to inherit legacy design decisions, and need to make sure that we make our design choices based on considered, reasoned decisions – not just because something is “best practice”.
If you have any comments or questions, please leave them below.