Lately I have been into the seperation of permissions in one of our VMware Cloud Director (VCD) environments. This means that instead of giving everybody a Provider Administrator account, I want to provide a form of Role Based Access Control (RBAC) and provide users with the correct amount of rights within their context in VCD.

This proves to be cumbersome in VCD at the moment since there is no official documentation on what a specific right does or enables for the users (next to the description itself) that are assigned the right. You can have a look at how Rights and Roles can be used and how they work at the following official VMware Documentation link.

The situation

I’ve set out to do my own research on this to make sure we can provide a safe environment to the internal organisation. So therefore I have made some custom roles. Starting from VCD 10.3 it was possible to use external Identity Providers (IDP’s) for the provisioning and assignment of rights in the VCD Provider user context. With this possibility we have also realised some new roles, which has a couple of certain permissions assigned to them.

In one of the roles the issue came up that the user had the ability to perform all of the tasks they needed, except for the fact that they could not fully view all properties from a vApp which had vApp Networks and a VM assigned within the vApp. Let’s make that a bit more graphical in the following figure:

Graphical vApp UI representation with VM's and networks
Graphical vApp UI representation with VM’s and networks

If this situation was in effect, the users assigned with the role I made received the following error scenario’s:

Opening a vApp error mesage
Opening a vApp error mesage

In the figure above you can see that this is the vApp view. Just opening up the vApp gave us this error. The other tabs on the left also provided similar errors

Opening the network configuration for a VM inside a vApp
Opening the network configuration for a VM inside a vApp

In the previous figure you can see that a loading screen popped up when the user tried to open up the network configuration page of a VM that resided in the beforementioned vApp. If the VM was not part of a vApp nothing happened and the user was able to edit the networks assigned to the VM.

After some digging, since there is no specifiic right that enables certain specific vApp actions or views, I found the following two interesting log pieces in the vcloud-container-debug.log file:

root@vcd-cell01 [ /opt/vmware/vcloud-director/logs ]# tail -f vcloud-container-debug.log | grep -i "denied" -A 2 -B 2
2022-10-26 14:39:56,038 | DEBUG    | pool-jetty-1303039        | OperationsManagerImpl          | Operation denied, required but missing operations:
Operations not in users context. | requestId=xxxxxxxx-e293-4669-83dc-xxxxxxxxx,request=GET https://vcd/api/vApp/vapp-4ea2a1dd-d079-427e-85e0-xxxxxxxx,requestTime=1666787995611,remoteAddress=xxx.xx.xx.xx:46342,userAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...,accept=application/*+xml;version 36.3
Operations not found on  ( xxxxxxxx-546b-4ed7-84f9-xxxxxxxxxxx) | requestId=xxxxxxx-0700-46ea-be70-f0138796a088-xxxxxxxxxx-0f1e-4bc7-9e09-962a4f79939b,request=GET https://vcd/cloudapi/1.0.0/orgVdcNetworks,requestTime=1666788590990,remoteAddress=xxx.xx.xx.xx:58374,userAgent=Apache-HttpClient/4.5.13 (Java/11.0.14),accept=application/json;version 35.0
2022-10-26 14:49:51,110 | DEBUG    | pool-jetty-1299244        | OperationsManagerImpl          | Operation denied, required but missing operations:
Operations not in users context. | requestId=xxxxxxx-e4da-41cf-8559-xxxxxxxxx,request=GET https://vcd/api/vApp/vapp-xxxxxxx-xxxx-427e-85e0-xxxxxxxxxx,requestTime=1666788590972,remoteAddress=xxx.xx.xx.xx:58370,userAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...,accept=application/*+xml;version 36.3 

Interesting to see is that we are apparently missing the following two rights:


The first one seems to indicate a certain vCenter Server (vSphere) permission, since all vSphere permissions have “VIM” in the name. The second one is unknown. Both of these descriptions do not match any right inside the VCD database (I checked). So at this time we had to enable GSS to find the resolution to this. I could’ve found this out by doing a trial and error phase in which I tried every single right there is, but there are a couple hundred of them inside VCD, which would take me forever.

Troubleshooting together with GSS eventually provided us with a solution. It seemed to be the following permission that had to be added to the role:

  • Networking -> Provider Network -> View Provider Network

Once we added this the users were able to view all information from the vApp, see their attached vApp networks and edit the VM’s that were inside the vApp again. However, what else this right enables is unclear, except that it also enables (in the Provider user context) the following visibility for the tabs called:

  • External Networks
  • Tier-0 Gateways

The user in question can only see the tabs and view the information. They cannot do anything actionable with it unless you have assigned more rights to the role ofcourse.

I hope this was usefull for you guys.

Bryan van Eeden

Bryan is an ambitious and seasoned IT professional with almost a decade of experience in designing, building and operating complex (virtual) IT environments. In his current role he tackles customers, complex issues and design questions on a daily basis. Bryan holds several certifications such as VCIX-DCV, VCAP-DCA, VCAP-DCD, V(T)SP and vSAN and vCloud Specialist badges.


Leave a Reply

Avatar placeholder

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