vCenter Admin Group Member Denied an Action: Check for a Restricting Permission

An account is a member of a group that holds the Administrator role, yet in the vSphere Client some actions are greyed out or refused. Group membership alone does not decide what a user can do. vCenter looks at which permissions exist on which objects and for which principal, and some of those can override the group's role.

This article shows how to check, for one user and one VM, whether a documented restriction explains the denial: a permission set directly on the user, or a lower assignment that overrides the group's role. The result is either a named conflicting assignment that the record demonstrates, or a case recorded as unresolved with the missing evidence named. It is not an instruction to grant the Administrator role to anyone.

This guide does not check which privileges a particular operation needs on which objects, or what a custom role contains. A denial that the permission rows do not explain goes to the access owner as unresolved.

This guide is based on source research only. Nothing in it was run. All names are fictional.

Three documented permission rules

From the vSphere 8.0 Security guide (How Do Multiple Permission Settings Work in vSphere, last updated 28 October 2026):

1. A permission set on a user overrides the user's groups on the same object. If several groups have roles on an object and no permission for the user is defined directly on it, the user gets the union of the groups' permissions. If a permission for the user is defined directly on the object, "the permissions for the user take precedence over all group permissions."
2. A child permission overrides the parent. A child object inherits a parent's permission only if the parent permission is set to propagate. A permission set directly on a child object overrides the permission inherited from the parent.
3. A VM has two parents. "Virtual machines inherit permissions from both the parent virtual machine folder and the parent host, cluster, or resource pool simultaneously" (Hierarchical Inheritance of Permissions in vSphere, 8.0; also KB 380445).

Broadcom's own examples, in brief:

KB 401728 (vCenter 7.x and 8.x) describes the administrator version of Example 3:

• The SSO administrator account is still a member of the Administrators group, and that group still has the Administrator role.
• The account itself has been given a restrictive role, such as Read-Only, at the vCenter or global level.
• Broadcom states that "an explicit permission assigned directly to a user account takes precedence over permissions inherited from group memberships", so the account loses the group's full rights.
• The symptoms are greyed-out options on inventory objects and greyed-out Add, Edit and Delete buttons for global permissions.

Before you start

• The exact principal. Record the user as it is shown at sign-in, including the domain (for example CORP\jlee versus jlee@vsphere.local). Two accounts with similar names are different principals.
• The exact object and action. Record the VM and the specific greyed-out or refused action, for example "Power On greyed out on vm-app07".
• An account that can view permissions. You only view, and this guide does not change anything. Do not sign in as the affected user to "test" more actions.

Step 1: record the VM's two parent paths

Open the VM in the vSphere Client and record both of its parent paths:

• VMs and Templates view: the VM folder path up to the data centre. For example, DC-SYD > Finance > App.
• Hosts and Clusters view: the host or cluster, plus any resource pool and vApp. For example, DC-SYD > CL-PROD > RP-Finance.

KB 380445 notes that the hidden top-level VM, host, network and storage folders cannot carry permissions directly. They are containers that users do not see, so you will not find assignments on them.

Step 2: record every permission on every object in both paths

Broadcom's 8.0 procedure for changing permissions starts with the object's Permissions tab, where each row is a user or group paired with a role (Change or Remove Permissions on an Inventory Object, 8.0). Use that tab only to view. Do not click Edit or Delete.

For the VM itself, and for each object in both paths up to the vCenter root, record these columns:

Also record the global permissions shown under Administration, because KB 401728's case was a restrictive role at the vCenter or global level. Record each row only once. Note on which object you saw it, and whether the client shows it as assigned there or as inherited from a parent object.

This guide does not assert how your client labels inherited rows. If you cannot tell where a row is assigned, check the parent objects until you find the object where it is assigned.

Step 3: find the assignment that wins

Work from the VM upwards, along each path, for the affected user.

First, decide which recorded rows can reach the VM at all. A row is a candidate only when all three are established:

• Principal: the row is for the user, or for a group the user is shown to be a member of. Unknown membership is recorded as unknown, and the row is not used.
• Origin: the object where the row is assigned, not where it was seen as inherited.
• Reach: the row is assigned on the VM itself, or on an ancestor in one of the VM's two paths and set to propagate. A row on an ancestor that does not propagate does not reach the VM.

Keep rows assigned directly on the VM separate from rows that reach it by propagation from an ancestor. Apply the steps below only to candidate rows.

