Managing users from the command line

The prostore user command creates, changes and deletes Tengri users directly in the metadata catalog, without connecting to a running server. Use it when signing in is impossible or inconvenient: during initial setup, after losing administrator access, or for bulk changes from scripts.

Otherwise, users are easier to manage through SQL (CREATE USER, ALTER USER, DROP USER) or the settings section of the web interface.

The command line works with the catalog as the administrator and checks no privileges. Anyone who can run it with access to the catalog can create an administrator or change the administrator’s password. Restrict access to the Tengri servers and to the catalog database.

Connecting to the catalog

Every command needs the metadata catalog connection string. Pass it with --catalog-uri or set the TNGRI_CATALOG_URI environment variable (TENGRI_CATALOG_URI is accepted too):

export TNGRI_CATALOG_URI=postgresql://prostore:prostore@<CATALOG_IP>:5432/prostore
prostore user list

It is the same string the server starts with, see Configuring settings via environment variables.

Commands

Command Purpose

list

List users.

create

Create a user.

edit

Change a user: name, password, worker pool, sign-in methods, sign-in blocking.

delete

Delete a user permanently.

mint-recovery

Issue an access recovery token.

Listing users

prostore user list

Prints the name, creation date and default pool of each user, including the built-in service users (see Built-in users). AI agents are left out.

Creating a user

Option Description

--username

User name. Required.

--password

Password for password sign-in.

--pool

Default worker pool.

--sso-idp

SSO provider the user signs in through.

--sso-subject-id

The user’s identifier at the SSO provider (NameID). SSO sign-in does not work without it.

A user with a password:

prostore user create --username alice --password '<password>' --pool default

A user who signs in only through SSO:

prostore user create --username bob \
  --sso-idp corp-saml \
  --sso-subject-id bob@example.com

A new user gets the same standard privileges as a user created through SQL.

With neither a password nor SSO, the user is created but cannot sign in — the command warns about it. Add a sign-in method later with edit.

The complexity rules of the password policy (see Password policy and access protection) do not apply to passwords set from the command line. In addition, a password set at creation is not added to the password history and does not start the expiry clock — only a change through edit or SQL does.

Changing a user

edit changes only the options you pass and leaves everything else as it was.

Option Description

--username

The user to change. Required.

--rename

New user name. Privileges are not carried over, see the warning below.

--password

New password. Turns on password sign-in and lifts the account lock.

--pool

New default pool. An empty string '' clears it.

--active / --inactive

Allow or forbid signing in to the account.

--enable-password / --disable-password

Turn password sign-in on or off without changing the password. Turning it on requires a password to be set already.

--enable-sso / --disable-sso

Turn SSO sign-in on or off.

--sso-idp

Assign or change the SSO provider.

--sso-subject-id

Assign or change the user’s identifier at the SSO provider.

--ldap-idp, --ldap-principal

Link the user to an LDAP account. Pass both together.

--enable-ldap / --disable-ldap

Turn LDAP sign-in on or off. While it is on, password sign-in is off.

--unlink-ldap

Remove the LDAP link and restore password sign-in.

The LDAP options need the master key in the TNGRI_MASTER_KEY environment variable. Linking an account and turning on LDAP sign-in is described in linking from the command line.

Common tasks

Reset the password and unlock the account after a run of failed sign-ins:

prostore user edit --username alice --password '<new password>'

Forbid signing in without deleting the user:

prostore user edit --username alice --inactive

Move a user from a password to SSO:

prostore user edit --username alice \
  --sso-idp corp-saml --sso-subject-id alice@example.com \
  --enable-sso --disable-password

Renaming from the command line does not carry over the user’s roles and privileges: they stay attached to the old name. The renamed user loses their privileges, and a new user later created with the old name receives them. Rename users with the SQL command ALTER USER <name> RENAME TO <new name>, which carries privileges over.

A password change lifts both the lock after failed sign-ins and the sign-in ban set with --inactive. To change a blocked user’s password and keep them blocked, pass both options in one command:

prostore user edit --username alice --password '<new password>' --inactive

Deleting a user

prostore user delete --username alice

Deletion is permanent: the user’s API tokens, secrets, password history and granted privileges go with them. The command asks for confirmation; --yes skips it, for example in scripts.

To disable a user only for a while, use edit --inactive.

Issuing a recovery token

prostore user mint-recovery --username admin

The command prints the token once; store it outside Tengri. When and how to use it is described in the recovery checklists.

Built-in users

On every start the server checks that the built-in users exist: the administrator admin and the subsystem service users — compaction, webapp, mcp, monkey, seed. Missing ones are created again.

Do not rename or delete built-in users.

  • After the next restart, a renamed or deleted admin is replaced by a new admin with the default password.

  • System administrator rights are tied to the name admin: a renamed account loses them.

  • Service users are created again, and their subsystems keep running under the new accounts.

To protect the admin account, change its password and issue a recovery token for it.