PRA Access Control: — Group Policies, Jump Item Roles, Schedules & Approvals

① The permission model — users, teams & Group Policies, the master control

In the last lesson Vault held the passwords and injected them. Today we climb to the control plane: who is even allowed to ask. PRA answers with four stacked objects, and the first is the Group Policy. Think of it as the HR-issued ID card at Infosys: HR does not configure each employee's gates one by one — your card GRADE decides which buildings open, and changing the grade changes them all at once.

Where do the people come from? Either local PRA users, or users mapped in from a Security Provider (AD, LDAPS, SAML) under /login > Users & Security > Security Providers. Group Policies live right beside them at /login > Users & Security > Group Policies — a policy bundles account settings (display name rules, password/2FA expectations, console permissions) plus memberships: which Jump Groups the member belongs to and with which Jump Item Role, which teams, and which default session policy. One AD security group mapped to one PRA group policy is the cleanest pattern you will see in real deployments at TCS or ICICI.

Now the part interviews love: precedence. A real user matches several group policies at once — Rahul is in AllStaff AND DBA-Admins. Each setting inside a group policy is individually defined, and as of recent versions, when two policies define the same setting, the policy higher in the group-policy precedence order wins. For Jump access specifically the rule is documented and exact — a specificity chain: a role assigned on the user↔Jump Group relationship beats a role from a group-policy↔Jump Group relationship, which beats the user's default Jump Item Role. Most specific wins; the default is only the fallback where nothing specific exists.

The four knobs you will turn every week

Tap each card — these four objects are the entire lesson. Everything else is detail.

② Jump Item Roles — view, start, edit, delete… scoped per Jump Group

The docs define a Jump Item Role as “a predefined set of permissions regarding Jump Item management and usage.” Three defaults ship with the product: Administrator (everything), Start Sessions Only (the vendor classic), and — new in version 25.2 — Auditor, which holds exactly one permission: View Reports. In the Pathfinder UI the same object is called an Asset Role; interviewers still say Jump Item Role, so learn both.

Open a role and you see the real permission checkboxes: Create new Assets or upgrade Jump Clients · Move and Copy Assets · Remove existing Assets · View Session and Asset Reports · Start Sessions · Edit Tag · Edit Comments · Edit Asset Policy · Edit Session Policy · Edit Connectivity and Authentication · Edit Behavior and Experience. One trap to defuse now: Move and Copy Assets moves Jump Items between Jump Groups — it has nothing to do with copying files off a server. File movement is a Gate-4 (session policy) matter, and confusing the two is a classic interview slip.

The classic build: vendor sees ONLY their 3 servers

Meera's company supports exactly three ICICI database servers — and must never see anything else. Four steps. Step 1 — make the wing: create Jump Group vendor-dbsupport at /login > Asset Management > Asset Groups (classic: under the Jump menu). A Jump Group is a society wing: your gate pass works for A-wing only. Step 2 — move the flats in: put the three Jump Items (Remote RDP shortcuts to 172.16.40.11, .12, .13) into that group — your own account needs Move and Copy Assets for this. Step 3 — make the pass: create the group policy Vendor-DBSupport, membership = Meera's vendor users (local or via a Security Provider). Step 4 — scope the role: inside that policy grant Start Sessions Only on vendor-dbsupport — and ONLY there — leaving the default role granting nothing.

Why so paranoid about the default? Because of the specificity chain from section ①: the default role applies on every Jump Group that has no explicit assignment. A permissive default is an estate-wide grant nobody remembers making — the hotel that stamps EVERY floor onto a visitor's keycard and then wonders how the guest reached the server room. Also worth knowing: PRA ships a dedicated Users & Security > Vendors page for full vendor-group onboarding flows — but the Jump-Group + scoped-role pattern here is the mechanism underneath, and it is what interviews probe.

③ Jump Policies — schedules, ticket IDs & approval workflows

Meera can now see her 3 servers — but ICICI's contract says: business hours only, every session tied to a change ticket, and the NOC notified. That is Gate 3: the Jump Policy (Pathfinder: Asset Policy), created at /login > Asset Management > Asset Policies (classic: under the Jump menu) and then attached per Jump Item or per Jump Group. Each policy carries a Display Name, a Code Name (auto-generated if blank — you will meet it again in the API below), and a description.

