Privilege Management for Unix/Linux + AD Bridge: — pbrun, Policy Servers & One Identity

① The Unix root problem — 500 servers, 500 rulebooks, zero answers

Aditya runs Linux operations at Infosys for a banking client. The estate: 500 RHEL servers (10.20.0.0/16), a shared root password that has lived in a team spreadsheet since 2019, and a hand-edited sudoers file on every box. It works — until the RBI-empanelled auditor asks two questions: who could run a root shell on these servers last quarter, and what did they type? Aditya has no answer for either.

Here is why sudo stops scaling. The decision is local — each server consults its own file, and 500 files drift apart within months. The evidence is local — sudo writes to syslog on the same box, and anyone who becomes root can edit or erase that log. There is no keystroke record — once a user lands in a root shell, sudo logs one line ("opened a shell") and goes blind. And there is no entitlement report — no single command anywhere can answer "who can run what, where". A shared root password is even worse: every login shows up as root, so actions are unattributable by design.

The four failures auditors circle in red

Tap each card — these are the exact gaps PMUL and AD Bridge were built to close.

② PMUL — pbrun, the policy server & the flight recorder

PMUL is the product the field still calls PowerBroker. Think of it as a gram panchayat for root: pbrun is the application form you submit, pbmasterd is the sarpanch who stamps ACCEPT or REJECT according to the one rulebook (/etc/pb.conf), pblocald is the clerk who actually does the work, and pblogd is the registrar writing every word into the register. Four daemons, four jobs, one estate-wide answer.

$ pbrun id
$ pbrun /usr/sbin/useradd appdeploy
$ pbrun --testmaster=pbmaster01.corp.icici.in /sbin/shutdown -r now

uid=0(root) gid=0(root) groups=0(root)
# useradd: policy accepted — runs as root, silent on success
pbrun: Request rejected by pbmaster01.corp.icici.in
# --testmaster = dry-run: shows the decision, executes nothing (reject text varies by version/policy)

The rulebook itself, /etc/pb.conf, is written in PMUL’s event-driven, C-like policy language: variables such as user, command and runhost flow into conditions, and the first accept; or reject; ends the decision. Set the iolog variable in an accept branch and the entire session — every keystroke in, every byte out — is recorded to a log file you can replay later with pbreplay. That recording is the flight recorder sudo never had. One caution from the field: anything typed inside the session, including passwords at hidden prompts, lands in the iolog — treat iologs as secrets and restrict who can replay them.

$ pbcheck -s -f /etc/pb.conf
$ pbcheck -e -f /etc/pb.conf > entitlement.csv
$ pbreplay -t /var/adm/pb.rahul.web14.2026-06-08.a04412

# syntax check: no errors reported — safe to push
# entitlement.csv = who can run what, where (the auditor answer)
[2026-06-08 14:21:07] systemctl restart nginx
[2026-06-08 14:21:09] tail -50 /var/log/nginx/error.log
# -t prefixes each replayed line with its timestamp

Sudo Manager — keep sudo, centralise the chaos

Ripping out sudo on day one is politically impossible in most Indian estates — admins have muscle memory and run-books reference sudo everywhere. Sudo Manager is the middle path: a sudo plugin (pbsudomgr.so) goes onto each host, sudomgrinstall registers the host and uploads its existing sudoers to the policy server, and from then on sudoers files are checked out, edited and checked back in centrally (via pbadmin) — like a head-office recipe book every branch kitchen must cook from. Sudo sessions can be iologged and replayed with the same pbreplay. Admins keep typing sudo; the auditor finally gets one source of truth. Also know pbssh: it brokers and records SSH to agentless devices, but with no agent on the target it cannot elevate anything there.

③ AD Bridge — one identity for every Linux box

