VCP 6 Delta Beta Exam Study Material (series)

Objective 1.1: Configure and Administer Role-Based Access Control

Ok so starting off with the first objective here. Underneath are the following topics:

• Identify common vCenter Server privileges and roles
• Describe how permissions are applied and inherited in vCenter Server
• View/Sort/Export user and group lists
• Add/Modify/Remove permissions for users and groups on vCenter Server inventory objects
• Create/Clone/Edit vCenter Server Roles
• Determine the correct roles/privileges needed to integrate vCenter Server with other VMware products
• Determine the appropriate set of privileges for common tasks in vCenter Server

So first it is good to go over a few things. We will start with the type of permissions that are available to us.

In order to perform tasks on objects or be able to view properties or even log in, we need to have the proper permissions associated with the user we are logging in with. We have:

vCenter Server Permissions – These permissions are assigned through the vCenter for an object that the vCenter manages. This permission is made up of one or a number of privileges that you are allowing this user to have for that object. This would include things such as modification of a VM or creation of datastores etc.

Global Permissions – These are permissions assigned to a user that needs to access more than one solution. For example a user needs to access not just vCenter but also vRealize Operations Manager. This is a permission that spans across the whole vsphere.local (or whatever you named your SSO domain) These are also replicated across the domain.

Group Memberships – These are permissions associated with a group. It is much easier to apply permissions to a group and then just add or remove a user rather than assigning roles to a user every time you need to change. A user can me a member of more than one group and will receive the union of the privileges associated with the groups (keep in mind that most restrictive applies)

ESXi Local Permissions – This is only for managing a single ESXi host.

The Permission Model

There are 4 concepts that make up the permission model. Permissions, Users and groups, Privileges, and Roles.

Permissions – Every object in the vSphere world has associated permissions. These permissions specify what privileges that group or user have on that object.

Users and Groups – You can only assign permissions to authenticated users or groups. These can either be the built-in users and groups in vCenter or they can be from one of the added identity sources (such as AD).

Roles – Roles are predefined sets of privileges. Instead of having to find out what permissions you need to assign to a user or group, every single time. You can gather privileges into a single Role – such as VM Creator, to easier assign them. There are a number of them already pre-defined in vCenter for you

Privileges – These are the fine grained access controls. You group these into Roles.

Assigning permissions.

There are a few things to keep in mind when assigning permissions. You can assign permissions to a Parent object so that the child objects can inherit the permission as well (If inheritance is on). Child permissions will always override Parent permissions. What does this mean? If you were to create permissions on a child object that deny being able to modify it, even if the user has admin rights on the parent, he will not be able to do so.

A user will also receive the aggregate of the groups he/she are added to. If one group has read permission and also belongs to a group with modify permission, that user will get both of the permissions. Now if one of those groups happens to be more restrictive, such as a Read-Only permission or Access Denied, then that will take precedence no matter what other group they belong to, for that object.

In order to Add Permission to an Object you need to do the following:

1. Browse to the object you that you want to add the permission to in the Object Navigator
2. Click on the object and then click on Manage tab and then under that click on Permissions

 

3. Click on the Add (+) icon and then on the Window that comes up, click on Add
4. Click on the Domain and either choose the SSO Domain or Identity Source where the user resides

5. After the user is selected you then need to assign a Role that has the desired access you wish to assign          to this user – Also choose if it propagates to children objects or not.

6. Click OK and your user should now show up in the middle pane

 

That’s all there is to it. To modify, just click in the middle pane on the user you wish to modify and then click on the pencil.

To remove, click on the user you wish to remove and then click on the red ‘x’.

 

The above assumes you have the privileges you want for that user already setup in a role. If you don’t you will need to first create a role with the needed privileges.

 

If you don’t you will need to do the following.

From the Main Home Screen, click on Administration on the Object Navigator Pane (left pane)

1. Click on Roles on the left hand pane
2. You can now choose from either creating a new Role from scratch or copying one of the existing Roles and then Modifying it. To create a new Role click on the plus sign (+) if you wish to copy an existing, click on the Role you wish to copy and then click the Clone Role Button.
3. When you create a new Role you are presented with a box to give it the name of the Role and underneath all the privileges available to assign to it.

4.    If you decided to choose door number 2 and clone an existing role this is what it                  might look like.

5.  You would then go in just like the other, and choose what privileges you want that              role to have.

Incidentally you would go to the same basic place for global permissions as well. The Global Permissions are there to give a user/group privileges to all objects in a hierarchy.

1. Go to Administration from the Home Screen and then click on Global Permissions

2. In order to add to it, once again, click on the plus sign (+). Or to modify, click on the object and then on the pencil icon.

In order to assign Global Permissions, you need the .Permissions.Modify permission privilege on the root object for all inventory hierarchies

There are a number of Default Roles to be aware of as well. They are as follows:

Administrator Role – Users assigned this Role are allowed to view and perform all actions for this object. By default [email protected] has the Administrator role on both vCenter Single Sign On and vCenter Server after installation.

No Access Role – Users assigned this role cannot view or change the object in any way. All new users and groups are assigned this role by default. The only users not assigned this by default are the [email protected], root user, and vpxuser.

Read Only Role – Users assigned this role are only able to view the state of the object and details about the object. They cannot view the remote console and all actions on the menu and toolbars are not allowed.

Required Privileges for Common Tasks

This is where it starts getting tricky because everything is very granular. You need to think of not just the privilege that you are assigning but also what are you performing it on. I am going to just “borrow” the table from the PDF. And only the Create a Virtual Machine. For the rest of them feel free to view the PDF.

Here is the link to the Security Guide – http://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-security-guide.pdf

Alright. I think that about covers this particular point. Next up will be Objective 1.2 on Securing ESXi, vCenter Server, and vSphere Virtual Machines.