These days i stumbled upon a change in the behavior of permissions in vCenter 6.5.

On our vSphere 6.0 environment we are using many roles and permissions from a connected Microsoft active directory. We set permissions on the global and also at a lower level in the VMware permission hierarchy.

For a new customer, I had to build a new vSphere 6.5 environment. I connected the vCSA to a Microsoft active directory and set permissions the same way as in the 6.0 environment. After doing that I recognized that something seems to be wrong:

• The usage of access roles at the global level is no longer displayed under Administration/Access Control/Roles although I have permissions defined at that level.
• Some permissions which are defined at the global level with inheritance are set a second time at the vCenter level. (I didn´t create them at the vCenter level.)
• Some permissions are displayed as inherited from the global level at the vCenter level (which is right) but been shown as set at the vCenter level in the Administration/Access Control/Roles view.

 

First, I thought I made a mistake and destroyed the permission hierarchy by setting a fancy permission. Therefore, I set up a test environment with a complete fresh install of a vCSA 6.5 Build 5973321. I created a second VM with a Windows 2012 domain controller to be used as external identity source.

 

First finding:

After installing a fresh vCSA version 6.5 build 5973321 I discovered that permissions, which are set at the global level, are no longer displayed as used at that level. Even the administrator access role, which is set 4 times at the global level, is shown as used only at the vcenter level.

 

Second finding:

To test the different handling of permission inheritance, I add the domain controller as identity source. Additionally I created a new user and a new group in the local vsphere.local domain of the vCSA. Then I added both, a user and a group, from the active directory and the vsphere.local domain at the global level and enabled inheritance for that permissions. (I used the administrator role for all permissions.)

With that setting the usage of the access role at the global level still is not displayed under Administration/Access Control/Roles view. Instead they are displayed a used at the vCenter level.

 

At the vCenter level some permissions are shown as inherited, some not. The permissions from the external identity source are shown as not inherited. I tried to delete the permissions from the external identity source at the vCenter level but got a error. (“Remove operation failed.”)

So for me It looks like they are still a global permission but misleadingly shown as set at the vCenter level.

 

Third finding:

Because I want to configure some much more complex permissions as just granting administrative rights at the global level, I created a new access role named test. I add 2 more permissions at the global level with this role. One permission with a external user from the active directory, the second permission with a local user from the vsphere.local domain. Additionally I disabled inheritance for that permissions.

Checking usage of my access role under Administration/Access Control/Roles shows me that this role is not in use!

After enabling inheritance for this permissions the same behavior as for the administration role occurs. They are show as used at the vCenter level, while at the vCenter level only the permission for the internal vsphere.local domain is shown as defined as global permission.

 

My conclusion:

 

The whole thing seems to be a simple display error. But it is very annoying when you´re struggling with complex permissions. As roles shown as not used when they are only used at the global level (with no inheritance), there is a good chance that someone delete that role to clean up old access roles. (I tried that also. The permissions at the global level silently are deleted also.)

If you are trying to build complex permissions with and without inheritance in your vCenter you have to be extremely careful. Better wrote down what you configured and don´t trust in what´s shown to you in vCenter management.

 

Now that I know how to deal with this display error I could work further on installing the new environment for the customer. As soon as I find some time, I will open a case with VMware support. I´m curious what they will tell me.

 

Addendum (3-1-2018):

Finally found the time to open a case for this at VMware support. Got the answer that it is indeed a design error in permission handling. They directed it to development for further investigation. It will be fixed in one of the upcoming releases. No detailed informations available at this time when this will be fixed.