One of the more mysterious parts of vCenter Operations Manager (vCOps) from a new administrator’s perspective is exactly how you control access to the objects that any particular user can see within the interface. It’s an easier relationship to understand when using the vSphere Web Client, as the user can only view objects they were given permissions to view along with the Health status of that object in the Summary tab.

I see a fair bit of confusion from both discussions with folks that I work with and those on various forums on exactly how you translate permissions from vSphere to vCOps. Some discussions have given the (bad) advice of stating that a user must be a full vSphere Administrator to use vCOps – this is false.

Controlling vCOps Access

When working in an environment that uses vCOps, I typically start by cloning out the Read-only role into a new role called “Read-only with vCOps”.

I then edit the role to include the Global permissions of “vCenter Operations Manager User”.

Setting vCOps User Permission on the vCenter Object

Assign a user the new “Read-only with vCOps” role in the hierarchy at the vCenter object. I typically turn off propagation unless that user needs to see the entire infrastructure.

Make sure to then apply any additional permissions the user needs in other locations.

End Results

Here’s an example of the permissions I applied for Bob Sponge. I’ve assigned the “Read-only with vCOps” at the root vCenter Object with propagation disabled, and then again at the “Lab” cluster with propagation enabled.

When good ol’ Bob logs in, he cannot see the other cluster but can see the Lab cluster. Any objects that he does not have rights to will appear grey with a “Restricted” error as shown below.

Results of Applying vCOps User Permission Lower

Failure to apply the global “vCOps User” permission on the vCenter object will result in a “User not authorized” failure, as shown below for my Bob Sponge user.

vCenter Permissions Troubleshooting

I have run into cases where the user was assigned permissions in a variety of places, such as at the top level vCenter object, the Data Center, and the Cluster, but only changed to the “Read-only with vCOps” role at a single layer, such as at the Cluster. This caused some weird issues in that the user would get either a “user not authorized” or “incorrect user name/password” error when they tried to log in.

Here’s an example of this behavior. And yes, I’m typing in the password correctly 😉

My best advise would be to offer a consistent level of permissions across the user account from a vCOps perspective, especially for the top most layers of permissions. If an account has been granted rights to the vCenter object, ensure that it has vCOps User access.

LDAP Integration?

This is another area that seems to stump folks. All documentation that references creating user accounts and typing them into LDAP are referring to the “Custom UI” / Custom Dashboards feature of vCOps “Enterprise” edition (also found in the vCOps Advanced Suite license). The normal vCOps web interface, also known as the “vSphere UI”, has no settings for LDAP integration – it simply draws from the accounts configured in vCenter.

If you want to use LDAP accounts with the vSphere UI, just ensure that the accounts are given the permissions needed (as shown above in this guide) in the vCenter tree. For vSphere 5.1 users, this means incorporating that domain into your SSO service.

Looking for details on configuring SSO? Try my two part blog / video SSO series!

Thoughts

I hope this addresses some of the mystery around vCOps user permissions and clears up the FUD around needing to grant full Administrator access to an account for viewing vCOps. Feel free to share your experiences in the comments below!