Home > SSO > SSO deployment options or how to achieve single pane of glass using the VCSA 5.5

SSO deployment options or how to achieve single pane of glass using the VCSA 5.5

And another twitter question leading up to a blog post.

— Andrew Dauncey (@daunce_) 22. Juni 2014


Actually I do not, so why not write one myself then. For those who attended the SSO GSS webinar or have seen me present at VMUGs or customer days will already know what I am talking about on a high level, this will fill the information with a little bit more detail.

As everyone should know by now Linked Mode is not supported when using the VCSA (as it relies on the AD LDS replication which is a Windows only feature).

There is another option though which will allow you to control several vCenter Servers with a single Web Client (unlike Linked Mode this method does not work with the C# client and we will get into the why in just a second). You will lack the enhanced Linked Mode features though (replication of roles and licensing sharing across multiple vCenter Server instances), on the upside you are not limited to 10 vCenter Servers with this method.

The answer is a bit hidden in the Documentation but can be found using the following link.

Change the vCenter Single Sign-On Mode in the VMware vCenter Server Appliance

An instance of vCenter Single Sign-On runs on the vCenter Server Appliance. By default, the vCenter Server Appliance uses the embedded Single Sign-On instance, but you can point to an external instance of vCenter Single Sign-On that is running on another system.

The external vCenter Single Sign-On instance can be on a different vCenter Server Appliance or on a Windows machine.

So now you know the 2 options to register the appliance against a Single Sign-On server. And you basically should instantly rule out one of these options as you will create a dependency. If you are using the embedded SSO of another appliance it would need to be available 24/7 or other systems won’t be able to authenticate user logins when they are pointed to that particular SSO.

What about the other choice, installing vCenter Server Single Sign-On on an external Windows machine. This initially would also introduce a single point of failure during Windows patches or on system crashes. But by using a Windows machine you are no longer bound to the 1 deployment option of SSO in the appliance. You now have the choice of all 3.

sso

Deployment option 1 “, vCenter Single Sign-On for your first vCenter Server”, option 2 “vCenter Single Sign-On for an additional vCenter Server in an existing site” and option 3 “vCenter Single Sign-On for an additional vCenter Server with a new site”.

Out of these 3 options 2 will provide you with a single pane of glass view. Namely option 1 and 2.

As mentioned above option 1 will create a single point of failure but is easier to deploy and manage. Option 2 will cause you some initial headaches on deployment, as you will need a load balancer for this to be supported which means you will also need to replace certificates and do some internal repointing for the Single Sign-On server but it does provide more reliability as you now can shut down a single instance for maintenance and redirect the traffic to the second node using the load balancer (which indeed should be a pair as otherwise this is a single point of failure as well).

So why is option 3 not viable? It does work perfectly fine for the Windows Linked Mode deployment, doesn’t it? The reason is that we do replication of the AD LDS instance which includes basically all licensing options, web url options for each vCenter Server, health data and much more. As the VCSA does not have this service we cannot rely on it to replicate the vCenter Server information.

So what are we doing instead when choosing install option 1 or 2. We are installing a single “authentication site”. Pretty similar to the site ID used by SSO 5.1 in multisite and HA deployments.

And here is the wonderful part now. As long as each vCenter Server is registered against the same “authentication site” you will be able to see it in the vSphere Web Client, as long as the user your are logging in with does have permissions on that vCenter Server, as they will be registered against the same lookupservice component of vSphere Single Sign-On.

You will not be able to do the same with the C# client as mentioned above, and this has to do with the mechanism the C# client actually pulls the inventory from. It does not leverage the Inventory Service to do so but goes straight into the database. As the database does have a 1:1 relation for vCenter Server it will not be aware of any other vCenter Server instances. Therefore you will only see one vCenter Server when logged in into the C# client.

What’s the difference using the Web Client now?

Simply put the vSphere Web Client will follow the following steps when you hit the submit button on the page.

  1. Send a request to the Single Sign-On server to authenticate the user
  2. Initialize the GUI after successful authentication (even if the user does not have permissions to anything he/she will be able to login into the Web Client and simply see nothing)
  3. Next a lookup in the lookupservice of Single Sign-On is done to see exactly which solutions are registered to the SSO node, all vCenter Servers that are registered against that “authentication” site the lookupservice belongs to are pulled
  4. vCenter Server in conjunction with the Inventory Service will check permissions and will fill the Inventory Tree in the Web Client with everything the user is authorized to see, additionally SSO also checks the internal groups to see if the user is an administrator in the vsphere.local space to display configuration options for SSO.

So because of the lookupservice registration of each vCenter Server in the same “authentication site” (and it needs to be the same lookupservice and not a different one) we are able to see several vCenter Servers in the Web Client without the use of Linked Mode.

Categories: SSO Tags:
  1. Andrew Dauncey
    July 7th, 2014 at 19:54 | #1

    Thanks again Frank.

    I’ve been meaning to ask, although it’s possible, is this a supported configuration?

    Great content on here. Keep it up.

    • admin
      July 7th, 2014 at 20:10 | #2

      Well VMware has the stance that everything that is in the docs usually is supported if not stated otherwise some place else. As sharing the lookupservice using several SSO servers is intended for some deployments I don’t see any support issues here from my point of view and would not pull the “unsupported” last resort on this if I got a case, until being told otherwise by either Product Management or Engineering.

      It is important that this SSO server has to be external towards the appliances though, as there is another post out there by William Lam (http://www.virtuallyghetto.com/2012/09/automatically-join-multiple-vcsa-51.html) that would describe on how you could achieve the same only using the local SSO servers of the appliance, which indeed was never tested.

  2. August 5th, 2014 at 17:09 | #3

    Thanks for posting this and especially for the explanation of the options and the differences in the interaction between the web client and the C# client.

  3. Chris
    March 9th, 2015 at 15:12 | #4

    Hey Frank,

    great site here!!! I’m loving it for years now!

    Days ago I took over 4 vCenter Servers (3* Windows, 1* Appliance) from my predecessor on the job. As I can see, one Windows vCenter is setup using the integrated installer, two using an external SQL DB; each one uses its own SSO instance. The Appliance uses embedded DB and SSO.

    As you can see, this infrastructure is quite some pain für a lazy bugger like me: I’d love to have at least a single (central) external SSO server, allowing for me to use a) a central auth source and b) administer the vCenter Servers from one vSphere Web Client (single pane of glass).

    Is there a method to change the SSO modes of existing Windows-based vCenter Server installs? A re-install is not possible, because there are large dvSwitches configured in each install and we currently can’t get any downtime windows for the customer guests on the infrastructure.

    • admin
      March 9th, 2015 at 21:11 | #5

      Hey Chris,

      Sure that can be done, but might have some further implications depending on how much vsphere.local internal users and groups are leveraged in your environment. If they are not used at all, everything is fine, otherwise you will need to recreate them on the central instance and reconfigure permissions for those users probably.

      The procedure to follow is the “repointing” KB.

      Re-pointing and re-registering VMware vCenter Server 5.1 / 5.5 and components
      http://kb.vmware.com/kb/2033620

      Hope that helps.

  4. Chris
    March 10th, 2015 at 10:46 | #6

    Hey Frank,

    thanks alot for pointing me to that KB! We currently don’t use @vsphere.local at all – everything only Active Directory integrated.

    I’ll try to do this in my tedtbed environment some time next week and will report back here

    Regards,
    Chris

  1. No trackbacks yet.