Authentication
Last modified on May 30, 2023
Overview
StrongDM supports three authentication models:
Additionally, you can find more information about authentication via SSO on the SSO Settings page and see a list of identity provider integrations if you wish to learn more about how to configure SSO authentication with StrongDM.
Delegated Authentication
The most common method of authenticating to StrongDM is via delegated authentication.
Authentication is commonly delegated to a directory (such as Microsoft Active Directory) or single sign-on provider (such as Okta or Google).
It is not necessary to delegate authentication but can be convenient to link existing tools with StrongDM.
Native Accounts
Native accounts are necessary for StrongDM administrative users.
Native accounts are also utilized in cases where a directory or single sign-on provider is not available.
Hybrid
The Hybrid authentication model employs a Directory or SSO provider, but also allows the StrongDM administrator to create accounts that are not SSO-linked. This can be useful in organizations where contractors or other non-SSO users require access to StrongDM.
Multi-factor Authentication
StrongDM supports multi-factor authentication (MFA) during a variety of authentication actions on the platform. Currently, StrongDM supports two options for MFA:
When you set up an SSO provider to authenticate with StrongDM and also enable MFA in the Admin UI, MFA prompts during logins do not occur. In this scenario, your configured MFA only plays a role to re-authenticate users when the desktop app locks due to inactivity, not during normal login attempts.
If using SSO, we recommend setting up MFA through your SSO provider to also trigger MFA prompts during user logins.
Please see the guides for setup and usage of individual MFA providers (Duo, Time-based One-time Passwords) for further information.
Passwords
Password requirements are set in the Admin UI in Settings > Security. You can force the passwords of your StrongDM users to be of higher strength. By default, the only password requirement is that the password be eight characters long.
Password strength requirements can be increased from “No minimum strength” to “Medium,” “Strong,” or “Excellent.” If you require higher password strength, users need to add complexity to their passwords until they grade at the higher rating you have set as the requirement.
The strength of a password can be difficult to determine. In this case, StrongDM uses the zxcvbn password strength method to test your password strength. This method discards arbitrary rules about characters and length. Instead, this method analyzes each suggested password and gives it a strength rating based on a number of factors, including length, dictionary checking, password matching, and so forth.
Independently of the password strength requirement, you can also set a minimum length requirement for your users’ passwords. You should not set this minimum length to be lower than the default minimum for the password strength requirement that you have set.
Timeouts
There are two types of authentication timeouts for StrongDM users: idle timeouts, which have to do with the idle time of an authenticated user; and session timeouts, which pertain to overall length of authenticated sessions. Note that these limitations are applied for human users, not service accounts.
Idle Timeout
Idle timeouts force users to log out of the client or Admin UI after a set amount of minutes of inactivity (that is, instances where no packets are received). For example:
- The client logs out users after 20 minutes of idleness.
- Admin UI logs out users after 20 minutes of idleness.
Note that idle timeouts may be triggered by blocked processes and long-running queries.
Session Timeout
The session timeout forces users to log out once their session reaches the predetermined time limit. For example:
- Users must re-authenticate every eight hours.