I’ve been getting feedback and questions from a number of different places of people wanting to disable Single Sign-on in vSphere 5.1 for various reasons (with vCenter). This is mainly due to difficulties around implementation of SSO in combination with other VMware solutions, such as VMware View, vCloud Director. My response to the questions is very simple. DON’T DO IT! At least not with vCenter itself. vSphere 5.1 and vCenter was not designed to run without SSO and this is definitely not supported and will likely result in a broken environment. This brief article will give you some tips on how you can be successful with SSO.
Firstly some reference material you should read:
VMware KB; vCenter Single Sign-on FAQ: Q: Can I disable SSO and revert to the old method of authentication in vCenter Server? A: NO.
VMware vCenter Blog: vCenter Single Sign-on Deployment Options
VMware vCenter Blog: vCenter Single Sign-on Availability
VMware Support Insider: SSO Best Practices and KB’s
Tips for Single Sign-on Success
1. Keep it simple. Put SSO on the vCenter if you have a single vCenter. The resource consumption is minimal and it is easier to protect and manage. If you have a multi-vCenter environment consider putting SSO on a separate standalone VM, potentially protected with vCenter Server Heartbeat, else just use vSphere HA. For most environments vSphere HA will be sufficient for availability requirements. Only use a multi-site configuration where it is absolutely essential and if necessary get VMware Support and PSO advice.
2. Read the vCenter Single Sign-on FAQ and references above.
3. Do not cluster the vCenter Single Sign-on Database, Database clustering isn’t supported and won’t work (instead of sometimes where it isn’t supported but does work). Both MS SQL deployed on a cluster and Oracle RAC are not supported at the moment for vCenter Single Sign-on. You can protect the SSO Database by using vSphere HA or vCenter Server Heartbeat. As the DB is small and not very resource intensive you could have it on the same system as SSO itself.
4. Make sure you’re running the latest version of vCenter and Single Sign-on. A lot of enhancements and bug fixes have been provided in vSphere / vCenter 5.1b.
5. Test your deployment of vCenter Single Sign-on thoroughly in your lab or test environment first. Make sure you are specifying the correct Windows AD DN and credentials. Be aware of how SSO works in a multi-domain / multi-forest environment. It would be a good idea to maintain a separate lab or sandpit from your production vSphere environment for testing purposes (doesn’t have to be big at all).
Where can you disable SSO?
You may disable SSO integration from vCloud Director. SSO is only used for vCloud administrator authentication, not tenant authentication. If you already have a management AD for vCloud Director authentication then SSO integration is optional. If SSO authentication is used client devices will need access to the SSO system and this would normally be blocked by firewalls. This may complicate the solution. Be aware though that (from what I understand) if you disable SSO you won’t be able to use SAML. So this should not be done lightly, and in any case should be thoroughly tested.
Don’t disable SSO in vCenter / vSphere 5.1. Keep it simple. That way you’ll have less problems and you’ll benefit from the integration that SSO provides now and in the future. As always feedback is appreciated. If for some reason you want to not use SSO for vCenter right now the only supported method is to stick with vCenter / vSphere 5.0 U2. If you are on an earlier versions of vSphere than 5.0 I would strongly recommend you consider upgrading to 5.0 U2, which includes great performance and functionality enhancements.
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.