Objective 1.1 – Configure and administer role-based access control

Role-based access control (RBAC) is a common approach to managing authorizations and permissions, based on specific roles assigned to specific users or groups.

In VMware vSphere, roles are just sets of privileges used to authorize users (or groups) for specific vSphere inventory objects.

VMware vSphere provides the following four categories of permissions, from the most general to the most specific:

• Group membership in the SSO domain: Some users of the vCenter Single Sign-On (SSO) domain, such as the default administrator, have specific, implicit permissions. For more information, refer to Objective 1.3.
• Global permissions: These permissions are applied to a global root object, and can propagate to all objects. Also, they can span across different VMware products (for example, vSphere and vRealize Orchestrator).
• vCenter permissions: This is the main model used by vSphere Server to assign granular permissions to objects in different inventories.
• ESXi local permissions: Each ESXi host has local permissions, local rules, and local users. For hosts managed by vCenter, vCenter permissions are usually used. But local permissions still exist, and they are the only permission model for standalone ESXi hosts.

This chapter will mainly focus on vCenter and global permissions, as required by the exam questions. Objective 1.3 will provide more information about SSO-related concepts. ESXi local permissions are not covered in detail, but the RBAC model is quite similar to the one used by the vCenter permissions.

Objective 1.1 for VCP65-DCV and VCP6-DCV is the same, because there weren't any major changes in role-based access control from vSphere 6.0 to vSphere 6.5.

The official vSphere 6.5 Security Guide contains detailed information about authentication, authorization, and different permission configurations, and can be accessed at https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-652-security-guide.pdf.

Compare and contrast propagated and explicit permission assignments

The VMware vSphere RBAC model is based on the following concepts:

• Inventory: A collection of multiple virtual or physical objects managed by vCenter, in a hierarchical organization. In vCenter Server, there are four different types of inventories, with different types of objects. For more information, refer to Table 1.1.
• Object: Each object in the vCenter inventory has associated permissions, or inherits them from its parent object.
• User and Group: In vCenter Server, users are authenticated through the SSO component; in ESXi, users are authenticated with a local authentication or AD authentication (refer to Objective 1.3). Note that you can only assign privileges to authenticated users, or groups of authenticated users.
• Privilege: This is the ability to access or execute specific functions, tasks, and operations.
• Role: Roles are just groups of privileges, used to make permissions management much easier.
• Permission: Permissions specify which role matches a specific group of users, for a specific object.

The following table summarizes the types of inventories, with the different types of objects:

vCenter inventory	Related objects
Hosts and clusters	vCenter Servers Data centers Folders Clusters Hosts Resource pools vApps VMs
VMs and templates	vCenter Servers Data centers Folders vApps VMs Templates
Storage (Data stores and data store clusters)	vCenter Servers Data centers Folders Data store clusters Data stores
Networking	vCenter Servers Data centers Folders Portgroups Distributed Virtual Switches Distributed Portgroups Distributed Uplinks

Table 1.1: Permission, role, user/group, and object

VMware vCenter permissions are assigned to objects in the vCenter inventory hierarchy by specifying which user or group has which privileges on that object. Then, to specify the privileges, you use specific roles.

The same concepts are used for ESXi local permissions, but with some limitations; for example, the predefined roles are limited, and users/groups are limited to local ESXi and/or Active Directory (AD) domains. Also, there is only a single inventory.

The different vCenter inventories can be used to provide different levels of object hierarchies, and to group objects in different ways. Note that some objects (such as VMs) can exist in multiple inventories.

Later sections in this chapter will help you to understand how permissions are propagated through the object hierarchy.

It is a good practice to assign only those permissions that are required to increase the security, and to have a clear permissions structure.

Global permissions are applied to a global root level, instead of a specific object. In this way, a global permission grants privileges for all objects in all inventories, but only if you assign a global permission by selecting the Propagate to children option. Without the propagation, a user will only have access to some global functionalities, such as creating roles. Also, remember that global permissions can span different VMware products.

Note that vSphere tags are a specific vCenter object type, with their own permission propagation model. This is because a tag object is not a child of vCenter, but is created at the vCenter root level. If you have multiple vCenter Servers in linked mode, then all tag objects will be shared across all vCenter Server instances. To learn how permissions are applied to tag objects, you can refer to the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-2199584C-B422-4EEF-9340-5449E1FB7DAE.html).

View/sort/export user and group lists

User and group lists can be displayed and sorted from the vCenter Web Client in the Users and Groups menu, located via Home | Administration | Single Sign-On.

Note that you need an SSO admin privilege to access this page. For more information about SSO, refer to Objective 1.3.

You can choose a specific domain (identity source, as described later). The Users tab will show the users, and the Groups tab will show the groups.

