In more than one instance, I have experienced a situation where we had
issues with managing permissions in both vCenter (vSphere 4) and
VirtualCenter (VI3). The issue is that a user loses access rights when a
group to which the user belongs is added with less permissions.
An example could be that a given user, 'UserA', has administrator rights at the top level (Hosts and Clusters) and then at a lower level (let's say at Datacenter level), a given security group, Group1, in which UserA exists is given, let's say, 'Virtual Machine User' rights. This will decrease the permissions for UserA on that datacenter to only Virtual Machine User in stead of Administrator - he cuts the tree under himself, so to speak.
The consequence can be that in stead of risking this scenario of suddenly losing access rights when groups are added, then security groups are not used at all, only single users are added. This is not a problem when only a few users needs acces to the vCenter or VirtualCenter. However, if many users need access, e.g. 20-40 employees, it gets rather complex to manage.
To be absolutely sure how these permissions work, I have done a bit of testing on both vCenter and VirtualCenter.
Test cases
First of all, permissions seem to work identically in both versions, that is VI3 (VirtualCenter) and vSphere (vCenter). Furthermore, when permissions are changed in vCenter, then they are applied more or less instantaneously. So if you change or configure permissions for a user that has the vSphere client open, then the changes will appear to the user at the same time while he has the vSphere client (or VI Client) open (this makes it nice and easy for testing purposes, by the way...)
If the administrator role is assigned to UserA at the Hosts and Clusters level, and then he is assigned less permissions at a lower level (e.g. at a given Cluster), then the less permisssions on that lower level will win.
It works the same way the other way around, if UserA has 'Read only' on Host and Clusters and Administrator rights at a given Datacenter, then UserA will have full rights on that Datacenter and read only on the rest of the virtual environment.
If UserA has Administrator rights at the Hosts and Clusters level and at the same time a group to which UserA belongs is added with Read only to the same level - the interesting question is which of the two different permision levels will UserA be granted, Administrator (as a single user) or Read only (as he belongs to the group)?
The answer is that the highest defined permissions defined at a given level for a user will win. In the case UserA will have administrator rights at hosts and clusters level.
Administrators group
Another thing to be aware of is that Windows Administrators on the vCenter server are automatically added as administrators in vCenter. If you do not intend to give all of your Windows admins full acces to your VMware environment, then remove the 'Administrators' group from vCenter (in stead, you can add the local administrator user a an administrator in vCenter, so you have the possibility to log in with a local account should AD fail..)
Security groups or Distribution lists
Only security groups defined in Active Directory (AD) can be used as groups in vCenter. Distribution lists won't work.
Recommendations for managing users
In regards to the use of groups for managing users in vCenter, I recommend that groups are used at the hosts and clusters level (of course, this can vary greatly depending on your setup). For example, you could have three groups:
Even though a VMware admin belongs to several groups, as long as these are defined at the same level, then he/she will retain administrator rights.
By using security groups, then the VMware admins won't have to manage user administration on the VMware environment. When a user is added to a given group in AD (this should be handled by your user administration department or system), then he automatically gets access to vCenter.
An example could be that a given user, 'UserA', has administrator rights at the top level (Hosts and Clusters) and then at a lower level (let's say at Datacenter level), a given security group, Group1, in which UserA exists is given, let's say, 'Virtual Machine User' rights. This will decrease the permissions for UserA on that datacenter to only Virtual Machine User in stead of Administrator - he cuts the tree under himself, so to speak.
The consequence can be that in stead of risking this scenario of suddenly losing access rights when groups are added, then security groups are not used at all, only single users are added. This is not a problem when only a few users needs acces to the vCenter or VirtualCenter. However, if many users need access, e.g. 20-40 employees, it gets rather complex to manage.
To be absolutely sure how these permissions work, I have done a bit of testing on both vCenter and VirtualCenter.
Test cases
First of all, permissions seem to work identically in both versions, that is VI3 (VirtualCenter) and vSphere (vCenter). Furthermore, when permissions are changed in vCenter, then they are applied more or less instantaneously. So if you change or configure permissions for a user that has the vSphere client open, then the changes will appear to the user at the same time while he has the vSphere client (or VI Client) open (this makes it nice and easy for testing purposes, by the way...)
If the administrator role is assigned to UserA at the Hosts and Clusters level, and then he is assigned less permissions at a lower level (e.g. at a given Cluster), then the less permisssions on that lower level will win.
It works the same way the other way around, if UserA has 'Read only' on Host and Clusters and Administrator rights at a given Datacenter, then UserA will have full rights on that Datacenter and read only on the rest of the virtual environment.
If UserA has Administrator rights at the Hosts and Clusters level and at the same time a group to which UserA belongs is added with Read only to the same level - the interesting question is which of the two different permision levels will UserA be granted, Administrator (as a single user) or Read only (as he belongs to the group)?
The answer is that the highest defined permissions defined at a given level for a user will win. In the case UserA will have administrator rights at hosts and clusters level.
Administrators group
Another thing to be aware of is that Windows Administrators on the vCenter server are automatically added as administrators in vCenter. If you do not intend to give all of your Windows admins full acces to your VMware environment, then remove the 'Administrators' group from vCenter (in stead, you can add the local administrator user a an administrator in vCenter, so you have the possibility to log in with a local account should AD fail..)
Security groups or Distribution lists
Only security groups defined in Active Directory (AD) can be used as groups in vCenter. Distribution lists won't work.
Recommendations for managing users
In regards to the use of groups for managing users in vCenter, I recommend that groups are used at the hosts and clusters level (of course, this can vary greatly depending on your setup). For example, you could have three groups:
- VMware admins (Administrator)
- VM admins (Deploy/destroy rights, change VM specs, etc.)
- Windows admins (console access to the VMs, similar to ILO access on physical servers)
Even though a VMware admin belongs to several groups, as long as these are defined at the same level, then he/she will retain administrator rights.
By using security groups, then the VMware admins won't have to manage user administration on the VMware environment. When a user is added to a given group in AD (this should be handled by your user administration department or system), then he automatically gets access to vCenter.
No comments:
Post a Comment