Home > vSphere API > What Roles Does A User Have in vSphere?

What Roles Does A User Have in vSphere?

November 30th, 2011 Leave a comment Go to comments

If you have read my previous article on vSphere security model, you know how it works. Still, you may wonder what roles a particular user may have, as asked in a recent email from one of my former VMware colleagues.

In an operating system, a user is assigned to a group or multiple groups therefore granted a certain permissions. In vSphere, a role is simply a set of privileges and that is it. It’s natural to think of a role as a group sometimes, but it’s really not.

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


Generally speaking, there is no generic roles for a user to have, but always under a scope of what entity alone or plus its descendants in the inventory tree.

The following screenshot from MOB should explain more. As you can see, a Permission object always has entity while associating user with a role. The propagate field indicates whether the entity’s descendants are covered as well.

With that being clarified, you can check what roles a user has on a managed entity. To get that information, you can call the retrieveEntityPermissions() of the AuthorizationManager managed object type. Note that you need to pass in a managed entity or its ManagedObjectReference as parameter. Optionally, you can use the retrieveAllPermissions() method assuming you want to filter through all the returned Permission objects by yourself.

Now, this is not yet the end of the problem. What if as shown above, the principle is actually a group (indicated by the group field in Permission)? In that case, your ID may not show up in any of the Permission objects. How would you know you are part of one of the groups?

The answer is no if you only look at vSphere itself. You want to look it up from the AD of your domain. It is not that difficult by the way. On your computer running vSphere Client, just type in the following command in a DOS console:

> gpresult /X myGroup.xml

Then you will find your group information in the XML file. It’s too long to be list here, but you can easily try it out by yourself.

With these two piece of information, you can figure out what roles, if any, a user has over an entity in the inventory hierarchy.

Categories: vSphere API Tags: ,
  1. BeeMan
    January 19th, 2012 at 12:19 | #1

    Hi Steve,

    Thanks a lot for the detailed explanation.

    What if as shown above, the principle is actually a group (indicated by the group field in
    Permission)? In that case, your ID may not show up in any of the Permission objects.

    Could you please explain why wouldn’t the ID of the group show up in the Permissions?
    Isn’t the roleId a “foreign key”?
    Do you specifically mean the case where the users got personal permissions, and all are part of some group, which was “assigned” to a permission?

    Thanks a lot!

  2. January 19th, 2012 at 16:15 | #2

    Thanks for your comment! As you noticed, the principal is a group. The ID of the group does show up in the Permission object. See the principal field. The roleId, when in a Permission object, is a foreign key.


  3. BeeMan
    February 8th, 2012 at 10:31 | #3

    Hi Steve,
    Another question, I guess the answer to it will explain the “The answer is no if you only look at vSphere itself ” sentence.

    I am trying to get a list of groups a user belongs to on a VC.
    In any combination I use, I get the Not Supported error.
    Am I mistaken with the parameters, or is it not supported in VC?

    I used several combinations, this one looks to me like the right one:
    retrieveUserGroup parameters are as follows:
    domain = null

    result: Not Supported

    Thanks a lot for your help!

  4. BeeMan
    February 8th, 2012 at 10:44 | #4

    By the way, I get Not Supported, also on the example you wrote in your book, page 444:

    What am I doing wrong?

  5. February 8th, 2012 at 17:13 | #5

    Per the API reference, the NotSupport exception is “Thrown if you specify a domain for systems that do not support domains, such as an ESX Server. The method also throws NotSupported if you specify membership (belongsToGroup or belongsToUser) and the server does not support by-membership queries.”
    On my book page 445, it’s noted that the code gets NotSupport exception. While reading the comment before the code, I also mentioned the sample works with both ESX and vCenter. In vCenter case, it may need a little tweak on parameters or it depends the vCenter setting. I don’t recall all the details but I ran every sample in the book for sure.

  6. BeeMan
    February 12th, 2012 at 08:51 | #6

    Well, I found out that belongsToGroup and belongsToUser are not supported on Windows Server. The code works, but returns a NotSupported, which is OK by definition.

    So to get whether a user is in a certain Windows group, we may use the UserDirectory.checkGroupMembership(“”, { “Administrators” } ) method.

    Thank you!

  7. BeeMan
    February 12th, 2012 at 08:52 | #7

    Somehow the form removed the user parameter:

    UserDirectory.checkGroupMembership(“username”, { “Administrators” } )
    Check whether username is in Administrators group.

  8. Ravi M
    April 10th, 2012 at 04:51 | #8

    Hi Steve,

    I am encountering the issue of having the Group ID as principal, but the user’s privileges need to be determined at that entity.

    Going with your suggestion of issuing a gpresult command is only useful, if the user logged in to the vCenter Server with computer credentials. What, if the user used different credentials for the computer and the vCenter Server.

    If we try to issue gpresult /user /x mygroup.xml, this command works only if the user has logged in to that machine before; forcing the command to be issued in the machine running vSphere Client. (We might want to issue the command at our own plugin server machine and not the machine running vSphere Client)

    Isn’t there a way to get the Privileges for a user name at an entity (combining the union or override of group’s and user privileges assigned at that entity!)


  1. No trackbacks yet.