How Delinea Privilege Control for Servers (PCS) replaces coarse-grained root/admin access with granular, identity-aware, policy-driven privilege elevation — giving the right users exactly the rights they need and nothing more.
Most server environments rely on all-or-nothing access models. Admins get root — a single account with unlimited power — or they get nothing. This is one of the most dangerous misconfigurations in enterprise security.
A single root password shared across a server tier. One phished admin, one stolen credential from a config file — and every server in the tier is owned. No rotation, no individual accountability.
Admins granted ALL=(ALL) NOPASSWD: ALL in sudoers — effectively giving unrestricted root without even requiring a password. Misconfigurations like this exist on the majority of enterprise Linux servers.
CVE-2021-3156 (Baron Samedit) and similar sudo vulnerabilities allow any user to escalate to root. Without command-level restrictions, even patched systems remain vulnerable to logic-based escalation.
When 15 admins all use the same root account, a destructive command ("who deleted the database?") cannot be attributed to any individual. Compliance audits fail, insider threats go uninvestigated.
sudoers files are managed manually per-server and drift over time. The same admin has different rights on different servers, creating unknown privilege gaps and over-grants that accumulate silently.
sudo is a useful tool but was designed for individual server management — not enterprise governance. It has no centralised policy management, no Active Directory integration, no session recording, no real-time monitoring, no alerting, no automatic rotation, and no compliance reporting. sudoers files are plain text, drift over time, and are invisible to most security teams.
Delinea PCS replaces scattered sudo with a centralised, policy-driven privilege management layer. Every elevation is identity-aware, scoped to specific commands, time-limited, fully audited, and enforced consistently across thousands of servers from a single policy engine.
Understanding the four foundational concepts that underpin granular server access: Identity, Zones, Role-Based Access, and Command Filtering.
Servers are joined to Active Directory (or LDAP) via PCS's AD bridging capability. Linux and Unix servers authenticate users against AD, meaning every login is tied to an individual AD identity — not a local account. No more shared root. Every action carries a named user identity.
Servers are organised into Zones — logical containers that define which AD users and groups can access which servers, with which rights. A Production Database Zone might contain 50 PostgreSQL servers, all sharing the same access policy. Changes to the zone policy propagate instantly to all member servers.
Within each zone, roles define what a user can do. A DBA Role might allow service postgresql restart but block rm -rf. A Read-Only Auditor Role might allow only log inspection commands. Roles are defined centrally and mapped to AD groups — ensuring consistent enforcement everywhere.
PCS evaluates every privileged command against a policy allow-list before execution. Commands not on the list are blocked and logged. This is fundamentally different from sudo, which operates on a static file and cannot perform dynamic risk evaluation or contextual decisions.
The AD user's group membership determines their zone access and role. Their role defines the exact commands they can elevate. Every attempt — allowed or denied — is logged with full identity context.
| Capability | Native sudo | Delinea PCS |
|---|---|---|
| Policy Management | Per-server flat file — manual, drifts over time | Centralised, Active Directory–integrated, push to all servers |
| Identity | Local OS user — no AD tie | AD/LDAP identity — individual attribution always |
| Command Scope | Static patterns, easily bypassed (e.g. shell escapes) | Dynamic evaluation, shell-escape prevention, argument inspection |
| Session Recording | None | Full terminal session capture, keystroke logging, replay |
| Compliance Reporting | None | Pre-built PCI, HIPAA, SOX, CIS reports |
| Behavioural Analytics | None | Anomaly detection on command patterns |
| Windows Servers | Not applicable | Windows privilege management included |
| Multi-Platform | Linux/Unix only | Linux, Unix, macOS, Windows unified |
A capability-by-capability walkthrough of Delinea Privilege Control for Servers — from AD bridging and zone management to command filtering, session recording, and compliance.
sudo bash), argument wildcards, and indirect privilege escalation patterns — not possible with native sudo.Below is an illustrative PCS role policy for a database administrator. Note how specific commands are allowed, dangerous commands are explicitly blocked, and argument patterns are controlled — far more precise than a sudoers file entry.
Simulate server access as different users with different roles. Experience how PCS allows, blocks, and records commands in real time — try to escalate privilege and see PCS intervene.
From pre-deployment checklist to phased rollout and operational best practices — a practical guide for deploying Delinea PCS across your server estate.
If sudo is not disabled after PCS deployment, users continue using it — bypassing PCS recording and policy entirely. Native sudo must be removed from PATH or the binary renamed/locked as part of cutover.
Starting with permissive policies to avoid disruption and never tightening them. PCS's value comes from specificity — begin tightly, then expand based on legitimate requests.
Denied commands are a rich signal — for both policy gaps (legitimate command not allowed) and attack detection (privilege escalation attempts). These must feed into a regular review process.
Eight questions testing your understanding of server granular access principles and Delinea PCS capabilities. Immediate feedback on every answer.