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.