Password Safe Architecture: — Managed Systems, Managed Accounts & Functional Accounts

① The vault model — Password Safe on BeyondInsight, and the trinity

First, get the layering straight, because interviewers test it in the opening minute. BeyondInsight is the platform — it owns assets, discovery, Smart Rules and reporting. Password Safe is the PAM module that runs on it — the vault, the request engine, the rotation agents and the session proxy. One console, two layers, one licence conversation. Old-timers still call it PowerBroker (PBPS) — the name survives in registry paths, so recognise it.

Now the trinity that this whole series leans on. A managed system is the box — the docs call it a "computer or device where one or more account passwords are to be maintained". A managed account is the credential being protected — root on db-prod-01, the local Administrator on a file server. And a functional account is the worker — the account Password Safe itself logs in with to change everyone else’s passwords. Think of an SBI branch: the branch building is the managed system, the gold in each locker is the managed account, and the bank’s own master-key custodian — who can re-key any locker but never owns the gold — is the functional account.

The platform coverage is wide and a favourite Remember-tier exam line: Password Safe manages credentials on Windows, Unix/Linux, AD and LDAP domains, databases, network devices (firewalls, routers, iLO out-of-band cards) and cloud platforms. The thing that makes scale possible is that you never click systems in one by one for long — discovery scans find them and Smart Rules onboard them. That automation engine is lesson 5; today you only need to know it exists and that Smart Rule settings override per-account edits.

One more thing the docs say with unusual force: the setup steps "must be completed in the order presented" — 1) functional account → 2) password policy → 3) discover/add assets → 4) onboard managed systems → 5) onboard managed accounts → 6) Smart Rules, access policies, roles. You can onboard a system without a functional account, but the docs are blunt: you cannot onboard accounts until you have onboarded systems — and account onboarding is blocked until a functional account exists for that platform. The worker is hired before the lockers are filled.

Four words you will use every single day

Tap each card — these are the vocabulary anchors for the next 16 lessons.

② Functional accounts in depth — the worker behind every rotation

The docs define a functional account as the "account that can access the system with the privileges required to manage and change passwords". You create it at Configuration > Privileged Access Management > Functional Accounts > Create New Functional Account — two required choices drive the rest of the form: Entity Type (Asset or Directory) and Platform. Pick the Microsoft Entra ID platform and the fields change shape entirely: Azure Scope, Username (UPN), Application (Client) ID, Tenant ID, Client Secret — because in the cloud the "worker" is an app registration, not a username-password pair.

How much privilege does the worker need? Less than most people give it. On a Windows member server: local admin, or just the change-password user right assigned via GPO. In AD: delegated reset-password rights plus read/write of the lockout attribute on the target OUs — not Domain Admin. (Managing protected groups like Domain Admins does need extra AD delegation steps, because AD strips delegated rights on protected objects — that is the only case with a real argument for more.) On Linux: root, or a sudo elevation command configured in the platform settings so the FA elevates only for the password change. Every extra right you grant the worker is blast radius if the worker is ever stolen.

GET https://bi.tcslab.local/BeyondTrust/api/public/v3/FunctionalAccounts
Authorization: PS-Auth key=<128-char-api-key>; runas=tcs\rahul.v;

HTTP/1.1 200 OK
[ { "FunctionalAccountID": 7, "PlatformID": 4,
    "DomainName": "tcs.local", "AccountName": "svc_psafe_rotate",
    "Description": "Rotation worker - never check out" } ]

Now the confusion that produces real outages: functional vs managed. Both live on the same screen family, both are privileged, and on a sleepy Friday someone — or an over-broad Smart Rule — onboards the functional account as a managed account. Password Safe then dutifully rotates the worker’s own password. But queued change jobs, and the platform’s stored copy of the FA credential, still hold the old secret. The docs’ warning is exact: functional accounts "have built-in management capabilities and passwords could fail to synchronize". Result: every rotation on that platform starts failing at once — the watchman’s own key was changed and nobody told him, so no lock in the building can be re-keyed.

③ The request lifecycle — request, approve, checkout, rotate

Password Safe gives users one of four roles: Requestor (may ask), Approver (may grant), Requestor/Approver (both — though never self-approving the same request in a sane design), and ISA — Information Systems Administrator, the power-user role that skips approval entirely. A request names the system, the account, a Reason (maximum 200 characters — auto-filled from defaults, like a gate-pass register entry) and a duration.

