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:

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.
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 are fine-grained access controls. You can group those privileges into roles, that you can then map to users or groups.
Figure 1. vSphere Permissions
Several privileges are combined in a role. The role is assigned 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.

The permissions model makes it easy to get things done quickly by offering predefined roles. You can also combine privileges to create custom roles. See Defined Privileges for a reference to all privileges and the objects to which you can apply the privileges. See Required Privileges for Common Tasks for some examples of the sets of privileges you need to perform these tasks.

In many cases, permissions must be defined on both a source object and a destination object. For example, if you move a virtual machine, you need some privileges on that virtual machine, but also privileges on the destination data center.

The permissions model for standalone ESXi hosts is simpler. See Assigning Permissions for ESXi

vCenter Server User Validation

vCenter Server systems that use a directory service regularly validate users and groups against the user directory domain. Validation occurs at regular intervals specified in the vCenter Server settings. For example, if user Smith was assigned a role on several objects, and the user’s name was changed to Smith2 in the domain , the host concludes that Smith no longer exists and removes permissions associated with that user from the vSphere objects when the next validation occurs.

Similarly, if user Smith is removed from the domain, all permissions associated with that user are removed when the next validation occurs. If a new user Smith is added to the domain before the next validation occurs, the new user Smith is replaces the old user Smith in permissions on any object.