1. On the nearest object that carries a candidate row for this user or for any of their groups: - Is there a row for the user directly? If so, that row decides, over every group row on that object (rule 1). - If there is no direct user row, the user gets the union of all their groups' rows on that object.
2. Is the deciding row nearer to the VM than the group's Administrator row? A permission set lower in the tree overrides one propagated from above (rule 2). An Administrator group role at the root does not survive a different role set for that group or user on the folder that holds the VM.
3. Does the Administrator row reach the VM? If it is not set to propagate, it does not reach child objects at all, and there is no conflict to find on that path.
4. Do both paths agree? Both parents contribute to the VM (rule 3). Record the deciding row on the folder path and on the resource path separately. Broadcom's pages state that a VM inherits from both parents at the same time. The pages cited here do not give a rule for combining two different roles from the two paths, so do not assume one path cancels the other. Report both, and record the VM-level outcome as unresolved.
5. Is there no candidate row that restricts the user? Then the record does not establish a conflicting assignment. Record the case as unresolved, naming what is missing: for example, the privileges the operation needs on each object involved, or the contents of a custom role. Hand it to the access owner without naming a winning row.

Worked example (hypothetical)

User CORP\jlee is shown in the directory as a member of CORP\vc-admins and not of CORP\finance-ops. CORP\vc-admins, which holds the Administrator role at the vCenter root, set to propagate. Power On is greyed out on vm-app07.

The Step 2 record:

Reading it:

• Candidates: both root rows (the user, and a group the user is in), assigned on the root and set to propagate, so both reach the VM through both paths. The Finance row is not a candidate, because CORP\jlee is not in CORP\finance-ops. Nothing is assigned on the VM itself.
• At the root, there is a direct row for CORP\jlee (Read-only) as well as the group row (Administrator). The user row takes precedence over all group permissions on that object (rule 1).
• No candidate row lower in either path overrides it, so Read-only is what reaches the folder path and the resource path for this user.

The demonstrated conflicting assignment: the direct Read-only permission for CORP\jlee on the vCenter root, which overrides the user's group Administrator role. This matches KB 401728.

What to hand on: the record and that one row, to whoever owns vCenter access. Whether the direct row should be removed, changed or kept is their decision. KB 401728's resolution changes the direct row's role. This article does not recommend granting Administrator. A narrower role, or no direct row at all, may be the correct outcome.

Two contrasting cases

Troubleshooting

Acceptance checks

1. The principal, object and action are recorded exactly.
2. Both parent paths of the VM are recorded.
3. Every permission row on the VM, on each object in both paths, and in global permissions is recorded with principal type, role and propagation.
4. Every row used in the finding is a candidate: principal membership, assignment origin and reach to the VM are recorded.
5. The finding is one of: a named conflicting assignment (object, principal, role, propagation) with the rule that makes it decide; the expected role is on a different branch; or unresolved, with the missing evidence named (for example, different outcomes on the two paths, or the privileges the operation needs). An unresolved case does not name a winning row.
6. Any change goes to the access owner as a separate change, with this record attached.

Risk notes

• Granting Administrator to fix one denial widens access everywhere the permission propagates. Fix the specific conflicting row instead.
• Removing a direct user row changes effective access at once. The new access has to be worked out again from the rows that remain: other direct rows inherited from ancestors, lower assignments, propagation and both VM paths. Broadcom's group-union rule covers only the case where several groups have rows on the same object and the user has no direct row on that object. Removal is not a guaranteed result; the access owner decides it.
• NoAccess can hide objects (Example 3), so someone may believe VMs are missing. Confirm with an account that has broad view rights before escalating.
• Do not edit to inspect. The Edit dialog on the Permissions tab can change both the role and Propagate to children in one click.
• KB 401728's resolution signs in with an existing account that is a member of the Administrators group. As an option, the KB says a new account can be created and added to that group, and to "consider" deleting it if it is no longer necessary. Any such account change belongs to the access owner's incident remedy, outside this read-only inspection.

These are source-documented behaviours. Expert review and a lab check are still needed before changing access in production.

Learning notes

• A permission set directly on a user beats that user's groups on the same object.
• A permission set lower in the tree beats one propagated from above.
• A VM inherits from its folder and from its host, cluster or resource pool at the same time. Check both.
• A role on another branch is not a precedence problem. It simply does not apply.
• A row counts only if it reaches the VM: right principal, known origin, and propagation from an ancestor.
• The useful outcome is a demonstrated conflicting assignment, or an honest "unresolved", never a wider role.

References

Related articles

• Harden VMware without breaking operations, which covers creating least-privilege roles and testing allowed and denied operations.