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
- Open Administration > Users.
- Click Create.
- Under Name and Password, enter the Name (username), Password, and confirm it in Password Validation.
- 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.
- Choose how to grant permissions:
- Under Basic Permissions, pick a Role (
Read,ReadWrite, orAdmin), or - Under Advanced Permissions, assign one or more existing Permission Policies.
- Under Basic Permissions, pick a Role (
- 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
- Open Administration > Users.
- 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).
- 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.
- Choose how to grant permissions, same as a local user — a Role under Basic Permissions, or one or more Permission Policies under Advanced Permissions.
- Confirm to link the user.
Using the CLI
users ldap link <name> --role=<permissions>|--permissionPolicies=<name...> --email=<email> [--enabledMultiFactorAuthentication] [--force]
| 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
users ldap link jsmith@corp.example.com --role ReadWrite --email jsmith@corp.example.com
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
- Open Administration > Users.
- Select the user and click Edit.
- Under User Selection, confirm the user (Name).
- To change the password (local users only), fill in Change Password: Old Password (only required when editing your own account), Password, and Password Validation.
- Update Email and MFA and/or the user's permissions under Basic Permissions / Advanced Permissions as needed.
- 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
- Open Administration > Users.
- Select the user and click Delete.
- 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.