Identities, Auth &
Access Control
This course covers how StrongDM identifies and authenticates every participant in its network — from human users to service accounts — and how advanced security layers like SSO, MFA, and credential management protect your infrastructure.
Identities in StrongDM
Understand the difference between Nodes and Users, how identities are created and managed, and how privileges follow users across clients.
Service Accounts
Learn how non-human identities are managed, why they're high-value targets, and how StrongDM controls their access securely.
Identity Providers
Integrate with external SSO systems like Okta, Google, and Azure AD to centralize authentication and streamline user management.
Multi-Factor Authentication
Explore how MFA adds a critical second layer of verification — for console logons and policy-based resource access.
Credentials & Aliases
Discover how credential leasing and identity aliases handle the "last-mile" authentication to resources without exposing secrets to users.
Module 1 — Identities & Users
How the StrongDM control plane recognizes and authenticates participants in the network.
Nodes
Gateways and Relays that proxy traffic to resources. Identified using tokens generated at creation time. The token must be copied and stored — it cannot be retrieved later.
Users
Human identities that need access to resources via the StrongDM client. Not tied to a specific machine. Privileges are portable — they follow the user to any client they log into.
| Attribute | Native StrongDM User | Provisioned User |
|---|---|---|
| Created By | StrongDM administrator directly | External identity system (IdP/SCIM) |
| Edited In | StrongDM Admin UI | Source system only — synced to SDM |
| Authentication | Password + optional IdP/MFA | Managed by external provider |
| Required Fields | Unique email, First name, Last name | Sourced from identity provider |
| Access Assignment | Via roles within StrongDM | Via roles within StrongDM (same) |
Email Address (Required — Must Be Unique)
Each user requires an email that is unique across the StrongDM tenant. This serves as the primary login identifier.
First & Last Name
StrongDM accepts duplicate names but unique names are strongly recommended for operational clarity, especially in audit logs.
Password Protection + Optional Security Layers
Native users are password-protected by default. You can layer on an Identity Provider (IdP) and/or Multi-Factor Authentication (MFA) for stronger security.
Module 1 Knowledge Check
QuizModule 2 — Service Accounts
Non-human identities that support automated processes — and why they require special handling.
Purpose
Service accounts support business-critical programs and processes that run persistently — websites, databases, automation pipelines.
Why They're Powerful
They carry high-level privileges, and their credentials must be known by multiple applications — making them uniquely powerful.
Why They're Dangerous
These unique qualities — always-on, high-privilege, widely-known credentials — make service accounts prime targets for attackers.
Admin Token — No Admin Permissions
When a service account is created in StrongDM, it generates an admin token. Critically, this token has no admin permissions by default. It is used purely for authenticating to the control plane.
Managed Like User Accounts
StrongDM manages service account access exactly like human user accounts — through role assignments that define what resources can be accessed.
Auto-Connect: No (Default)
Service accounts do not automatically connect to datasources. Access must be explicitly granted. This is the recommended configuration.
Auto-Connect: Yes
Enabling this allows service accounts to connect to datasources automatically. Only appropriate in specific, well-understood scenarios.
Module 2 Knowledge Check
QuizModule 3 — Integrating with Identity Providers
Connecting StrongDM to external SSO systems for centralized authentication.
When an Identity Provider is enabled, users go through an additional validation step after entering their standard credentials. The IdP confirms the user's identity through their existing corporate account, preventing unauthorized access even if passwords are compromised.
Settings → User Management
IdP integration is configured in the Admin UI under Settings > User Management. Select your provider, enter the Client ID and Client Secret, and save.
Applies to Users & Admins
IdP can be applied to both regular users and administrators, securing both the StrongDM client and the Admin UI.
SSO Exceptions for Admins
Exceptions can be made for specific users (marked as non-SSO) to prevent admin lockout during IdP outages.
Module 3 Knowledge Check
QuizModule 4 — Multi-Factor Authentication
Adding a second verification layer to protect console access and resource policies.
MFA for Console Access
Protects logons to the StrongDM Admin UI and the StrongDM client. Applied at the login step. Requires a registered MFA device. If SSO is enabled, this is overridden — MFA only applies via policies.
MFA for Policies
Applied at the resource access step. Configured in the policy "With" statement. Available even when SSO is enabled. Allows fine-grained MFA triggers based on context.
Duo
3rd-party MFA platform. Requires a Duo environment to be provisioned before integration. Sends push notifications to enrolled devices.
Okta
3rd-party MFA platform requiring a full Okta environment. Integrates with Okta Verify and other Okta authenticator flows.
TOTP (Built-in)
Time-based One-Time Password — StrongDM's native MFA option. No external environment needed. Works with Google Authenticator, Authy, or any TOTP-compatible app.
Duo / Okta / TOTP
Module 4 Knowledge Check
QuizModule 5 — Leased Credentials & Identity Aliases
How StrongDM handles authentication to resources — the "last mile" — without exposing secrets.
When a user connects to a resource through StrongDM, the Gateway or Relay must authenticate to that resource. But how do you do that without exposing credentials to the user? StrongDM solves this with two approaches: Credential Leasing and Identity Aliases.
How It Works
The Gateway/Relay uses the credentials that were stored when setting up the resource in StrongDM. All connections use this shared identity.
Secret Store
Credentials used in leasing are retrieved from a secret store (e.g., Strong Vault). The node fetches them at connection time — users never see them.
Audit Log Implication
Resource logs reflect the shared service account identity, not the individual user's StrongDM identity. StrongDM's own logs capture the actual user.
User's Own Credentials
Identity Aliases allow each user to authenticate to a resource using their own credentials. Actions on the resource are attributed to the individual alias — improving auditability.
Identity Sets
Resources configured for Identity Aliases reference an Identity Set — a named group. Each user's alias must belong to the Identity Set that the resource is configured to use.
| Attribute | Credential Leasing | Identity Aliases |
|---|---|---|
| Credentials Used | Shared resource credential | Each user's own credentials |
| Stored In | Secret store (e.g., Strong Vault) | Database / directory service |
| Resource Log Shows | Shared account name | Individual user's alias |
| Secret Store Required | Yes | No |
| Auditability | Per-session in SDM logs | Per-user in resource logs |
Module 5 Knowledge Check
QuizCourse Complete!
You've finished StrongDM 201 — Authentication. You now understand how StrongDM identifies every participant in its network and layers security across users, service accounts, IdPs, MFA, and credential management.