vSphere supports several models with fine-grained control for determining whether a user is allowed to perform a task. vCenter Single Sign-On uses group membership in a vCenter Single Sign-On group to decide what you are allowed to do. Your role on an object or your global permission determines whether you are allowed to perform other tasks in vSphere.
- vCenter Server Permissions
The permission model for vCenter Server systems relies on assigning permissions to objects in the object hierarchy. Each permission gives one user or group a set of privileges, that is, a role for a selected object. For example, you can select a virtual machine and select Add Permission to assign a role to a group of users in a domain that you select. That role gives those users the corresponding privileges on the VM.
- Global Permissions
- Global permissions are applied to a global root object that spans solutions. For example, if both vCenter Server and vRealize Orchestrator are installed, you can use global permissions. For example, you can give a group of users Read permissions to all objects in both object hierarchies.
- Global permissions are replicated across the vsphere.local domain. Global permissions do not provide authorization for services managed through vsphere.local groups. See Global Permissions.
- Group Membership in vCenter Single Sign-On Groups
- Members of a vsphere.local group can perform certain tasks. For example, you can perform license management if you are a member of the LicenseService.Administrators group. See the vSphere Authentication documentation.
- ESXi Local Host Permissions
- If you are managing a standalone ESXi host that is not managed by a vCenter Server system, you can assign one of the predefined roles to users. See the vSphere Single Host Management - VMware Host Client documentation.
- For managed hosts, assign roles to the ESXi host object in the vCenter Server inventory.
Understanding the Object-Level Permission Model
You authorize a user or group to perform tasks on vCenter objects by using permissions on the object. The vSphere permission model 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. For example, a group of users might have the ReadOnly role on one VM and the Administrator role on another VM.
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. Users and groups must be defined in the identity source that vCenter Single Sign-On uses 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, which 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.
- Select the object to which you want to apply the permission in the vCenter object hierarchy.
- Select the group or user that should have privileges on the object.
- 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.
|To find out about...||See...|
|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|
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.