1
Concepts
2
Network
3
Resources
4
Users
5
Access
6
Audit
7
Client
8
Advanced

1. Understand the Platform

What Is StrongDM?

StrongDM is a Zero Trust PAM platform that manages access to databases, servers, Kubernetes clusters, clouds, and web applications. It combines authentication, authorization, networking, and observability into a single platform. Unlike traditional PAM tools focused on password vaulting, StrongDM is a protocol-aware proxy that sits in the network path, enabling full query logging, session recording, and runtime credential injection without the user ever touching a password.

Architecture

C
Client
Desktop app + sdm CLI on user workstations. Creates a TLS 1.2 encrypted connection to gateways. Config updates in real time from the control plane.
N
Nodes
Gateways & Relays (traditional) or Proxy Clusters. Both are fully supported. The last node before a resource decrypts credentials and deconstructs requests for auditing. Users never see credentials.
R
Resources
Databases, SSH/RDP servers, K8s clusters, cloud accounts, web apps. From the resource's perspective, all traffic comes from the StrongDM node.
Credential Leasing

StrongDM uses a "dual key" system. Neither the user's client nor the proxy node alone can decrypt credentials -- both a valid proxy instance AND a valid user session are required. Credentials are injected at the "last mile" between proxy and target. Even a compromised admin account can't extract plaintext credentials.

Further Reading
TopicLink
What Is StrongDM?docs.strongdm.com/concepts/what-is-strongdm
How StrongDM Worksdocs.strongdm.com/concepts/how-strongdm-works
Securitydocs.strongdm.com/concepts/security

2. Deploy Your Network

You need at least one node before users can connect to anything.

Gateways & Relays Traditional

Gateways are public-facing entry points (need reachable IP/DNS). Relays extend into private subnets via egress-only connections. Max ~20 gateways, unlimited relays. Don't put behind a load balancer.

Proxy Clusters

Sit behind YOUR load balancer. One or more proxy workers per cluster. Bridged clusters for private subnets. Better scaling for large deployments. Min 2 workers for HA.

Quick Start: Gateway on Linux

  1. Create in Admin UI
    Networking > Gateways > Add gateway. Enter name, advertised host (public IP/DNS), port (default 5000). Click Create.
  2. Copy the token
    Shown once only. Save it securely.
  3. Install on server
    gateway-install.sh
    curl -J -O -L https://app.strongdm.com/releases/cli/linux
    unzip sdmcli_*_linux_amd64.zip
    sudo ./sdm install --node

    For UK: add --app-domain app.uk.strongdm.com. For EU: --app-domain app.eu.strongdm.com. Paste token when prompted (won't echo).

  4. Verify
    Back in Admin UI, gateway should show online with a heartbeat. If not, hard refresh. Check daemon: ps aux | grep sdm.
Notes

Disable SELinux during install. Installer must run as user in /etc/passwd. Server needs: 2 CPUs, 4 GB RAM, any Linux distro. Relays are identical except no advertised host/port (egress-only).

Further Reading
TopicLink
Networking Overviewdocs.strongdm.com/admin/networking
Proxy Clustersdocs.strongdm.com/.../proxy-clusters
Gateways & Relaysdocs.strongdm.com/.../gateways-and-relays
Linux / EC2 / GCP / K8s / DockerSee sub-pages
Ports Guidedocs.strongdm.com/.../ports-guide

3. Add Resources

With a node online, onboard the infrastructure users need. Go to Resources > Managed Resources > Add Resource, select a type, fill in connection details, and verify the healthcheck goes green.

Before adding

Verify the target is reachable from your node: SSH into the node and run nc -zv <HOSTNAME> <PORT>

Detailed Setup by Resource Type

SSH Server Types

StrongDM supports four SSH resource types. Choose based on how you want to handle key management:

TypeAuth MethodBest For
SSH (Public Key)StrongDM generates a key pair. You install the public key on the host.Simplest setup. StrongDM manages the private key lifecycle.
SSH (Certificate)StrongDM CA issues ephemeral certificates. Host trusts the CA.Best security. No keys to manage per-host. Supports Identity Aliases.
SSH (Customer Key)You provide your own private key.When you must use existing keys. Supports per-user keys via secret store + $SDM_USERNAME.
SSH (Password)Username + password.Legacy systems. Only NTLM auth.

Adding an SSH (Public Key) Server

  1. Add the resource
    Resources > Managed Resources > Add Resource. Select SSH (Public Key). Enter display name, hostname, port (default 22), and username the node should use to connect.
  2. Install the public key
    After creation, StrongDM generates a key pair. Copy the public key from the resource settings and append it to ~/.ssh/authorized_keys on the target host for the configured user.
  3. Verify healthcheck
    Resource should go green. If not, check Diagnostics tab. Common issues: wrong username, public key not installed, firewall blocking port 22 from the node.

Adding an SSH (Certificate) Server

  1. Get the CA public key
    Go to Settings > Secrets Management > Certificate Authorities. Select the SSH CA and copy its public key.
  2. Configure the target host to trust the CA
    On the SSH server, add the CA public key to /etc/ssh/ and add TrustedUserCAKeys /etc/ssh/sdm_ca.pub to sshd_config. Restart sshd.
  3. Add the resource in StrongDM
    Select SSH (Certificate Based). Set hostname, port, and choose Leased Credentials (with a username) or Identity Aliases (with an Identity Set + healthcheck username). The CA defaults to Strong CA.
Key Type Options

Available signing algorithms: RSA-2048 (default), RSA-4096, ECDSA-256, ECDSA-384, ECDSA-521, ED25519. ED25519 offers the best performance with small keys but less broad support.

cli-examples.sh
# Add SSH (Public Key) via CLI
sdm admin servers add ssh prod-web-01 --hostname 10.0.1.50 --port 22 --username ubuntu

# Add SSH (Certificate) via CLI
sdm admin servers add ssh-cert prod-app-01 --hostname 10.0.1.51 --port 22 --username ubuntu

# Add SSH (Password) via CLI
sdm admin servers add sshPassword legacy-box --hostname 10.0.1.99 --port 22 --username admin --password 'P@ssw0rd'

# List all servers
sdm admin servers list

RDP Server Types

TypeAuth MethodBest For
RDP (Password)Username + password (NTLM only)Simple setup. Note: only NTLM auth, not Kerberos. "Protected Users" group blocks NTLM.
RDP (Certificate)StrongDM CA or third-party CA issues certificatesProduction. Supports Identity Aliases, on-prem AD and Entra ID. Supports NLA (on-prem only).

Adding an RDP (Password) Server

  1. Add the resource
    Resources > Managed Resources > Add Resource > RDP (Password). Enter name, hostname/IP, port (default 3389), username (DOMAIN\user or user@domain format for AD), and password.
  2. Verify
    Healthcheck confirms network reachability (not credential validity). Connect from the StrongDM desktop app using your RDP client to fully verify.
RDP (Password) Limitations

Only the standard Microsoft Remote Desktop client (MSTSC) is fully supported. Windows 11 24H2 clients need build 26100.3323+. The healthcheck only confirms the host is reachable, NOT that credentials are correct.

Adding an RDP (Certificate) Server

  1. Configure the CA
    Every org gets a Strong CA for RDP automatically. For Enterprise: you can use third-party CAs (AD CS, AWS Private CA, Keyfactor EJBCA, etc.). The CA's public certificate must be trusted by Active Directory.
  2. Add the resource
    Select RDP (Certificate Based). Choose Leased Credentials or Identity Aliases. For leased: enter AD username (DOMAIN\user), password, and optionally SID (required for Full Enforcement mode). For Identity Aliases: select Identity Set and enter AD service account for healthchecks.
  3. If using NLA (on-prem AD only)
    Enter Domain Controller Hostnames (comma-separated) and Server FQDN. Nodes must have outbound access to Kerberos port 88 on domain controllers. NLA is NOT supported for Entra ID environments.
cli-rdp.sh
# Add RDP (Password) via CLI
sdm admin servers add rdp win-server-01 --hostname 10.0.2.10 --port 3389 --username 'CORP\admin' --password 'P@ssw0rd'

# Add RDP (Certificate) via CLI
sdm admin servers add rdp-cert win-server-02 --hostname 10.0.2.11 --port 3389 --username 'CORP\svc-sdm' --password 'P@ssw0rd'

Adding Databases

The pattern is the same for all database types: Resources > Managed Resources > Add Resource, select the type, fill in hostname, port, credentials, and optionally select a proxy cluster and secret store.

Common Database Properties

NameDisplay name. No quotes or angle brackets. HostnameEndpoint reachable from your node (e.g., mydb.cluster-xyz.us-east-1.rds.amazonaws.com) PortNative port (Postgres: 5432, MySQL: 3306, MSSQL: 1433, MongoDB: 27017, Redis: 6379) Username / PasswordCredentials for the connection. Can come from StrongDM or a third-party secret store. DatabaseDefault database to connect to (if applicable). Proxy ClusterOptional. Select if using proxy clusters instead of gateways. Secret StoreOptional. Select a third-party vault instead of storing creds in StrongDM.

Per-Type Examples (CLI)

add-databases.sh
# PostgreSQL
sdm admin resources add postgres prod-pg --hostname pg.internal.co --port 5432 --username sdm_user --password 'secret' --database myapp

# MySQL
sdm admin resources add mysql prod-mysql --hostname mysql.internal.co --port 3306 --username sdm_user --password 'secret' --database myapp

# Microsoft SQL Server
sdm admin resources add sqlserver prod-mssql --hostname mssql.internal.co --port 1433 --username sa --password 'secret' --database master

# MongoDB (Replica Set)
sdm admin resources add mongo prod-mongo --hostname mongo1.internal.co --port 27017 --username admin --password 'secret' --auth-database admin

# Redis
sdm admin resources add redis prod-redis --hostname redis.internal.co --port 6379

# DynamoDB (IAM - no creds needed, uses instance profile)
sdm admin resources add amazonEksiamProfile prod-dynamo --hostname dynamodb.us-east-1.amazonaws.com --region us-east-1
Multiple Credential Levels

You can add the same database endpoint multiple times with different credentials. Example: one resource with read-write creds for admins, another with read-only creds for analysts. Assign each to different roles.

Kubernetes Clusters

StrongDM supports EKS, AKS, GKE, and generic Kubernetes. Key features:

  • Resource Discovery: Auto-scan groups, roles, bindings, service accounts. Enable with the "Enable Resource Discovery" checkbox when adding the cluster.
  • Privilege Levels: Map K8s groups to StrongDM privilege levels. Users get different access tiers on the same cluster without creating separate resources.
  • Identity Aliases: Map each user to a K8s identity for native audit logging. Requests include impersonation headers with the user's alias.
  • Leased Credentials: Default mode. All users connect using the same base credential. StrongDM handles auth.
add-eks.sh
# Add EKS cluster
sdm admin clusters add amazon-eks prod-eks \
  --cluster-name my-cluster \
  --endpoint https://ABCDEF.gr7.us-east-1.eks.amazonaws.com \
  --region us-east-1 \
  --certificate-authority "$(cat ca.pem)" \
  --access-key-id AKIAXXXXXXXX \
  --secret-access-key "secret" \
  --discovery-enabled

# Add EKS with Instance Profile (no static creds)
sdm admin clusters add amazon-eks-instance-profile prod-eks-iam \
  --cluster-name my-cluster \
  --endpoint https://ABCDEF.gr7.us-east-1.eks.amazonaws.com \
  --region us-east-1 \
  --certificate-authority "$(cat ca.pem)" \
  --discovery-enabled
Further Reading
TopicLink
Clusters Overviewdocs.strongdm.com/.../clusters
K8s Discovery & Privilege Levelsdocs.strongdm.com/.../kubernetes-management
K8s Identity Aliasesdocs.strongdm.com/.../kubernetes-identity-alias

Bulk Import & Cloud Discovery

Bulk Import (CLI)

sdm admin resources add <TYPE> --template > import.json to get a template. Edit, then sdm admin resources add --file import.json to import.

Cloud Discovery

Settings > Connectors > Add Connector. Select cloud, pick nodes with read access, set crawl interval. Discovered resources appear for selective onboarding.


4. Users, SSO, and SCIM Provisioning

Get users into StrongDM and configure how they authenticate.

Quick: Manual Invite

Principals > Users > Invite. Enter name and email. User gets an invitation. Fine for testing, doesn't scale.

SSO Configuration

Configure single sign-on so users authenticate through your existing identity provider.

Okta SSO via OIDC

  1. Create an Okta app
    In Okta Admin Console: Applications > Applications > Browse App Catalog. Search for "StrongDM" and add it. On the Sign On tab, set Credentials Details > Application username format to Email.
  2. Copy Okta values
    From the StrongDM app in Okta, note the Client ID and Client Secret from the Sign On tab. Note your Okta domain (e.g., https://yourcompany.okta.com).
  3. Configure in StrongDM
    In StrongDM Admin UI: Settings > User Management > Single Sign-on. Click the lock to edit. Select Okta as provider. Enter: SSO URL (https://yourcompany.okta.com), Client ID, Client Secret. Choose SSO settings (e.g., require SSO for all users). Click Activate.

Okta SSO via SAML

  1. Create an Okta SAML app
    In Okta Admin Console: Applications > Applications > Browse App Catalog. Search for "StrongDM" and select the SAML variant. Add the app and configure the SAML settings as directed by the StrongDM docs.
  2. Get SAML metadata
    From the Okta app's Sign On tab, copy the Identity Provider metadata URL or download the metadata XML.
  3. Configure in StrongDM
    Settings > User Management > Single Sign-on. Select SAML as provider. Upload or paste the metadata URL. Set the entity ID and ACS URL as shown in the StrongDM UI. Click Activate.
Reference

docs.strongdm.com/.../okta-saml

Microsoft Entra ID SSO via OIDC

Best Practice

If using Entra for both SSO and SCIM, create two separate enterprise apps -- one for SSO, one for SCIM. This avoids configuration conflicts.

  1. Register an app in Azure
    Azure portal > App registrations > New registration. Set name, supported account types, and redirect URI: https://app.strongdm.com/auth/return (or regional equivalent). Click Register.
  2. Copy values
    From the app Overview: copy the Application (client) ID and Publisher Domain. Under Certificates & secrets: create a client secret and copy the value (not the secret ID). Shown once only.
  3. Configure in StrongDM
    Settings > User Management > Single Sign-on. Select Azure. Enter: SSO URL (https://login.microsoftonline.com/<PUBLISHER_DOMAIN>), Client ID, Client Secret. Click Activate.

Microsoft Entra ID SSO via SAML

  1. Create an Enterprise app
    Azure portal > Enterprise Applications > New application > Create your own. Select "Integrate any other application". Set up SAML-based sign-on.
  2. Configure SAML settings
    In the SAML configuration: set Entity ID and Reply URL (ACS) as shown in the StrongDM Admin UI's SAML settings page. Download the Federation Metadata XML from the Entra app.
  3. Configure in StrongDM
    Settings > User Management > Single Sign-on. Select SAML. Upload the metadata XML or paste the metadata URL. Click Activate.
Reference

docs.strongdm.com/.../saml

SCIM Provisioning

Auto-sync users and groups from your IdP. Groups map to Roles in StrongDM. User lifecycle (create, update, suspend) is fully automated.

Okta SCIM Provisioning

  1. Get a SCIM token from StrongDM
    Settings > User Management > Provisioning. Set SCIM Provider to Okta. Click Activate SCIM. Copy the token (shown once).
  2. Configure Okta app
    In the StrongDM app in Okta: Provisioning tab > Configure API Integration. Check Enable API Integration. Enter API Token (the SCIM token). Base URL: https://app.strongdm.com. Click Test API Credentials, then Save.
  3. Enable provisioning features
    Under Provisioning > To App: enable Create Users, Update User Attributes, Deactivate Users. Push Groups maps Okta groups to StrongDM Roles.
  4. Assign users and push groups
    Assignments tab: assign groups of Okta users. Push Groups tab: push Okta groups to StrongDM as Roles. If a user already exists in StrongDM, Okta takes ownership.
Note

If you were using an older Okta directory sync script via the StrongDM API, disable it before activating SCIM. Azure does not support nested role provisioning via SCIM.

Entra ID SCIM Provisioning

  1. Get a SCIM token from StrongDM
    Settings > User Management > Provisioning. Set SCIM Provider to Azure. Click Activate SCIM. Copy the token (shown once).
  2. Create an Enterprise app in Azure
    Azure portal > Enterprise Applications > New application. Create a new app for SCIM (separate from your SSO app).
  3. Configure provisioning
    In the app: Provisioning > Get started. Set Mode to Automatic. Under Admin Credentials: Tenant URL = https://app.strongdm.com/provisioning/azure/v2, Secret Token = your SCIM token. Click Test Connection, then Save.
  4. Set scope and sync
    Under Settings > Scope: choose "Sync all users and groups" (entire directory) or "Sync only assigned users and groups" (only entities listed in Users and Groups for this app). Start provisioning.
Identity Aliases via SCIM

You can provision Identity Aliases through Entra ID SCIM by adding a custom attribute mapping. Set the target attribute to urn:ietf:params:scim:schemas:extension:strongdm:2.0:User:identityAliases. Format: <IDENTITY_SET_NAME>, <ALIAS>. Multiple sets separated by pipe (|).

Permission Levels

AdministratorFull access. Creates roles, manages users, adds resources, configures policies. Database AdminManages resources but not users or roles. Team LeaderManages users within assigned roles but can't create roles or add resources. UserConnects to resources they have access to. Default level.

Identity Aliases

Map each user to a specific identity on target resources (SSH, RDP, K8s). Create Identity Sets in Principals > Identity Sets, then assign each user an alias within that set. When connecting to a resource configured with that set, StrongDM impersonates the alias. Native server logs show the individual user, not a shared service account.


5. Configure Access

Roles (Standing Access)

Create roles in Access > Roles. Each role has up to 10 access rules: static (select specific resources) or dynamic (by type + tags, auto-includes new matches). Assign users via Principals > Users > Roles tab.

Access Workflows (JIT) Enterprise

Create in Access > Workflows. Assign requestable resources, eligible roles, approvers, and duration. Users request from catalog; approvers notified via Slack/Teams/UI. Up to 50 workflows. Higher-priority workflow wins on overlap.

Policies (Cedar) Enterprise

Fine-grained control in Access > Policies. Written in Cedar. Augments role-based access with contextual conditions (time, location, device trust, specific commands).

cedar-examples.cedar
// Require MFA for production
@mfa("MFA required for production")
permit ( principal, action == StrongDM::Action::"connect", resource )
when { resource.tags.getTag("env") == "prod" };

// Block DROP TABLE everywhere
forbid ( principal, action == SQL::Action::"drop_table", resource );
Further Reading
TopicLink
Rolesdocs.strongdm.com/.../roles
Access Workflowsdocs.strongdm.com/.../access-workflows
Policiesdocs.strongdm.com/.../policies
Policy Taxonomydocs.strongdm.com/.../policy-taxonomy

6. Auditing

Everything through StrongDM is logged automatically. No agents needed.

C
Connections
Who connected, when, from where, how long. Logs > Connections.
Q
Queries
Full SQL query text at protocol level. Logs > Queries.
S
Sessions
Replayable SSH/RDP recordings. Logs > Sessions.
A
Activities
Admin actions (role changes, user mods, etc). Logs > Activities.

Also: Reports for compliance reviews, Log Export for SIEM integration, Threat Detection for anomaly flagging.


7. Client Installation

macOS / Windows

Download from Admin UI Downloads page. Run installer, log in. Desktop app shows available resources.

Linux

client.sh
curl -J -O -L https://app.strongdm.com/releases/cli/linux
unzip sdmcli_*_linux_amd64.zip
sudo ./sdm install

Basic CLI Usage

sdm-basics.sh
sdm --version           # Check version
sdm status              # List available resources
sdm connect <NAME>     # Connect to a resource
sdm admin resources list # Admin: list all resources
sdm --help              # Full help

After connecting, point your client tool at 127.0.0.1 + the assigned port. Username/password usually blank (StrongDM handles auth).


8. Advanced

Each topic below has a dedicated deep-dive document with full setup procedures, code examples, and troubleshooting.

External Docs Links
TopicLink
Terraformdocs.strongdm.com/.../terraform
Parent/Childdocs.strongdm.com/.../parent-child
Vaultdocs.strongdm.com/admin/secrets
APIdocs.strongdm.com/references/api
CLIdocs.strongdm.com/references/cli

Note

Content sourced from docs.strongdm.com, March 2026. For the latest, start at docs.strongdm.com/admin.