Authentication

Overview #

StrongDM supports three authentication models:

• Delegated authentication
• Native accounts
• Hybrid

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 the use of multi-factor authentication (MFA) challenges when a user authenticates with StrongDM or, through policies, when they access particular resources.

See the MFA section to learn how to use MFA to secure your StrongDM organization and to configure a supported MFA provider.

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.

PCI Authentication Requirements #

If you are subject to the requirements of PCI-DSS v4 and you are using StrongDM’s Native Accounts, please strongly consider using Multi-factor Authentication as a part of your access controls to the StrongDM Platform. In the event you choose not to use MFA with Native Accounts, the PCI Standards Council has mandated StrongDM advise you of the following points, per Requirement 8.3.10:

• You should require your users of the StrongDM Platform to periodically expire/change their passwords
• You should require users to change their passwords any time you or they suspect that password has been compromised, disclosed to an unauthorized party, or reused from another platform