Role-Based Access Control

This section describes the components of role-based access control (RBAC) in Skylar One (formerly SL1) and how to use them to determine which end users have access to which features within the system.

Use the following menu options to navigate the Skylar One user interface:

• To view a pop-out list of menu options, click the menu icon ().
• To view a page containing all of the menu options, click the Advanced menu icon ().

What is Role-Based Access Control?

Role-based access control (RBAC) is a methodology that enables Skylar One administrators to determine which end users have access to which features within the system. It has three primary components:

• Organization memberships

• Access hooks and access keys

• User accounts and user policies

The role that each of these components plays in configuring RBAC in Skylar One is described in the following sections.

Utilizing Organizations for Role-Based Access Control

An organization is a group for managing elements and user accounts. All policies, events, tickets, users, and other elements in Skylar One are associated with an organization.

Most managed elements in Skylar One, such as devices, can be assigned to only a single organization.

On the other hand, users can be assigned to multiple organizations. This can be done directly through their user account or indirectly through a user policy that is associated with their account.

In Skylar One, a user has access to only those elements that are assigned to an organization to which the user also belongs. However, being assigned to the same organization as an element does not automatically grant the user access to that element; the user's account must also include the access hooks necessary to view or perform specific actions on that element.

For this reason, think of organizations as the first-level filter for determining RBAC in Skylar One, not the final determining factor.

For example, a system might have three organizations: Org A, Org B, and Org C. If user is a member of Org A and Org B and is assigned the appropriate access keys to view the Devices page or Device Manager page, the user will see only devices in Org A and Org B on those pages. The user will not be able to see or interact with elements associated with Org C.

Utilizing Access Hooks and Access Keys for Role-Based Access Control

An access hook controls access to a specific action that can be performed in the Skylar One user interface. These actions include navigating to a page, viewing information about an element in the system, and editing elements in the system. Each access hooks is designed to be highly granular, providing access to only one action on one specific entity or page. Because of this granularity, there are hundreds of access hooks available in Skylar One.

Access hooks are not granted to users directly; instead, access hooks are grouped together to form an access key, which can be granted to users either directly through their user account or indirectly through a user policy.

In Skylar One, a user must be assigned to the same organization as an element and have been granted the necessary access keys to view or edit that element.

Due to the importance of access hooks in determining role-based access control in Skylar One, users cannot add or alter access hooks.

For more information about access hooks and access keys, see the section on Access Permissions.

Utilizing User Accounts and User Policies for Role-Based Access Control

User accounts allow individual users to access the Skylar One user interface. In Skylar One, there are two broad types of user accounts:

• Administrators, who are granted all permissions available in Skylar One. Administrators can access all pages and perform all actions and tasks on all elements, regardless of their organization.

• Users, who are granted access to specific pages, the permission to view specific information, and the ability to perform specific tasks within Skylar One through the access keys they are granted in their user accounts. Their access is also limited to only those elements that are associated with the same organizations to which the users are assigned.

User policies allow you to define a custom set of account properties and privileges that you can quickly apply to one or more user accounts.

When creating or editing a user account or user policy, the following fields help determine the level of role-based access control the user account or policy has in Skylar One:

• Organization or Primary Organization. Specifies the primary, default organization for the user.

• Additional Organization Memberships. Specifies all other organizations of which the user is a member.

• Account Type. Specifies whether the user is an administrator or a non-administrator user.

• Privilege Keys. Specifies all of the access keys that are granted to the user.

  Because administrator users automatically have access to all pages and actions in Skylar One, the Privilege Keys pane is grayed-out if the Account Type field is set to Administrator.

If a user is able to modify user accounts, user hierarchy is also enforced in the following ways:

• Non-administrator users cannot modify administrator accounts.
• Non-administrator users cannot make themselves or another user an administrator.
• Users cannot grant or remove access keys that they have not also been granted.

For more information, see the sections on Creating and Editing User Accounts and Creating a User Policy.

Role-Based User Accounts

Separate from the manner in which Skylar One utilizes organization membership, access hooks and keys, and user accounts and policies to establish role-based access control throughout the system, it also offers two limited access, role-based user accounts that can be used for performing maintenance tasks or troubleshooting problems. This section describes those role-based user accounts and how to use them.

What are Role-Based User Accounts?

Remote support personnel or contractors sometimes require temporary or limited access to a Skylar One appliance to perform maintenance tasks or to troubleshoot problems. For these situations, you can grant access to the Skylar One appliance using one of the following limited access, role-based accounts:

• sl1admin
• sl1user

Role-based accounts are supported on All-In-One Appliances and in the distributed Skylar One architecture. These accounts are not currently supported for the extended Skylar One architecture.

These role-based accounts are installed by default in Skylar One version 11.1.0 and higher. No configuration is required to enable the accounts.

The sections that follow provide more details about these accounts.

Role-Based sl1admin Account

The sl1admin account enables the system owner to grant temporary access to support staff who perform maintenance and troubleshooting tasks.

