Intro
For one of my customers I looked at a content library (permissions) problem which they have been dealing with for some time. The problem that the customer had was that the vCenter reported that the account(s) had not enough rights to deploy in the resource, whenever a template was chosen in the content library. Fun fact, I had the same problem with my account while I was a full administrator.
Problem Overview
Content Library Error: You do not have permission to create a virtual machine from a library template in the selected resource.
The problem was quite persistent and consists of 4 underlying problems. Which actually happens more often, so I thought lets sum the up in case someone is having similar issues.
Cause 1 – Operations Role had too few rights within vSphere
In this particular case one users was part of an AD group which was part of the “Operations Role”. Within vSphere you have standard roles, but you can of course also change them or create new roles with more or less rights. In his case their role had not enough rights. So always check the documentation if this is the case. However, if you have admin rights and you still cannot perform some operations or tasks, then of course something else is (also) blocking you. Lets go to the next one.
Cause 2 – Other AD groups block permissions when a user is a member of multiple AD groups that are assigned within vSphere
This one was a bit trickier. I noticed that as an admin I could not deploy from the content library either. When I created a new user that was not a member of anything, but only the VMware Administrators group, then it worked. After some research I found out that in the customers vSphere environment, there were several AD groups that had a Role assigned to them. The following groups from AD have also been assigned a Role within vSphere:
VMWARE_VSPHERE_ADMINISTRATOR
VMWARE_VSPHERE_BACKUP
VMWARE_VSPHERE_OPERATIONAL
VMWARE_VSPHERE_READ_Only
sa_veeamBu
2thline_systemsmanagement
XenApp_Admins
I for instance was part of the “VMWARE_VSPHERE_ADMINISTRATOR” group in AD which in vSphere had the Administrator Role assigned in global Permissions, my colleague had the “VMWARE_VSPHERE_OPERATIONAL” role assigned, but we were both also part of the groups “2thline_systemsmanagement” & “XenApp_Admins” within AD. Both groups also had a role assigned within vSphere, which was the Virtual Machine Power user. So whenever we logged in, we got mixed rights. Once I removed myself from the groups within AD, or when I removed the groups within the vSphere environment, we were only part of one group, and got the appropriate rights.
Cause 2: Solutions & Tip
AD groups are handy, especially when it comes to application rights. However, I would suggest that you make specific VMware vSphere groups within AD, that are not being used for other applications, files or systems. This way you can keep the rights simple and clean. In our case, I removed all the groups within vSphere that were being used by other resources besides vSphere and created new groups as the following.
This way, you are sure that you don’t mix up rights, and you can select user to be part of only 1 Group within AD & vSphere. Another tip is to use a clear naming convention. This way, you can easily identify if a certain group should be part of a role within the VMware vSphere environment.
Make sure though that when you remove the old groups that you remove them from all assigned Objects & Global Permissions. If you want to know where you can see where all the rights are placed, go to:
Administration Roles Select a Role and click the Usage Tab
Cause 3 – Placing the permissions on the wrong objects, Content library usages Global Permissions
So there are several ways to place permissions within vSphere. One is through Global Permissions which gives you overall rights within the vSphere environment if you want to. You can propogate the rights from the root towards it children or not. Another way is to assign rights directly on the object. You can even sign a specific AD group that hasn’t been used before, on a specific object.
However, the content library works a little different.
* The Content Library doesn’t get deploy permissions from the object (vCenter) hierarchy but from the root (Global Permissions)
The content library is one of the few components on which you can’t set permissions directly via permissions on an object.
- Normally you grant permissions on an object, which affects lower-level objects. The vCenter is one of the highest objects.
- However, The content Library is not directly under the vCenter object or a storage object, even though you specify it as a vCenter location or even storage location.
- The only way to do this is to create permissions even higher up the hierarchy that do address the content library, in this case root or Global Permissions.
Below is a picture for clarification:
Cause 4 – LDAP group vs LDAP user (upgrade) bug in combination with the Content Library/Global Permissions
The last vague problem I had was that AD users logging in via LDAP using group permissions, often had different permissions than when I assigned a role to an AD user directly within vSphere (and not via an AD group). This issue was mainly related to Global Permissions and in combination with rights for the content library, and it didn’t show up in different objects. This a (sort of known) bug within vSphere, which happens most often after an upgrade.
I solved this by simply recreating the groups within vSphere.
So that’s it. Those are the most common reasons why certain rights & permissions within vSphere are not working. If you have a similar issue with AD rights, I would suggest that you would test it by simply creating a clean AD account with no rights, and then start by assigning it to one group with lots of rights. Then keep adding or removing the rights or change the roles, and you should be able to figure your problem out.
P.S.
There is another bug. When you remove a user from a LDAP group, it is possible that he can still log in for a while, even though he should not be able to login at all. This probably has to do with the synchronization, but because of this you can get weird test results if you have multiple groups via LDAP on.
I hope this was helpfull and that this post made the somewhat complex Permission Hiërarchie & structure within vSphere, a little bit more clear. Once again thanks for reading, and let me know what your thoughts are on this topic.
Samir is the author of vSAM.Pro & a Life enthusiast who works as a consultant in the field of IT. With a great passion for Tech & Personal Development, he loves to help people with their problems, but also inspire them with a positive outlook on life.
Besides that, he is also a big Sport & Music junky that loves to spend a big chunk of his time on producing music or physically stretching himself.
