Cannot add permissions to a VM

[keljo]

I'm having problems adding or changing permissions on one VM only. I am logged in with an account that has the Administrator role. When I click on the permissions tab and right click on a user that has permissions, everything is grayed out including viewing properties for the user. If I go to any other VM, I can delete or add users and groups just fine. Anyone have any ideas?

[bretti]

What is grayed out? When you right click on the user do you get the options for delete and properties? If you click on properties does it bring up the change access rule box?

Is this VC 1.4 or VC 2.0?

[keljo]

When I right click, I can see the options to delete and properties, but they are both grayed out. I cannot click on either one. This is VC 2.0.1.

[keljo]

Let me ask this - it might have something to do with it. If I am apart of the Administrators role, but also on this VM lets say I am also a member of another group that has read-only rights as well. Which group wins? This might be what's happening, although I took myself out of the read-only group and I still can't do anything. But I would like to know which right at that point is applied, the read-only one or the admin.

[bretti]

I believe the role with the most privileges wins. So being in a read only group should not affect it. I'll try that over here and see if I get the same results.

[bretti]

I added myself to the read only permissions, logged out and back in and was not affected. I still had all the privileges I had before as an admin. So I think you can safely rule that out.

[keljo]

Thanks everyone for all of the suggestions. I'll go through them one by one.

-Yes, this is for one VM only that I'm having the problems.

-Yes I get the same problem when going through Inventory and permissions. They are still grayed out.

-It does say defined in "This object". But even if it wasn't, I should be able to see the properties.

-After I removed myself from the read-only group, I did log out and back in, but still the same problem.

Any other ideas, I'm kind of out now that impensb ruled out the permission thing?

[bretti]

Anyone else have any ideas?

Can you remove the host and VM's from the inventory? Then add it back in?

Message was edited by:

impensb

[keljo]

Ok, we figured it out. And this is really weird, it almost has to be a bug. At the very highest level, we just added another user account that had admin privs, exactly like the acct I was logged in as. We then logged in as that acct, and could change stuff. So we removed the Users group that had the read-only rights and then I logged out with my acct and logged back in and everything was like normal. I could then right click and delete or view properties. That just doesn't make any sense. The acct we added at the top level has the same permissions and is at the same level as my acct. At any rate, it's fixed now, thanks for all the great ideas and help.

[bretti]

That does seem odd. Glad to hear it's working.

[jhicks]

I added myself to the read only permissions, logged

out and back in and was not affected. I still had

all the privileges I had before as an admin. So I

think you can safely rule that out.

Yes, but how did you test this? While this thread references the root only (i think), there are several scenarios that need to be tested. Results in one may not be consistent with another:

1. Both RO & Admin permissions at root of Hosts & Clusters

2. RO at root, Admin at a lower level (e.g. Folder)

3. Admin at root, RO at a lower level

Some folks have reported the RO permissions overriding Admin. This may have been prior[/b] to 2.0.1 though. Maybe ALL the bugs weren't worked out...

[bretti]

I agree there does seem to be more to the Read Only role than we have discovered here.

FWIW my test was this. 2.0.1

At the root of Hosts & Clusters.

Administrators User/Group - Administrator Role

Read-Only User/Group - Read-Only Role

To start with my account was only a member of the Administrators Group.

I closed Virtual Center.

Added my account the Read-Only Group.

Waited a few minutes for AD replication.

Logged on to Virtual Center.

Could still right click and view the properties of a permission.

That was it, I did not go much further than that.

Thanks

Brett

[keljo]

The only thing I see different from your test and my actual scenario is that my read-only group that had the read-only role was applied at the VM level, not at the top level. So the admin group I was in was applied at the top level, but the read-only users group I was also in was applied only to the VM. Maybe that is the reason we had the problem.

It still is weird though, because the user acct we fixed it with had the exact same privs at the exact same level as my acct. Oh well, just seems like we should be careful with the roles we add huh?!

[bretti]

Good info. I guess we do need to be careful. :smileygrin:

[jhicks]

Maybe that is the reason we had the problem.

I thought this might be the case. However, it may also be some sort of order of processing by VC - given the inconsistency you saw between two users.

Try two new users;

On the first, allocate the RO permissions first then the Admin permissions. Then try Admin followed by the RO role. I'm wondering if VC is just sequentially applying the permissions (based on the order they're listed in the permissions table), instead of merging them as its supposed to.

Message was edited by:

hicksj

[atdude]

After reading your post, I recreated the situation in a test environment. Other than re-installing, I found the following to work -

1) If not already, make the VirtualCenter server a member of a domain

2) Run DCPromo, and promote the VirtualCenter server to a Domain Controller. This will remove/disable the "Local Users and Groups", therefore the "Users" group assigned Read-Only permissions is no longer valid.

3) Reboot and log back in to the VirtualCenter server, and verify that only the "DOMAIN\Domain Admins" group has Administrator permissions

4)Re-run DCPromo, and remove the Domain Controller functionality from the VirtualCenter server (this will re-enable the Local Users and Groups). This will prompt you for a new Local Administrator account password

5)Reboot and login again to the VirtualCenter server as a Domain Admin, and grant the LOCAL administrator account "Administrators" VirtualCenter permission(s)/Role

6) You should now be good-to-go.

Granted, this method is fairly time-consuming but it will at least prevent you from having to re-install ESX. I suppose another option is, if you happen to have multiple VirtualCenter servers, is to add the ESX host to another VirtualCenter server/datacenter/whatever.

[jhicks]

So the admin group I was in was

applied at the top level, but the read-only users

group I was also in was applied only to the VM.

Maybe that is the reason we had the problem.

Yes, this is how the permissions are supposed to work. Rights assigned "closer" to the object take precedence. If there are two direct assignments at the same level, it becomes a union.

This way you have the ability to override previously granted (at a higher level, e.g. Data Center) permissions should you need to restrict the user down lower (i.e. at the VM level).

atdude:

I'm not sure what your original problem was that you're trying to solve with this process. If you mistakenly cut off permissions of your Admins, you should instead modify the database, removing the offending row in the access table.

[jhicks]

It is supposed to be a Union.

However, this is not how it always works. This has been discussed quite a bit on the forums.

You need to logout of VC and back in for the changed permissions to be applied.

[bretti]

And it's just for this one VM right?

Try this, it should produce the same results. Click on the user role on the permissions tab so that it is highlighted. Then from the menu at the top, select Inventory, then Permission. Are those options still grayed out also?

Message was edited by:

impensb

[bister]

What does the "Defined in" column say? If it's not "This object" you cannot alter this setting because it is defined in a level above.

Regards,

Christian

[bretti]

That's true, but you should still be able to click the properties of the permission to see what's in it.

If you try to change one that is propagated from another location other than the original object you get a warning message.

"The permission for the user/group, someuser/somegroup[/i] is inherited from the object, someobject[/i]. Modifying it for this object will create a new permission for this object, and not change the original permission."