> For the complete documentation index, see [llms.txt](https://docs.strongdm.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.strongdm.com/admin/principals/authentication.md). # Authentication ### Overview StrongDM supports three authentication models: * [Delegated authentication](#delegated-authentication) * [Native accounts](#native-accounts) * [Hybrid](#hybrid) Additionally, you can find more information about authentication via SSO and see a list of identity provider integrations on the [SSO Settings](/admin/principals/sso.md) page and a similar set of information about user provisioning on the [Provisioning](/admin/principals/provisioning.md) page. #### 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](/admin/access/policies.md), when they access particular resources. See the [MFA section](/admin/principals/mfa.md) 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](https://github.com/dropbox/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. {% hint style="info" %} In most cases, if a password fails to meet the account's password requirements, adding length or complexity of characters can increase the password strength. {% endhint %} 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. ### Enforce Single Sessions The **Enforce Single Sessions?** setting lets you control whether or not users can have multiple active sessions of StrongDM open at the same time, where a session is a login to the Admin UI, CLI, or desktop app from any device. This setting may be enabled or disabled from the Admin UI in **Settings** > **Security**. The **Enforce Single Sessions?** setting is disabled by default. When enabled (set to **Yes**), this setting disallows users from having multiple sessions in the Admin UI, desktop app, and/or CLI simultaneously. For example, when single sessions are enforced, if Bob is logged into the Admin UI on his personal computer at home and then logs into the Admin UI on his work laptop, his home session is logged out. As another example, when single sessions are enforced, if Bob logs in to the Admin UI in Chrome and then logs in to the Admin UI from Safari, he is logged out of his session in Chrome. Single session enforcement applies only to logins for the same software type (that is, Admin UI, CLI, or desktop app). For example, if Alice is logged into the Admin UI from her computer at home, she can still log into the desktop app on her work laptop without being logged out of the Admin UI at home. ### Timeouts There are two types of authentication timeouts for StrongDM users: session timeouts, which pertain to the overall length of an authenticated session; and idle timeouts, which limit how long an authenticated user can remain inactive before being logged out. Both settings can be configured independently for Admin UI users and for desktop app/CLI users. Note that these limitations are applied to human users, not service accounts. Session and idle timeouts are configured in the Admin UI in **Settings** > **Security**. {% hint style="info" %} If you are upgrading from an earlier version, note that prior to this release, session and idle timeouts applied a single value across the Admin UI, desktop app, and CLI. Upon upgrade, existing organizations retain their prior configured value(s) for both the Admin UI and desktop/CLI settings until they are changed. {% endhint %} #### Session Timeout The session timeout forces users to re-authenticate once their session reaches the configured time limit (in minutes, days, or hours). Session timeout is set separately for the Admin UI and for the desktop app/CLI. When session timeout is set: * Admin UI users must re-authenticate when their session limit is reached. * Desktop app and CLI users must re-authenticate when their session limit is reached. For example, your organization could require Admin UI users to re-authenticate every 8 hours while allowing desktop/CLI users to remain authenticated for up to 24 hours before re-authenticating. #### Idle Timeout Idle timeout logs users out of the Admin UI or the client (desktop app/CLI) after a set period of inactivity (that is, no packets are received) in minutes, days, or hours. Idle timeout is set separately for the Admin UI and for the desktop app/CLI. When idle timeout is set: * Admin UI users will be logged out after the specified amount of time of inactivity (for example, after 20 minutes of inactivity). * Desktop app and CLI users will be logged out after the specified amount of time of inactivity (for example, after 590 days of inactivity). Note that idle timeouts may be triggered by blocked processes and long-running queries. ### 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 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.strongdm.com/admin/principals/authentication.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.