Ensuring that only the right users get access to vROps is an important part.
In vROps there are different ways to ensure this.
- Local Users
- vCenter Users
- LDAP and SSO
Most cases I see make use of option 3. But to not leave anyone behind lets just go over options 1 and 2 also.
Local Users
Local Users of vROps are authenticated locally against the vROps server. the Username and password are stored inside the vROps server.
By default there are 4 kinds of local users when you istall vROps:
- migrationAdmin
- admin
- maintenanceAdmin
- automationAdmin
They are all enabled and have access to all objects, and are member of the “everyone” local group. A part from the admin account, the other three accounts are not for logging into vROps. They are accounts that are used by vROps.
The Everyone local group, is the only group that exists from the installation. The 4 users above are all members of this group. The group however has no special permissions assigned.
Adding a local user is quite simple, it is a two step process:
Under Administration –> Access –> Access control –> User Accounts
Click on the green plus to create a new user.
Second page you would select a group, note here that you can not select the “Everyone” group.
Under Objects however you can select a Role and then what objects the user should have access to with that role.
Groups are created in much the same way, you put a group name and you assign members to the group and then select what objects the group has access to.
vCenter users
vCenter users must be admin and valid users in vSphere or have a privilege set in vROps. If the privilege is set in vROps then it needs to be assigned at root level of the vCenter. All privileges are then assigned below the root. The user will be able to view all the objects in vCenter and vROps alike.
A few other but important things in relations to vCenter users:
- User objects do not appear from other vCenter instances found in vCenter Linked mode
- a vCenter user has the read only right in vROps. You cannot change the role. If something must be changed in the access. This must be done in the vCenter, not in vROps. The Role is applied at the root level of the structure in vCenter. This means that if the user has more power at root level, this power is applied down through vCenters structure, according to what right the user has in vCenter.
- vCenter Server uses can not create or schedule reports in vROps
- If you use SSO with vCenter you must manually delete the user in vROps. The account will still appear otherwise in vROps
By Default the vCenter users have access to vCenter. If you want to change this, then you can do it from the following place: Administration –> Management –> Global Settings
LDAP and SSO
There are two kind of externals sources from where you can authenticate users against. The one is through LDAP and the second is through SSO. Users are verified against the external authentication source.
For LDAP only one domain. Multi-domains are not supported. This is also the case even if there is a two way trust between the domains.
Importing an Authentication source is done from the Administration tab.
Administration –> Access –> Authentication Sources
Click the green plus to add a new authentication source.
You can see above what choices you have. In this case I will just add an AD LDAP connection. The name actually has significance here as you need the @AD part for certain other aspects of integrating vROps for example with using an AD service account for connecting to vCenter. I suggest here that you use a single word for your AD connection and avoid spaces and odd signs. In my case I will just call it AD. After all, I can only add one LDAP connection as per above info. The user account does not need to be an administrative user. The user just needs to be able to search the AD for users. Normally a domain account should suffice.
Enter the information and don’t forget to test your connection.
Press OK to create the source (Notice under details that it automatically synchronizes users).
Now we should be able to import a group from AD. To do this go to Access control and select the Import group icon.
Type in the group name or part of it and hit search. Your group(s) should come up.
Check the group(s) you want to import and click on next.
Next we select what rights the group should have in vROps, since I”m important the admin group, I will want it to have full access so I select the Assign the role to the group and giving rights from the root level.
You will receive a warning asking if you really want to give access to all objects in the system. Click yes to continue or no to go back and select something more granular.
That is it, if you have added members to the group, then the members should show up after a synchronization.
If you can not wait until the sycnhornization has taken place, then go back under “Authentication Sources” below Access control and find the identity source and click on the synchronize button.
Access Control
For Roles there are a few more by default. None of the users above are assigned to any of the groups.
The most important thing to notice here is that only Users or groups with the Administrator role can edit user permissions. PowerUser role can manage Clusters but not users. Administrator role does not have access to manage Agents.
You can create your own Roles if required and configure them. If you do require roles other than the ones defined by default, you can also select a role that is close to what you require and clone it. I would recommending doing this rather than modifying a default role.