Executive summary
Server Suite and StrongDM solve adjacent but distinct problems. Server Suite governs identity and privilege on the host: an agent on Linux/Unix decides who can log in, as what role, and what they can elevate to. StrongDM governs access to the resource itself: a gateway in front of SSH/RDP/databases/Kubernetes decides whether the connection ever happens.
They are not redundant. They enforce at different layers and target different operational teams. Customers running both get a fuller chain of custody, from "did you get to the resource" through "what did you do once on it."
How they work together — one user, two boundaries
A single request travels through both products. Each enforces at its layer; together they form the complete chain of custody.
At-a-glance comparison
| Dimension | Delinea Server Suite | StrongDM |
|---|---|---|
| Primary purpose | AD-bridged identity and privilege on Linux/Unix | Infrastructure access proxy for SSH, RDP, databases, Kubernetes |
| Enforcement | Agent on the target host | Gateway in front of the target (no agent on target) |
| Identity source | Active Directory (native bridge) | Any SAML / OIDC IdP (Okta, Entra ID, Google) |
| Licensing | Per agent / per system | Per user (seat) |
| Privilege elevation | dzdo sudo replacement, role-based on the box | N/A on host; access grant is the privilege boundary |
| Database access | No native DB protocol support | Native: Postgres, MySQL, MSSQL, Oracle, Mongo, Redis, Snowflake, BigQuery |
| Session recording | Audit & Monitoring add-on (DirectAudit), host-side | Built in, protocol layer (DB queries, RDP video, SSH keystrokes) |
| Device posture / ZTA | No native endpoint posture integration | Native CrowdStrike Falcon ZTA score gating |
| JIT model | Time-bound role activation on the host | Time-bound access grant to a resource |
| Network model | Agent contacts AD/DC | Client → gateway → target; target stays in private network |
| Offline behavior | Works with cached AD creds if DC unreachable | Requires control-plane connectivity |
| Strength | Deep Linux/Unix identity, AD-integrated, mature in regulated estates | Modern DBA / DevOps access, broad protocol coverage, cloud-native |
The point is not "which wins" — it's "which boundary do you enforce at."
Where each one enforces
user
dzdoUser authenticates to the box via AD. The agent decides what roles can be activated and what dzdo can run. Decision lives on the host.
user
resource
User points client at StrongDM. The gateway authenticates via IdP, checks policy, optionally checks device posture, then proxies the connection. Decision lives in front of the target.
How each handles JIT
Server Suite
Identity is persistent, privilege is just-in-time.
User is always allowed to log in as themselves. They activate a privileged role for a defined window, and dzdo enforces what that role can execute. Audit trail is on the host.
"You can always log in, but you can't always be root."
StrongDM
Access itself is just-in-time.
User has no standing connection to the target. They request access (often through Slack/Teams approval), receive a time-bound grant, and the gateway opens the connection for the duration. After expiry, the path closes.
"You can't even reach the box until someone says yes."
A regulated customer with insider-threat concerns often wants both: brokered, recorded entry (StrongDM), plus least-privilege enforcement on the box (Server Suite).
Server Suite JIT — host-side role activation
- User authenticates with their own AD identity (always allowed).
- User requests activation of a privileged role (e.g.
oracle-admin) for a time window. - Server Suite enforces what commands the role can run via
dzdo. - Window expires; privilege drops back to baseline. Identity is unaffected.
- Audit trail captured on the host (commands, optional screen capture with A&M).
StrongDM JIT — gateway-side access grant
- User has no standing access to the resource.
- User requests access to a specific target (DB, server, K8s cluster, etc.).
- Approval workflow fires (Slack/Teams/API) or auto-approves per policy.
- Time-bound grant opens the path through the gateway.
- Connection proxied; recorded at the wire (DB queries, RDP video, SSH keystrokes).
- Grant expires; gateway closes the path.
Use case scenarios
Click any scenario to expand. These are the conversations to have with customers based on what they already own.
01
Regulated Linux estate + DBA team
▾
Server Suite continues to govern AD-bridged login and role-based privilege on the Linux fleet for sysadmins. StrongDM brokers the database connections (Postgres, Oracle, MSSQL) the DBAs make from their workstations. One product owns "who can SSH as what role on the host"; the other owns "who can open a DB session and what queries they run." Audit chains cleanly across both layers.
02
Mixed-OS shop: Okta for DevOps, AD for Security
▾
Server Suite governs Unix/Linux identity via AD, with no rip-and-replace for the *nix admin team. StrongDM front-doors cloud-native resources (Kubernetes, RDS, Snowflake) for the DevOps team using Okta. Same customer, two operational realities, both covered.
03
CrowdStrike Falcon shop wanting device-posture gating
▾
StrongDM can block or allow access based on the endpoint's Falcon ZTA score, so a compromised or out-of-compliance laptop can't reach production. Server Suite has no native concept of endpoint posture. Pairing them lets the customer add posture-gated access to existing Server Suite-governed estate without ripping out the AD bridge.
04
Audit consolidation
▾
Two complementary recording layers:
- StrongDM captures at the wire: user X was approved at 10:42, connected to
db-prod-3, ran these specific queries. - Server Suite DirectAudit captures on the host: on the adjacent jump box, user X activated the
oracle-adminrole and ran these commands.
Together, a single forensic event has both halves of the story.
05
Legacy + modern coexistence during migration
▾
Customer has thousands of Linux servers running Server Suite, audit-approved, working, sunk cost. They want to add governed access for a new cloud analytics team. Don't rip out Server Suite; layer StrongDM on top for the new use cases and leave the existing *nix estate alone.
Where they overlap
Be honest with customers about this.
- SSH to Linux servers. Both can govern SSH, very differently. Server Suite uses native SSH with AD identity and host-side enforcement. StrongDM proxies SSH through its gateway with its own session recording and IdP identity. Customers can legitimately run both: Server Suite for direct admin SSH from a trusted management network, StrongDM for brokered/recorded SSH from anywhere else.
- Session recording. Both record, but at different layers. Not duplicate effort; complementary evidence.
Where each is uniquely strong
Server Suite only
- Deep AD integration for Linux/Unix
dzdoprivilege elevation, role-based- Works with cached AD creds if DC offline
- File integrity monitoring (with A&M)
- Mature in regulated estates (PCI, HIPAA, FedRAMP)
StrongDM only
- Native database protocol awareness
- CrowdStrike Falcon ZTA posture gating
- Kubernetes, cloud-managed DBs, internal web apps
- Agentless on the target (managed services)
- IdP-flexible: any SAML/OIDC, not AD-dependent
Licensing models, plainly
Server Suite
Cost scales with how many hosts you protect.
StrongDM
Cost scales with how many humans need access, independent of how many resources sit behind the gateway.
What this document deliberately does not claim
So the doc stays honest. Confirm any of these with Delinea PM before adjusting customer-facing copy.
- No claim of a unified Delinea Platform identity tie-in between the two products today.
- No claim that DirectAudit and StrongDM session recordings are correlatable in a single pane today.
- No specific pricing tiers or per-resource discounts; those are deal-specific.
- Neither product replaces a PAM vault. Secret Server / Delinea Platform still owns credential vaulting.