First gate inside the policy: the Jump Schedule — a timezone plus start/end day-time entries, like a society's visiting hours board: visitors 10:00–18:00, watchman turns you away at 20:05 no matter how friendly you are. The optional checkbox “Force session to end when schedule does not permit access” is the strict version: a session running past the window is disconnected — with 15-minute warnings beforehand, so Meera's half-finished database patch is not killed without notice.

Second gate: Jump Approval — “Require approval before a session starts.” The requester submits a reason, a requested start time and duration; the policy's approvers get an email and answer; an approved request opens a time-boxed grant capped by the policy's Maximum access duration. It is the bank locker with two keys: your key (the request) opens nothing until the bank officer (approver) turns theirs — and the locker room closes again after the visit. One more option matters operationally: the policy decides whether only the requestor may use an approval, or any user permitted on that Jump Item may ride the same window. And the rule everyone trips on: a schedule and an approval cannot both be enabled on the same policy — the console rejects it. Deterministic window or human gate: pick one per policy, build two policies if you need both behaviours.

Three more switches finish the policy. “Require a ticket ID before a session starts” makes PRA demand a ticket number and check it against your ITSM integration — the society gate-pass slip: no slip number in the register, no entry. A per-policy 2FA challenge can force re-authentication right before the Jump. And Jump Notification emails fire at session start and/or end — Karthik's NOC at Airtel gets a mail the second a vendor session opens, which converts “vendor was in the system silently for 3 hours” from an incident-report sentence into an impossibility. There is also a Disable Recordings override on the policy — leave it alone unless legal forces your hand; lesson 14 shows what audits look like without recordings.

Trust, but verify with the API. Every Jump Policy you click together is readable (and writable) through the PRA Configuration API — enable a client at /login > Management > API Configuration, fetch a token, then list the policies. This is also how you catch drift between what the runbook says and what the appliance really enforces.

curl -s -X POST https://pra.icicilab.in/oauth2/token \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d "grant_type=client_credentials"

{
  "access_token": "eyJhbGciOiJSUzI1NiIs…",
  "token_type": "Bearer",
  "expires_in": 3600
}

curl -s https://pra.icicilab.in/api/config/v1/jump-policy \
  -H "Authorization: Bearer $TOKEN" \
  | jq '.[] | select(.code_name=="vendor_bizhours")'

{
  "id": 7,
  "display_name": "Vendor-BizHours",
  "code_name": "vendor_bizhours",
  "schedule_enabled": true,
  "ticket_id_required": true
}

④ Session policies — what happens INSIDE, and the four-layer map

The session has started — legitimately. Gate 4 decides what the user's hands may do now. A session policy lives at /login > Users & Security > Session Policies and governs the in-session toolset: screen sharing behaviour, file transfer (and which direction), clipboard use, command shell access and similar controls. It attaches in two places: to people (via the group policy from Gate 1) and to targets — per Jump Item. That second path is exactly why the Jump Item Role has an Edit Session Policy checkbox: items carry their own session policy, and changing it is itself a guarded permission. Think valet key: the valet can start and park your car, but the same key refuses to open the boot.

For Shell Jump targets — Karthik's routers at Airtel, reached over SSH through a Jumpoint — there is a sharper tool: command filtering. As of recent versions you define allowed/blocked command patterns for Shell Jump sessions, so a vendor's rm -rf or a curious show running-config | include password is stopped at the proxy before it ever reaches the device, and the attempt lands in the session log. Combine it with the recording and you have both prevention AND evidence — the CCTV does not stop the thief; the locked counter does.

Why so much ceremony around the inside of a session? Because attackers think in layers too. In May 2025 BeyondTrust published advisory BT25-03 (CVE-2025-0217, CVSS 4.0 = 7.3): a local authentication bypass in PRA that let a local authenticated attacker view Shell Jump session connection details and access connected sessions without authorization — fixed in PRA 25.1. A patched appliance closed the hole; layered session controls and recordings are what told affected teams whether anything had actually been touched. The full CVE story — including the December 2024 Treasury incident — is the next lesson.

Layer all four on one target — then prove it

Meera's finished stack on 172.16.40.11 reads like a sentence: the group policy says she exists and sees one Jump Group; the Jump Item Role (Start Sessions Only) says she may start sessions and nothing else; the Jump Policy (vendor_bizhours) says only Mon–Sat 10:00–18:00 IST with a valid ticket, force-ended outside the window, NOC notified; the session policy says no files, no clipboard, filtered commands, recording on. Four objects, four screens, one defensible answer to the auditor's favourite question: “what exactly could the vendor do?”