• The sl1admin account does not appear in the Skylar One user interface. This account is available for SSH or console access to the command line of a Skylar One appliance only.
• Skylar One grants one-time passwords from a file of hash values. The initial file is generated upon install or upgrade of Skylar One. This file is regenerated each time half the passwords in the file have been granted or when the file reaches 7-days old, whichever occurs first.
• Each time a one-time password is granted, Skylar One creates a log entry in the Audit Logs page (System > Monitor > Audit Logs).
• The sl1admin user does not have full root access. The sl1admin user uses a tmux shell and has access to only a limited set of commands. The sl1admin user can restart services, shutdown and reboot Skylar One appliances, and run sudo commands that do not require root access.
• All sudo actions by the sl1admin user are logged in the file /var/log/secure.
• Additionally, the Skylar One administrator can attach to the session in read-only mode to watch the sl1admin session in progress or attach in read-write mode, which allows the Skylar One administrator to take over the session, if necessary.

The ability to use one-time passwords is disabled in AWS deployments of Skylar One.

Using the sl1admin Account

To log into the sl1admin account:

1. In a console or command window, SSH to the Skylar One appliance, as follows, using the IP address of the Skylar One appliance.

   ssh sl1admin@<ip_address>

2. The password prompt will display a 3- or 9-digit number. Make note of this number to use in the next step.

   The numeric code is 3 digits unless you have canceled out in the middle of your most recent login or if another user is also logging in to the sl1admin user account at the same time. In either of those cases, you will be given a 9-digit numeric code such as 001/030/009.

3. Open the Skylar One user interface and go to the Appliances page (System > Settings > Appliances). Find the appliance you are logging in to in the list of appliances and click its lock () icon. The One Time Password modal appears.
4. Enter the numeric code that was displayed in step 3 into the One Time Password modal. Click Generate Password. The generated password appears.
5. Type the generated password into the console window at the password prompt. Press Enter. After authentication is complete, the sl1admin user session begins in a tmux shell. You will see a green status bar at the bottom of the screen.

Monitoring an sl1admin Session in Progress

You can monitor an sl1admin session that is in progress using the em7admin account. To monitor the session:

1. In a console or command window, SSH to the Skylar One appliance where the sl1admin user session is in progress. Log in with an administrator account.

2. Obtain the unique identifier (UID) of the tmux session in progress by entering the following command.

   file /tmp/tmux*/default

3. Note the UID returned by the command. In the following example, the UID is "1001"

   /tmp/tmux-1001/default: socket

4. Use the UID to attach to the tmux session with the following command.

   tmux -S /tmp/tmux-<uid>/default attach

   The command above provides read/write access to the tmux session. If you want to attach as read-only, append "-r" to the command string.

5. Exit the attachment to the session by pressing Ctrl+b, and then "d".

Role-Based sl1user Account

The sl1user account allows a user to perform maintenance tasks from a set of menu options. This menu allows the sl1user account to administer a Data Collector.

• The sl1user account does not appear in Skylar One user interface. This account is available for SSH or console access to the command line of a Skylar One appliance only.
• The sl1user account can:

• modify the IP address of a network interface
• test DNS entries
• modify and test NTP entries
• view system status
• view the message of the day

• Each action performed by the sl1user account is logged in /var/log/em7/slmenu.log.

Changing the Password for the sl1user Account

During installation or upgrade to Skylar One version 11.1.0 or later, the password for the em7admin account is copied and set as the sl1user account password.

SciencLogic strongly recommends that you change the initial default em7admin password before granting access to the sl1user account. Because the initial default password for the sl1user account is the same as the password for the em7admin account, you must change the password before the first use of the sl1user account.

To change the password for the sl1user account:

1. Log in to the console of the Database Server or SSH to the Database Server.

2. Enter the following command:

   sudo passwd sl1user

3. When prompted, type and then re-type the new password.

Using the sl1user Account

To use the sl1user account:

1. In a console or command window, SSH to the Skylar One appliance, as follows, using the IP address of the Skylar One appliance and the sl1user password.

   ssh sl1user@<ip_address>

2. At the sl1user main menu, make a selection using the number of the selection or the arrow keys. Click OK.

3. When you are finished, choose Exit from the main menu to close the session.

Menu Options for sl1user

The menu options available for the sl1user account are described below.

• Network Configuration. The Network Configuration menu lets the sl1user select an interface from a list of interfaces and edit the configuration for that interface. For example, if the gateway or DNS entry was configured incorrectly during installation, the sl1user can choose this menu option to correct the configuration.
• NTP Configuration. The NTP Configuration menu lets the sl1user perform basic NTP actions. Menu options are as follows:
• Edit configuration. Edit the existing NTP server entries.
• Test configuration. Check if the configured NTP servers are responsive.
• Force Sync. Force a sync with the NTP servers in case of clock drift, for example.
• Restart Service. Restarts the chronyd service.
• DNS Configuration.
• Edit configuration. Edit the existing DNS server entries.
• Test configuration. Check if the configured DNS servers are responsive.
• System Status.
• View System Status Log. Displays the contents of the last run of the system status script.
• Run System Status. Runs the system status script on demand.
• Message of the Day. Because the sl1user login is inside a shell, the message of the day is not displayed after the sl1user authenticates. This menu option provides a way for the sl1user to view the message of the day.

To move back to the previous menu, use the Exit option. If you are at the top-level menu, the Exit option ends the sl1user session.