VMware ESXi and vSphere Cluster Management

Assign Permissions to vCenter Server Inventory Objects

Learn how to assign role-based permissions to vCenter Server inventory objects, select users or groups, choose propagation, and verify access.

vCenter Server permissions control which actions a user or group can perform on managed vSphere resources. A permission connects three things: an identity, a role, and an inventory object. The role supplies the allowed privileges, while the inventory object determines where those privileges apply.

This workflow is performed in the vSphere Web Client, the browser-based administrative interface for vCenter Server. It is different from assigning permissions directly while managing a standalone ESXi host. For background, review communication between vCenter Server and ESXi and the vSphere access control system.

How vSphere permissions work

A user is an individual identity that can receive access. A group is a collection of users that can receive one common assignment. The identity is also called the principal in access-control terminology.

A role is a named collection of privileges. A privilege is authorization for one specific action, such as viewing an object, powering on a virtual machine, or changing its configuration. A permission assigns a role to a user or group on an inventory object.

An inventory object is a manageable resource or container in vCenter Server. Examples include a datacenter, cluster, ESXi host, virtual machine, vApp, resource pool, datastore, network, or folder. The resulting access depends on both the role and the location where the permission is assigned.

Component	Purpose	Example
User or group	Identity receiving access	Active Directory group `VM-Operators`
Role	Named collection of allowed privileges	An organization-approved VM administration role
Privileges	Individual authorized actions contained in a role	Power on, console access, or reconfigure a VM
Inventory object	Resource or container where access applies	A VM, folder, datastore, or datacenter
Propagation setting	Controls whether the assignment is inherited by child objects	`Propagate to children` enabled on a VM folder

Inventory objects that can receive permissions

vCenter Server lets administrators assign access at different points in the inventory hierarchy. Common targets include:

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

Use a broad container when a team needs the same access across many related objects. Use a specific resource when access must be limited to one VM, datastore, network, or other object. Assigning access at a high-level object can unintentionally expose many child objects, so select the smallest suitable scope.

Choosing the permission scope

Assignment Target	Typical Use	Impact of Propagation	Access-Control Consideration
Datacenter	Delegating access across a large administrative boundary	Can reach many contained folders, clusters, hosts, and VMs	Use only when broad access is necessary
Cluster	Managing workloads or hosts in one cluster	May apply to child hosts, pools, and VMs depending on the hierarchy	Check whether all workloads in the cluster share the same boundary
Folder	Giving a team access to an organized set of VMs or resources	Applies to child objects when enabled	Keep objects with similar ownership and access requirements together
Individual virtual machine	Providing access to one VM	Normally no child-resource inheritance is needed	Good choice for exception-based or least-privilege access
Datastore	Delegating storage administration or datastore visibility	Does not automatically mean access to every unrelated datastore	Review permissions inherited from parent objects
Network	Allowing a team to use or manage a specific virtual network	Scope remains tied to that network object and its hierarchy	Avoid granting access to a broader network container unnecessarily
Resource pool	Delegating workload management within a resource boundary	Can affect child pools or VMs when propagation applies	Confirm that the role cannot manage resources outside the intended pool

Least-privilege design

Least privilege means granting only the access required to complete the task. Before assigning a permission, identify the required object, the required actions, and whether the assignment must cover future child objects. Prefer a narrowly scoped object and an organization-approved role over a broad datacenter assignment or an unnecessarily powerful role.

Prerequisites and identity sources

Before beginning, confirm that you can manage permissions in the target vCenter Server and that the required identity source is available. An identity source is a configured directory or authentication domain from which vCenter Server can locate users and groups. Active Directory is a common identity source.

When possible, assign access to a directory group instead of individual users. Group-based assignments simplify onboarding and offboarding, provide a consistent audit trail, and reduce the number of permission entries. Use an individual assignment only when the access is genuinely specific to that person or a group is not practical.

Assign a permission in the vSphere Web Client

Select the target inventory object in the vSphere Web Client. Choose the folder, datacenter, cluster, VM, datastore, network, resource pool, or other object where access should begin.
Open the object's management area by selecting Manage, and then open Permissions. Interface labels can vary slightly by vSphere version.
Start the workflow with the add-permission control, commonly shown as an add button or plus icon.
In the identity selector, choose the appropriate domain or identity source.
Search for the intended user or group. Check the spelling and search criteria, then select the matching account.
Use the control to add the selected account or group to the permission assignment.
Choose the required role. Select a built-in role or an organization-approved custom role that matches the task.
Review the privileges included in the role before saving. Confirm that the role permits the required action without granting unnecessary administrative capabilities.
Decide whether to enable Propagate to children. Enable it only when child objects should inherit the assignment.
Confirm or save the assignment.
Return to the object's Permissions view and verify that the new entry is listed.

