VMware Cloud Community
abeleski
Contributor
Contributor
Jump to solution

Permissions Issue. Admins Locked out. Delete options greyed out. HELP!

Hi I hope somebody can help me resolve this.

We run VC2.5 with 3 clusters of ESX 3.5. The VC server is a member of a windows domain. Today I added an Active Directory group to one of the clusters and gave it the Read Only role. When I look at the permissions tab of the cluter where I added the group I see (Domain\Group - Read Only- This Object) AND (Administrators-Administrator-Hosts & Clusters).

What happens now is that I cannot perform certain functions within that cluster when I am logged in as myself i.e an Administrator. I also cannot remove the Role nor the Group I added to the cluster. When I try the options are greyed out. I also cannot change the Role to any other Role.

Could please somebody let me know how to resolve this? I sSeems to be a bug to me but I could be wrong.

Thanks in advance.

Reply
0 Kudos
1 Solution

Accepted Solutions
JonRoderick
Hot Shot
Hot Shot
Jump to solution

Sounds as though your admin ID in the Administrators group is also a member of the Domain/Group that has read only rights. As the permissions are least rights wins, you're only getting the read-only permissions.

Suggest you check the membership of the Domain/Group and log in with an ID that is a member of the Adminstrators group but NOT the Domain/Group.

Good luck.

Jon.

View solution in original post

Reply
0 Kudos
11 Replies
JonRoderick
Hot Shot
Hot Shot
Jump to solution

Sounds as though your admin ID in the Administrators group is also a member of the Domain/Group that has read only rights. As the permissions are least rights wins, you're only getting the read-only permissions.

Suggest you check the membership of the Domain/Group and log in with an ID that is a member of the Adminstrators group but NOT the Domain/Group.

Good luck.

Jon.

Reply
0 Kudos
hicksj
Virtuoso
Virtuoso
Jump to solution

Sounds as though your admin ID in the Administrators group is also a member of the Domain/Group that has read only rights.

As the permissions are least rights wins, you're only getting the read-only permissions.

Re: conflict, agreed.

Re: "least rights" - that is not true. The issue is that the "Administrator" role is inherited at the Cluster level, while the other role has been directly assigned to the Cluster. The "closer" assignment "wins" (NOT the least restrictive)

Had BOTH roles been assigned directly to the Cluster, the effective permissions for a member of both groups would be a UNION.

Edit: I recommend using AD groups that have been defined only for Virtual Center purposes, rather than using existing general purpose groups - unless you have well defined role based groups in AD that do not tend to cause this type of conflict.

weinstein5
Immortal
Immortal
Jump to solution

hicksj nailed it on the head - permissions assigned to an object take precedent over inherited permissions -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
Reply
0 Kudos
JonRoderick
Hot Shot
Hot Shot
Jump to solution

Thanks for setting me straight but I'm sure I had a similar problem the other day, where both groups were defined at the datacenter level - surely there must be some kind of least-privilege system at work then? I'm off work at the moment but will check it out again in a few weeks.

Cheers.

Reply
0 Kudos
weinstein5
Immortal
Immortal
Jump to solution

if you think roles are a group of assigned priveledges - either you can do something or not - so when two groups are assigned permissions at the same object the privledges become a union of the assigned priveledges -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
Reply
0 Kudos
abeleski
Contributor
Contributor
Jump to solution

Come to think of it, my userid IS a member of both the Administrators group AND the group which I added that has read only rights. I am not at work at the moment but will check it out tomorrow. Totally separate AD groups for VC makes sense so this does not happen in future if it ends up being the problem. I will let you all know how I go.

Thanks for all your inputs guys. Much appreciated.

Reply
0 Kudos
JonRoderick
Hot Shot
Hot Shot
Jump to solution

Thanks - I'm still pretty sure that read-only must trump any other assigned privileges, inherited or explicit. Would kind of make sense really - you want to restrict a user to read-only and not run the risk of someone else elevating privileges via a back door.

Anyway, no use yakking about it if I can't back it up with evidence so I'll check back when I have had a chance to play on my test rig.

Cheers.

Jon

Reply
0 Kudos
hicksj
Virtuoso
Virtuoso
Jump to solution

Jon - Perhaps you had used a User assignment along with a Group assignment? When a User is assigned one role directly to an object, while simultaneously a member of a group that's assigned another role directly on that same object, the role assigned to the user will take precedence (there is no UNION in this case).

Reply
0 Kudos
JonRoderick
Hot Shot
Hot Shot
Jump to solution

Think I was using groups but can't be certain - will check.

Reply
0 Kudos
abeleski
Contributor
Contributor
Jump to solution

Jon's suggestion was spot on. My userid was also a member of the group which I assigned to the cluster for RO access. After removing my userid from the group it now works as it should. I have full rights again. I have been playing with permissions for 2 days and the whole time it didnt make sense to me how it behaved. Until yesterday I managed to completely lock myself out while trying to understand the permissions. Now thanks to Jon, I understand what was going on the whole time. Should have thought of it myself. Forgot that I was also a member of that group.

I would like to thank you all for your input. I have learned more about how permissions work in VC. By the way is there a document which I can read to find out more about permissions and roles?

Thanks again.

Reply
0 Kudos
JonRoderick
Hot Shot
Hot Shot
Jump to solution

Not sure if you've had a look at the vmware documentation site but try the Basic System Admin guide (page 265 of ).

Also, I see you're using AD (same as me and most other people) - don't forget to plan for access to VC when AD is unavailable for some reason - i.e. build in some acess method that doesn't require AD to be functioning in order to work. Granted that if you're AD is bust, you've probably got bigger problems than getting VC access but it's one less problem to handle.

Cheers (and thanks for the points).

Jon

Reply
0 Kudos