The numbers to memorise, because MCQs and capacity planning both use them: default ReleaseDuration is 120 minutes, the hard ceiling is 525,600 minutes — exactly one year; the ISA’s own default is also 120. After approval, Retrieve Password displays the value for a maximum of 20 seconds per click (viewable again any time during the release). Check in early and the release ends early. If the account has Change Password After Release enabled, check-in queues an immediate rotation — the password Sneha saw is dead minutes later, like an OYO room code that changes the moment a guest checks out. Scheduled rotation, independently, fires at ChangeTime 23:30 UTC by default.

Who else can hold the same credential at the same time? That is the exclusive vs concurrent decision, set per access type on the access policy. The schedule block for each access type — View Password, RDP, SSH, Application — carries its own fields: Approvers (how many must say yes), Auto Approve, Record session, Keystroke Logging, Concurrent (1 = exclusive, or more, or Unlimited) and Force Termination. Exclusive checkout means the second engineer waits — exactly like a library book already issued. Concurrent suits read-only service consoles; production root should almost always be exclusive, so the audit trail maps one human to one session.

The API mirrors the human flow one-for-one, which is why learning the portal teaches you the API for free: POST Auth/SignAppIn opens a session (state is kept between calls), POST Requests raises the request, GET Credentials/{requestId} retrieves the secret after approval, PUT Requests/{requestId}/Checkin releases it. The ISA shortcut is its own endpoint — POST ISARequests hands back the credential in one call, no approval. Think of the ISA as the senior doctor’s all-access hospital pass: reception (approvers) is for visitors.

# 1. sign in once - session state persists across calls
POST /BeyondTrust/api/public/v3/Auth/SignAppIn
Authorization: PS-Auth key=<128-char-key>; runas=icici\sneha.k;

# 2. raise the request (system 124, account 318, 120 minutes)
POST /BeyondTrust/api/public/v3/Requests
{ "SystemID": 124, "AccountID": 318, "DurationMinutes": 120,
  "Reason": "CHG0042117 - DB patch window" }

# 3. after approval: retrieve, work, then check in
GET /BeyondTrust/api/public/v3/Credentials/2231
PUT /BeyondTrust/api/public/v3/Requests/2231/Checkin

200 OK            (SignAppIn - session established)
201 Created  →  2231              (the request ID)
200 OK       →  "vR9!xK...Qq2#"   (the released password)
204 No Content                    (checked in - rotation queued)

④ Where credentials flow — reveal, proxy, API, and the road to cloud

A credential leaves the vault through one of three doors, and choosing the right door per consumer is real architecture work. Door 1 — portal reveal: the human reads the password (20-second display) and types it somewhere. Maximum exposure: it can be noted down, shoulder-surfed, keylogged. Door 2 — proxied session: the user connects to Password Safe’s session proxy — SSH on 4422, RDP on 4489 (session-monitoring listener on 4488) — authenticates as herself, and the proxy injects the managed credential into the connection. The admin never sees the password; there is nothing to leak, and the session is recorded. Door 3 — API retrieval: applications fetch secrets programmatically — which needs an API registration, Enable for API Access switched on for the account, and a Requestor or ISA role for the runas user. No human in the loop at all.

# pattern: ++@
ssh -p 4422 sneha.k+dbadmin@icici.local+db-prod-01@psafe.icicilab.local

sneha.k@psafe.icicilab.local’s password: ********
[Password Safe] approved request found - injecting credential for dbadmin
[Password Safe] session recording: ON (keystrokes logged)
dbadmin@db-prod-01:~$

Below the doors sits a routing layer you meet the day your deployment grows past one team: workgroups. Every managed system and account carries a WorkgroupID; worker nodes are assigned to workgroups so "a worker node only processes tasks for that group’s managed accounts". In multi-tenant builds each organization needs at least one worker node — and a worker node belongs to exactly one organization. Wipro running PAM-as-a-service for three clients = three organizations, three (or more) worker nodes, zero cross-tenant rotation traffic.

Finally, the question every firewall team asks about Password Safe Cloud: "what do we open inbound?" Answer: nothing. You install Resource Brokers on-prem; each dials outbound on 443 to your cloud site at <yoursite>.ps.beyondtrustcloud.com and pulls work down. A broker installs nine services covering the four local jobs: directory authentication, discovery, credential rotation and the session proxy. Brokers group into resource zones (the built-in Default zone cannot be edited; up to 50 more; 200 brokers max; run 2+ per zone for redundancy; 16 GB RAM minimum each). It is the Delhivery local-hub pattern: the warehouse (cloud) never enters your society — the hub inside the gate dials out to fetch jobs, and the gate stays closed inbound.