I was testing vSphere 5.5 upgrades in my lab and came across an interesting situation that you need to be aware of.  In a nutshell, pay attention to how your Active Directory groups are configured on your vCenter Server and avoid nesting any domain level user or group accounts inside of local groups.

Here’s the situation I ran into.  My lab was running a vanilla vCenter 5.1 install.  In vCenter I only had one permission assigned, which is for the local “Administrators” group.

With this setup I was able to login with any user who was a member of the local “Administrators” group.  This included *both* the local administrator account as well as the domain administrator account.  The reason the domain administrator was able to login is because when my vCenter server joined the AD domain the “Domain Admins” group was automatically added as a member of the local “Administrators” group.  So the domain administrator’s access was obtained through a nested group membership – the  domain group “Domain Admins” was nested inside the local “Administrators” group, which was given permissions to vCenter.

While this nesting of a domain group inside of a local group worked with 5.1, it does not work with 5.5.  I discovered this following a successful upgrade to vCenter 5.5.  After the upgrade I could login as the domain administrator, but I couldn’t see any objects in the vCenter inventory.  (see

To fix this I had to explicitly assign permissions to the vCenter server for the “Domain Admins” group.   To do this I logged in as the local administrator, selected the vCenter server, then went to the “Manage” and “Permissions” tabs.  There I added full admin permissions for the “Domain Admins” group.

The take away here is when moving to vSphere 5.5, whether a new install or an upgrade, watch your group memberships and avoid nesting domain users and groups in with local groups.  Again, more information can be found in this knowledge base article:

About the Author

Kyle Gleed

Kyle Gleed is a Group Manager within VMware’s Integrated Systems Business Unit (ISBU) where he leads a team focused on the adoption and deployment of the solutions and capabilities of the Software-Defined Data Center. Follow Kyle on twitter @Kyle_Gleed