To sort a column, just click on the column heading. To change the order direction (ascending or descending), just click on it again. To show or hide a column, right-click on any of the column headings and select or deselect the name of the relevant column.

You can export the displayed list to a file (in a Comma-Separated Values (CSV) format) by selecting the Export button, as follows:

Figure 1.1: User lists in the vsphere.local domain

Add/modify/remove permissions for users and groups on vCenter Server inventory objects

As described previously, a permission is a match between an object in the vCenter object hierarchy, a user (or a group), and a role.

With vSphere Web Client, you can manage vCenter permissions for users or groups by selecting one object from one of the vCenter inventories and then clicking on the Permissions tab:

Figure 1.2: vCenter permissions on a specific object

With the selected toolbar, you can add, edit, or remove selected permissions.

For Global Permissions, the toolbar remains the same, but you must select the Global Permissions menu that is located at Home | Administration | Access Control:

Figure 1.3: Global permissions

You will need an SSO admin privilege to access this page. For more information about SSO, refer to Objective 1.3.

Remember that global permissions can span more vCenter servers in the same SSO domain.

When you add or modify a permission, you need to select one or more users (or groups), a specific role, and whether the permission will be propagated in the objects hierarchy (refer to the next section for more information):

Figure 1.4: Modifying global permissions

In order to assign users or groups sets of privileges, you will need the vCenter Modify.permissions privilege.

For more information, refer to the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-3B78EEB3-23E2-4CEB-9FBD-E432B606011A.html).

Determine how permissions are applied and inherited in vCenter Server

If you assign a permission to an object, it can be propagated down the objects hierarchy. The propagation is enabled by default, but you can disable propagation for each permission by checking the Propagate to children checkbox, as follows:

Figure 1.5: Disabling permissions propagation

VMware vCenter objects are hierarchical. This means that permissions (with the Propagate to children option) will be inherited (all child objects inherit from their parent objects). The following diagram, from the vSphere Security Guide, shows the entire objects hierarchy:

Figure 1.6: vCenter objects hierarchy

Also, the global permissions can be propagated, or not propagated, and the different inventories, which happens with the vCenter permissions in the objects hierarchy.

Note that propagation is not necessarily enforced. The resultant permission is always more specific in the hierarchy. A permission defined at the child object level always overrides a permission propagated from parent objects.

Note that some objects can exist in different inventories (such as VMs in Hosts and Cluster, VMs, and Templates inventories). This means that different permissions can be applied in different views.

What are the differences between global permissions and vCenter permissions applied at the vCenter object level, if you are using propagation in both cases? The vCenter object exists in all four of the inventories, so the vCenter permissions will only be propagated on specific objects of the selected inventory. With global permissions, the propagation is on all objects!

For more information, refer to the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-03B36057-B38C-479C-BD78-341CD83A0584.html).

Create/clone/edit vCenter Server Roles

In VMware vCenter, there are different types of roles, as follows:

• Default roles: These are predefined on vCenter Server, and cannot be modified or deleted.
• Sample roles: These are also predefined, and are used to manage certain types of tasks. They can be cloned, modified, or removed.
• Custom roles: These can be defined by the administrators, and are created from scratch or cloned from existing roles.

The following table summarizes the predefined roles:

Type	Role
System role	Administrator role No cryptography administrator role No access role Read-only role
Sample role	VM power user role VM user role Resource pool administrator role VMware consolidated backup user role Data store consumer role Tagging admin role Network administrator role Content library administrator role

Table 1.2: vCenter predefined roles

Usually, role names are quite descriptive about what kinds of tasks will be permitted, but you can edit them to see the complete list of privileges.

You can manage the vCenter roles using the vSphere Web Client by selecting the Roles menu and navigating to Home | Administration | Access Control:

Figure 1.7: Managing vCenter roles

The selected toolbar will allow you to create, clone, modify, or delete a role.

To create a new role from scratch, just click on the Create role action icon, type a name for the new role, and then select the right privileges for the role.

To clone an existing role into a new role, just select the desired source role and click on the Clone role action icon, then type a name for the new role. At that point, you can modify it with the Edit action icon.

Instead of creating a new role from scratch, in order to avoid potential permissions mistakes, VMware suggests cloning an existing role.

For more information, you can refer to the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-18071E9A-EED1-4968-8D51-E0B4F526FDA3.html).

Configure VMware Identity Sources

When a user logs in to a vSphere environment, the vCenter SSO will validate the user's credentials through one of the configured identity sources.

If the user also specifies the domain name (using the domain\user or user@domain format), the authentication will match the specific identity source.

For more information on the SSO components, you can refer to Objective 1.3.

Identity sources are some kind of centralized user and group system, usually some type of authentication domains, and vSphere supports the following:

