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.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.
[…] As with vSphere 4.1 and 5.0 vCenter is supported on 64bit OS only. Now though there is the important addition of Single SignOn (SSO). This makes auditing and control of the environment much more robust, and at the same time creates an additional component and design considerations. VMware with the vSphere 5.1 release now allows for the Inventory Service, in addition to the SSO service to be split out for scalability and performance reasons. Note as of View 5.1 the View Composer service can also run on a separate server. However there is no guidance currently as to when it makes sense to run a split install of this nature. I’d recommend you check out my article vSphere 5.1 Gotcha with Single Sign On (SSO). […]
Great article and very helpful to my upgrade.
[…] AD authentication to VMware SSO 5.1 (Gabe’s Virtual World) vSphere 5.1 Gotcha with Single Sign On (SSO) (Long White Virtual Clouds) Comparing behaviour of vCenter Single Sign On with earlier versions of […]
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!
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 (email@example.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.
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 🙂
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.
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 🙂
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.
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.
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?
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.
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?
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.
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!
Oren, I've got impression you're not using the Web Client? Pls install the Web Client from the 5.1 ISO. In 5.1 all authentication now goes to SSO not the vCenter anymore.
Pls have a look this two links, hopefully it helps:
[…] vSphere 5.1 Gotcha with Single Sign On (SSO) […]