PMUL fixed what runs as root. The second sprawl is who exists at all: 500 servers × local accounts in /etc/passwd means leavers who never leave, password rules nobody enforces, and a different UID for the same human on every box. AD Bridge is Aadhaar for Linux machines: the server joins Active Directory, and from then on identities resolve live through NSS/PAM via the agent — nothing is ever copied into /etc/passwd. Disable one AD account and the leaver is locked out of all 500 servers before the exit interview ends. Logins get Kerberos SSO with the same AD credentials used on Windows.

$ sudo /opt/pbis/bin/domainjoin-cli join --ou Linux/Prod corp.flipkart.internal svc-adjoin@corp.flipkart.internal
$ sudo /opt/pbis/bin/domainjoin-cli query

Joining to AD Domain:   corp.flipkart.internal
Password:
SUCCESS
Name = pgapp12
Domain = CORP.FLIPKART.INTERNAL
Distinguished Name = CN=PGAPP12,OU=Prod,OU=Linux,DC=corp,DC=flipkart,DC=internal

What the join actually touches: /etc/nsswitch.conf, /etc/pam.d/*, /etc/krb5.conf and /etc/hosts — which is why a botched join breaks logins, not just "AD stuff". Identity mapping lives in cells: the single Default Cell serves the whole forest, while Named Cells attach to specific OUs (stored as a serviceConnectionPoint object’s keywords attribute) so the same AD user can hold UID 1001 in dev and UID 5001 in PCI prod — or legacy servers can keep their historical UIDs while still mapping to one AD identity. In Directory Integrated mode the Unix attributes (uidNumber, gidNumber, loginShell, unixHomeDirectory) sit on the AD objects using the RFC 2307 schema. And Group Policy comes to Linux: the agent applies GPOs every 30 minutes, at boot, or on demand with /opt/pbis/bin/gpupdate --verbose, caching them under /var/lib/pbis/grouppolicy — sshd settings, sudoers fragments, message-of-the-day, pushed from GPMC like any Windows fleet.

④ Deploying it — HA, log servers & the Password Safe split

Production layout first. The policy server is now your root decision point, so it gets the availability treatment: at least two policy servers in every estate, listed in order in each host’s submitmasters entry in /etc/pb.settings — pbrun walks the list and fails over automatically. Logging moves to a dedicated log server (pblogd) so evidence survives even if a run host is compromised, and so iologs — which may contain typed secrets — live on a hardened box with restricted pbreplay access. Policy changes go through a pipeline: edit → pbcheck -s → pbrun --testmaster dry-runs → push. In Indian enterprise estates this stack shows up wherever Unix meets auditors: core-banking Linux farms at banks (RBI audits ask precisely the "who can run what" question), telecom OSS/BSS estates, and the managed-services floors at Infosys, TCS, HCL and Wipro — whose PAM job descriptions explicitly want Linux/UNIX depth alongside the vault skills.

Now the better-together design. PMUL does not remove root — it makes using root rare. The remaining root password still exists, so it goes into Password Safe as a managed account: vaulted, auto-rotated on schedule and after every release, checked out only for break-glass moments (the policy server farm itself is down, single-user-mode recovery, filesystem surgery). Think bank locker (vaulted root, dual keys, register) plus the society watchman’s register for daily work (pbrun, every entry logged). AD Bridge supplies the one identity both pillars reference: the same corp\sneha.rao who authenticates to Linux via Kerberos is the user PMUL policy evaluates and the requester Password Safe records. One human, one identity, three controls.

POST https://bi.corp.flipkart.internal/BeyondTrust/api/public/v3/Auth/SignAppIn
Authorization: PS-Auth key=<128-char-api-key>; runas=corp\sneha.rao;

POST https://bi.corp.flipkart.internal/BeyondTrust/api/public/v3/ISARequests
{ "SystemID": 214, "AccountID": 902, "DurationMinutes": 60 }

200 OK   {"UserId":41,"UserName":"corp\\sneha.rao", ...}   # session state kept between calls
201 Created
"V9r!t2#kPq8w..."   # the root password — released 60 min, rotated on expiry
# ISA role = instant, approval-less retrieval; every release still lands in the audit log