permission – Page 2

vSphere 6.5b prevents vSphere Web Client logins for users w/o VC permissions

03.14.2017 by William Lam // 8 Comments

A patch update was just released for vCenter Server 6.5, dubbed vSphere 6.5b. While glancing through the release notes, I caught one interesting "resolved issue" which I thought was worth sharing.

Users with no vCenter Server permissions can log in to the vSphere Web Client

Users without permissions can log in to the vSphere Web Client. Users can click the menu options, but no inventory is displayed.

Users with no permissions can no longer log in to the vSphere Web Client.

To enable the login, set the allow.user.without.permissions.login = true property in the webclient.properties file.

This particular behavior has been something that has confused a few customers and has been asked about since the introduction of vCenter Single Sign-On (SSO) service. The issue or rather the confusion is that prior to the SSO service, vCenter Server handled both authentication as well as authorization.

With SSO, authentication was no longer being handled by vCenter Server and this meant that even if you had no permissions in vCenter Server but you could authenticate to SSO (especially common when Active Directory is configured), you would still be allowed to login to the vSphere Web/H5 Client.

Although vCenter Server would does the right thing and does not display any inventory if you do not have any permissions, it was still not a desired behavior in addition to the confusion it caused. I was pleasantly surprised to see that we have changed this default behavior by disallowing logins to the vSphere Web/H5 Client if a user has no VC permissions. Below is the message you will receive if you try to login without VC permissions.

If you wish to revert to the original behavior, you can do so by simply adding the allow.user.without.permissions.login = true setting into the vSphere Web/H5 Client configuration file (webclient.properties) and restart the vSphere Web/H5 Client service. I think many of our customers will appreciate this fix as well as the new default behavior!

How to restrict access to both the Standalone VMRC & HTML5 VM Console?

12.08.2015 by William Lam // 10 Comments

Several weeks back there were a couple of questions from our field asking about locking down access to a Virtual Machine's Console which includes both the new Standalone VMRC (Windows & Mac OS X) which runs on your desktop as well as the new HTML5 VM Console which runs in the browser. Below is a screenshot of the vSphere Web Client showing how to access the two different types of VM Consoles.

restricting-vmrc-and-html5-vm-console-access-1
To prevent users from accessing either of the VM Consoles which also applies to the vSphere C# Client, you can leverage vSphere's extensive Role Based Access Control (RBAC) system. The specific privilege that governs whether a user can access the VM Console is under VirtualMachine->Interaction->Console interaction as seen in the screenshot below.

If a user is not granted the following privilege for a particular VM, when they click on either the Standalone VMRC link or the HTML5 VM Console, they will get permission denied and the screen will be blank. Pretty simple if you want to prevent users from accessing the VM Console or allowing only VM Console access when they login.

UPDATE (01/31/17): If you are using VMRC 8.1 or greater, you no longer need the additional permission assignment on the ESXi level if you ONLY want to provide VM Console access, just assign it to the VM. However, if you need to provide device management such as mounting an ISO on the client side, then you will still need to assign VMRC role (along with the required privileges for device management) at the ESXi host level.

UPDATE (12/15/15): If you want to restrict users from having ONLY VM Console access which may include the Standalone VMRC, you will need to ensure that the user has the role applied not only on the VMs you wish to restrict but also at the ESXi host level since Standalone VMRC still requires access to ESXi host. You do not need to grant read-only permissions for the user at the ESXi level, but you just need to assign the user "VMRC" only role at the ESXi level or higher to ensure they can connect to the VMRC.

Why is there a "No access" vSphere Role?

12.10.2013 by William Lam // 5 Comments

vSphere's (vCenter Server & ESXi) authorization system includes several pre-canned Roles such as Read-Only, Administrator and Virtual Machine Administrator as an example. One of the roles that has intrigued me for awhile which is the "No access" role. This seems to be a really odd role to have, I mean what would you do with such a role if it does not have access to anything?

In a conversation I had last week with a fellow colleague, the "No access" role made its way into the conversation and I learned that there was a specific use case for this role, however it was unclear what that might have been. This go me interested and I decided to reach out to some folks to see if I can get to the bottom of this and the use case associated with it.

It turns out there are some customers who have some very interesting requirements in which they need to separate out users who have the Administrator role and prevent them from seeing and performing operations on specific vSphere Inventory objects. An example of this would be a vCenter Server with 4 vSphere Clusters where Admin1 can only see the first two Clusters and Admin2 can only see the last two Clusters and both users have the Administrator role.

To accomplish the above example, you can leverage the "No access" role in the following manner. As the "Uber" Administrator, you would assign both Admin1 and Admin2, lets call them Alan and Cormac the Administrator role at the vCenter Server level. This will grant them full access to the entire vSphere Inventory.

Now, to prevent Alan from seeing Cluster 3 & 4, we need to go into the Cluster object and add the "No access" role to both those objects. We do the same for Cormac but for Cluster 1 & 2. If we now login as the user Alan, we will see that only Cluster 1 & 2 are visisble.

If we login with the user Cormac, we can only see Cluster 3 & 4 as expected.

Although this may not be a common request in your environment, I can see some interesting use cases for having such a setup like on-boarding a new junior admin and wanting to provide them Administrative access to particular Clusters and removing the views for others they should not have access to.

I would like to thanks Rupam from our GSS organization for sharing the reasoning behind "No access" as well as a specific use case for the feature.