I have had various people asking me over the last 9 months what I would recommend when it comes to SSO. Would I use a multi-site configuration, maybe even an HA configuration or would I go for the Basic configuration? What about when I have multiple vCenter Server instances, would I share the SSO instance between these or deploy multiple SSO instances? All very valid questions I would say. I have kept my head low intentionally the last year to be honest, but after reading this excellent blog post by Josh Odgers where he posted an awesome architectural decision flow chart I figured it was time voice my opinion. Just look at this impression of the flow chart (for full resolution visit Josh’s website):
Complex? Yes I agree, probably too complex for most people. Difficult to digest, and that is not due to Josh’s diagramming skills. SSO has various deployment models (multi site, HA, basic), and then there is the option to deploy it centralized or localized as well. On top of that there is also the option to protect it using Heartbeat. Now you can probably understand why the flow diagram ended up looking complex. Many different options but what makes sense?
Justin King already mentioned this in his blog series on SSO (part 1, 2, 3, 4) as a suggestion, but lets drive it home! Although it might seem like it defeats the purpose I would recommend the following in almost every single scenario one can imagine: Basic SSO deployment, local to vCenter Server instance. Really, the KISS principle applies here. (Keep It Simple SSO!) Why do I recommend this? Well for the following simple reasons:
- SSO in HA mode does not make sense as clustering the SSO database is not supported, so although you just deployed an HA solution you still end up with a single point of failure!
- You could separate SSO from vCenter, but why would you create a dependency on network connection between the vCenter instance and the SSO instance? It is asking for trouble.
- A centralized SSO instance sounds like it make sense, but the problem here is that it requires all connecting vCenter instances to be on the same version. Yes indeed, this complicates your operational model. So go localized for now.
So is there a valid reason to deviate from this? Yes there is and it is called Linked Mode. Linked Mode “requires” SSO to be deployed in a “multi-site” configuration, this is probably one of the few reasons I would not follow the KISS principle when there is a requirement for linked-mode… personally I never use Linked Mode though, I find it confusing.
So there you have it, KISS!
Great post Duncan! I work mostly as an EUC engineer and see multiple vCenters at a single site due to separating the desktop and server environments. I have been recommending to customers that they build a separate VM for SSO and join all vCenters to that instance due to the fact that so many customers want linked mode. However, your note about all vCenters connecting to that SSO instance must be at the same version is a great point that I will have to mention going forward. That scenario forces them to do an all or nothing upgrade.
Can anyone please provide a source on the statement that SSO and all the vCenters themselves need to be the same version? I couldn’t find anything that implies this.
The article was taken online for whatever reason, but you can find the statement cached here:
http://webcache.googleusercontent.com/search?q=cache:nU0uiBRFcJgJ:blogs.vmware.com/vsphere/tag/centralized+&cd=3&hl=en&ct=clnk&gl=nl&client=firefox-a
When they say “same version” do they mean “same build”. A newer build version of SSO would work with an older vCenter version, right?
I agree – we’ve reverted back to the single server mode for these reasons.
It’s worth noting that if you install vCenter with the simple install then you can’t just change the SSO mode, you have to re-install using the individual component installation to get the advanced SSO setups. If you think you might need multi-site (or even after the warnings above, HA) SSO at some point in the future then it’s best to start off with the individual component install, even if it is on a same server.
Another thing to bear in mind is that the Linked Mode and Multi-site SSO is not supported to traverse firewalls – this was a deal-breaker for me (I documented my process here: http://www.definit.co.uk/2013/02/vmware-vcenter-linked-mode-not-supported-through-firewalls/) but the short answer was that the response from VMware Support is that it is not supported (when I found an engineer who had more than basic knowledge of SSO!)
Thanks for posting the above Sam – made for interesting discussion here in the office. The only time I’ve employed Linked Mode (and therefore multi-site SSO) is recently in a proof of concept for SRM 5.0 – everything I’d read (granted not exhaustive research) suggested Linked Mode for the vCenters at protected and recovery sites is best practice.
“personally I never use Linked Mode”, I’m with you Duncan, I personally don’t use linked mode as well but this is me thinking out loud and arguing both sides what about VMware View? it contradicts VMware’s goal when it comes to View. I personally don’t use VMware View with linked mode. I personally would rather rely on a good storage to do the compression and dedupe to accomplish what . In fact there are good storage startup that has great idea to where linked-mode would sound like a bad idea. Is it because of the many storage startup that has great idea the reason why you don’t use linked mode?
Hi Totie,
Don’t confuse linked mode (vCenter) with linked clones (VDI). This article is referring to the SSO requirements with Linked Mode vCenter servers to enable sharing of roles and licence keys.
Thanks for clarifying, I did got the two technology confused.
I’ve been considering to change my design to a local SSO for quite some time now, but I haven’t found any KB article describing how to change the SSO-server the vCenter uses. Anyone knows if such an article exists?
I wish VMware had posted something that simple 6 months ago when I started the migrations, or guidelines of any sort for that matter. Unfortunatley, we are already going with a hybrid, clustering similar purposed vCenter servers to a single SSO with FT and linking it to load balanced webclients, forget that SSO-HA nightmare. still a pain… Ps. I still want that sweatshirt you were wearing at the beta. 🙂
Great post. I am working on a vSphere 5.1 install and it is obvious there is no one solution that fits all. I had to go for the multi-site implementation because of SRM requirement. My SSO, vCenter and DB backend are on separate servers. The reasoning behind this was that we may implement View and I wanted some level of separation. I still have questions around protecting SSO though and would like to hear what other people do as an alternative to heartbeat? Since I have all services on different servers it becomes more complicated to implement not too mention the cost. I am thinking to about using a powercli script that clones the servers required on an hourly basis to different host/storage. If need be I can log on to local host and fire the VM up. I’d still rely on HA in first instance. Is this viable?
PS: I know Heartbeat keeps things in sync. I said hourly as that seems good enough to me for a “backup”.
If I’d rely on our traditional or SAN backup I would not get an hourly RPO.
Here is what we have. We have SSO in HA mode with SQL database on a clustered instance. We also have the VMware Web Client installed on both SSO nodes are load balanced as well using F5. We had a tough time getting the SSO working (I say the issues were more related to getting the certificates working, without a cert it is not possible to configure SSO in a HA or multi-site mode), but with 3rd level support from VMware Canadian engineers our system is working fine now. We now have a proper working SSO and Web client environment. SSO had lot of bugs but now with the new 5.1 Update 1a and Certificate automation tool I think things are more under control now.
In HA mode, only the primary node will have the SSO admin server functionality. That means if the SSO primary is down and the vcenter goes down, to bring back vcenter you need the primary SSO server to be available. (Since Vcenter requires the SSO admin service). There is a work around to make the SSO Secondary server a SSO admin server. But this is not recommended. We have tested this and have not seen any issues so far.
Are there any documentation that says SSO in HA mode is not supported in a clustered database (SQL)?
Our vcenter is still a single point failure, but we will be implementing Heart beat very soon. As of now we have a single vcenter using SQL clustered database as back end and SSO in HA mode with SQL clustered database as back end. We have Web client server services installed on both SSO nodes and are load balanced as well.
When coming to configuring F5 for load balancing there is no documentation from VMware. We are just using F5 as a load balancer and are using the Layer 4 forwarding. No certificates are installed on F5. This setting is same for SSO and Web client.
I’m a big fan of Duncan and his blogs are always a life saver for many. I totally agree with his concept of KISS and if you have not yet implemented SSO, I would suggest sticking with this option. For those who have already implemented SSO in HA and Multi site mode and if it is working, I do not think there is a need to go back. If you want to do so, you have to reinstall SSO completely. No other option.
I still have a question, and expect comments from experts. Why it says SSO is not supported for clustered database? It is working fine for me. Support engineers never said no for this. Are there any documentation from VMware that says, DB clustering for SSO is not supported?
It’s my understanding that SSO does not support a distributed/HA database accessible by multiple SSO nodes. Do you foresee this implemented in a future release? This shortcoming is the reason we’ve decided to install one SSO/SSodb per Vcenter.
Can you provide a link that says SSO in HA mode do not support clusteres SQL instances? I do not see that anywhere in the Vmware Installation document. For us, we are using SSO HA with the help of a clustered SQL database on a multi node MS cluster. We have not experienced any issues and it works great.
I was told distributed databases weren’t supported in SSO by my TAM, http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2036922 seems to say that distributed databases (not clustered) are only supported when using Multi Site SSO.
Our dev lab design was to have multiple Vcenter’s connecting to 2 or more SSO servers backed by 2 or more distributed databases utilizing local accounts (no AD). So, It may be the combination of requirements that led to our answer that it was not supported.
Distrubuted databases and a clustered database are different I think. What we are using is a single database from a Microsoft clusteretd SQL Instance. I do not see any reference that says we should not be using a database that is hosted on a MS cluster.
Duncan: Can you please clarify what you mean by ” SSO in HA mode does not make sense as clustering the SSO database is not supported”. Does that means SSO does not support a database that is hosted on a MS cluster ?
It means using a database clustering service is not supported for SSO.
I can’t comment on futures to be honest…
How about we deploy SSO and vCetner on the same server. But during the SSO install, we use multi-site mode instead of basic mode, so we only register the local vCenter (i.e.: one SSO with one vCenter on the same VM). In this case we can change the setup to linked mode without reinstall the SSO. Is there any problem with this approach?
I’m So glad there are leading engineers that find KISS still a good way to go. For me its always been about operational \ support efficiency, not necessarily about getting slick with complex solutions, which can sometimes be counter productive to a smooth running infrastructure.
What do folks do re: SSO for the vCenter servers in the vCloud management cluster – I’ve just received my copy of “VMware vSphere Design 2nd Edition” and noticed the statement “SSO can only be used for cloud adminstrators and not for organizations within the cloud” which I’m not sure I understand. I assume a local SSO for the vCloud management vcenter in each case as per KISS principle..(although the graphics miss out an SSO instance for this vcenter)… do VCD cells still get pointed at customer specific LDAP sources directly rather than use SSO in the real world?
Hi All,
We have a requirement to install SSO in HA mode. I am stuck @ load balancer configuration.
Can you please assist me.
@ Deepu — Can you please suggest me as you have sso in ha in your environment.
Thanks
Duncan,
Does vShpere 5.5 enhancements to SSO change your recommendation. how bout the increased scale of the vcenter appliance.
How SSO authentication is different from usual AD authentication ?
Thanks for the post Duncan but what still confuses me what exactly is the benefit of SSO that I can actually SEE in my working environment.
In earlier versions before SSO was introduced & as well now in the versions where SSO is introduced this is what we do :-
1) Open vSphere client/Web client in from 5.1 versions.
2) Enter your AD domain credentials.
3) And you are logged into vSphere infrastructure, can view all the components, you don’t need to re-enter your credentials for accessing any component separately.
So we’ve always been entering our credentials just once to access everything then how this SSO is different.
As by SSO we mean entering your credentials just once while accessing a system & it’ll carry on your same set of credentials to it’s subsystems preventing you from re-entering the credentials again & again.
I’m still trying to figure this out, if you could help me answering this, would be really helpful.
Thanks !
This just means you can add multiple Identity Sources so that users/groups from other directory services can access your vCenter. Correct me if Im wrong?
Nahhh..that’s definitely not the purpose of SSO as majorly anyone is using LDAP for directory services.
Hi,
in VSphere 5.5 – SSO 5.5 no need of DB and only 3 options available to install the SSO.