User Management Guide
This user management guide collects documentation on all of these features as well as how they interrelate in a single place. It is meant to complement the relevant documentation found in the management UI chapter:
Finally, the context menu section is also relevant to orcharhino’s user management. User access in orcharhino is restricted based on context which represents real world organizational structures. An organization might be a business unit and a location might be a data centre.
orcharhino’s user management consists of users, roles, and permissions.
Restricting access to different parts is convenient in order to avoid accidental changes by unauthorised personnel if your orcharhino is administered by more than one person. orcharhino provides the possibility to assign specific roles with fine-grained access filtering configurations to every user.
sshinto your orcharhino server.
Get a list of existing authentication sources:
hammer auth-source list.
Get a list of existing user roles:
hammer role list.
Create a new user:
hammer user create --admin false --auth-source-id 1 --login alice --mail firstname.lastname@example.org --password asd123 --role-ids "21,42".
Adjust the authentication source and user role IDs accordingly. Run
hammer user create --helpfor more information.
Refer to the Hammer CLI guide for more information.
sshinto your orcharhino server.
Get a list of existing users:
hammer user list.
Create a new API personal access token:
hammer user access-token create --name my_PAT --location-id 1 --organization-id 2 --expires-at 2021-04-01 --user-id 3.
Adjust the location, organization, and user ID accordingly. This will return the PAT as follows:
Personal access token [my_PAT] created: 7UqkVjcN6VyTdbmhYiDNmw
View existing API access tokens:
hammer user access-token list --user-id 3
---|--------|--------|-------------------- ID | NAME | ACTIVE | EXPIRES AT ---|--------|--------|-------------------- 1 | my_PAT | yes | 2021/04/01 00:00:00 ---|--------|--------|--------------------
Adjust the user ID accordingly. Run
hammer user access-token create --helpfor more information.
Refer to the API endpoint on your orcharhino for more information:
If you set a random passphrase for a new user and adjust its user roles accordingly, you can create a PAT for this user and use it as an "API only" user.
A role is a set of permissions that can be allocated to desired users or user groups. Every user has one or more roles and obtains all permissions that are defined within. Refer to roles on how to create and assign roles to users and user groups.
Note that you can create any number of roles fitting your needs but you have to save them first before providing them with filters.
Depending on the number of users with access to your system, it might be more efficient to create groups to bundle permissions instead of targeting users individually. Refer to user groups on how to create and manage user groups.
Filters are part of the roles and describe a set of allowed actions on a specific element, i.e. a resource type. You have to create a filter for every resource type you want to be accessible by users with a specific role. For example, you can create a filter of the resource type host which allows the role to only edit a specified list of hosts instead of all hosts.
By default, every user bears at least the permissions of the anonymous role which can be edited but not deleted. The permission set of the anonymous role will be automatically granted to every user account within orcharhino. You can edit this role and even deprive it of all of its filters, but you cannot delete the role itself.
A resource type describes entities of the orcharhino that require permissions to interact with. They are similar to the types of resources that are managed by orcharhino, like hosts, products, or content views. The number of actions available varies for each resource type. The default actions to which permissions can be granted to for almost every resource type are view, create, edit, and destroy.
Please note that some filters depend on each other in order to take proper effect. For example, the permissions of the reports resource type are only valid if the user also has access to the orcharhino dashboard and the permission to view hosts.
The most convenient way to manage orcharhino user accounts is to connect orcharhino to an LDAP server. This allows you to delegate the task of authentication and authorization of orcharhino users to a trusted source in your environment. Refer to the creating an LDAP authentication source section on how to attach an existing LDAP server to your orcharhino.
Job templates can be used to execute arbitrary commands on any system that accepts the SSH key used by orcharhino’s remote execution features. By default, this will include all managed systems as many orcharhino features depend on it. In addition, ATIX provides job templates intended to target the orcharhino host itself in order to automate orcharhino administration.
As a result, it is highly recommend to limit job template access for standard users.
You can disable job template access completely by ensuring your standard users do not have access to either the
Remote Execution Manager or the
Remote Execution User roles.
Since users will often need access to at least some job templates, you can also use a combination of the
Remote Execution User role along with filters to limit users to specific templates and/or specific hosts, allowing for almost arbitrarily fine grained permissions management.
The example below uses a filter to exclude users from using the
Run Command - SSH Default and
Run Command - Ansible Default templates.
These templates are particularly versatile, since even users that may not edit any job templates (
Remote Execution Manager role) can use them to run arbitrary commands via job parameters.
Navigate to Administer > Roles and select Clone from the drop down menu of the
Remote Execution Userrole. Select a new name of the role and save it to orcharhino.
Edit this role and adjust its filters on the Filters tab:
Set the permission from
host.name != orcharhino.example.com and host.name != orcharhino-proxy.example.com. This will limit job invocations to not use the orcharhino or orcharhino proxy as target host.
Set the permission from
job_category != Commands and job_category != "Ansible Commands".
Make sure your limited user has access to your cloned
Remote Execution Userrole only.