# Privilege Management for Unix/Linux + AD Bridge: — pbrun, Policy Servers & One Identity Source: https://ai.techclick.in/blog_beyondtrust_pmul_ad_bridge Markdown: https://ai.techclick.in/blog_beyondtrust_pmul_ad_bridge.md Publisher: Techclick Infosec Pvt Ltd BeyondTrust PMUL & AD Bridge for L1/L2 engineers: pbrun, pbmasterd policy decisions, iolog recording, Sudo Manager, domainjoin-cli, cells, Kerberos SSO, Linux GPO. Privilege Management for Unix/Linux + AD Bridge: — pbrun, Policy Servers & One Identity student learning map A visual study map for Privilege Management for Unix/Linux + AD Bridge: — pbrun, Policy Servers & One Identity showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Privilege Management for Unix/Linux + AD Bridge: —... BeyondTrust · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① The Unix root problem — 500... 4. Practice ② PMUL — pbrun, the policy server... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most engineers think pbrun is just "enterprise sudo" — same tool, paid licence — and that joining Linux to AD means syncing AD users into /etc/passwd. Wrong on both counts. sudo decides on the box from a file root can edit; pbrun ships the request to pbmasterd on a central policy server , which answers accept or reject and records every keystroke into a replayable iolog. And AD Bridge never copies users into /etc/passwd — identities resolve live from AD via NSS/PAM , so disabling one AD account locks a leaver out of all 500 servers in one click. ## ① 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. 👉 So far: sudo = local decision + local, erasable logs + no keystrokes + no fleet-wide report. Next: the picture auditors want instead. Figure 1 — Where sudo stops and central policy starts Left half in red shows three Linux server stacks, each holding its own drifting sudoers file, plus a sticky note with a shared root password and a confused auditor question. Right half in blue shows the same servers asking one central policy server holding a single pb.conf rulebook, with every decision and keystroke flowing to a log server that produces an entitlement report for the auditor. 500 rulebooks vs 1 rulebook — where sudo stops and PMUL starts TODAY: sudo + shared root web14 sudoers v3? db07 sudoers v9? app221 edited 2023? root: Infy@2019 shared on a sticky note Auditor: who can run what, where? Answer: grep 500 drifting files… Who typed rm -rf as root? Unknown. local decision · local logs · zero keystrokes WITH PMUL: one central rulebook web14 db07 app221 policy server pbmasterd /etc/pb.conf ×1 - log server pblogd · iolog Auditor answer = one entitlement report pbcheck -e → who, what, where (CSV) Key shift: the root decision LEAVES the server untrusted/attacker trusted/vaulted policy/decision key insight allowed/audited Left: today — every server its own rulebook, root shared on a sticky note, the auditor gets a shrug. Right: the same servers ask ONE policy server (pbmasterd, one pb.conf), and every decision plus every keystroke lands on a log server that can print the auditor’s answer as a CSV. Pause & Predict Predict: the auditor asks Aditya for last quarter’s root activity on db07. With plain sudo + shared root, what is the BEST evidence he can physically produce? Type your guess. Reveal answer Answer: Fragments: /var/log/secure entries on db07 itself (which root could have edited), maybe a .bash_history (trivially disabled or wiped), and SSH logins that all say "root" — so no human attribution. No keystrokes, no central copy, no entitlement list. That gap — not convenience — is why PMUL exists. ### The four failures auditors circle in red Tap each card — these are the exact gaps PMUL and AD Bridge were built to close. 🗒️ Shared root tap to flip Every login is "root" — nobody is anybody. Unattributable by design. So: individual identity must come first. 📂 Sudoers drift tap to flip 500 hand-edited files, no versioning, no owner. So: one central rulebook beats 500 local ones. 🙈 No keystrokes tap to flip sudo logs the command, then goes blind inside the shell. So: you need a flight recorder, not a doorbell log. 📊 No report tap to flip No command answers "who can run what, where". So: entitlement reporting is an audit requirement, not a luxury. Quick check · Q1 of 10 The auditor asks Aditya at Infosys: "Show me everyone who could run a root shell on these 500 servers, and what they typed last month." With local sudoers + shared root, what is his honest answer? a) Both are easy — sudo logs everything to a central server by default b) Neither is possible — entitlements live in 500 drifting files, and shared-root logins are unattributable with no keystroke record c) Entitlements no, but keystrokes yes — /var/log/secure records every keypress d) Keystrokes yes via .bash_history; entitlements need one grep Correct: b. sudo logs locally (not centrally) and records invocations, not keystrokes; /var/log/secure has auth events only; .bash_history is user-editable and root can wipe it. Entitlements are scattered across 500 files with no aggregate view. Both auditor asks fail — which is the business case for this whole lesson. ## ② 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. Figure 2 — One pbrun request through four daemons Four nodes left to right: a submit host where Rahul types pbrun, the policy server running pbmasterd on port 24345 holding pb.conf with an accept or reject decision diamond, the run host where pblocald on port 24346 executes the task as root, and the log server where pblogd on port 24347 stores the event log and the iolog keystroke recording replayable with pbreplay. A red reject arrow returns to the user. Leader lines call out that the decision leaves the box and the keystrokes land centrally. One pbrun request, four daemons — the gram panchayat of root submit host web14 rahul$ pbrun \ systemctl restart submitmasters → pb.settings policy server pbmasterd :24345 pb.conf accept; / reject; run host pblocald :24346 executes as root only AFTER accept log server pblogd :24347 event log + iolog pbreplay = playback request accept reject; → user told no, event still logged ← the decision is made HERE, never on web14 ← every keystroke lands here Even a root user on web14 cannot edit the register — it lives elsewhere untrusted/attacker trusted/vaulted policy/decision key insight allowed/audited Follow Rahul’s request left to right: pbrun on the submit host consults the submitmasters list in /etc/pb.settings, pbmasterd (TCP 24345) decides accept or reject from pb.conf, pblocald (24346) executes as root only on accept, and pblogd (24347) writes the event log plus the keystroke iolog. The dashed red path: a reject; goes back to the user — and is still logged. Submit host (RHEL) · pbrun — the sudo that phones the policy server $ pbrun id $ pbrun /usr/sbin/useradd appdeploy $ pbrun --testmaster=pbmaster01.corp.icici.in /sbin/shutdown -r now Expected output 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. ### ▶ One pbrun request, end to end Rahul at HCL restarts nginx on web14 (10.20.4.14) through PMUL. Press Play for the healthy path, then Break it to see the failure. ① Submit rahul@web14 pbrun systemctl restart nginx → submitmasters list in /etc/pb.settings ▼ ② Decide pbmasterd:24345 evaluates /etc/pb.conf → accept; (user=rahul, command allowed) ▼ ③ Execute pblocald on web14 runs the task as root — request user never becomes root ▼ ④ Record pblogd:24347 writes event log + iolog — every keystroke, replayable Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Policy server · pbcheck (pre-flight) + pbreplay (the CCTV playback) $ 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 Expected output # 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 COMMON MISTAKE — pushing pb.conf without pbcheck Symptom: minutes after a policy edit, every pbrun in the estate starts getting rejected (or worse, an over-permissive branch starts accepting everything). Cause: pbmasterd only reports policy errors to its own log at runtime — there is no compile step protecting you. Fix: pbcheck -s -f /etc/pb.conf before every push, then pbrun --testmaster= to dry-run the exact accept/reject decision without executing anything. Figure 3 — sudo vs pbrun — same prompt, different universe Two-column comparison. The sudo column in red: decision made locally on the same server, rulebook is a per-server sudoers file that drifts, audit is local syslog lines that root can erase, no keystroke recording, and 500 servers means 500 rulebooks. The pbrun column in blue: decision made centrally by pbmasterd, one pb.conf rulebook, central tamper-resistant event log, full iolog keystroke recording replayable with pbreplay, and one entitlement report for any number of servers. sudo vs pbrun — same prompt, different universe sudo pbrun (PMUL) Decision: on the same box, by the local binary Decision: central — pbmasterd reads pb.conf Rulebook: /etc/sudoers per server → drifts Rulebook: ONE pb.conf on the policy server Audit: local syslog — root can erase it Audit: central event log on pblogd Keystrokes: none (bash history ≠ evidence) Keystrokes: full iolog → pbreplay playback At 500 servers: 500 rulebooks, 500 logs At 500 servers: still 1 rulebook, 1 register Auditor ask: grep marathon, gaps admitted Auditor ask: pbcheck -e entitlement CSV fine at 5 servers · fails audits at 500 built for the 500-server estate middle path: Sudo Manager — keep sudo, centralise the sudoers files (section ②) heritage name: PowerBroker — interviewers still say it sudo asks a file on the box · pbrun asks head office — and head office keeps the CCTV Read row by row: where the decision happens, where the rulebook lives, what the audit trail survives, and what each looks like at 500 servers. The middle path for brownfield estates — Sudo Manager — is flagged at the bottom of the sudo column. ### 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. Rahul at HCL faces this pbrun works instantly from most servers, but from two new DC subnets it hangs forever — same user, same policy, same command. Likely cause The new DC firewall opened only TCP 24345–24347. PMUL’s dynamic (optimized) connections also use a configurable listening range — default 1024–65535 — and those ports are silently dropped, so some sessions never complete the handshake. Diagnosis Run pbrun -d connect from an affected host: the connection attempt to the policy server stalls mid-handshake instead of failing fast. Healthy hosts complete in milliseconds. /etc/pb.settings → minlisteningport / maxlisteningport (submit hosts + policy server), then the DC firewall rule set Fix Constrain the dynamic range in /etc/pb.settings on all hosts (e.g. minlisteningport 49152 / maxlisteningport 49251), open exactly that range on the firewall alongside 24345–24347, restart the PMUL daemons. Verify pbrun id from each affected subnet returns uid=0(root) instantly, and the new events appear in pblogd’s log — confirm with a quick pbreplay of one session. Quick check · Q2 of 10 Priya at ICICI types pbrun systemctl restart postgresql on db07. Where is the allow/deny decision actually made? a) Locally on db07 — the pbrun binary reads a cached copy of the policy b) In Active Directory — Kerberos group membership decides c) Centrally — pbmasterd on the policy server evaluates /etc/pb.conf and returns accept or reject d) By pblogd, after checking her previous iolog history Correct: c. pbrun submits the request to pbmasterd (per the submitmasters list in /etc/pb.settings); the policy server alone stamps accept; or reject; from pb.conf. Nothing is decided on db07, AD plays no part in the PMUL decision, and pblogd only records — it never judges. Pause & Predict Predict: the only policy server goes down for patching at 2 AM. What happens to pbrun across 200 servers — and what should the design have been? Type your guess. Reveal answer Answer: Every new pbrun request fails or hangs: the decision is central, so the dependency is central. pbrun walks the submitmasters list in /etc/pb.settings, so the design fix is at least two policy servers listed for failover (plus a separate log server) — exactly what section ④ builds. ## ③ 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. Linux server · domainjoin-cli — join the box to AD, then prove it $ 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 Expected output 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 COMMON MISTAKE — SUCCESS printed, nobody can log in Symptom: domainjoin-cli prints SUCCESS, but AD logins fail on the spot. Two causes bite again and again. One: the first join requires a restart before AD logons work — the docs say it plainly, and everyone skips it. Two: DNS was faked — the docs’ pre-checks are nslookup and ping ; if someone "fixed" resolution via /etc/hosts, the join may pass but Kerberos breaks later. Reboot after first join, and make real DNS a gate, not an afterthought. 👉 So far: join with domainjoin-cli, identities resolve live from AD (no /etc/passwd copies), reboot after the first join. Next: how one person carries different UIDs per environment — cells. Figure 4 — AD Bridge — live identity, no local copies, per-environment cells Left: a Linux server where login passes through PAM and NSS into the AD Bridge agent under /opt/pbis, with a crossed-out /etc/passwd showing no local copy. Centre: arrows to an Active Directory domain controller using Kerberos and LDAP, with Group Policy flowing back every 30 minutes. Right: a cells inset showing the same AD user meera.iyer mapped by a Dev named cell to UID 1001 and by a Prod named cell to UID 5001, both linked to one identity like one Aadhaar with different state ration cards. AD Bridge — Aadhaar for Linux machines Linux server pgapp12 ssh meera.iyer@pgapp12 PAM + NSS hooks AD Bridge agent /opt/pbis /etc/passwd entry nothing copied locally — disable in AD = locked out everywhere Active Directory DC corp.flipkart.internal Kerberos (SSO tickets) LDAP (identity lookup) GPO (Linux settings) live lookup GPO every 30 min Cells — same person, per-env UID AD: meera.iyer Dev cell (OU) uid 1001 Prod cell (OU) uid 5001 one Aadhaar, different state ration cards Named Cell = serviceConnectionPoint on the OU Default Cell = one, enterprise-wide One identity to join, one to disable, one for PMUL policy to reference — no /etc/passwd sprawl Left: login flows through PAM/NSS into the AD Bridge agent (/opt/pbis) and out to the DC — the crossed-out /etc/passwd line is the point. Right: cells — the same AD user meera.iyer is UID 1001 under the Dev cell and UID 5001 under the Prod cell: one Aadhaar, different state ration cards. 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. Meera at Wipro faces this A joined SLES server loses AD authentication after every reboot — "lost connection to domain" — until someone manually restarts the AD Bridge services. Then it works perfectly until the next reboot. Likely cause Service start ordering: lsass (the AD Bridge auth service) comes up before the network stack is fully ready, fails its first domain contact, and never recovers on its own — a known pattern on SLES and older releases (tracked publicly on the pbis-open GitHub issues). Diagnosis Right after a reboot, run /opt/pbis/bin/get-status — it shows the domain offline while the network is clearly up; system logs show lsass starting before the interface got its address. /opt/pbis/bin/get-status → then journalctl / /var/log/messages for the lsass vs network start order Fix Fix the unit/service ordering so AD Bridge services start after the network is online (or add a conditioned restart of the AD Bridge services post-network-up). Keep the agent on a current release. Verify Reboot the box in a maintenance window: get-status reports the domain online without manual help, and an AD user can ssh in on first try. Quick check · Q3 of 10 The same AD user must be UID 1001 on dev servers but UID 5001 on the PCI prod segment — both tied to one identity for audit. Which AD Bridge feature does this? a) Named Cells attached to the Dev and Prod OUs, each holding its own UID/GID mapping b) Two separate AD accounts, one per environment c) Editing /etc/passwd on each server to override the UID d) A Kerberos ticket flag that rewrites the UID at login Correct: a. That is exactly what Named Cells exist for: per-OU containers of Unix identity data (uidNumber, gidNumber, shell, home) mapped to ONE AD object. Two AD accounts destroys the single-identity audit goal; /etc/passwd edits are the sprawl we are eliminating; Kerberos carries no UID-rewrite flag. Pause & Predict Predict: domainjoin-cli just printed SUCCESS on pgapp12. Meera immediately tries ssh meera.iyer@pgapp12 with her AD password. What happens? Type your guess. Reveal answer Answer: It fails. After the FIRST join, the computer must be restarted before AD logons work — the docs state it and the field forgets it. After the reboot: get-status should show the domain online, and her AD ssh login lands with the UID her cell defines. ## ④ 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. BeyondInsight → Managed Systems → Create New Managed System (then onboard the root account against it). (Recreated for clarity — your console matches this.)"> 🖥️ This is the screen where root gets vaulted — BeyondInsight → Managed Systems → Create New Managed System (then onboard the root account against it). (Recreated for clarity — your console matches this.) bi.corp.flipkart.internal · Managed Systems 1 Entity Type Asset 2 Platform Linux DNS Name / IP pgapp12.corp.flipkart.internal (10.20.31.14) 3 Functional Account svc_pbsafe_fa — SSH, elevation configured 4 Automatic Password Management Yes — rotate after release Create Managed System Password Safe API · break-glass checkout of vaulted root (ISA role) POST https://bi.corp.flipkart.internal/BeyondTrust/api/public/v3/Auth/SignAppIn Authorization: PS-Auth key= ; runas=corp\sneha.rao; POST https://bi.corp.flipkart.internal/BeyondTrust/api/public/v3/ISARequests { "SystemID": 214, "AccountID": 902, "DurationMinutes": 60 } Expected output 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 👉 So far: two policy servers + a log server for PMUL, root vaulted and rotated in Password Safe, AD Bridge as the shared identity. One card to keep — the pocket card. Figure 5 — PMUL + AD Bridge pocket card A three-panel quick-reference card. Panel one lists PMUL commands: pbrun for policy-checked root, pbrun testmaster for a dry run, pbcheck for syntax and entitlement reports, pbreplay for iolog playback, pbssh for brokered SSH without elevation. Panel two lists AD Bridge commands: domainjoin-cli join, query and leave, get-status, gpupdate verbose. Panel three lists default ports pbmasterd 24345, pblocald 24346, pblogd 24347, plus key files pb.settings, pb.conf and the group policy cache. A footer states the better-together split with Password Safe. PMUL + AD Bridge — the pocket card PMUL commands pbrun run via central policy pbrun --testmaster= dry-run accept/reject pbcheck -s -f pb.conf syntax pre-flight pbcheck -e entitlement CSV (audit) pbreplay replay keystrokes pbssh broker+record, NO elevation sudo + pbsudomgr.so Sudo Manager: keep sudo, centralise sudoers AD Bridge commands /opt/pbis/bin/ domainjoin-cli join \ join AD · reboot after 1st join! domainjoin-cli query name, domain, DN domainjoin-cli leave un-join cleanly get-status agent + domain health gpupdate --verbose force GPO (else 30-min cycle) pre-checks: nslookup + ping the domain (no /etc/hosts shortcuts) Ports & files pbmasterd 24345 policy decision pblocald 24346 task execution pblogd 24347 event log + iolog /etc/pb.settings submitmasters, port ranges /etc/pb.conf THE policy (pbcheck first!) /var/lib/pbis/grouppolicy GPO cache on Linux firewall trap: dynamic range 1024-65535 — constrain it in pb.settings Better together: Password Safe vaults + rotates root (break-glass) · PMUL elevates day-to-day · AD Bridge = the one identity sudo = decide on the box · pbrun = decide at head office · vault checkout = rare, audited exception Screenshot this one: PMUL commands on the left, AD Bridge commands in the middle, the three daemon ports and the files that matter on the right — with the better-together split as the footer. VERIFY — four checks that prove the estate is healthy (1) pbcheck -e produces a current entitlement CSV — your standing auditor answer. (2) pbreplay of a random recent iolog plays back cleanly — the flight recorder is recording. (3) /opt/pbis/bin/get-status on a sample of joined boxes shows the domain online. (4) In BeyondInsight, the root managed accounts show green last-rotation status — the break-glass key is fresh. Quick check · Q4 of 10 Design review at ICICI: the estate needs BOTH root passwords handled and day-to-day elevation controlled. Which split is the intended better-together? a) Vault root in Password Safe and have engineers check it out for every restart and log review b) Run PMUL only and delete the root passwords entirely c) Use AD Bridge GPO to add engineers to a root-equivalent group on each server d) Password Safe vaults + rotates root for break-glass; PMUL (pbrun) handles daily elevation per command; AD Bridge provides the one identity both reference Correct: d. Option (d) is the architecture: command-level least privilege with iolog for routine work, a rotated vaulted root only for emergencies, one AD identity across both. (a) makes everyone full root daily (checkout fatigue + over-privilege); (b) is impossible — root must exist on Unix; (c) recreates standing privilege, the thing we are removing. Pause & Predict Predict: with this split live for six months, how often should a human actually check the root password out of Password Safe? Type your guess. Reveal answer Answer: Almost never — single digits a year. Daily work flows through pbrun under policy. Every root checkout should be an audited exception with a reason (recovery, policy-server outage), and the password rotates the moment it is checked back in. If checkouts are weekly, your pb.conf policy has gaps — fix the policy, not the process. 🎮 Hands-on: BeyondTrust PAM Essentials room Sibling lesson: EPM for Windows & Mac ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. Is pbrun wrapping sudo, or replacing it? Policy server dies — am I locked out of root forever? Does AD Bridge copy AD users into /etc/passwd? Why does pbssh not give me root on my Cisco router? Why do the docs and registry still say PowerBroker and PBIS? What do Indian PAM job ads actually want from this lesson? Pre-curated from BeyondTrust docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember A pbrun request needs an accept/reject decision. Which daemon makes it, on which default port? a) pbmasterd on TCP 24345 b) pblocald on TCP 24346 c) pblogd on TCP 24347 d) sshd on TCP 4422 Correct: a. pbmasterd is the policy-server daemon — it evaluates /etc/pb.conf and stamps accept; or reject; (default port 24345). pblocald (24346) only executes after an accept; pblogd (24347) only records; 4422 is Password Safe’s SSH proxy — a different product in this suite. Q6 · Apply Sneha at TCS inherits 300 Linux servers with hand-edited sudoers files. Management wants central control + session recording this quarter, but admins must keep typing sudo. What does she deploy? a) Full PMUL agents everywhere and rewrite all 300 sudoers as pb.conf policy this quarter b) Sudo Manager — the pbsudomgr.so plugin keeps native sudo while sudoers files are checked out/in centrally, and sessions can be iologged c) AD Bridge with a Group Policy that locks the sudoers files read-only d) pbssh from a central jump host for all admin work Correct: b. Sudo Manager is exactly this brownfield path: keep sudo (zero retraining), centralise the sudoers files on the policy server with check-out/check-in, add iolog recording. A full pb.conf rewrite of 300 files in a quarter is unrealistic; GPO read-only locks fix nothing about drift or audit; pbssh is for agentless devices and adds no sudo control. Q7 · Apply Karthik edited pb.conf to block /sbin/shutdown for the app team. How does he prove the policy decides correctly BEFORE pushing it live — without executing anything? a) Run pbreplay against yesterday’s iologs to see what would have happened b) Start pblocald in debug mode on a test server c) pbcheck -s for syntax, then pbrun --testmaster= /sbin/shutdown -r now to see the accept/reject decision with nothing executed d) Just push it — pbmasterd refuses to load a policy that contains mistakes Correct: c. pbcheck is the pre-flight (syntax + entitlement) and --testmaster dry-runs the real decision without running the command. pbreplay only plays back past sessions; pblocald never decides anything; and pbmasterd does NOT refuse bad policy at load — it only reports errors to its log at runtime, which is exactly why estates get locked out by unchecked pushes. Q8 · Analyze After domainjoin-cli printed SUCCESS on 40 new Ubuntu servers, AD logins fail on all of them. nslookup and ping of the domain work fine from each box. Most likely cause? a) The joins silently failed — SUCCESS is cosmetic and must be re-verified in AD b) Kerberos is not supported on Ubuntu, so AD Bridge cannot authenticate there c) The Default Cell was deleted, so no UID mapping exists anywhere d) The servers were never restarted — the first join requires a reboot before AD logons work Correct: d. The documented rule: after joining a domain for the first time, you must restart the computer before you can log on. DNS pre-checks passing rules out the resolution cause. SUCCESS is a genuine join result; Ubuntu supports Kerberos fine (the community walkthroughs use it); and a missing Default Cell would be an unusual deliberate act — 40 fresh joins all failing identically points to the skipped reboot. Q9 · Analyze Rahul’s team bought PMUL expecting pbssh to give engineers root on their Cisco routers. Sessions connect and record perfectly, but elevation never happens. Why? a) The Shell Jump licence add-on is missing from the policy server b) pbssh only brokers and records SSH to agentless targets — with no PMUL agent on the router there is nothing to elevate; rights come from the device’s own login c) The iolog variable, once set, disables elevation for the session d) Routers need pblocald cross-compiled for IOS before elevation works Correct: b. pbssh’s documented design: it controls who connects and records the session, but it cannot elevate privileges on the target because no agent runs there — run-host variables do not apply. Shell Jump is a PRA concept, not PMUL licensing; iolog is recording-only; and there is no pblocald for IOS — that distractor is the misconception itself. Q10 · Evaluate Two designs for a 500-server bank estate. (A) Vault root in Password Safe; engineers check root out for every task. (B) PMUL pbrun policy for daily work; root vaulted in Password Safe as rotated break-glass; AD Bridge for one identity. Which is stronger, and why? a) A — fewer moving parts always wins in audits b) A — a checkout with approval is stronger than any policy engine c) B — daily work gets command-level least privilege with iolog evidence, root checkout shrinks to a rare audited exception, and one AD identity feeds both controls d) They are equivalent — both produce an audit trail Correct: c. Design A hands out the FULL root shell for every routine task — over-privilege, checkout fatigue, and recordings of unrestricted root sessions instead of scoped commands. Design B enforces least privilege per command (accept/reject + iolog), keeps root as a rotated emergency key, and ties everything to one AD identity. The audit trails are not equivalent: A logs that root was used; B can prove exactly what each named human was allowed to do and did. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: In one line: what changes about the root decision when you move from sudo to pbrun? Then compare to the expert version. Compare with expert answer Expert version: sudo decides locally from a file on the same server (which root can edit); pbrun ships the request to pbmasterd on a central policy server that stamps accept or reject from ONE pb.conf and records every keystroke to a central iolog — the decision and the evidence both leave the box. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on PMUL & AD Bridge at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary pbrun PMUL’s submit command — like sudo, but the allow/deny decision is made centrally by the policy server. pbmasterd Policy server daemon (TCP 24345) that evaluates /etc/pb.conf and stamps accept; or reject; on each request. pblocald Run-host daemon (TCP 24346) that executes the accepted task, typically as root. pblogd Log server daemon (TCP 24347) that writes event logs and iologs — the central register. iolog Full keystroke + output recording of a PMUL session, enabled by the iolog policy variable; treat as a secret. pbreplay Plays back an iolog like CCTV footage — interactive or batch, with timestamps. pbcheck Policy pre-flight: -s syntax-checks pb.conf, -e prints the who-can-run-what-where entitlement report (CSV). pbssh Brokers + records SSH to agentless devices (routers, firewalls). Cannot elevate on the target — no agent there. Sudo Manager PMUL mode keeping native sudo while sudoers files are stored, versioned and checked out/in centrally (pbsudomgr.so + pbadmin). AD Bridge Joins Linux/Unix to Active Directory (formerly Likewise/PBIS — hence /opt/pbis paths): live identity, Kerberos SSO, Linux GPO. Cell AD Bridge container for Unix identity data. One enterprise-wide Default Cell; Named Cells attach to OUs for per-environment UID/GID. domainjoin-cli AD Bridge join tool (/opt/pbis/bin): join, leave, query, fixfqdn. First join requires a reboot before AD logons work. #### 📚 Sources BeyondTrust Docs — EPM for Unix & Linux overview (pbrun → pbmasterd accept/reject → pblocald → pblogd request flow). docs.beyondtrust.com/epm-ul/docs/epm-ul-overview - BeyondTrust Docs — pbrun options (--testmaster, -h, -u) + Firewalls/Port Usage (pbmasterd 24345, pblocald 24346, pblogd 24347; dynamic min/maxlisteningport ranges). docs.beyondtrust.com/epm-ul/docs/pbrun · docs.beyondtrust.com/epm-ul/docs/firewalls - BeyondTrust Docs — Sudo Manager User Guide (pbsudomgr.so plugin, central sudoers check-out/check-in, pbadmin, sudomgrinstall) and pbssh for SSH-managed devices (no elevation on target). docs.beyondtrust.com/epm-ul/docs/sudo-manager-user-guide · docs.beyondtrust.com/epm-ul/docs/connections-to-ssh-managed-devices - BeyondTrust Docs — pbreplay and pbcheck administration programs (iolog playback options; -s syntax check, -e entitlement report). beyondtrust.com/docs/privilege-management/unix-linux/admin/administration-programs/pbreplay.htm · …/pbcheck.htm - BeyondTrust Docs — AD Bridge: domain-join tool, join prerequisites (nslookup/ping, restart-before-logon), cells (Default vs Named, serviceConnectionPoint), Group Policy agent (30-min refresh, /opt/pbis/bin/gpupdate, /var/lib/pbis/grouppolicy). docs.beyondtrust.com/adb/docs/domain-join-tool · docs.beyondtrust.com/adb/docs/ad-bridge-group-policy-settings - GitHub BeyondTrust/pbis-open issues #171 & #217 — field reports: AD Bridge agent loses domain connection after reboot (lsass vs network start ordering on SLES). github.com/BeyondTrust/pbis-open/issues/171 - Community walkthrough — joining Ubuntu to AD with PBIS/AD Bridge (real domainjoin-cli session ending in SUCCESS). blog.yasithab.com/ubuntu/how-to-join-ubuntu-computer-to-active-directory-domain-using-pbis/ - PeerSpot reviews + identityskills 2026 PAM career comparison — BeyondTrust’s Unix story (PowerBroker heritage) as a differentiator vs CyberArk; India job-market demand and the two-PAM-tools hiring pattern. peerspot.com/products/beyondtrust-password-safe-pros-and-cons · identityskills.com/blog/cyberark-vs-beyondtrust-vs-delinea-which-pam-tool-should-you-learn-in-2026/ ### What's next? Your Unix estate now has one rulebook and one identity. Next: wiring BeyondTrust into everything else — REST API authentication, SAML SSO, ServiceNow ticket-gated checkouts, SIEM forwarding and Entra ID. Next · Integrations: API, SAML, ServiceNow, SIEM & Entra → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt