vCenter 6 'Empty Inventory' due to permissions

[jpiscaer]

I have a fully functional, completely working vCenter 6 environment. Admin users can log in and see the entire inventory, as they're supposed to.

However, I have a number of business users that need restricted permissions in a subfolder in the inventory. I have added a new role to vCenter with the permissions they need, and applied that role for that user to the specific subfolder.

Now: those users are not supposed to see any other folders in the inventory tree above of on the same level in the tree, just their own folder.

Before I upgraded to vCenter 6 (appliance), I had it working fine. With vCenter 6, this model broke: the users only see the 'empty inventory' text in the 'VMs and Templates' view.

Weird thing is: when that same user browses to 'vCenter Inventory Lists', clicks 'Virtual Machines', he sees his own (and only his own) VM and can interact with it in accordance with his permissions.

So it seems there's a new permission needed in vCenter to see only that part of the Inventory tree applicable to a specific user, but I (1) haven't found that permission yet and (2) wouldn't even know to which object in the tree to assign the permission

Any thoughts?

[vantonov]

Have the same issue. I gave a group of users access to the spicific folder and they see "empty inventory" through web client. Although they can see this folder through old client, but they are external users they can't use software clients, only web. Any thoughts? Also if I give this group read only permission to see the whole cluster, inventory shows up but also no rights to see Remote Console and etc. from the servers in question, even if I permit administartor access to them.

[unsichtbare]

You may need to add the same permission to the vCenter and Datacenter, but uncheck 'Propagate'

[jpiscaer]

I tried that, but that only gives me visibility into those specific objects, not the entire tree..

[vantonov]

We found out that this is clearly AD credentials issue. When we create local [e-mail] and give him the same privelegies it works like a charm in both Web and Classic client.

[jpiscaer]

Ow wow, that is a nasty issue! Guess this is something that only VMware can fix in a bug fix?

[vantonov]

I am sure it is. We have tested the thing on freshly installed vCenter, result is the same.

[jpiscaer]

I'm using Zentyal (OpenLDAP) as an identity source, added to vCenter as a 'Active Directory as an LDAP Server' identity source. I'm guessing VMware KB: OpenLDAP schemas supported in VMware vCenter Single Sign-On‌ is relevant here, specifically the part about entryUUID.

[vantonov]

We are using Microsoft Active Directory as a source, I don't think this article is for us.

[rnelson0]

Has anyone found a resolution to this? It's cropping up intermittently and the workaround of using the vcenter inventory list is not satisfactory.

[unsichtbare]

Higher-level objects (like: vCenter, Cluster and Datacenter) need specific permissions, but not propagating.

Lower-level objects (like: Resource Pool, VM Folder) need those same permissions, but allow to propagate.

Networks and Datastores need customized permissions because any permission which propagates from the vCenter or Datacenter will apply to everything equally.

Here is a write-up: Cloud permissions for VMware vSphere (Roles, Privileges and Permissions) | JohnBorhek.com

[rnelson0]

unsichtbare,

To confirm, you had the permissions assigned to the resource pool/datastore/networking and had no issues, then upgraded to v6 and encountered the bug? You then fixed it by adding the 'Create New' at the datacenter level without propagation?

[unsichtbare]

Not at all.

I am having no issues with permissions specific to vSphere 6. IMHO, permissions are working as well as in vSphere 5.X

Rather, I was concerned that that propagation/non-propagation was the issue here. I have worked with this issue many times and the solution is usually to create a non-propagating permission for the Datacenter level and then apply that permission with propagation at the:

• Resource Pool
• VM Folder
• Network
• Datastore

[rnelson0]

The solution at Cloud permissions for VMware vSphere (Roles, Privileges and Permissions) | JohnBorhek.com worked for me. Essentially, intermediate objects now need to be readable for users to have their rights at the lower level. Let's say your structure in the Hosts And Clusters view is:

• DataCenterA:
  • Cluster1:
    • HostA
    • HostB

In 5.5 you would have assigned rights to Cluster1 and everything was okay. In 6.0 you still assign rights to Cluster1, but also assign read-only (or higher) permissions that do not propogate on DataCenterA, and any other intermediate items.. All four views - H&C, VMs & Templates, Storage, and Networking - have the same issue, so add the read-only rights on all intermediate items in each view.

Thanks to unsichtbare for the tip on this!

[FreddyFredFred]

I have my custom role created (just allows basic access to power on/off vm and snapshot it). In 5.5, I could assign it to a folder under VMs and Templates (or to a specific VM) and everything was great. I built a new 6.0 vCenter and having the same problem as others now.

Following your example, if I have 10 different user groups using the same role, and if I want to prevent them from seeing other folders, it seems like I have to do the following:

Create an "all" group for all my user groups (to save adding permissions to a bunch of groups)

Data Center > Read-only, no propagate, to "all" group

All Clusters > Read-only, no propagate, to "all group"

VM folders > Custom role, propagate, to user group

If I have to make an exception for 1 vm for example, it seems like I need to assign a role to the VM and user, then go back to the folder, cluster and DC and give read-only permissions to this one user? That seems crazy and makes a huge mess out of the permissions.

I also discovered that if I remove a permission, regardless of whether it's on a test VM I'm using or a random folder, I get empty inventory. Add permission back, to anything, and I see my VMs again. That can't be normal?!?

[rnelson0]

