I was talking to a customer yesterday about a storage solution and we strayed into a discussion about the vSphere Web Client, and compatibility with this, that, and the other (VUM and SRM to be specific).
While we were at it, the subject of Single Sign-on (SSO) on vSphere 5.1 arose again. SSO is a difficult subject for many people still. Configuring it is tricky for some, and this is covered a million times around the web. I think it’s pretty straightforward once you’ve mucked about with it in the lab for a day or two.
Most blogs drift into the mechanics of how to set it up and don’t reinforce the important points. If you really want the full skinny on it, check out Justin King’s links here. This time I just want to reinforce a point about linked mode.
Use Cases Simplified
The question I was asked was all about Linked Mode and how this plays with SSO. The environment was 5.1 so let’s talk about that.
Firstly, it is a pre-requisite for Linked Mode that you MUST USE MULTI-SITE SSO in v5.1.
Once you know that, it makes things a bit simpler. As follows……
- Multi-site SSO means when you log into vCenter on either member of the same SSO domain you will see the other vCenter
- This applies to both the vSphere Web Client and the traditional VI client
- This means you have a single pane of glass for both your vCenters, assuming you had two.
- And this DOES NOT require Linked Mode.
- Without Linked Mode I think it’s simpler to just add permissions at the relevant object to each vCenter prescriptively.
- Add permissions via AD groups to objects like Clusters, Datacenters in the inventory.
- With Linked Mode, ADAM is used to centrally store permissions for linked venters within Active Directory.
- During login there is a “handshake” to check permissions against objects in linked virtual datacenters. Depending on the outcome users inherit different permissions or maybe no permissions.
- So with Linked Mode there’s always the possibility of a permissions or naming conflict between vCenter instances.
So I think it’s best to avoid the use of Linked Mode. I think it’s fair to say most people used it previously to provide a single pane of glass which means it’s no necessary.
That’s one of the nice things about multi-site SSO – it negates the need for that.
Authentication – where ?
Remember that Multi-site in 5.1 means that if an inter-datacenter link is down, while you won’t see the other vCenter (just like in Linked Mode) you should still be able to login on each “partitioned” site. You can setup the local SSO instance to authenticate against the local AD instance/server. This means you use AD replication to ensure you have site resilience for user logins to vCenter.
Also one thing that is important to point out !!!!!!!!!
is that SSO is a means to an end.
You set it up initially and register all your vCenter components against it (vCenter, Inventory, Lookup Service etc …). Once that’s done SSO is configured to tell it that your AD domain is an LDAP source for example. Once you’ve done that you really shouldn’t be messing about in SSO too much.
By modifying AD group permissions in vCenter and adding users to same, this will define how permissions are inherited for users. SSO just acts as a middleman so to speak, as per Justin’s lovely drawing.
vCenter 5.1 SSO is entirely different to vCenter 5.5.
There is no database in 5.5 whereas you have to manually sync databases up in 5.1 etc. That’s a potential risk with SSO 5.1 – the management overhead were a change not handled in a controlled fashion.
But as I mentioned earlier, all your user permissions management should be accomplished by adding users to AD groups and then assigning to vCenter objects.
It’s also possible to use SSO 5.5 and vCenter 5.1 together to simplify it all.
So I know others have written against using multi-site SSO but for me, if designed and configured properly and you have more than 2, 3, 4, 5 + vCenters, it’s not really practical having to open up lots of different windows to manage a single “estate”.
So a use case of multi-site SSO is to provide better manageability for an overall environment and not make people’s lives a pain …
So, do go “Basic” SSO if you like, which is easier to install and manage from a platform perspective, but probably not in terms of managing your virtual machine estate.
I hope this presents a quick discussion around the benefits of multi-site SSO and the possible absence of any further justification for vCenter Linked mode from here on in….
258 total views, 1 views today
5 thoughts on “vCenter 5.1 SSO and Linked Mode …. recap …”
I just want to mention that linked mode is required to get the single pane of glass. Otherwise you will see just the local vCenter and not the partner vCenter.
sorry for the delay. I have checked this and I was sure it wasn’t required – I wasn’t doubting you. So yes it seems to be the option you choose during the install to select Linked Mode.
Many thanks for your comment and apologies for the delay.
Hi again Paul
I already commented this post, and today I discussed with a colleague another option without linked mode and now I’m wondering if you maybe talking about the following scenario when you say linked mode is not required.
Installing the Web Client & SOO on a dedicated server and pointing multiple vCenter servers to that external Web client & SSO. this should also provide a single pane of glass without linked mode.
Thanks again Patrick. That’s certainly thinking outside the box.
Keep ’em coming 😉
Hm… I’m a bit confused. vSphere 5.5: you should be able to point multiple vCenters to dedicated SSO & Webclient to get single pane of glass but it will introduce latency and is in general not recommended by VMware. There is no option to use Multisite SSO without Linked mode correct?