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 KB: Troubleshooting Issues with Single Sign-on in a VMware View Environment
VMware vCenter Blog: vCenter Single Sign-on Deployment Options
VMware vCenter Blog: vCenter Single Sign-on Availability
vSphere 5.1 Gotcha with Single Sign On (SSO)
vSphere 5.1 Generally Available – Important Upgrade Considerations
VMware KB: Backup and Restore of vCenter Single Sign-on Configuration
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.
Final Word
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.
SSO database is not supported in SQL clustered environment, do you have a link or KB article that i can refer to? I need to show this to my DBA :))
Hi Sam, There is no link or KB as SSO DB is not supported on a SQL Clustered environment. VMware documents the supported configurations and scenarios and clustered database is not one of those configurations and is therefore not documented yet. SSO is also not supported with SQL Mirroring. If your solution doesn't change the way the database interacts with the software then you can seek support from your clustering solution vendor, but VMware will be unable to help. Although they will do their best to help until it's determined it's a clustering fault. The closest you'll get is KB 1024051. But that is specific to vCenter not SSO.
Hi Sam,
You can take a look at this article published by Justin King of VMware Tech Marketing which mentions the no-support for clustered database systems for vCenter and SSO etc. http://blogs.vmware.com/vsphere/2013/03/vcenter-s…
My client has SSO installed in “standalone mode” and now they want it to be in “multisite mode”. Is it possible to do so, without this linked mode do not work.
@Preetam, Linked mode does work with SSO in standalone mode – just point both vCenter boxes to the same SSO instance. I've got it working for a customer…. It's not the ideal solution – http://blogs.vmware.com/vsphere/2013/02/linked-mo… shows the "correct" way to set it up – just ignore the SRM bits towards the end….. Hope this helps? Jack
Can I use heartbeat for SSO and avoid using multisite SSO. My customer has two sites with two vCenters required to be in linked mode. Due to all the horror stories I hear about multisite, I was hoping to do standalone mode with the SSO protected by heartbeat. Both vCenters in the two data centers will be connected to the single SSO and in the event that the datacenter where the SSO is running goes down, the heartbeat in the second datacenter would be brought up for authentication.
Hi Mohan, Yes this would work and is the approach I would recommend as it still keeps things relatively simple. I would put SSO on it's own server then protected by Heartbeat. One of the vCenters could also be protected by heartbeat if you like. But be aware you need a stretched layer 2 network as you won't want the IP address of SSO changing. Also consider what you would do if the network between the two sites went down but both sites were still up. This split brain scenario needs to be properly considered and dealt with.
Heartbeat installation document says different subnets over the WAN are supported. If the customer does not have stretched VLANS, can this still be used for SSO? What happens if the SSO IP address changes during a disaster, but DNS is updated to reflect the new IP? Thank you for your feedback!
Yes heartbeat supports it (WAN mode and different IP's) but a lot of the components of SSO use IP address and not DNS, so they will break. So if you can't keep the IP's the same (LAN Mode, you could switch over a subnet by doing some routing changes etc) then you're better off having two separate SSO / vCenter implementations and potentially look at Linked Mode, or just keeping them isolated.
[…] 6. Disabling vSphere 5.1 Single Sign-on – Long White Virtual Clouds – By Michael Webster @vcdxnz001 […]
[…] Disabling Single Sign On – Dont Do It! – […]