Here is a decent doc on permissions on VI: http://www.vmware.com/pdf/vi3_vc_roles.pdf
I will also say that in a discussion with support around permissions they seemed to favor using deny. We had so far avoided it ourselves but we have a pretty simple hierarchy.
Seen that before. I don't need a complex role/privelege setup. I simply want to allow admin rights to a different group of users.
I know who I want to have access. I don't know who I don't want to have access. Negative permissions are never not uneasy to use. To keep them working I have to remember to add people to the group when the group I'm negating changes. This is a maintenance hassle.
My main question is why can't I remove the Admins propagation after I've added the Vlan1 administrators group. I'm in it. There are still admins applied to the group. Why complain?
I am thinking you can. You were just being warned the requested change could /bleave the system without full administrative privilege... I think this is just VC not fully understanding what you are doing so it is displaying a pretty stern warning so you think before you do.
I haven`t tried to do this myself though so I would be trying this out in a sandbox environment first.
Nope. Just an OK and the permissions still show the propagate box checked when reviewed after clicking OK.
Hence my confusion. Sounds like a warning. Really it's an error messge, bc it doesn't do what it's warning you about. If it was a warning there would be a cancel button.
I've opened SR 189486521. (I remember when SR numbers were 5 digits long). Looks like we've done 200 million SRs since those days. Price of progress.
There is an easy explanation to this.
It keeps people from cutting their feet off. This was a huge problem in the past, so VMware has restricted the removal of the base Administrator role assignment.
Very similar to Windows permissions, or eDirectory... once Admin is granted it can't be removed below. Well, you can try, but effective rights remain at superuser level.
The key is, only those who should have FULL access within your Virtual Infrastructure should be assigned the Administrator role. Period. If you ever think you need to restrict this person below, don't assign them Admin. Create a new role(s) that provides what they require, and assign only where needed.
Bottom line: You cannot remove the Administrator role assignment.
And that's covered in the docs where?
Ya know, now that I think about this... what I mean is:
You must have an Administrator role assigned at every level of the infrastructure... however, I'd have to test if this can be reassigned at various levels. As long as you assign the new group the Administrator role, then remove the original, I'm not sure why that wouldn't work. However, I do believe the the Admin from the higher level will be able to reset the permission on this newly restricted folder. Again, would have to test when I get a chance. Also, the new Admin group must have a local server account as a member, I think, in the event that VC server becomes isolated from the Domain.
sorry, been away from the office & my vm children for 3 weeks. not yet thinking entirely clearly. Hope above makes sense.
Don't think this can be changed. You basically can change which group is associated with administrators, but only once, afaik.
What we did to get this to work is create a M$ sec. group and added the admins into it. We then added the "Administrators" role to that group, and added the "Read-Only" role to the (local) Administrators group on VCS. Now all of our nosey domain admins who are local admins on various machines cant connect into our VI environment and break things!
I created a local account on the VC server and added it as Administrator set to not to propagate. I have done this in the past to test what rights I need to give someone before going live. This time I go to the datacenter to add the account and I get this message. I go back to the Host and Clusters and try to change it to propagate, however the message appears. I can not even remove the account any more.
I know this can be removed in SQL, but wanted to see if there was a way to fix this from the VC.
This was not an issue with 3.0 or 3.1.