• SSO domain: This is a default identity source, created with the configuration of the PSC.
• AD (native): When the SSO is joined to an AD domain, it is possible to use the domain or the forest as an authentication source.
• LDAP (AD): The users are defined on an AD domain, but you don't have to join the SSO to the AD domain.
• LDAP (OpenLDAP): The users are defined on an OpenSource LDAP server.
• Local OS: The users are defined in the SAM file (for Windows-based SSO) or the /etc/passwd and /etc/shadow files (for Linux-based SSO).

Note that the SSO domain is always enabled, and is included in the available identity sources.

You can add new identity sources or remove existing ones, and you can also change the default source.

Note that you must have vCenter SSO administrator privileges in order to manage the identity sources.

From the vSphere Web Client, just select the Configuration menu, located at Home | Administration | Single Sign-On. Then, select the Identity Sources tab:

Figure 1.8: SSO identity sources

To configure a new identity source, select Identity Sources and click on the plus icon (+). Then, choose the proper identity source type and enter the specific identity source settings.

For example, for AD, you will see a screen like the following:

Figure 1.9: Adding an AD domain as a new identity source

When an identity source is added, all users and groups in the new domain can be authenticated by SSO. However, in vCenter, they will have the No access role.

For more information about authentication, see the Platform Services Controller (PSC) 6.5 Administration Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.psc.doc/GUID-B98DF9C2-FE7D-483F-9521-C17C138B59D8.html).

Apply a role to a user/group and to an object or group of objects

Once a role has been defined, you can use it to assign specific authorizations to authenticated users or groups.

Whenever possible, it's recommended to assign permissions to groups instead of users, for better and more flexible permissions management.

The entire procedure was described previously, in the Adding/modifying/removing permissions for users and groups in vCenter Server inventory objects section.

You will need the Permissions.Modify privilege for the specific objects to modify the permissions and roles.

Note that some objects may reference other objects, such as VMs that include data store objects (for the virtual disk locations) and network objects (for the connected portgroups). In those cases, you will need to apply for the right roles in all of the different inventories.

Change permission validation settings

As described previously, the SSO component can have different identity sources. When a directory service (such as AD or LDAP) is used, the SSO regularly validates users and groups on the directory domain. This validation occurs at regular intervals, specified in the vCenter Server settings.

You can view or change these settings with the vSphere Web Client by selecting your vCenter Server in the vSphere object navigator and then selecting the Configure tab and clicking on General under Settings.

Select the User directory area, and view or change the values as needed:

Figure 1.10: vCenter Server settings—User directory

There are different options and settings, as follows:

• User directory timeout: This is the maximum amount of time, in seconds, that SSO allows a search to run on the selected domain source. For large domains, this can be increased.
• Query limit: This helps you to define whether there must be a maximum number of users and groups that vCenter can display.
• Query limit size: This is the maximum number of users and groups that vCenter displays in the Select Users or Groups dialog box. If you enter 0 (zero) or remove the previous option, all users and groups will appear.
• Validation: This is used to define whether validation is enabled or disabled.
• Validation period: This is how often, in minutes, validation is performed.

For more information, refer to the vCenter Server and Host Management Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vcenterhost.doc/GUID-007C02A8-C853-4FBC-B0F0-933F19768DD4.html).

Determine the appropriate set of privileges for common tasks in vCenter Server

Many tasks require permissions on multiple objects in the inventory. Without all of them, the task cannot be completed successfully.

The vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-4D0F8E63-2961-4B71-B365-BBFA24673FDB.html) contains several examples of combined sets of permissions required for common tasks, with some hints on how to manage permissions to perform generic tasks.

The following table, from the VMware guide, shows some examples of common VM administration tasks with their required privileges, and, where applicable, the appropriate sample roles that can be used (instead of configuring the single privileges):

Task	Required privileges	Applicable role
Create a VM	On the destination folder or data center: Virtual machine | Inventory | Create new Virtual machine | Configuration | Add new disk (if creating a new virtual disk) Virtual machine | Configuration | Add existing disk (if using an existing virtual disk) Virtual machine | Configuration | Raw device (if using an RDM or SCSI pass-through device)	Administrator
	On the destination host, cluster, or resource pool, navigate to Resource | Assign virtual machine to resource pool	Resource pool administrator or administrator
	On the destination data store or the folder that contains the data store, navigate to Datastore | Allocate space	Data store consumer or administrator
	On the network that the VM will be assigned to, navigate to Network | Assign network	Network consumer or administrator
Power on a VM	On the data center in which the VM is deployed, navigate to Virtual machine | Interaction | Power On	VM power user or administrator
	On the VM or the folder of VMs, navigate to Virtual machine | Interaction | Power On