Target object: Operations VMs folder
Identity source: Example Active Directory domain
Principal: VM-Operators
Role: Organization-approved VM administration role
Propagate to children: Enabled when all child VMs share the same access boundary

Selecting a user or group

The identity-selection dialog typically provides a domain or identity-source selector and a search field. Select the domain that contains the account, search for the user or group, and add the result to the assignment. For example, select the appropriate directory domain, search for jdoe, and add that user before choosing a role.

If the intended account cannot be found, do not substitute a similarly named account without verification. Confirm the selected domain, verify that the account or group exists, check spelling and search filters, and ensure that the identity source is configured and reachable by vCenter Server.

Selecting a role

The role determines the actions available after the permission is applied. A role may allow viewing, operating, or modifying an object, depending on its privileges. Select a built-in role or an organization-approved role that matches the documented responsibility.

Review the role's privileges before confirming the assignment. A user may be able to sign in successfully but still be unable to perform a task if the role lacks the required privilege. Conversely, a role with excessive privileges can grant broader control than intended.

Propagation and inheritance

Propagation is the inheritance of a permission from a parent inventory object to its child objects. The Propagate to children option controls whether the assignment travels down the relevant inventory hierarchy.

Propagation is useful when a team should manage every VM in a folder. Assigning the role once on the folder and enabling propagation can cover existing and subsequently organized child objects, depending on the inventory relationship and vSphere behavior. It avoids maintaining many separate VM-level assignments.

Use propagation cautiously when child objects have different ownership or security boundaries. A permission assigned to a datacenter, cluster, or folder with propagation can grant access to more resources than expected. If only one VM should be accessible, assign the permission directly to that VM and leave propagation disabled.

Inheritance example

Suppose a folder contains three operations VMs. A permission assigned to the folder with propagation enabled can be inherited by those child VMs. A permission assigned directly to one VM without propagation affects only that VM.

Parent assignment: Operations VMs folder plus propagation enabled.
Inherited access: Child VM A, child VM B, and child VM C.
Narrow assignment: VM B only, with propagation disabled.

When child objects require different access boundaries, separate the objects into appropriate folders or use direct assignments rather than relying on a broad propagated permission.

Practical permission examples

Grant VM administration rights to an operations group

Select the folder containing the operations team's virtual machines.
Add the directory group used by the operations team instead of adding each administrator individually.
Choose a VM administration role that matches the team's responsibilities.
Enable Propagate to children if the role should apply to the VMs in that folder.
Save the assignment and verify the group, role, folder scope, and propagation setting.

Provide access to one virtual machine

Select the individual VM, not its parent folder or datacenter.
Add the required user or group from the correct identity source.
Assign the narrowest suitable role.
Leave propagation disabled unless the VM has relevant child objects that also require the assignment.

Delegate datastore access

Select the relevant datastore.
Assign an appropriate role to the storage administration group.
Review parent-level permissions to ensure that the group does not also receive access to unrelated datastores.

Verify and review the assignment

After saving, verify the permission in the selected object's Permissions view. Review all of the following:

The intended user or group.
The selected identity source or domain.
The assigned role.
The target inventory object.
Whether Propagate to children is enabled.
Whether the resulting access matches the intended task and boundary.

Test the user's intended operation where appropriate. Confirm that the user can perform the required task and cannot manage unrelated objects. Include group memberships and other permission entries in the review, because effective access can be broader than one visible assignment.

Troubleshooting permission assignments

The intended user or group cannot be found

Confirm that the correct domain or identity source is selected.
Verify that the account or group exists in the directory.
Check spelling, capitalization, and search criteria.
Confirm that the identity source is configured and reachable by vCenter Server.

The user can sign in but cannot perform the expected action

Verify that the correct role was assigned.
Review the privileges included in that role.
Confirm that the permission was placed on the correct inventory object.
Check whether access was expected through inheritance but Propagate to children was not enabled.

The user has access to more objects than intended

Check for assignments on a parent datacenter, cluster, or folder.
Review whether propagation was enabled.
Check directory group memberships and overlapping permission entries.
Reduce the assignment scope or replace the role with a less privileged role.

A child object does not receive expected access

Verify that the parent assignment has Propagate to children enabled.
Confirm that the object is actually a child in the relevant inventory hierarchy.
Review more specific permissions or organizational access rules affecting the child.