8.4 Split Workflow: Separating Session Use from Credential Retrieval

8.4 Split Workflow: Separating Session Use from Credential Retrieval

Quick Answer: A split workflow divides the user population by what they are allowed to do with a credential rather than by which Safe they can see. The operator population receives List accounts + Use accounts, which lets them click Connect and be brokered into a recorded PSM session while the secret is never displayed. A much smaller break-glass population additionally receives Retrieve accounts, which exposes Show and Copy and is the only way to log on to a target through a non-PSM connection. Getting this split right is what makes "nobody knows the production root password" operationally true rather than aspirational.

---

The Permission Semantics That Make the Split Possible

CyberArk's Safe member permissions are not a single ladder of increasing trust; Use accounts and Retrieve accounts are deliberately separable. The documented behaviour is precise, and the exam tests the boundary:

Read the last row carefully. A user holding List + Use can start a brokered PSM session all day and never see a character of the password. The moment that user needs to launch a native RDP or PuTTY client directly against the target — bypassing PSM — Retrieve accounts becomes mandatory. That single sentence is the entire mechanical basis of the split workflow, and exam items phrase it as scenarios: "the user can connect through PSM but the Show button is greyed out — which permission is missing?"

---

Designing the Two Populations

A working split workflow assigns two distinct Safe member profiles against the same Safe:

Population A — Operators (the default, and the overwhelming majority).

• Permissions: List accounts, Use accounts.
• Experience: they see the account, click Connect, and land in an isolated, recorded PSM session.
• Security property: the credential never reaches their workstation, their clipboard, or their memory. Credential theft malware on the operator endpoint has nothing to harvest, because the PSM server — not the operator's machine — holds the secret.
• Audit property: every action produces a session recording in the recordings Safe, not merely a "password retrieved" line.

Population B — Break-glass / native-tooling users (a named handful).

• Permissions: List accounts, Use accounts, Retrieve accounts.
• Justification: legitimate cases exist — a PSM outage, a connection component that does not yet exist for an exotic appliance, or a vendor tool that must consume the credential directly.
• Controls: pair the extra permission with dual control approval, exclusive access and one-time password behaviour (sections 6.2 and 6.3), and a requirement that the user supply a reason. The retrieval itself then becomes a high-signal audit event that a SIEM rule can alert on, precisely because it is rare.

---

Reinforcing the Split Above the Safe Layer

Safe permissions alone describe what a user may do. Two layers above them decide what the platform offers:

• Master Policy. Require privileged session monitoring and isolation set to Active mandates that connections traverse the PSM proxy rather than running natively from the endpoint. Combined with the recording rules covered in chapter 7, it converts the split from a permission convention into an enforced architecture.
• Platform configuration. The account's platform must have a matching connection component configured under UI & Workflows → Privileged Session Management, otherwise the Connect button has nothing to launch and the operator population is stranded with a permission they cannot exercise. DisableDualControlForPSMConnections is the related parameter that lets PSM initiate a connection without confirmation even when the Safe enforces dual control — useful, but it weakens the approval half of the workflow and should be a deliberate exception.

A split workflow therefore fails in one of two directions, and the exam likes both failure modes:

1. Too permissive: Retrieve accounts granted to everyone "so they can work," which silently collapses the split — users bypass PSM, and recordings stop reflecting reality.
2. Too restrictive: Use accounts granted but no connection component configured on the platform, so the Connect button never appears and users escalate for Retrieve accounts as a workaround, producing exactly the outcome the design was meant to prevent.

---

Do Not Confuse Split Workflow with Split Password Mode

Two similarly named ideas are routinely mixed up:

Split workflow is about who may see a secret versus who may merely use it. Split password mode is about nobody holding a complete secret. Dual control is about approval. An exam item that describes "users can connect but cannot view the password" is describing the split workflow, not dual control and not split password mode.

---

Verifying a Split Workflow

After configuration, validate it empirically rather than by reading the permission matrix:

1. Log on to the PVWA as a Population A test user. The account appears in the list; Connect is available; Show and Copy are not offered.
2. Launch the connection. Confirm a recording is produced in the recordings Safe under the identity of the test user.
3. Attempt a native connection to the same target using credentials the user could plausibly obtain. It must fail, because the user never received the secret.
4. Log on as a Population B test user, retrieve the credential, and confirm the retrieval is captured as a distinct audit event in the Safe activity log — the signal your monitoring should be alerting on.