Last modified on February 4, 2023
This article describes how to manage your organization’s users and service accounts from the Admin UI Users page.
A user is an entity that has the ability to log in to your StrongDM organization using the desktop app, the CLI, or the Admin UI. Users are managed by either StrongDM or an identity provider, such as Azure AD or Okta, if provisioning is configured for your organization. All users are displayed with their name and email address.
A service account is a slightly different type of entity that allows for programmatic access to StrongDM resources. See Service Accounts for more details. Service accounts are shown with their display name.
Users and service accounts may be displayed with one or more of the following labels and special indicators:
- A lock icon indicates that the user is locked out of StrongDM.
- An eye icon indicates a high-traffic user whose queries are not visible in the Admin UI logs but are available via the command line.
- A (non-SSO) label indicates that Single Sign-on (SSO) is configured for your organization, but the user was manually invited and logs in with a password. This also requires the Allow non-SSO users option to be selected for the organization.
- A Service Account label distinguishes service accounts from user accounts.
Invite a User
You can invite a user to join your StrongDM organization. All you need to know is their name and email address.
- In the Admin UI, go to Access > Users.
- Click Add user.
- Enter the email address, first name, and last name. To invite multiple users, click Add row.
- Click Send invitations to send an email with instructions on how to join StrongDM.
Add a Service Account
Service accounts provide programmatic access to resources via StrongDM. Unlike a user account, a service account requires only a display name—not a full name and email address—because service accounts are for machines, programs, and applications that authenticate with admin tokens to access automated processes or any automated function that needs resource access.
They are used for automation or for allowing programs and applications to use StrongDM, when there is no live human to authenticate. For example, a service account is ideal for the following:
- Continuous-integration pipelines
- Periodic extract-transform-load (ETL) jobs
- Business intelligence (BI) tools
- Jupyter Notebooks and similar self-contained analysis environments
- Containerized environments (often in conjunction with the StrongDM client container) that need access to StrongDM-protected resources
To create service accounts, make sure you have admin access to the Admin UI. Then follow these steps:
- In the Admin UI, select Users from the left-hand navigation.
- Click the Add service button.
- Enter a name for the service account. Notice that a first/last name and email address are not needed because service accounts are for programs/machines, not people.
- Click Create service account.
- Copy the generated service account token and keep it somewhere safe, as you won’t be able to see it again.
Grant access to resources
StrongDM uses role-based privileges to control access to resources. Like User accounts, service accounts gain access to resources through role membership, via the static and dynamic access rules that have been defined for that role. For information on how to assign a role to an account, see Roles.
After creating a service account, generating a service account token, and granting the account access to resources via role membership, you need to authenticate the account in your environment in order to use it.
You can set up service accounts to connect clients to resources either automatically or manually.
For fully automated service account configurations, enable auto-connect to ensure that your clients are connected by default. Auto-connect is dependent on Port Overrides being enabled. You can configure service accounts to auto-connect to resources in the Admin UI under Settings > Security.
Set Remote Identities
Remote Identities allow users to authenticate to SSH or Kubernetes resources using the identity of the StrongDM user connecting to it rather than our standard leased credential method. Each user is allowed to have one Remote Identity.
Use the following steps to set a Remote Identity:
- Go to the Settings tab of the user or service account.
- In the Remote Identity field, enter any string that is not already in use.
The Remote Identity is the name to be used to authenticate to SSH CA and Kubernetes resources that are configured to use Remote Identities. Each Remote Identity must be unique and the identity must already exist and be configured on the resource in order for a connection to be made.
Suspend a User
You can revoke a user’s access to infrastructure by suspending their account. In the Admin UI, there are two ways to suspend a user: use the quick Actions button on the Users page, or update the user’s settings.
To suspend a user from the Users page, follow these steps:
- On the Users page, click the Actions button beside the user’s name. This button lets you take quick action on a user without having to go into the user’s details.
- Select Suspend user and then click Confirm suspension.
To suspend a user from the user’s Settings tab, follow these steps:
- On the Users page, click the name of the user.
- Go to the Settings tab and click Suspend user.
- Click Confirm suspension.
Assign Permission Level
Permission level determines what administrative actions are available to the user, including the ability to add resources to the organization, edit those resources, or manage other users. There are four permission levels:
- Account Administrator: A user who has full administrative access to the entire organization. Only Account Administrators can create roles and grant access to datasources and servers.
- Database Administrator: A user who can configure and manage resources (such as datasources, servers, clusters, clouds, and websites).
- Team Lead: A user who can manage users within a particular role. This permission level is designed for managers who are in charge of a team but don’t necessarily control the infrastructure they use. Team Leads can invite new users exclusively to the role they manage, and those users inherit the same access as the Team Lead.
- User: The default for any person invited to the account. Users can query and access the resources to which they have been granted access.
There are several ways to assign permission level in the Admin UI:
- Click the Actions button beside the user’s name and select Set permission level.
- Click into the user’s name to view their details, and set the desired permission level on the Settings tab.
- Use bulk operations to set permission level for multiple users. Select the checkbox beside each user’s name, and click the Set permission level button in the dialog.
Roles determine what resources a user can access. Each user may be added to one or more roles, up to a maximum of 20.
On the Users page, the Roles column displays the name of any role(s) that have been assigned to the user. If no roles have been assigned to the user, the column shows no roles.
There are several ways to assign roles to users in the Admin UI:
- Click the Actions button beside the user’s name, and select Set roles.
- Click into the user’s name and set the desired role(s) on the Roles tab.
- If assigning the same role(s) to multiple users, select the checkbox for each user and click the Set Roles button in the dialog. Select the role(s) you want to assign and click Apply roles.
Remove Users From Roles
You can remove users from roles by following these steps:
- Select the checkbox beside each user’s name.
- Click the Remove from all roles button in the dialog.
- Click Confirm remove.
Note that if provisioning is enabled for your organization, and users and roles are managed by an IdP such as Okta or Azure AD, you cannot remove IdP-managed users from IdP-managed roles from within the Admin UI. The Admin UI does not show IdP-managed roles.
You must remove users from such roles from the IdP’s portal. You can, however, remove IdP-managed users from StrongDM-managed roles.
Grant Temporary Access
Temporary access allows users to gain access to certain resources for a limited amount of time. For example, if Bob needs 30 minutes of read-only access to the production Redis replica to diagnose a customer issue, Alice can grant temporary access to Bob, which automatically closes any active connections the moment the grant expires.
Temporary access grants occur at the user level rather than role level and are the only way to grant access directly to users.
You can grant temporary access to a user in one of the following ways:
- Click the Actions button beside the user’s name and select Grant temporary access.
- Click into the user’s name and use the dialog on the Temporary Access tab to select which resources the user can access and when access expires.
Use the Actions Button
The Actions button for a user shows all the actions you can take on a selected user, without having to go into the user’s details:
- Edit details
- Set roles
- Remove from all roles
- Grant temporary access
- Set permission level
- Send password reset email
- Suspend user
- Delete user
View User Insights
The Users page displays insight cards to users who have the Account Administrator permission level. Insight cards provide valuable metrics that quickly tell admins how many active, inactive, and billable users are in the StrongDM organization, as well as the date and time when the report was last generated. Metrics are refreshed every 24 hours.
Active users are users who have triggered any event in StrongDM in the last 90 days. The Active Users insight card displays the number of active users in your organization, along with the date and time when the active users report was generated. To filter the Users page to show active users, click on the Active Users insight card, or enter the
active:true filter in the Search field.
Inactive users are users who have not triggered any event in StrongDM in the last 90 days. The Inactive Users insight card displays the number of inactive users in your organization, along with the date and time when the inactive users report was generated. To filter the Users page to show inactive users, click on the Inactive Users insight card, or enter the
active:false filter in the Search field.
Billable users are users in your organization who are not currently suspended. The Billable Users insight card shows the number of billable users and the date and time when the billable users report was generated.
Search for Users
The Search field allows you to find users and service accounts in your organization according to name, email, role, permission level, status, provisioning type, and tags. You can either type into the Search field or use the Role and Permission Level filter drop-down menus to narrow your search. The table header displays the number of results returned by the active search and filter query.
You can enter any text or string into the Search field, such as name, email address, or parts of a name or email. The Admin UI checks against all first names, last names, and emails in your organization.
User search filters
User filters display users according to their status (active or suspended), access (locked out or not), provisioning type (managed by StrongDM or by an identity provider), or tag.
You can type or copy/paste the following filters into the Search field, with or without other text. Do not use quotes or tick marks.
|Shows inactive users (users who have not triggered any event in StrongDM in the last 90 days)|
|Shows active users (users who have triggered any event in StrongDM in the last 90 days)|
|Shows users who are not locked out|
|Shows all locked out users|
|Shows users managed and provisioned by StrongDM|
|Shows users managed and provisioned by a third-party identity provider (for example, Azure AD or Okta)|
|Shows all non-suspended users|
|Shows all suspended users|
|Shows users with the specified tag; supports wildcards (|
By default, the Users page filters out suspended users. The
suspended:false filter is applied automatically when you visit the Users page.
Role, Permission level, and Managed by filters
Additionally, you may narrow the search results by selecting a filter from the Role, Permission Level and Managed by drop-down menus located to the right of the Search field.
Select Role to automatically populate filters based on role assignment.
Select Permission level to automatically populate filters based on permission level.
If provisioning is enabled for your organization, select Managed by to automatically populate filters based on provisioning type (managed by either StrongDM or an identity provider).
Save your favorite search and filter queries
The parameters of your search and filter queries are reflected in the page URL, allowing you to bookmark your favorite searches and filters in your web browser.
For example, when filtering users based on the Account Administrator permission level, the URL becomes
Note that when filtering users by role, the URL includes the role ID parameter, rather than the role name (for example,
Create Admin Tokens
Admin tokens provide tokenized account access for automated StrongDM use. They can be utilized for administrative tasks, such as:
- Managing users
- Managing roles
- Managing resources
- Managing gateways and relays
- Managing access
- Managing Secret Stores
Admin tokens are generated in the Admin UI under Access > API & Admin Tokens. To create an admin token, follow these steps:
- Make sure you have admin access to the Admin UI.
- On Access > API & Admin Tokens, click Add token.
- On the Create Admin Token page, give your token a name.
- Specify when the token expires.
- Choose which rights this admin token grants and select the appropriate options for your admin token use case.
- Click Create. The token appears in a modal.
- Copy the token and keep it somewhere safe. The token only displays once.
There are two methods to authenticate the CLI with an admin token: with an environment variable or through the
sdm login command.
The CLI references the environment variable
SDM_ADMIN_TOKEN if it is set. You can set this in your shell by using
The CLI can use the token directly if the
--admin-token flag is used:
sdm login --admin-token='<TOKEN_VALUE>'
SDM_ADMIN_TOKENis set as an environment variable, there is no need to log in via the CLI or GUI. Any active client sessions break when you try to log in with the
--admin-tokenflag. Instead, you can just begin executing commands without needing to log in with credentials.
Once authenticated with an admin token, you can run any
sdm admin command granted to the token. No other commands (for example,
sdm status) work using an admin token, regardless of permission level.
You can run any of the following commands that you have granted to the token once you are authenticated with the token:
- User commands:
sdm admin users list
- Role commands:
sdm admin roles list
- Datasource commands:
sdm admin datasources list
- Server commands:
sdm admin servers list
- Relay commands:
sdm admin relays list. Note that the
relays listcommand requires the token to have been granted
datasources list; without it,
relays listdoes not work because it provides some information on the connected datasources for each relay.
Rotate Admin Tokens
Rotating an admin token generates a new secret while maintaining the name and permissions. We recommend doing so if you believe a token has been compromised, a user with access to the token has left your organization, or a user who owns the admin token is suspended.
To rotate a token, use these steps.
- Find the token on the API & Admin Tokens page.
- Click to Rotate. A tooltip alerts you that the existing secret is deactivated after 24 hours.
- Click Rotate to regenerate the token secret and expire the existing token after 24 hours.
Delete Admin Tokens
Once a token is rotated or deleted, the token immediately loses its ability to authenticate commands.
Admin Tokens Created by Suspended Users
What happens to admin tokens that are owned by a suspended user? Admin tokens and API keys are still usable even if the user who created them is suspended.
When suspending a user, the Admin UI lists the keys and tokens created by that user and asks if the tokens should be deleted. Select No to keep them.
After confirming suspension, you can see in section Access > API & Admin Tokens that the admin tokens and/or API keys continue to be owned by the suspended user and remain usable. For the admin tokens that are still needed, rotate the credentials to deactivate the existing token secret and generate a new one.
Because API keys are a public/private pair, new keys need to be created and the old keys need to be deleted when any automation systems use the new keys.
You can find resources and information about the following StrongDM topics in this section: