Confused with what vCenter Single Sign-On is?
I was until I dived in and found answers which I will do my best to explain here.
vCenter Single Sign-On is a new feature of vSphere 5.1 that is not just an authentication broker but also a security token exchange providing a more secure way of accessing your vSphere solutions. What that means is that when you previously logged into vCenter Server, you were authenticated with the provided username and password against the Active Directory configured for vCenter Server. With vSphere 5.1 and vCenter Single SIgn-On you no longer log directly into vCenter Server but with a security domain defined by your vSphere environment. When logging in to vSphere 5.1 you actually pass authentication to the vCenter Single Sign-On server which can be configured with multiple identity sources like Active Directory and OpenLDAP and on successful authentication, your username and password is exchanged for a security token which is then used to access the vSphere components like vCenter Server and vCenter Orchestrator etc.
Although vCenter SIngle Sign-On is an additional component in the vSphere suite, a critical component that is required before any other vSphere 5.1 component is installed or upgraded, it actually doesn’t necessarily mean you need to re-architect your vSphere environment. You can use vSphere just as you have been from years past and vCenter Single Sign-On will fit right on in just as an additional service local too or separate from vCenter Server.
Where some of the confusion comes from I believe is with the added benefits that vCenter Single Sign-On can bring when administering multiple vSphere environments. When installing vCenter Server you have the choice to specify or install a vCenter Single Sign-On server providing the ability to add multiple vCenter Servers and their components to a centralized vCenter Single Sign-On source. This provides a single pane of glass view across all vCenter servers, 5.0 and higher for administration as well as the ability to define queries that can be searched across multiple vCenter Servers without the requirement of Linked Mode used in the past.
Now this maybe seen as a single point of failure, a critical one at that when talking authentication but vCenter Single SIgn-On can be configured in a clustered or multisite deployment to help with availability.
Clustered deployments are with multiple instances of vCenter SIngle Sign-On are deployed, one is defined as a primary instance the remainder as slaves and all share a single database instance and placed behind a third party load balancer can provide redundancy or high availability of the vCenter Single Sing-On solution. This typically is local to a single site however if geographical sites are used with multiple vCenter servers, you can still utilize a central clustered environment, however a multisite configuration is recommended.
Multisite deployments are where a local replica is maintained at remote sites of the primary vCenter Single SIgn-On instance. vCenter Servers are reconfigured to use the local vCenter SIngle SIgn-On service and reduce authentication requests across the WAN. Multisite deployments do drop the support of single pane of glass views unless Linked Mode is utilized and multisite deployments are actually required to maintain Linked Mode configurations where roles, permissions and licenses are replicated between linked vCenter servers. Linked mode will re-enable single pane of glass views across multisite instances.
I hope this was informative
vCenter Single Sign-On – Part 2: Deployment Options
vCenter Single Sign-On – Part 3: Availability
vCenter Single SIgn-On – Part 4: Pre Install Requirements
thanks justin. struggling to get multisite sso to work in support of srm 5.1 install. looking forward to the next part in the series
Where you able to get SRM to work with Multisite sso. I am planning on implementing Multisite sso for client that will be using SRM.
Many thanks Justin. Your explanation was very helpfull. Very clear and well done.
How does this work with Vmware Essentials (the $500 kit)? Can you do connect multiple Vmware Essentials together?
Hi, am trying to deploy Vmware Data Protection and during the install wizard it asks for a SSO server and port number but I dont think I have SSO installed as part of my vcenter deployment. When I type in the SSO server name as my vcenter server name it tells me it cant find a SSO server?? Can you please advise? Have checked vcenter server “Programs” and cannot find any trace of SSO. Do I have to install it as a separate component into vcenter? Can I not deploy VDP without SSO server?? Thanks
Peter,
SSO is a separate install with vCenter 5.1 and is required for the Inventory Service and vCenter. You can install SSO without upgrading to 5.1 but you’ll need the 5.1 media to install it. It can be installed on any Windows server you want as well. It doesn’t have to be on the vCenter server.
Eric
Is SSO really dependant in order to install vCenter and inventory service? Is there an option to not install SSO?
SSO is required for inventory service, vCenter and web client to install and is a mandatory dependency. You cannot use vCenter 5.1 without SSO
Vmware Data Protection requires vCenter 5.1 which is dependent on vCenter Single Sign-On. When you install vCenter 5.1 you are asked for the SSO configuration and this is also used when setting up Vmware Data Protection.
I understand that there will be some benefits for some, but for a single site it seems like a waist of resources and a possible vulnerability. I don’t have a problem with VMware adding this, but I hate that they are cramming it down the throats of everyone that uses vCenter, whether they want it or not. It is either take it and use it or loose vCenter. I have this kind of single minder software development. Most vCenter installation have absolutely no need for this. It is like Mc’ Ds saying that since one person likes Mac sauce on their fries we will start to put it on everybody’s fries and not give them an option not to have it. I thought virtualization was about doing more with less. Why all the bloat!!!
Agreed!
+1
Fully agree!
+1
Me too agree ryan its make more complicate to work on let make concise to work
I agree. I don’t see how it, in it’s current architecture state, has any benefit for multisite setups either. I think the fact that there is an entire web site dedicated to answering questions about SSO coupled with the fact VMware admits they are being overloaded with support calls for SSO, is a clear indicator this solution, as it is now, is not ready for the enterprise and was not very well thought out. And sadly you have no option. You have to install it.
I agree with this…whether VMware sees it as a major benefit to us, we should still have the option not to install if we don’t want this.
I see this as just some added bloatware that I won’t be using.
Agreed! It’s now insanely complex to install and configure vcenter.
Justin,
In a SSO multi site environment what happens if you lose your primary SSO database. Is there a set time in which to recover it?
if done correctly all your multisite SSO instances will have the same copy of the database, every time a change is made to the identity source, an SSO user or SSO group the SSO admin needs to manually replicate this to each site with the provided export and import scripts. It would simply be a case of manually replicating the entire database or restore from backup.
I would only ever use multisite SSO if using linked mode, no other scenario justifies the overhead.
Thanks for clarifying Justin
Hi Justin, This SSO stuff is a bit confusing. When you discuss replicating the database for a multisite deployment are you talking about the database, say SQL, that was created and configured prior to installing SSO? That does not seem to be the case. It seems like it is referring to some other DB for SSO. So then what is the database for that we are creating in preparation to install SSO? What is the SSO instance database for if SSO is just going to authenticate to something such as AD? And how does this multisite replication benefit an SRM implementation? If the production site goes down and recovery is started at the DR site using SRM you still need the database (SQL) required to install SSO at the DR site and you also will still need the SSO instance database at the DR site because the production site is now down with no access to either production site database. So with that in mind what is the point in replicating in the first place? Why wouldn’t you just have an SSO implementation at the production site and a SSO implementation at the DR site, each standalone, and each using their own local AD server for authentication? Further, since the documentation indicates if the SSO instance is down at one site the SSO instance at the other location doesn’t authenticate users at the site where the SSO instance failed and all authentications will fail at that site. So again, why the replication in the first place. It does not seem this SSO was very well thought out. There is also no reference as to when you would or would not install SSO on the same server as vCenter and/or SRM, or how to size an SSO database. It seems like this shouldn’t have to be this confusing.
And also, how does all this effect Linked Mode or how is Linked Mode effect by this, understanding Linked Mode is only for the vSphere Client. Still if leveraging Linked Mode for a production site and DR site, from what I understand you need to have a “multisite” configuration with the SSO “database” replicating between sites. I understand the Web Client use SSO to present all vCenters that you have permissions to and not Linked Mode, but still what is the impact if one site experiences a disaster? And again, what database are we actually replicating? The best I can tell each SSO instance leverages two databases, the one required to install SSO (say SQL) and then one it appears SSO creates on the SSO server during installation?
Justin, Also you indicate, “every time a change is made to the identity source, an SSO user or SSO group the SSO admin needs to manually replicate this to each site with the provided export and import scripts.” Why would you replicate the identity source to a remote location when, from what understand, a local SSO instance is not going to attempt to authenticate to a remote identity source. That is the whole purpose of the local SSO. Why does it care about remote identity sources? And what exactly are SSO users and groups? Doesn’t SSO leverage AD users and groups similar to what vCenter does? Is this implying that now we must create and manage vCenter users and groups (roles and permissions) and now also create and manage SSO users and groups (roles and permissions)? And again, what database is actually replicating?
Justin, Also vSphere documentation indicates this:
“vCenter Server instances in linked mode can be connected to different physical Single Sign-On servers, but must be connected to a single logical Single Sign-On server. A single logical Single Sign-On server can take any of the following forms.
■ A single physical Single Sign-On server.
■ Two nodes of a cluster. Effectively this is the same as a single physical Single Sign-On server because the nodes use the same Single Sign-On database.
■ Two nodes in multisite mode.
It indicates that each vCenter instance can be connected to different physical SSO servers but that they must be connected to the same logical SSO server. Then defines one option for a logical SSO server is a physical SSO server. So if you have each vCenter instance connected to a different physical SSO server that constitutes a single logical SSO server? That makes no sense.
Justin, sorry just one more time, 2 frequently asked and answered questions are:
What SQL access rights does the database user require?
The database user you specify during installation must have the DBA privilege. However, you can grant the DBA privilege just before you encounter this screen in the installer and revoke the privilege after installation is complete
Is the database user that I specify during installation a separate user from the RSA_USER and RSA_DBA (the database users that are created during SSO installation)?
Yes. The database user you specify during installation is used to create the users RSA_USER and RSA_DBA.
It indicates that the user specified during SSO installation needs to have DBA privilege. It then indicates that the user specified during installation is different from the RSA_USER and RSA_DBA users and that the user specified is used to create the RSA_USER and RSA_DBA users. What if you created your database and tables ahead of time and created the 2 users as well, and gave the RSA_DBA user DBO privileges? Then, during the SSO installation the user specified (when prompted for it) is the RSA_DBA user you already created, would that not suffice? And why would we need to enter that user when prompted anyway if we already manually created the RSA_USER and RSA_DBA users? Isn’t the purpose of this user we are to specify to create the RSA_USER and RSA_DBA users (that we already created)?
Hi Justin,
Trying to decide on a configuration for our SSO 5.1 upgrade deployment, and you mention that Multisite can help with availability, but the following link to VMware publication states that Multisite provides no failover (redundancy). For active-active multi datacenter deployment would you recommend two SSO instances, or a multisite master/slave configuration? Any insight you could provide on this would be appreciated!
Thank you
“Note
Multisite Single Sign-On deployment is designed only for faster local access to authentication-related services. It does not provide failover between Single Sign-On servers on different sites. When the Single Sign-On instance on one site fails, its role is not taken over by a peer Single Sign-On instance on another site. All authentication requests on the failed site will fail, even if peer sites are fully functional.”
Source:
http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc%2FGUID-3BDE41A9-32C2-40D8-A17E-5070E2332D2F.html
Dan, sorry if it sounds confusing, multisite is designed for a local copy of the authentication service to prevent requests going across the WAN link. The configuration is only used by the local vCenter services and does not provide redundancy unless each multisite SSO instance is configured with a second SSO server providing local SSO HA. Multisite by default does not provide site redundancy.
Why are the customers forced to install something they absolutely not required in the enterprise? We already have other SSO at work. Don’t need another one. Customers should be given the option to chose, rather than forcing it on them, especially when it is a not a core component. Hope the same mistake will not be repeated in next version.
there are many types of single sign-on services available to the enterprise, vSphere SSO is not a replacement for these, it is an authentication service for the vSphere environment only. We would not be able to test and validate every external solution out there and so have a dedicated solution.
Sounds like a neat setup, but what is wrong with people who come up with the architecture of these systems?
Try to deploy this in a new setup and you will find out that before you deploy vSphere 5.1 with SingleSignOn you really need to have all of your other systems (domain, DNS, etc) up and running. Not only running, but with FQDN and IPs that won’t change. Otherwise you will quickly find out that this SSO is nothing but a pain in the behind.
We just want to let our hosts grab the licenses from the vCenter but instead have to deal with this monstrosity.
I am posting the detailed pre-requirements very soon
Using SSO Multisite, in 3 localities, can protect each instances of SSO with vCenter Heartbeat?
Note – SSO – Site A protect by VCHB, SSO – Site B protect by VCHB and SSO – Site C protect by VCHB
Thanks.
Excellent article with clear and concise explanation. I request that you add a separate article explaining single and multi-site deployment models.
Thanks for explanation. Need to leern vSphere and been struggling about it, because my literature is only for 5.0.
Ѕωеet blοg! I founԁ it whіlе ѕearchіng on
Yаhoo News. Do you hаve any tiρѕ on how to gеt liѕted in Yahоo
Νеωs? І’ve been trying for a while but I never seem to get there! Cheers
Useful info. Lucky me I discovered your web site unintentionally, and I am surprised why this twist of fate didn’t came about in advance! I bookmarked it.