vCenter permission inheritance – A different story for DVS

Giving permission in vCenter outside of the regular administrators is a common practice with my customers. Some business groups needs access for Shutdown/reboot/reset only their VM. Others need access to their whole cluster to do different tasks. Unfortunately vCenter permission inheritance is not as easy/intuitive as NTFS permission. But we have a great documentation explaining the Hierarchical Inheritance of Permissions in vCenter. This documentation explains which objects have a parent/child relationship so you have an idea of where you need to set specific permission and to what other objects these permissions get inherited.

How to use vCenter permission inheritance on DVS correctly?

Problem

My customer is replacing their existing automation tool with a different self-developed tool that is using Foreman in the background. During some network discovery tasks in Foreman, we saw an issue. It was not possible to gather information about the Distributed Virtual Switches. When the customer removed permissions from a particular switch it worked without a problem.

The customer then came to me and ask me about how to set permissions correctly on the DVS. I gave him the mentioned documentation and we added the required group with “Propagate to children” on the DVS. Unfortunately, the task in Foreman still didn’t work which was a little bit strange for me. To be sure that everything was correct we checked some port groups to see if the user group was there. To our surprise, the group wasn’t there.

I started then to dig deeper into this problem. I checked therefor the MOB (Managed Object Browser) to see the relationship there.

This is the relationship of the DVS:

And this is the relationship of the distributed port group:

As we would have expected is the DVS (DVSObject-01) a child object of the network folder object. What we didn’t expect is that the distributed port group is also a child object of the network folder. That is the reason “Propagate to children” is not working on a DVS level.

Unfortunately, I don’t know if this was always the case or not. So I checked several vCenter versions (6.5 U1, 6.5 U3, 6.7 U2 and latest 7.0 U3x). In all of this versions, the distributed port groups were child objects of the network folder object. Therefor I would assume it was always the case.

From a documentation perspective this should now be the correct view.

Solution

With the knowledge we have now, what can we do to accomplish the permission inheritance goal? In my case we created a network folder and moved all required DVS into this folder. Then we set a “No Access” role for the required group on the datacenter object. We changed then the specific role my customer has for Foreman on the newly created network folder.

Conclusion

It’s always a learning curve when you think you know a product inside out and then discover that certain things are working completely different. But I think this is the beauty in an IT job. You are always learning and you can always improve your experience and knowledge. I will do my best to get the Hierarchical Inheritance of Permissions documentation fixed internally.

The funniest thing of this problem was that the actual problem with Foreman was not the vCenter permission inheritance. The problem was that the Foreman user had access to some distributed port groups but not to the distributed switch. Therefore Foreman can’t tell to which DVS this ports were related to and through an general error message.