While vCenter Server 7 has many users and roles predefined by default, you might need to create a custom role and add users. As you know, the vCenter Server role is a predefined set of privileges. After adding permission to an object, you can assign a role to the user or group. The default roles in vCenter are not modifiable; this means that you cannot change the privileges that are associated with those default roles. Let's have a look at a couple of roles.

Administrator—Can perform all actions on the object. The role also has all privileges of the Read Only role. With the Administrator role, you can assign privileges to users and groups.

Read Only—Users can view the state of an object, but not modify it. For example, users cannot view the remote console for a host; no action is permitted.

No Access—Cannot view or change object. All new users are assigned this role by default.

Then there are specific roles such as No Cryptography Administrator, Trusted Infrastructure Administrator (for vSphere Trust Authority), and No Trusted Infrastructure Administrator.

Where to add new roles?

Log in to the vCenter Server by using the vSphere Client and go to Administration > Click Roles in the Access Control area. Select Administration and click Roles in the Access Control area.

To create a role, just click the Create Role action icon.

To create the role by cloning, just select a role, and click the Clone role action icon.

How to clone a role in vCenter Server 7

How to clone a role in vCenter Server 7

Click OK to validate. Then select the newly created role and click the Edit icon. As you can see, the No cryptography administrator role has all privileges except cryptographic operations. This role was created on purpose and is useful when you don't want to pass any of the cryptographic operations to a part of your team.

Edit cloned role in vCenter Server 7

Edit cloned role in vCenter Server 7

This is the safest way of creating a new role based on an original role. In this way, when you change something, you'll be changing the clone, not the original.

After you create a new role, you can assign privileges. The fact is that a role is a predefined set of privileges that define read properties or rights to perform actions. As an example, the Datastore role allows the creation and modification of datastores.

vCenter has two different kinds of roles:

  1. System Roles—These are permanent roles. You are not allowed to edit the privileges associated with these roles.
  2. Sample Roles—There are sample roles provided by VMware, and they are intended to be used for cloning, modifying, or removing.

Sample roles cannot be reset back to default, so in order to avoid losing the original config, simply clone the role again before making any modifications.

What different objects exist in vCenter Server?

Let's quickly recap the different objects we can find within vCenter Server.

  • Permissions—Each object in the vCenter hierarchy has associated permissions. Each permission specifies which privileges one group or user has on the object.
  • Privileges—Access controls to the resource. Privileges are grouped into roles, which are mapped to users or groups.
  • Users and groups—Only users authenticated through single sign-on (SSO) can be given some privileges. Users must be defined within the SSO or be users from external identity sources, such as Microsoft AD or other LDAP.
  • Roles—A role allows you to assign permission to an object. Administrator and Resource Pool Administrator are predefined roles. You can clone or change most predefined roles (except Administrator).
  • Global Permissions—Global permissions are special. They are applied to a global root object that spans different solutions. Imagine that you have vCenter Server and vRealize Orchestrator installed side by side. These two products 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.

When you assign permission to an object, you can choose whether the permission propagates down the object hierarchy. You set propagation for each permission. Propagation is not universally applied; instead, you must check a checkbox for this. Permissions defined for a child object always override the permissions that are propagated from parent objects.

Where possible, assign a role to a group rather than individual users to grant privileges to that group. This is the same logic as in Windows administration. Grant permissions only on the objects where they are needed, and assign privileges only to users or groups that must have them. A good practice is to group objects into folders. Then you can assign permissions to folders containing hosts and other objects.

Go to the VMs and templates view. Pick or create a new folder and add objects inside. Select the Permissions tab, and click the plus sign to add new permission.

Assign permissions to folders

Assign permissions to folders

You should always enable propagation (unless it is not wanted) when you assign permissions to an object. This means when new objects are inserted into the inventory hierarchy, they inherit all permissions, as they should, so you don't have to assign them manually.

Note: You can use the No Access role to mask specific areas of the hierarchy if you do not want certain users or groups to have access to the objects in that part of the object hierarchy.

How to create users?

Go to Single Sign On, and within this section, select Users and Groups. Then pick the domain in which you want to create your user and click Add.

Add a new user to vCenter Server 7

Add a new user to vCenter Server 7

You'll get a new popup window asking you for the details.

Add New User popup window

Add New User popup window

Note: When you set up a Microsoft AD as the identity source, you'll still need to add/remove users of your AD via the Microsoft AD Users and Objects console. Within the vSphere client, the button is grayed out.

For groups, proceed in the same manner.

VMware directory service works in a similar way as Microsoft AD, where changes on one vCenter Server are propagated to other vCenter Servers connected to the same SSO. So, the VMware directory service replicates the role changes that you make to other vCenter Server systems. However, the assignments of roles to specific users and objects are not shared across vCenter Server systems.

Subscribe to 4sysops newsletter!

This topic is part of a free VCP7-DCV study guide that will help you to pass VCP-DCV 2020 certification based on the vSphere 7 product. You'll find all the topics on this page. After successfully passing the exam, you'll be certified VCP-DCV 2020.


Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account