Tag Archives: SSO

vCenter SSO 5.5: AD Group Membership Gotchya

I’ve been running vCenter SSO 5.5 in mixed mode with vCenter 5.1 for a little while in our lab and production environment and recently had to configure external authentication for access against a subset of VMs we host. I covered how to setup a vCenter 5.1 AD Identity source in a this previous post, and the process hasn’t really changed that much in 5.5.

While there has been a slight tweek in the UI, the setup process is the same except you now have an additional option to utilize AD with Integrated Windows Authentication, which is covered by @chriswahl in this blog post.

After configuring the identity source as shown below.

And after configuring the appropriate permissions in vCenter I was getting the following error while trying to login with a user who was part of a Group with access to the VM location.

There wasn’t a hell of a lot on Google that looked to resolve this issue, and after some investigation I found that the reason for the error was that vCenter SSO will look to interrogate/verify every group of the user attempting to login…even though some may be out of scope and not relevant. The fact the error was returning a GroupSID that couldn’t’ be found told me that during the login process, SSO enumerates all Groups in order to find a match relevant to the vCenter Permission. If that group falls out of the Base DN for Groups, SSO can’t resolve the name to match it.

To resolve the issue I had to modify the Base DN for Group Location to be the domain root…once done the user was able to login without issue. This probably isn’t a bug like previous AD Domain SSO bugs however its still limits security restrictions when designing/allocating a user and group OU structure for AD authentication.

vCenter SSO 5.5 Backwards Compatability: Mixed Mode Install

While at a post #vFourmAU event last week a group of us where talking about SSO in vCenter 5.1 and what a disaster it had been (credibility wise) and that VMware had done their best to improve the experience in the 5.5 release. Out of that conversation came word that if people where looking to upgrade from 4.x or 5.0 to 5.1 as an interim step to 5.5, you could install SSO 5.5 in that 5.1 Environment so as not to go through the relative pain that SSO 5.1 brings to the table…that is to say SSO 5.5 was backwards compatible.


That post above goes through a little background and case examples where it might be relevant to run SSO 5.5 mixed in with vCenter5.1.

While I have been doing a bunch of upgrade testing in the ZettaGrid Labs for 5.0 to 5.1/5.5 Upgrades I thought I’d go through the process of installing SSO 5.5 into the environment before upgrading the rest of the vCenter components to 5.1. My main driver here was the opportunity to not have to configure an SSO database and to be ahead of the game when it comes time to jump to 5.5.

vCenter 5.0 to 5.1 Upgrade Mixed Mode SSO 5.5 Install:

Load up the vCenter 5.5 Installer and select vCenter Single Sign On Install. You can see I’m running this installer on a vCenter 5.0 Update 2 instance. The aim here is to have this version upgraded to 5.1 while utilizing the mixed mode capability of SSO 5.5

Run through the installer as you would for a standard SSO 5.5 install

One of the differences to point out here with SSO 5.5 is that the infamous [email protected] account has been replaced with a domain name, in this case I’m rolling with the default vsphere.local domain.

Much like an AD install, you have the ability to choose the default first site name…which does use Default-First-Site is left unchanged.

Once the SSO Service has been installed you can swap out the vSphere 5.5 Media for the 5.1 version and proceed with the upgrade of the Inventory Service and the Upgrade of vCenter it’s self. Both installs ask you for the SSO information relating to the SSO service as shown below. 5.1 will default to [email protected] so you need to modify that to reflect the account details as configured during the SSO 5.5 installer.

Once both the Inventory Service and vCenter have been upgraded, the final step for mixed mode is to install the vCenter 5.5 Web Client as the 5.1 Web Client will not recognise the SSO 5.5 install so you will be unable to modify the Configuration until it’s installed. I did run into a few issues with the install from a 5.0 environment, but that was more due to the fact that I had expired certs in the 5.0 Web Client SSL Folder, which the 5.5 installer checks and than attempts to copy into the new install location. While on the vCenter Single Sign On Information page I got an error saying the SSL cert was invalid, however it was not reflecting the Lookup Service URL as you would assume…but actually doing a check against c:\ProgramData\VMware\vSphere Web Client\ssl\rui.crt which it validates and copies to the new install location.

Once installed it’s business as usual and we have a fully operational mixed mode environment ready for action.

How-To: vCenter 5.1 SSO Adding AD Identity Source

The SSO Component of vCenter 5.1 throws a couple of spanners in the works with regards to a straight forward upgrade of an existing vCenter install. While not overly complicated in terms of understanding what and how the SSO Service fits into the 5.1 puzzle, I found that it did add a couple of additional configuration steps that where not expected during and after the upgrade process. There are a heap of resources out there already on the end to end install of the SSO…be it a Simple Server install or a multi-server HA set-up, but your best bet is to catch up on the official VMware Documentation here.

EDIT: @VMwareKB vSphere Blog SSO Help Page http://t.co/9y20Kk22

In my environment we already employed AD authentication by way of Group Membership that dictated access to the vSphere Datacenters and Clusters. This was well established and working without too much hassle. My first attempt at the vCenter 5.1 upgrade yielded mixed results with the SSO, but lesson learnt was that I made the mistake of being too eager to jump into the upgrade without RTFM!

What I am now calling an exercise in executing a roll-back plan came about because I didn’t bother to understand how the SSO component affects an existing set-up and also from not paying attention during the install. In truth, I thought the first upgrade failed to install SSO correctly as I was getting errors when trying to login and the Web Client wasn’t able to connect to the SSO service. Couple of points here is that I rushed through the “Error 29155 Identity source discovery error” which is referenced by KB 2034374 and I attempted to “fix” the service by messing with the SSO Service Log-on user configuration. In the end I got impatient and rolled back the vCenter SnapShot I had taken before upgrade and started again. (Side note: that actually worked ok even after 5.1 agents where deployed to hosts managed by the vCenter…after rolling back the snap the 5.0 agent’s where re-redeployed without hassle)

So, once 5.1 had been installed and all components have been upgraded, you need to add your AD LDAP profile as an Identity Source via the vCenter Web Client. Without this, your existing AD credentials will not be honoured.

Log into the vCenter Web Client with the credentials provided during setup:


Click through Administration -> Sign-On and Discovery -> Configuration and click on the green + Button in the centre window pane.


Collect all your relevant AD LDAP information and complete the set-up as shown below.


If all the settings are correct you will get a positive Test Connection response.


Now that you have your Identity Source configured you can add the new source to the default domains by clicking Add to default domains in the top bar and bump the new source to the top of the list in the bottom pane. This allows you to not have to enter the NETBIOS name of the domain during login. eg DOMAN\username vs username.

Final thing to check now is to ensure that your previous Permissions based on AD groups are still in place relative to the vCenter, Datacenters, Clusters etc. As shown below, from this point forward you can configure access as you would have previously…the only change now is you have the option of selecting the Domain to reference.


What this means, is in theory you could pull in external/client LDAP Identity Sources to use as authentication mechanisms on your vCenter…not sure it’s totally useful for vCenter’s, but can see this being extremely useful for management and automation layers like vCloud and vCOPs or even vCO.