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.