Skip to main content

Users & Permissions

Users & Permissions

StorONE user accounts control who can log in to the system —— through the web interface, the CLI, or the REST API —— and what they're allowed to do once they're in. Every account is either a local user (username and password stored in S1 itself) or an LDAP user (authenticated against your existing LDAP/Active Directory server, but still explicitly linked into S1 before it can log in).

What an account can do is controlled separately, using one of two systems:

  • A basic permission role —— one of three built-in presets (Read, ReadWrite, Admin) that's enough for most accounts.
  • One or more permission policies —— custom, fine-grained rules you build yourself when a basic role is too coarse. See that page for details.

A user has exactly one or the other: a basic role, or a set of permission policies.

Creating a local user

Using the web interface

  1. Open Administration > Users.
  2. Click Create.
  3. Under Name and Password, enter the Name (username), Password, and confirm it in Password Validation.
  4. Under Email and MFA, enter the user's Email and leave Enabled Multi Factor Authentication on (it's on by default) unless you have a specific reason to turn it off.
  5. Choose how to grant permissions:
    • Under Basic Permissions, pick a Role (Read, ReadWrite, or Admin), or
    • Under Advanced Permissions, assign one or more existing Permission Policies.
  6. Confirm to create the user.

Using the CLI

users create <name> --password=<password> --passwordValidation=<password> --role=<permissions>|--permissionPolicies=<name...> --email=<email> [--enabledMultiFactorAuthentication] [--force]
Option Description
<name> The username for the new user.
--password=<password> The password for the new user.
--passwordValidation=<password> Re-enter the password to confirm (avoids typos).
--role=<permissions> The user's basic permission role: Read, ReadWrite, or Admin.
--permissionPolicies=<name...> Assign advanced permission policies to the user, instead of a basic role.
--email=<email> The user's email address.
--enabledMultiFactorAuthentication Enable multi-factor authentication.
--force Skip the confirmation prompt if the selected permission policies conflict with existing command rules.

Examples

Create an administrator with a basic role:

users create jsmith --password "Str0ngPass!" --passwordValidation "Str0ngPass!" --role Admin --email jsmith@example.com

Create a read-only user for a reporting integration, using an advanced permission policy instead of a basic role:

users create reporting-svc --password "Str0ngPass!" --passwordValidation "Str0ngPass!" --permissionPolicies read-only-monitoring --email reporting@example.com

Working with LDAP users

Rather than creating local accounts one by one, you can let users log in with their existing LDAP/Active Directory credentials. StorONE doesn't import your whole directory automatically —— you authenticate to the LDAP server, look up the specific account you want, and explicitly link it. Linking an LDAP user is otherwise just like creating a local user, except there's no password to set (LDAP owns that).

The LDAP authentication step starts a temporary session for the current CLI/API session only —— it isn't saved, so you'll need to authenticate again in a new session before looking up or linking further LDAP users.

Authenticating to LDAP

Using the CLI

users ldap authenticate --user_principal_name=<name> --password=<password_general>
Option Description
--user_principal_name=<name> LDAP UPN (user principal name).
--password=<password_general> LDAP password.

Example

users ldap authenticate --user_principal_name admin@corp.example.com --password "correct-horse-battery-staple"

Looking up LDAP users

Once authenticated, you can search your directory for the account you want to link.

Using the CLI

users ldap list [--filter=<name>]
Option Description
--filter=<name> Show only LDAP users whose account names match this partial account name.

Example

users ldap list --filter jsmith

Linking an LDAP user

Using the web interface

  1. Open Administration > Users.
  2. Authenticate to your LDAP server and locate the account you want to link (the web interface prompts for this the first time you add an LDAP user in a session).
  3. Under Email and MFA, enter the user's Email and leave Enabled Multi Factor Authentication on unless you have a specific reason to turn it off.
  4. Choose how to grant permissions, same as a local user —— a Role under Basic Permissions, or one or more Permission Policies under Advanced Permissions.
  5. Confirm to link the user.

Using the CLI

Option Description
<name> The LDAP username to link.
--role=<permissions> The user's basic permission role.
--permissionPolicies=<name...> Assign advanced permission policies to the user.
--email=<email> The user's email address.
--enabledMultiFactorAuthentication Enable multi-factor authentication.
--force Skip the confirmation prompt if the selected permission policies conflict with existing command rules.

Example

Editing a user

You can change a user's password, email, MFA setting, and permission assignment. If the account is LDAP-linked, the password fields aren't available —— the password lives in your LDAP directory, not in S1.

Changing your own password requires re-entering your current password in --oldPassword first; changing another user's password doesn't.

Using the web interface

  1. Open Administration > Users.
  2. Select the user and click Edit.
  3. Under User Selection, confirm the user (Name).
  4. To change the password (local users only), fill in Change Password: Old Password (only required when editing your own account), Password, and Password Validation.
  5. Update Email and MFA and/or the user's permissions under Basic Permissions / Advanced Permissions as needed.
  6. Confirm the change.

Using the CLI

users edit <name> [--role=<permissions>|--permissionPolicies=<name...>] [(--oldPassword=<password_general> --password=<password> --passwordValidation=<password>)] [--email=<email>] [--disabledMultiFactorAuthentication|--enabledMultiFactorAuthentication] [--force]
Option Description
<name> The user to modify.
--role=<permissions> The user's new basic permission role.
--permissionPolicies=<name...> Assign advanced permission policies to the user.
--oldPassword=<password_general> Your current password, required only when changing your own password.
--password=<password> The new password.
--passwordValidation=<password> Provide the new password again for validation (to avoid typos).
--email=<email> The user's new email address.
--disabledMultiFactorAuthentication Disable multi-factor authentication.
--enabledMultiFactorAuthentication Enable multi-factor authentication.
--force Skip the confirmation prompt if the selected permission policies conflict with existing command rules.

Examples

Promote a user from Read to ReadWrite:

users edit jsmith --role ReadWrite

Change your own password:

users edit myusername --oldPassword "old-pass" --password "new-pass" --passwordValidation "new-pass"

Listing users

Using the web interface

Open Administration > Users. The list shows both local and LDAP-linked accounts.

Using the CLI

users list [--permissionPolicies=<name...>]
Option Description
--permissionPolicies=<name...> Filter by assigned permission policies.

Example

users list --permissionPolicies read-only-monitoring

Deleting a user

You can't delete the account you're currently logged in as.

Using the web interface

  1. Open Administration > Users.
  2. Select the user and click Delete.
  3. Confirm the deletion.

Using the CLI

users delete <name> [--force]
Option Description
<name> The username to delete.
--force Skip the confirmation prompt.

Example

users delete jsmith --force

Next: Permission Policies —— building custom, fine-grained permission sets.