https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-security-guide.pdf
The permission model for vCenter Server systems relies on assigning permissions to objects in the vSphere
object hierarchy.
Each permission gives one user or group a set of privileges, that is, a role for the selected
object.
You need to understand the following concepts:
Permissions
Each object in the vCenter Server object hierarchy has associated
permissions. Each permission specifies for one group or user which
privileges that group or user has on the object.
Users and Groups On vCenter Server systems:
you can assign privileges only to authenticated
users or groups of authenticated users. Users are authenticated through
vCenter Single Sign-On. The users and groups must be defined in the
identity source that vCenter Single Sign-On is using to authenticate. Define
users and groups using the tools in your identity source, for example, Active
Directory.
vSphere Security
Roles:
Roles allow you to assign permissions on an object based on a typical set of
tasks that users perform. Default roles, such as Administrator, are predefined
on vCenter Server and cannot be changed.
Other roles, such as Resource Pool
Administrator, are predefined sample roles.
You can create custom roles
either from scratch or by cloning and modifying sample roles.
Privileges
Privileges:
are fine-grained access controls. You can group those privileges
into roles, that you can then map to users or groups.
------------------------
To assign permissions to an object, you follow these steps:
1 Select the object in the vCenter object hierarchy to which you want to apply the permission.
2 Select the group or user that should have privileges on the object.
3 Select the role, that is the set of privileges, that the group or user should have on the object.
By default,
permissions propagate, that is the group or user has the selected role on the selected object and its child
objects.
Permission assignments:
1. If an object inherits permissions from two parent objects, the permissions on one object are added to the
permissions on the other object.
2. Permissions applied on a child object always override permissions that are applied on a parent object.
***3. If multiple group permissions are defined on the same object and a user belongs to two or more of those
groups, two situations are possible:
3.1. If no permission is defined for the user on that object, the user is assigned the set of privileges assigned
to the groups for that object.
n
3.2 If a permission is defined for the user on that object,
the user's permission takes precedence over all
group permissions.
------------------------
Users in the vsphere.local domain.
SolutionUsers
Solution users group vCenter services.
Each solution user authenticates individually to vCenter Single Sign-On with a certificate.
By default, VMCA provisions solution users with certificates.
Do not add members to this group explicitly.
CAAdmins
Members of the CAAdmins group have administrator privileges for VMCA.
Adding members to these groups is not usually recommended.
DCAdmins
Members of the DCAdmins group can perform Domain Controller Administrator actions on VMware Directory Service.
***Do not manage the domain controller directly. Instead, use the vmdir CLI or vSphere Web Client to perform corresponding tasks.
SystemConfiguration.BashShellAdministrators
This group is available only for vCenter Server Appliance deployments.
A user in this group can enable and disable access to the BASH shell.
By default a user who connects to the vCenter Server Appliance with SSH can access only commands in the restricted shell. Users who are in this group can access the BASH shell.
ActAsUsers
Members of Act-As Users are allowed to get actas tokens from vCenter Single Sign-On. ExternalIPDUsers
This group is not used by vSphere. This group is needed in conjunction with VMware vCloud Air.
SystemConfiguration.Administrators
Members of the SystemConfiguration.Administrators group can view and manage the system configuration in the vSphere Web Client.
These users can view, start and restart services, troubleshoot services, see the available nodes and manage those nodes.
DCClients
This group is used internally to allow the management node access to data in VMware Directory Service.
NOTE Do not modify this group. Any changes might compromise your certificate infrastructure.
ComponentManager.Administrators
Members of the ComponentManager.Administrators group can invoke component manager APIs that register or unregister services, that is, modify services. Membership in this group is not necessary for read access on the services.
LicenseService.Administrators
Members of LicenseService.Administrators have full write access to all licensing related data and can add, remove, assign, and unassign serial keys for all product assets registered in licensing service.
Administrators
Administrators of the VMware Directory Service (vmdir). Members of this group can perform vCenter Single Sign-On administration tasks.
Adding members to this group is not usually recommended.
----------------------------------
vCenter Server provides system roles and sample roles by default:
1. System roles
System roles are permanent. You cannot edit the privileges associated with
these roles.
Administrator Role, No Access Role, Read Only Role
***The administrator@vsphere.local user, the root user, and vpxuser are the
only users not assigned the No Access role by default. Instead, they are
assigned the Administrator role.
You can remove the root user from any
permissions or change its role to No Access as long as you first create a
replacement permission at the root level with the Administrator role and
associate this permission with a different user.
***With Read Only Role a user can view
virtual machine, host, and resource pool attributes. The user cannot view the
remote console for a host. All actions through the menus and toolbars are
disallowed.
2. Sample roles
VMware provides sample roles for certain frequently performed
combination of tasks.
You can clone, modify or remove these roles.
VM User Role, VM PowerUser Role, DataStore Consumer Role, Network Consumer Role,
Resource Pool Administrator
***To avoid losing the predefined settings in a sample role, clone the role
first and make modifications to the clone. You cannot reset the sample to its
default settings.
