Understanding vCommander Access Control
Embotics vCommander provides role-based access control, which allows you to ensure that:
- administrators have the right level of access to the various parts of your virtual infrastructure
- data for the various groups of users that consume your IT services is appropriately segregated
vCommander has both an administrative console and a Service Portal, with roles governing where users are permitted to log in. You can assign both a vCommander role and a Service Portal role to the same user. This is useful for administrators who want to log into the Service Portal to verify the effects of configuration changes.
This topic provides an overview of vCommander access control and how to control administrative user access. Then we'll look at how to control Service Portal user access.
There are three things to set up for each administrative user:
- A user account
— A local user (created in vCommander) or a directory service user or group. vCommander integrates with both LDAP and Active Directory.
Passwords for local accounts are stored in the vCommander in encrypted format, using 256 bit AES encryption.
- A vCommander role — A role is a set of permissions determining what tasks a user can carry out. vCommander roles control what users can do in the vCommander console. (Service Portal roles control what users can do in the Service Portal; we'll look at these later.)
- Access rights — Access rights determine what parts of your virtual infrastructure each vCommander role may access. If an administrative user needs access to your virtual infrastructure, you must assign access rights. Access rights can't be assigned to users with Service Portal roles.
For example, one administrative user account exists when you first install vCommander: superuser. It can't be deleted. The superuser account:
- is a local user account
- allows the user access to the vCommander console with the vCommander role of Superuser
- has the highest level of access rights (Administrator) on all managed systems in your virtualized infrastructure
There are four things that you can set up for users in the Service Portal:
- Organizations — While not mandatory, we recommend that you use organizations as the basis of Service Portal user access control. Organizations support multi-tenant environments by allowing customized configuration and data segregation for your groups of Service Portal users.
- Parent organizations — If you add organizations, you can set up your multi-tenant environment with a hierarchy that uses parent organizations at the top level and has regular organizations grouped as children under those parent organizations.
- Single user account — This can be a local user, a directory service user, or a directory service group. (vCommander supports both LDAP and Active Directory).
- Service Portal role — Service Portal roles allow access to the Service Portal.
Using organizations is the easiest way to provide your Service Portal users with Service Portal access, because you can add users and groups and assign them a role when you create the organization.
Two Service Portal user accounts exist when you first install vCommander: user and manager. These accounts:
- are local user accounts
- have the Service Portal role of Delegated Admin and Manager, respectively, allowing access to the Service Portal only
- have no access rights (because users with Service Portal roles can't be assigned access rights)
Now that you understand the basics of vCommander access control, here's what you need to do:
- Learn about vCommander roles
- Add administrative users and assign them a vCommander role
- For those administrative users who need it, assign access rights
- Learn about Service Portal roles, and customize them or create new roles if you need to
- Set up organizations for your Service Portal user groups (when you set up organizations, you add users and assign organizational roles). This is the recommended usage for configuring Service Portal users. If you also want to use parent organizations, see Using Parent Organizations.
- Or, if you're not planning to use organizations, add Service Portal users and assign them individual Service Portal roles