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.

The following concepts are important.


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.


Privileges are fine-grained access controls. You can group those privileges into roles, that you can then map to users or groups.


Roles are sets of privileges. 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. See Create a Custom Role and Clone a Role.

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 to which you want to apply the permission in the vCenter object hierarchy.

  2. Select the group or user that should have privileges on the object.

  3. Select individual privileges or a role, that is a 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.

vCenter Server offers predefined roles, which combine frequently used privilege sets. You can also create custom roles by combining a set of roles.

Permissions must often be defined on both a source object and a destination object. For example, if you move a virtual machine, you need privileges on that virtual machine, but also privileges on the destination data center.

See the following information.

To find out about...


Creating custom roles.

Create a Custom Role

All privileges and the objects to which you can apply the privileges

Defined Privileges

Sets of privileges that are required on different objects for different tasks.

Required Privileges for Common Tasks

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

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, assume that user Smith is assigned a role on several objects. The domain administrator changes the name to Smith2. 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 replaces the old user Smith in permissions on any object.