VMware ESXi and vSphere Cluster Management

Assign Permissions to vCenter Server Inventory Objects in vSphere

Learn how to assign vSphere roles to users and groups on vCenter Server inventory objects, control inheritance, and verify delegated access.

A vCenter Server permission connects three things: a principal, a role, and an inventory object. The principal is the user or group receiving access. The role is a collection of privileges that defines allowed actions. The inventory object determines where those actions apply.

Authentication establishes identity: a directory or local account proves who is signing in. Authorization determines what that identity may do in vCenter Server. Permissions provide this authorization.

How vSphere Permissions Work

A privilege is an individual capability, such as viewing an object, configuring a virtual machine, or managing a resource. A role groups related privileges into a reusable permission set. A permission assigns that role to a principal on a particular object.

For example, assigning the MYDOMAIN\jdoe user a VM operations role on one virtual machine allows the privileges in that role to apply to that virtual machine. The same user does not automatically receive those rights on every object in vCenter Server unless another permission or inherited assignment grants them.

Permission assignment components

ComponentPurposeExample

Principal The user or group receiving authorization. MYDOMAIN\jdoe or MYDOMAIN\Virtualization-Operators

Role A named collection of vSphere privileges. Virtual machine operator or a custom role containing selected storage privileges.

Inventory object The resource or container where the permission applies. VM01, a folder, datastore, cluster, or datacenter.

Propagation Determines whether the assignment applies to child objects. Enabled for all workloads in a folder; disabled for one virtual machine.

Objects That Can Receive Permissions

vCenter Server manages an inventory hierarchy containing both resources and organizational containers. Common permission targets include:

  • Datacenters
  • Clusters
  • ESXi hosts
  • Virtual machines
  • vApps
  • Resource pools
  • Datastores
  • Networks
  • Folders

A higher-level object can provide access to descendants when propagation is enabled. For example, a permission on a folder can reach virtual machines inside that folder. A permission on a datacenter may reach its clusters, hosts, virtual machines, datastores, and networks, depending on the object hierarchy and propagation settings.

Choose the narrowest object scope that satisfies the requirement. Assigning access directly to a virtual machine is usually safer than assigning the same access at a datacenter level.

Common vSphere inventory objects and permission scope

Object typeTypical useEffect of propagationScope caution

Datacenter Broad infrastructure delegation. May reach many resource types below the datacenter. Use only when broad access is deliberate.

Folder Delegating access to a team or application grouping. Can reach child folders and objects. Confirm that unrelated workloads are not in the folder.

Cluster Managing hosts and workloads in a cluster. Can reach child hosts, resource pools, and virtual machines where supported by the hierarchy. Avoid using a cluster when only one VM needs access.

ESXi host Host-specific administration or inspection. Can affect objects associated with that host. Review the operational impact of host-level privileges.

Virtual machine Delegating operations on one workload. Normally limits the assignment to that VM when propagation is disabled. This is often the narrowest scope for VM support.

Datastore Providing storage-related access. Can reach subordinate objects only when applicable and when propagation is enabled. Use a datastore rather than a datacenter for storage-only duties.

Network Managing or viewing a specific virtual network. Propagation depends on the network object's place in the inventory. Do not grant broader infrastructure access for a network-only task.

Resource pool or vApp Delegating access to a workload grouping. Can reach contained child workloads. Verify the membership of the pool or vApp before enabling propagation.

Roles, Privileges, and Least Privilege

Select an existing role during permission assignment when it matches the user's operational responsibility. A standard predefined role is supplied by vSphere and represents a common permission set. A custom role is created for a more specific combination of privileges when predefined roles are too broad or too limited.

Apply least privilege: grant only the actions and object scope required for the task. A user who needs to power on and inspect one VM may not need permissions to alter clusters, hosts, datastores, or networking.

  • Match the role to the team's actual responsibilities.
  • Prefer a custom role when a predefined role includes unnecessary capabilities.
  • Review the privileges in a role before assigning it.
  • Consider both the role and the target object's scope; a limited role at a broad scope can still expose many objects.

Users, Groups, and Identity Sources

A principal can be an individual user or a directory group. The identity source identifies where vCenter Server searches for accounts, such as an Active Directory domain. Select the correct domain or identity source before searching for the account.

Group-based assignment is generally preferable when several people need equivalent access. Membership can then be managed in the directory instead of creating and maintaining repeated individual permissions in vCenter Server.

For an Active Directory example, select the MYDOMAIN identity source and search for jdoe. The resulting principal may be displayed as MYDOMAIN\jdoe. For a team, assign the role to a group such as MYDOMAIN\Virtualization-Operators instead of assigning it separately to every operator.

Assign a Permission in the vSphere Web Client

  1. Select the intended inventory object in the vSphere Web Client. Choose the specific VM, folder, datastore, cluster, or other object that should be the permission's scope.
  2. Open the object's Manage area.
  3. Open the Permissions view.
  4. Start the add-permission workflow.
  5. Add or select the target user or group. Choose the appropriate identity source or domain, then search for and select the principal.
  6. Select the role that matches the required responsibilities. Review whether it is a standard predefined role or a custom role.
  7. Set Propagate to children according to the required scope. Enable it only when descendants should receive the permission.
  8. Save the assignment.
  9. Refresh or reselect the object and verify that the principal, role, and propagation status appear in the permissions list.

Example assignment design

Identity source:       MYDOMAIN
Principal:             jdoe
Target object:         Selected vCenter Server inventory object
Role:                  Role appropriate to the requested responsibilities
Propagate to children: Enabled only when descendants require access

Understanding Permission Inheritance

Inventory objects form a hierarchy. A parent object can contain folders, clusters, hosts, virtual machines, datastores, networks, resource pools, or other child objects. When propagation is enabled, a permission assigned to the parent can become effective on eligible descendants.

For example, assigning a department group to a folder with propagation enabled can give that group the selected role on the virtual machines below the folder. Assigning the same permission directly to one VM limits the intended scope to that object when propagation is disabled.

Propagation should be reviewed carefully. A permission created on a datacenter, folder, or cluster can grant access to more objects than expected if the hierarchy contains additional workloads or resources.

Direct versus inherited permissions

Permission typeWhere it is assignedHow it reaches the objectWhen to use it

Direct Explicitly on the object being viewed. It applies because the assignment was made on that object. Use for a single VM, datastore, network, or other narrowly scoped target.

Inherited On a parent object. It reaches the child through propagation. Use for an intentionally managed group of related objects, such as all workloads in a team folder.

When reviewing a child object, distinguish an inherited entry from a direct entry. Removing or changing a direct permission on the child does not necessarily remove access inherited from a parent. To change inherited access, review the parent assignment and its propagation setting.

Practical Permission Scenarios

Grant access to one virtual machine

  1. Select the target virtual machine.
  2. Add MYDOMAIN\jdoe from the correct identity source.
  3. Assign a role suited to the required VM operations.
  4. Leave propagation disabled because the permission is intended only for that VM.

Delegate administration for a folder

  1. Select the folder containing the team's virtual machines.
  2. Assign a department group instead of individual accounts.
  3. Choose a role that matches the team's responsibilities.
  4. Enable propagation only after confirming that every child object in the folder should receive the access.

Provide limited datastore access

  1. Select the relevant datastore rather than the datacenter.
  2. Assign a role containing only the required storage-related privileges.
  3. Avoid propagation unless subordinate objects genuinely require the same access.

Grant broad infrastructure administration

  1. Select a high-level object such as a datacenter only when broad scope is deliberate.
  2. Assign the infrastructure administration group and the appropriate administrative role.
  3. Enable propagation only after confirming that all covered clusters, hosts, virtual machines, datastores, and networks should receive the intended access.

Verify the Assignment and Test Access

  1. Return to the selected object's permissions view.
  2. Confirm that the expected user or group is listed.
  3. Confirm that the assigned role is correct.
  4. Confirm whether propagation is enabled or disabled.
  5. Inspect relevant child objects if propagation was enabled and look for inherited entries.
  6. Test the account by performing the intended task.
  7. Attempt an unrelated administrative task, where safe, to confirm that unnecessary privileges were not granted.

Verification should check both positive and negative access: the principal should be able to perform the requested operation but should not gain unrelated administrative capabilities.

Permission Design Guidelines

  • Use the least-privilege role that supports the task.
  • Use directory groups instead of repeated individual assignments when access is shared.
  • Assign permissions at the lowest practical point in the inventory hierarchy.
  • Avoid unnecessary propagation from broad parent objects.
  • Review the contents of folders, clusters, and datacenters before assigning propagated access.
  • Document the purpose, target object, principal, role, propagation setting, and approving team for important permissions.
  • Review permissions periodically, especially after organizational or workload changes.

Troubleshooting Permission Assignments

The desired user or group cannot be found

  • Confirm that the correct identity source or directory domain is selected.
  • Verify that the account or group exists and is searchable in the directory.
  • Confirm that vCenter Server is configured to use the required identity source.

The user can sign in but cannot perform an expected action

  • Verify that the intended role was selected.
  • Review whether the role contains the privilege required for the action.
  • Confirm that the permission was assigned to the correct inventory object.
  • Check whether the user's access depends on inheritance that was not enabled.

The user can access more child objects than intended

  • Review the parent object where the permission was created.
  • Check whether propagation to children was enabled.
  • Move the assignment to a narrower folder or object scope, or disable propagation where appropriate.

The user has parent access but not access to a selected resource

  • Determine whether the resource is actually within the parent object's hierarchy.
  • Inspect direct and inherited permissions on the affected object.
  • Confirm that the parent permission was configured to propagate.

The permission does not appear after saving

  • Refresh the permissions view and reselect the inventory object.
  • Confirm that the assignment was saved against the intended object.
  • Verify that the administrator performing the change has sufficient authorization to manage permissions.

Key Exam Notes

  • A permission combines a principal, a role, and an inventory object.
  • A role contains privileges; the target object determines where those privileges apply.
  • Authentication identifies the account, while authorization determines allowed actions.
  • Propagation allows a parent assignment to apply to child objects.
  • Direct permissions are assigned on the object itself; inherited permissions come from a propagated parent assignment.
  • Group-based, least-privilege assignments at the narrowest practical scope are usually easier to manage safely.

For related administration, see vCenter Server permission assignment as the starting point for reviewing scope, roles, principals, and inheritance.