After logging into my brand spanking new vCenter 5.5 server I was treated with a vCenter server inventory count of 0. Interesting to say the least as I installed vCenter on a new windows 2008 R2 machine, connected to a fresh MS active directory domain. I installed vCenter with a user account that is domain admin, local admin and has all the appropriate local rights (Member of the Administrators group, Act as part of the operating system and Log on as a Service). The install process went like a breeze, no error messages whatsoever and yet the vCenter server object was mysteriously missing after I logged in. A mindbender! Being able to log into the vCenter server and finding no trace of this object whatsoever, it felt like someone answering the door and saying he’s not home.
I believed I did my due diligence, I read the topic “Prerequisites for Installing vCenter Single Sign-On, Inventory Service, and vCenter Server” and followed every step, however it appeared I did not RTFM enough.
administrator@vsphere.local only
Apparently vSphere will only attach the permissions and assign the role of administrator to the default account administrator@vsphere.local and you have to logon with this account after the installation is complete. See “How vCenter Single Sign-On Affects Log In Behavior” for the following quote:
After installation on a Windows system, the user administrator@vsphere.local has administrator privileges to both the vCenter Single Sign-On server and to the vCenter Server system.
It threw my off balance by allowing me to log in with the account that I used to install vCenter, this made me assume the account automatically received the appropriate rights to manage the vCenter server. To gain access to the vCenter database you must manually assign the administrator role to the AD group or user account of your liking. As an improvement over 5.1 vCenter 5.5 adds the active directory as an identity source, but will not assign any administrator rights, ignoring the user account used for installing the product. Follow these steps to use your AD accounts to manage vCenter.
1. Verify AD domain is listed as an Identity Source
Log in with administrator@vsphere.local and select Configuration in the home menu tree. Only when you are logged in with an SSO administrator vCenter will show the Single Sign-on menu option. Select Single Sign-on | Configuration and verify if AD domain is listed.
2. Add Permissions to top object vCenter
Go back to home, select menu option vCenter, vCenter Servers and then the vCenter server object. Select the menu option Manage, Permissions
3. Add User or Group to vCenter
Click on the green + icon to open the add permission screen. Click on the Add button located at the bottom.
4. Select the AD domain
Select the AD domain and then the user or group. In my example I selected the AD group “vSphere-admins”. I’m using groups to keep the vCenter configuration as low-touch as possible. When I need grant additional users administrator rights I can simple do this in my AD Users and Computers tool. Traditionally auditing is of a higher level in AD then in vCenter.
5. Assign Administrator Role
In order to manage the vCenter server all privileges need to be assigned to that user, by selecting the administrator role all privileges are assigned and propagated to all the child objects in the database.
6. Log in with your AD account
Log out the user administrator@vsphere.local and enter your AD account. Click on vCenter to view the vCenter Inventory list. vCenter Servers should list the new vCenter server.
Yup. The same thing happened to me :).
Yeah, same thing. I documented it some time ago here: http://www.vfrank.org/2013/09/23/how-to-log-in-to-single-sign-on-sso-in-vsphere-5-5/
Also you may have issues using AD Group and you you could have to add users manually to the Administrators Group on vCenter Server (see http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2059528 )
Annoying.
Since it has been awhile (and of course I did not keep any notes…) how does this differ from standing up a fresh 5.1 vCenter? Isn’t this the same behavior as 5.1?
Sure wish I would remember to document…any insight into the differences would be appreciated!
Great post Frank! This is such a common headache for vCenter administrators.
I have also found it useful to configure an external identity source in SSO prior to installing vCenter Server. This way you can configure the domain user or group that should be the initial vCenter administrator, using the installer.
I’ve blogged about this alternative solution: http://www.empiricvirtualization.com/2014/01/how-to-log-in-to-fresh-install-of.html
Shawn,
The difference is that v5.1 vCenter object will inherit permissions from the Authentication -> Users and Groups if there are no settings on the vCenter object itself. In 5.5, that no longer occurs. While you can explicitly set the permissions on the vCenter object in 5.1, it is not required due to the inheritance, thus many people skipped that step (including in many popular blogs describing VC5.1 SSO!). Given the single login that can make changes post-upgrade, I suggest enabling the permissions on the vCenter object prior to the upgrade to avoid the issue.
Great news, it looks like this issue has been resolved in vCenter Server 5.5.0b. You can read about it and my solution here: http://www.empiricvirtualization.com/2014/01/how-to-log-in-to-fresh-install-of.html
Unfortunately it’s not Joel, as I was using 5.5.0b.
Thank you, thank you, thank you! I’ve been messin’ with this for hours (days?) until I finally found this post. Whew!