I have started encountering further issues, most related to the inventory services, and the fixes suggested by support are not helpful. Logs are visible in the VCS  in new locations since 6.0, at C:\ProgramData\VMware\vCenterServer\logs\invsvc\inv-svc.log and C:\ProgramData\VMware\vCenterServer\logs\vsphere-client\logs\vsphere_client_virgo.log. Errors saying that the user doesn't have permission to see its own permissions don't seem to be very good. Later on, even after rebooting vCenter, it became impossible to start VMs via vCenter, though you could start them by connecting directly to the host. Something is wrong in the heart of this vCenter. It has done the 5.1->5.5->6.0 upgrade dance and, while we may have stumbled on some permissions issues, it looks like some corruption is present, maybe has been for a while.

While these problems may be fixable, I have wanted to migrate to the VCSA for a while so I am going to try that instead. I know this is not a resolution, but perhaps if you review those two logs for the users in question, you may find a clue, even if it's "permissions are not the only problem". Maybe that will help someone.

[FreddyFredFred]

I don't see much in the inventory service log on my side, but there's a few things in the virgo log. I see this error often:

The following exception occurred during request processing by the BlazeDS MessageBroker and will be serialized back to the client:  flex.messaging.MessageException: No destination with id 'userSessionServiceInternal' is registered with any service.

And then I have a few of these:

Property 'info' missing for object urn:vmomi:Task:task-8526:dc296043-ca55-404e-8b19-eaa8cb9d8563 com.vmware.vim.binding.vim.fault.NoPermission:

Unable to detect VcenterServer update version. Return: "0" com.vmware.vim.binding.vim.fault.NoPermission: Permission to perform this operation was denied.

But I'm not seeing anything that jumps out at me. I did open a ticket with VMware a few days ago but no updates.

[bnetech]

Hey Guys,

There is a easy way around this if you meet the following items:

• If you are on 6.0 u1 (I haven't tested early releases of 6.0)
• Access works in C# client but not with the web client
• Upgraded SSO from 5.x to version 6
• Used domain aliases in the past (most important)
• Also to note newly installed vcenter's will still have the same issue if you are using a existing SSO service.
  

To fix newly created permissions add the group or user with FQDN\USER or FQDN\GROUP not a ALIAS\*.  If you have upgraded and use the find group/user and then click add you will notice it still references the domain alias.

To fix older permission you can modify the VC DB and there is a KB article for this (I can confirm this also works fine for MS SQL): VMware KB: After upgrading to VMware vCenter Server Appliance 6.0 users are unable to view the inventory in the vSph…

[FreddyFredFred]

Anyone have any updates on this? I submitted a ticket to VMware a couple weeks ago but getting a callback (after the initial call) is proving to be impossible.

[FreddyFredFred]

I finally got a callback but I'm not that impressed with VMwares attitude. They can reproduce my problem and gave me a workaround except it doesn't fully work (the same thing others have suggested with read-only on multiple objects with no propagation). Once I make a change to a permission, upon refresh I get empty inventory again. User has two folers, remove access to one, they lose access to everything. They have taken note of my request  (make the web client permissions work properly like they did in 5.5) and maybe, eventually, somewhere, sometime, if someone wants to look at my request, they might do something.

I guess having a working web client with permissions that makes sense and work correctly without breaking every time there's a change is considered more of a feature request than a bug that needs fixing. At least that's the impression I was left with.

[Devastator126]

I am also experiencing the same problem. However I have noticed I can get it working for one user and then when I got to apply the permissions to the second users it breaks the first user. We have been waiting on a call back for about two weeks now.

[LandonUMN]

I have the exact same issue. We have a few dozen students with "Virtual machine user (sample)" permissions applied to their individual VMs. We had to apply Update 1 to fix this problem: VMware KB:    Users are unable to power on virtual machine with the Virtual Machine Power User role in vCenter Server 6…

to give them power access without granting them view access to all details on the host, cluster, data center and vCenter server up the tree (which is not appropriate access for students to our infrastructure, even if it is read-only). Then I emailed instructions on how to use the left menu/Navigator to find their VM. A couple days later, tickets come in that they no longer see their VMs but get an "Empty Inventory." With my test user, I could replicate both before and after.

The workaround for me was to tell everyone to search for their VM's name in the Search bar in the upper-right. That's letting them find and get access to their VM.

[emcKeith]

- VCSA 6.0 U1 (build 3018523)

- Web client 6.0.0 (build 2997665)

- Fat client 6.0.0 (build 2741530)

- Two vsphere.local users

- User1 is granted full administrator permissions to their own already created resource pool, vm folder, datastore and port group.

- Logging in as user1 with web client, user has access to their RP, vm folder, datastore and port group as expected.

- Next, user2 is granted full administrator permissions to their own already created resource pool, vm folder, datastore and port group.

- Logging in as user2 with web client, user has access to their RP, vm folder, datastore and port group as expected.

- But, logging back in as user1 with web client, user1 sees "empty inventory" in all views

- No issues when using fat client, but that's not an option for end users.

- Following steps of setting read-only at DC level etc did not resolve issue

[Inny]

In my case, running vCenter 6.0 U3, users were unable to view VM's to which they had "Virtual machine user (sample)" Permissions (Inherited to child items) through their containing folder.

The solution ended up being to assign them Read-only rights alongside their "Virtual machine user (sample)" Permissions (both Inherited to child items) through their containing folder.

In order to do this, I created a secondary Security Group SG_vCenter_Users with the primary Security Group SG_vCenter_VDI_Users as a Member.

It appears it was not necessary to add Read-only permissions at a higher level.

[Samiran Mukherjee]

I had the same issue and giving permission on the host level (read only) fixed the issue.

Looks like starting 6.0 we need to give permission at least on host level or VC level to view the object.

Hope this Helps!!!

Thanks!