Home > VMware > vSphere 5.1 Gotcha with Single Sign On (SSO)

vSphere 5.1 Gotcha with Single Sign On (SSO)

To be honest this is more of a PEBKAC (Problem Exists Between Keyboard and Chair) issue on my part. I was doing an upgrade from vSphere 4.1 to vSphere 5.1 and in the process upgrading vCenter (Simple Install). After the upgrade had completed successfully I logged in to the vSphere Web Client as the admin@system-domain user (who is the admin for Single Sign On). To my horror I could not see any vCenter objects registered and couldn’t access vCenter. After a little head scratching I remembered why.

This is by design. This is a measure to ensure separation of duties between authentication admin and virtualization admin for security reasons. The admin@system-domain user doesn’t have any access or authority to vCenter. So if you wish to use an SSO user to access vCenter you should set up a separate account and then log into vSphere Web Client or vSphere Client using a vCenter administrator and grant permission to the newly created SSO user (not the admin user). You are not prompted or warned of this if you do a simple install. However if you’re doing a split install (each component installed individually) you will be prompted to select who you’d like the vCenter Administrator to be. This is covered in the vSphere 5.1 Installation and Setup Guide – see How vCenter Single Sign On Deployment Scenarios Affect Log In Behavior.

While I was going through this process I also ran into vCenter Single Sign On installer reports: Error 29155. Identity source discovery error (2034374), which is one of the errors that I spoke about in my article vSphere 5.1 Generally Available – Important Upgrade Considerations. When you run into this error you will have to sign into vSphere Web Client using the admin@system-domain user and manually register your AD domain. Make sure that when you’re specifying the distinguished name for users and groups that you do it correctly. For example, OU=Users,DC=CORP,DC=DOMAIN,DC=COM, OU=Groups,DC=CORP,DC=DOMAIN,DC=COM. It is not case sensitive and note that specifying the OU is optional (Thanks Erik Bussink for the reminder). However if you don’t specify the OU there may be a performance impact as the searches will traverse the entire directory. I would recommend narrowing it down to an OU if possible. Once you’ve configured your AD correctly and run a test connection which is successful you should consider changing the order of the default domains and making the AD first.

Be aware that if you have hardened your environment and removed any local users on the vCenter Server from being vCenter Admins you could easily get locked out of vCenter if you are unable to communicate with AD (or configure it incorrectly in SSO). This is because no SSO users will have rights to vCenter by default as explained above. Also be aware that if SSO is installed on a different server from vCenter that it will not have any knowledge of the local accounts on the vCenter Server that were granted access. This could be a major problem for you if you have put your Domain Groups into the Local Groups on your vCenter Server and then assigned permissions from there (all local group and user permissions have been removed remember). The first thing I’d recommend when you get SSO working is to create a new SSO user to use in case of emergencies and troubleshooting. Carefully plan and execute your upgrade and you’ll avoid these issues.

Because SSO is using token based authorization (based on RSA technology) time sync in your environment will be critical. If your vSphere Hosts do not have consistent time, or your SSO / vCenter Server and other components don’t have consistent time you will run into trouble. You could find yourself being locked out of the environment, or services will failing to start. If something weird starts happening that you don’t expect you might want to look at all the system clocks and ensure they are in sync.

Good luck and I hope you are successful with your upgrade process.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.comby Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Categories: VMware Tags: , , ,
  1. Preetam
    September 28, 2012 at 12:59 am

    Good article..

  2. Jason
    September 28, 2012 at 8:09 am

    Great article and very helpful to my upgrade.

  3. David
    October 6, 2012 at 2:17 pm

    What type of database were you using and how did you go about upgrading it? I’m currently using SQL Express 2005 for vCenter 4.1 and no one can tell me how to do an in-place upgrade. It’s maddening!

    • October 6, 2012 at 7:18 pm

      Hi David, How big is your environment? If it’s larger than 5 hosts and 50 VM’s you’ll need to move to a full version of SQL (std edition at minimum) if you want it to be supported. In order to do the upgrade you’ll need to create an SSO DB. You may need the SQL management tools for this (which don’t come with Express edition) if you want to keep it in the same DB instance as vCenter. If you don’t have any other management tools linked into your vCenter and don’t need the stats you may opt for a fresh vCenter. You’ll have to upgrade SQL Express to 2008 as a minimum as 2005 is not supported. You may be able to get away with a simple install and in-place upgrade (after upgrading SQL Express) and run the SSO DB on a SQL Express instance 2K8. But I haven’t tested this and there doesn’t appear to be any good documentation on it that I can find. It might pay to file a support request as well before you start the process, or at a minimum file a documentation bug (docfeedback@vmware.com) as this isn’t covered well in the docs currently. Let us know how you get on. Also the SQL Express situation is covered in KB 2006706.

  4. October 6, 2012 at 7:17 pm

    Hi David,
    You can’t do simple install in that case. You have to install SSO and Inventory Server on separate VM from the vCenter VM.
    And.. stop being mad. Relax 🙂

    • October 6, 2012 at 7:21 pm

      Thanks Fajar for your feedback, that is a better option. Not many people have this scenario, which is probably why it isn’t well covered in the documentation.

      • October 6, 2012 at 7:28 pm

        You’re welcome Michael, I’ve got this the hardway 🙂
        I’ve mentioned this in Singapore VMUG, hopefully the VMware documentation team is willing to put something about it in the docs. It could be maddening like David said 🙂

  5. Simon Jones
    October 8, 2012 at 10:50 pm

    Hi Michael,
    Not sure if you have come across this or even if it’s a supported configuration. For one of the VC instances I have the Users are in one domain but the Groups they belong to are in another domain and there is a trust in place. Good practice is to use groups, so is this a configuration that could be used because in my lab I haven’t been able to get it working yet.

    • October 16, 2012 at 7:18 pm

      Hi Simon, Which domain in the vCenter in? The domain with the groups? Which way is the trust and what type of trust? This scenario will be even more interesting when SSO is bought into the mix.

  6. Oren
    November 12, 2012 at 3:42 pm

    Hi, Great article, Thanks for sharing your experience with us!
    I’ve had a similar problem that after upgrade from 4.1 to 5.1 I couldn’t login to vCenter with any domain users. I can login only with a local user of the windows machine that running my vCenter. I still didn’t find a solution for it, do you have any tips?

    • November 12, 2012 at 4:13 pm

      Hi Oren,
      Make sure during the upgrade the connectivity to your AD from vCenter and SSO is established all the time. SSO behaves very differently if it’s not connected to AD when you do the upgrade.

      • November 12, 2012 at 4:30 pm

        Upgrade already done, I’m not aware of any connectivity issues while I upgraded but maybe…
        My SSO and vCenter is the same machine (VM by the way)

        Anything I can do now, after the upgrade?

  7. November 12, 2012 at 4:42 pm

    Did you do the upgrade logged on to the vCenter VM as domain user or local user?
    If you logged on as domain user SSO will automatically connect to your AD and will recognize domain users you have. If you logged on locally during the upgrade you need to define your AD in SSO after upgrade. If you have backup, you can try to redo the whole process.

  8. November 12, 2012 at 5:00 pm

    Too many things have been changed in the configuration since the upgrade, I don’t want to redo it…

    Not sure what do you mean by “define your AD in SSO” where should I do it? I do have vCenter single sign on service running on my vCenter server but I don’t see where to configure stuff related to the SSO.
    I configured on each host in the Authentication services my domain but it is still not letting me login with my AD users.

    Thanks for your help mate!

  1. September 26, 2012 at 10:31 am
  2. October 1, 2012 at 4:27 am

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: