StrongDM New Tenant Setup Guide
Self-contained walkthrough with detailed setup procedures for servers, databases, SSO, SCIM, and more. Use the tabs to drill into specific resource types and IdP integrations.
Concepts
Network
Resources
Users
Access
Audit
Client
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
sdm CLI on user workstations. Creates a TLS 1.2 encrypted connection to gateways. Config updates in real time from the control plane.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
| Topic | Link |
|---|---|
| What Is StrongDM? | docs.strongdm.com/concepts/what-is-strongdm |
| How StrongDM Works | docs.strongdm.com/concepts/how-strongdm-works |
| Security | docs.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
- Create in Admin UINetworking > Gateways > Add gateway. Enter name, advertised host (public IP/DNS), port (default
5000). Click Create. - Copy the tokenShown once only. Save it securely.
- Install on servergateway-install.sh
curl -J -O -L https://app.strongdm.com/releases/cli/linux unzip sdmcli_*_linux_amd64.zip sudo ./sdm install --nodeFor UK: add
--app-domain app.uk.strongdm.com. For EU:--app-domain app.eu.strongdm.com. Paste token when prompted (won't echo). - VerifyBack in Admin UI, gateway should show online with a heartbeat. If not, hard refresh. Check daemon:
ps aux | grep sdm.
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
| Topic | Link |
|---|---|
| Networking Overview | docs.strongdm.com/admin/networking |
| Proxy Clusters | docs.strongdm.com/.../proxy-clusters |
| Gateways & Relays | docs.strongdm.com/.../gateways-and-relays |
| Linux / EC2 / GCP / K8s / Docker | See sub-pages |
| Ports Guide | docs.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.
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:
| Type | Auth Method | Best 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
- Add the resourceResources > Managed Resources > Add Resource. Select SSH (Public Key). Enter display name, hostname, port (default 22), and username the node should use to connect.
- Install the public keyAfter creation, StrongDM generates a key pair. Copy the public key from the resource settings and append it to
~/.ssh/authorized_keyson the target host for the configured user. - Verify healthcheckResource 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
- Get the CA public keyGo to Settings > Secrets Management > Certificate Authorities. Select the SSH CA and copy its public key.
- Configure the target host to trust the CAOn the SSH server, add the CA public key to
/etc/ssh/and addTrustedUserCAKeys /etc/ssh/sdm_ca.pubtosshd_config. Restart sshd. - Add the resource in StrongDMSelect 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.
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.
# 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 listRDP Server Types
| Type | Auth Method | Best 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 certificates | Production. Supports Identity Aliases, on-prem AD and Entra ID. Supports NLA (on-prem only). |
Adding an RDP (Password) Server
- Add the resourceResources > Managed Resources > Add Resource > RDP (Password). Enter name, hostname/IP, port (default 3389), username (
DOMAIN\useroruser@domainformat for AD), and password. - VerifyHealthcheck confirms network reachability (not credential validity). Connect from the StrongDM desktop app using your RDP client to fully verify.
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
- Configure the CAEvery 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.
- Add the resourceSelect 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. - 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.
# 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
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)
# 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-1You 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 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-enabledFurther Reading
| Topic | Link |
|---|---|
| Clusters Overview | docs.strongdm.com/.../clusters |
| K8s Discovery & Privilege Levels | docs.strongdm.com/.../kubernetes-management |
| K8s Identity Aliases | docs.strongdm.com/.../kubernetes-identity-alias |
Bulk Import & Cloud Discovery
sdm admin resources add <TYPE> --template > import.json to get a template. Edit, then sdm admin resources add --file import.json to import.
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
- Create an Okta appIn 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.
- Copy Okta valuesFrom 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). - Configure in StrongDMIn 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
- Create an Okta SAML appIn 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.
- Get SAML metadataFrom the Okta app's Sign On tab, copy the Identity Provider metadata URL or download the metadata XML.
- Configure in StrongDMSettings > 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
Microsoft Entra ID SSO via OIDC
If using Entra for both SSO and SCIM, create two separate enterprise apps -- one for SSO, one for SCIM. This avoids configuration conflicts.
- Register an app in AzureAzure portal > App registrations > New registration. Set name, supported account types, and redirect URI:
https://app.strongdm.com/auth/return(or regional equivalent). Click Register. - Copy valuesFrom 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.
- Configure in StrongDMSettings > 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
- Create an Enterprise appAzure portal > Enterprise Applications > New application > Create your own. Select "Integrate any other application". Set up SAML-based sign-on.
- Configure SAML settingsIn 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.
- Configure in StrongDMSettings > User Management > Single Sign-on. Select SAML. Upload the metadata XML or paste the metadata URL. Click Activate.
Reference
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
- Get a SCIM token from StrongDMSettings > User Management > Provisioning. Set SCIM Provider to Okta. Click Activate SCIM. Copy the token (shown once).
- Configure Okta appIn 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. - Enable provisioning featuresUnder Provisioning > To App: enable Create Users, Update User Attributes, Deactivate Users. Push Groups maps Okta groups to StrongDM Roles.
- Assign users and push groupsAssignments 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.
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
- Get a SCIM token from StrongDMSettings > User Management > Provisioning. Set SCIM Provider to Azure. Click Activate SCIM. Copy the token (shown once).
- Create an Enterprise app in AzureAzure portal > Enterprise Applications > New application. Create a new app for SCIM (separate from your SSO app).
- Configure provisioningIn 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. - Set scope and syncUnder 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.
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
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).
// 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
| Topic | Link |
|---|---|
| Roles | docs.strongdm.com/.../roles |
| Access Workflows | docs.strongdm.com/.../access-workflows |
| Policies | docs.strongdm.com/.../policies |
| Policy Taxonomy | docs.strongdm.com/.../policy-taxonomy |
6. Auditing
Everything through StrongDM is logged automatically. No agents needed.
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
curl -J -O -L https://app.strongdm.com/releases/cli/linux
unzip sdmcli_*_linux_amd64.zip
sudo ./sdm installBasic CLI Usage
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 helpAfter 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
| Topic | Link |
|---|---|
| Terraform | docs.strongdm.com/.../terraform |
| Parent/Child | docs.strongdm.com/.../parent-child |
| Vault | docs.strongdm.com/admin/secrets |
| API | docs.strongdm.com/references/api |
| CLI | docs.strongdm.com/references/cli |
Content sourced from docs.strongdm.com, March 2026. For the latest, start at docs.strongdm.com/admin.