When SSO goes bye bye, things get interesting

So until today I was under the impression that SSO only effects the web-client in 5.1. The way I understood was the vSphere client still behaves the way it did before and SSO is not engaged unless the web-client is used to login. This also brought me to the conclusion that if SSO goes down, one cannot login via the web-client but the vSphere client can still be used. Wrong!!

A colleague of mine pointed me to a this page that clearly states the following:

How does SSO integrate with the vSphere Client?

SSO does not integrate with the vSphere Client. However, when you log in through the vSphere Client, vCenter Server sends the authentication request to SSO.

Once I read that I started doubting my thought process and the importance of SSO in 5.1 Apparently all access to vCenter must be down once SSO is down (both via web and vSphere client).

After doing a lot testing this is what I found (vcenter 5.1 build 799731). When SSO is down,

  • access via web-client is down as expected 
  • access via vSphere client is flakey

What does flakey access mean? Well, I got mixed results and was finally able to see some pattern. When SSO service is down, I was able to login with the account that has had a successful login while SSO was running. The important thing here was, “use windows session credentials” had to be checked for which I had to be logged in with the account that had successfully logged in when SSO was up. If I didnt check the box and entered the credentials myself, it told me the username and pwd were incorrect. I know I can fat finger keys at times but I tested this over and over to come to this conclusion. It wasnt me. Access was only allowed when the check box was checked.

This also meant any new account that was created or granted access couldn’t login using the vSphere client. Rememeber we only had luck with accounts that were able to login succssfuly prior to SSO service going down. And that too required the checkbox to be checked. If the account was just created or granted access after SSO went down, the screen showed the beautiful message on the right. The same message was received if the account didn’t successfully login while SSO was up. Why cant this message say the SSO cannot be reached is beyond me. By the way the web-client will tell you “Failed to communicate with the vCenter Single Sign On server” when SSO is down. So thank you VMware for doing that. 

Another thing to keep in mind. When SSO service is down, your vCenter service continues to run. However, if you attempt to restart your vCenter service you will find yourself in trouble. I was unable to get the vCenter service to start with SSO being offline. Which makes SSO even more important. Yes even with vCenter down your VMs continue to work but there are other vCenter specific features that will not function like DRS, sDRS for example. And if this vCenter is connected to a vCloud instance thats another can of worms.

So the bottom line is, SSO is very very important. It has two parts, the application and the DB part. VMware has done a great job in giving the option to install SSO as single, clustered or even multi-site type deployments. The high availability in the application side is thought out there. However, the problem is DB. VMware does not fully support SSO DB on a SQL cluster. As a matter of fact, there have been known issues that have come about when trying to deploy SSO using a SQL cluster. So the real option with full support is a stand alone SQL node. But that also creates a single point of failure. When the DB goes down, you are unable to login using the web-client, you maybe able to login using the vSphere client and all other things we discussed above.

So building redundancy is extremely important. VMware’s recommended solution is to use vCenter Heartbeat. We all know that can be a pricey solution. However, if full support along with redundancy is importnat to you, that is the way to go. I hope VMware extends their full support to at least allow running DB on a SQL cluster for all their products including vCenter (which is still a grey area). That would be the right thing to do. Heartbeat provides added functionality and there will always be a market for that as well. I hope full support on DB residing on SQL clusters is not further delayed in the interest of the vCenter Heartbeat product.

In the end I will borrow Tom Petty’s words to tell VMware “Don’t do me like that”…

6 Responses

  • Thank for posting that sir.
    Indeed, SSO was something I just jumped into and followed the instructions and was happy to get going, didn’t give it too much thought. Now I can see how it will affect other things if it isn’t maintained. Thanks

    • You are welcome. Yep sso is great when it works and supplies a lot of things. But it can make things really interesting when it falls off the radar. I would want it to be highly available. Specially if it services more than one vCenter.

  • Nice post!.

    So vCenter is also not supported on SQL clusters? I’m not yet running 5.1, but I have 5.0 running on a SQL Cluster.

    • Thanks! There is a lot of grey area. To answer your question, its not fully supported. VMware would do their best but will have to stop if the issue is found to be connected with the cluster. Though this kb doesn’t talk specifically about SQL cluster but have look. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1024051

      I know a lot of people that run vCenter db on a SQL cluster and it works as well. But getting VMware to fully certify that setup is a different thing. My suggestion would be to work with your rep and get in touch with support and get their input for your setup. From what I have heard, support for SQL cluster for most VMware products is coming. Lets hope that happen soon.

  • Good article.

    I find vmware documentation to be very confusing when it comes to what will happen in certain circumstances and how to protect against it. Vmware support is very good but I don’t want to be waiting on the phone when things go wrong knowing I could planned well before hand.

  • So, what about this: Our vCenter (5.5U1) is a vm and is hardware version 10. To edit setting on it you must use the web client. Let’s say we wnat to take the vcenter vm down for maintenace. Typically, you would login to the esx host it’s on, edit settings on the vm. Because it’s hardware version 10, you MUST use the web client. But, the web client is down because so is the vcenter vm that it’s installed and running on. Solution?

Leave a Reply