Deploy a VM from a template	On the destination folder or data center, navigate to Virtual machine | Inventory | Create from existing or Virtual machine | Configuration | Add new disk	Administrator
	On a template or folder of templates, navigate to Virtual machine | Provisioning | Deploy template
	On the destination host, cluster, or resource pool, navigate to Resource | Assign virtual machine to resource pool
	On the destination data store or folder of data stores, navigate to Datastore | Allocate space	Data store consumer or administrator
	On the network that the VM will be assigned to, navigate to Network | Assign network	Network consumer or administrator
Take a VM snapshot	On the VM or a folder of virtual machines, navigate to Virtual machine | Snapshot management | Create snapshot	VM power user or administrator
Install a guest operating system on a VM	On the VM or folder of VMs, navigate to: Virtual machine | Interaction | Answer question Virtual machine | Interaction | Console interaction Virtual machine | Interaction | Device connection Virtual machine | Interaction | Power Off Virtual machine | Interaction | Power On Virtual machine | Interaction | Reset Virtual machine | Interaction | Configure CD media (if installing from a CD) or Configure floppy media (if installing from a floppy disk) Virtual machine | Interaction | VMware Tools install	VM power user or administrator
	On a data store that contains the installation media ISO image, navigate to Datastore | Browse datastore (if installing from an ISO image on a data store) On the data store to which you upload the installation media ISO image, navigate to Datastore | Browse datastore or Datastore | Low level file operations
Migrate a VM with vMotion	On the VM or folder of VMs, navigate to: Resource | Migrate powered on virtual machine Resource | Assign Virtual Machine to Resource Pool (if the destination is a different resource pool from the source)	Resource pool administrator or administrator
	On the destination host, cluster, or resource pool (if they are different from the source), navigate to: Resource | Assign virtual machine to resource pool
Cold migrate (relocate) a VM	On the VM or folder of VMs, navigate to: Resource | Migrate powered off virtual machine Resource | Assign virtual machine to resource pool (if the destination is a different resource pool from the source)	Resource pool administrator or administrator
	On the destination host, cluster, or resource pool (if different from the source), navigate to: Resource | Assign virtual machine to resource pool
	On the destination data store (if it is different from the source), navigate to Datastore | Allocate space	Data store consumer or administrator
Migrate a VM with Storage vMotion	On the VM or folder of VMs, navigate to Resource | Migrate powered on virtual machine	Resource pool administrator or administrator
	On the destination data store, navigate to Datastore | Allocate space	Data store consumer or administrator

Table 1.3: Required privileges for common tasks

These are just examples, but in most cases, you will need to build your own custom role (or set of roles).

Other software or solutions based on vSphere may specify the right privileges that are needed in order to build custom roles with minimum privileges.

Compare and contrast default system/sample roles

As described in the Creating/cloning/editing vCenter Server roles section, there are two different types of predefined roles:

• System roles (cannot be modified or deleted):
  • Administrator role: With this role, you can correspond to all privileges. By default, users with this role are the SSO administrator, the vCenter root (or administrator) user, and ESXi vpxuser (used by the vCenter agent).
  • No cryptography administrator role: This role has the same privileges as the administrator role, except for cryptographic operations privileges. This means that users cannot encrypt or decrypt VMs, or access encrypted data.
  • Read-only role: With this role, it's possible to view the details of the object, but it's not possible to change anything.
  • No access role: With this role, it's not possible to view or change the object in any way. By default, new users and groups are assigned to this role.
• Sample roles (can be cloned, modified, or removed):
  • VM administrator: This role allows for complete and total control of a VM, including some related host operations.
  • VM power user: This role grants rights only to a VM, including changing the settings or creating snapshots.
  • VM user: This role grants access rights exclusively to VMs, with limited functions, such as powering on, powering off, or resetting the VM, or running media from the virtual discs.
  • Resource pool administrator: This role is permitted to create resource pools and assign those pools to VMs.
  • Data center administrator: This role permits adding new data center objects.
  • VMware consolidated backup user: This role is required for the old VCB framework, but is a good starting point for other backup products.
  • Data store consumer: This role allows using space on a data store.
  • Network consumer: This role allows assigning a network to a VM or a host.

For more details, see Table 1.2 or the vSphere 6.5 Security Guide (https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.security.doc/GUID-18071E9A-EED1-4968-8D51-E0B4F526FDA3.html).

Determine the correct permissions needed to integrate vCenter Server with other VMware products

Sample roles can match specific integration requests. Also, Table 1.3, from the vSphere 6.5 Security Guide, showed some examples of common tasks with their required privileges, and, where applicable, the appropriate sample roles that can be used.

However, for other VMware products (and third-party products), you may need a specific set of permissions, and this list is usually provided by the related product documentation.

Also, remember that global permissions can span different VMware products. For example, for vCenter Orchestrator, you can use global permissions.