CyberArk CDE (CAU302) cheat sheet

Onboarding paths: manual account creation, automatic detection via discovery/scanning, and bulk import through a CSV or the Accounts Feed; each path lands in the same account object model.

Required fields for a local account: safe name, platform ID, address, username, and either a password or SSH key secret; missing platform or address blocks CPM management.

Account object key attributes: address, username, platformId, safeName, secretType, enableAutoMgmt, manualManagementReason, and status (password change in progress, success, failure).

Verification vs. change: 'verify' only tests the current credential against the target; 'change' sets a new random or reconciled password. Verify frequency is typically set shorter than change frequency.

Reconcile accounts exist so that a dependent account (e.g., Windows service, scheduled task, COM+ app) is updated after its parent account password changes; reconcile accounts are linked to a single parent.

Dual control and exclusive access are account-level policies: dual control requires two authorized users to approve a retrieval or change; exclusive access locks the account to one user for the session.

Dependent/platform-linked accounts must be onboarded before the parent password is rotated, otherwise services fail on the next change cycle.

Account deletion from a safe removes CPM management; the underlying target credential is not reverted, so rotate or document the credential before removal.

Automatic management can be disabled per account (enableAutoMgmt=false) with a mandatory reason; such accounts show as unmanaged and are skipped by CPM.

Safe member authorization levels, lowest to highest: Use accounts, Retrieve accounts, List accounts, Add accounts, Update account properties, Initiate CPM account management operations, Specify next account content, Rename accounts, Delete accounts, Manage safe, Manage safe members.

Authorizations are additive at the member level and inherited from the safe; a user's effective rights are the union of rights granted directly and through groups.

Safe member types: User, Group, Role; roles are reusable permission bundles applied to multiple safes and are the recommended way to standardize access.

Safe properties that gate behavior: Require dual control password access approval, Require reason for access, Require users to confirm password, Enforce exclusive access, and Enable password retention.

Retention rules: 'Retain period' keeps previous versions for a number of days; 'Retain versions' keeps a count of prior passwords; both are configured per safe and govern whether old credentials can be retrieved.

Object-level restrictions: a safe can be limited to specific platforms or to accounts matching a filter, and can be marked as an object-level access control safe to allow per-account permissions.

Deleting a safe does not delete accounts automatically unless confirmed; accounts in a deleted safe become unreachable, so move or export them first.

CPM user must be a member of the safe with the relevant CPM authorizations, otherwise password changes fail with a permissions error.

Platform components: UI/connection settings, automatic password management policy (change/verify schedules, interval, retries), password reconciliation, and the platform's associated connection components.

Platform base types include Windows, Unix, Oracle, MSSQL, MySQL, DB2, Sybase, SAP, and generic; a custom platform is usually cloned from the closest base and edited rather than built from scratch.

CPM change policy fields: 'Change password every N days', 'retry' count and interval, 'Immediate interval' for first change after onboarding, and 'Verify' schedule independent of the change schedule.

Password generation rules are defined per platform (length, character sets, excluded characters, allowed special characters) and are enforced on change and reconcile.

The CPM service account must be able to log on to the target and must hold the platform's required privileges (e.g., local admin or domain rights for Windows, DBA rights for databases).

Platform 'Privileged Account' settings define which account the CPM uses to perform changes; using the account's own credential versus a separate logon account changes the change flow.

Connection components (PSM) are attached to platforms; a platform with no connection component can still be CPM-managed but cannot be used for PSM sessions.

After editing a platform, changes apply to accounts at their next CPM cycle; to force immediate effect, trigger a manual 'Change' or 'Verify' on the account.

PSM session flow: user authenticates to PVWA, requests connection, PSM establishes the connection through the relevant Connection Component, and the session is recorded and audited.

Connection Component types include RDP, SSH, Telnet, AS400, DB (Oracle, MSSQL), Web, and app-based connectors; each maps to a specific platform and client.

PSM recording options: record entire session, record only keystrokes, or no recording; recordings are stored in the configured PSM storage and referenced from the session audit.

PSM for Windows requires the PSM server to be a hardened jump host; PSM for SSH (PSMP) runs on a Linux host and proxies SSH sessions without RDP.

Session limits are set by policy: maximum session duration, idle disconnect, and concurrent session limits; these are enforced by the PSM/PSMP.

Live session monitoring allows an authorized user to view an active session and, if permitted, terminate it; this requires the 'Monitor users' or equivalent administrative authorization.

Session isolation and 'Connect through PSM' settings determine whether users can bypass the PSM; bypass must be blocked for auditing to be trustworthy.

PSM gateway and remote access configurations must match the network path; a misconfigured PSM address is the most common cause of 'connection failed' on session launch.

Authentication methods: CyberArk password, LDAP/Active Directory, RADIUS, SAML, PKI/certificate, and multifactor (MFA) as a second factor; each is configured per directory or per authentication profile.

Authorization model: users -> groups -> roles -> safes -> accounts; effective permissions are the union of all paths, so removing a user from a group may still leave access via another group.

Vault-level authorizations (e.g., add/delete users, manage directories, audit) are separate from safe-level authorizations and are granted through the Master policy or admin roles.

Master policy governs global settings: session recording, dual control, exclusive access, password change rules, and authentication requirements; it applies unless a safe-level exception exists.

Least privilege: grant safe membership to groups rather than individual users, and prefer roles over direct user permissions to simplify audits and offboarding.

MFA enforcement can be set for specific users, groups, or directories; a common failure is MFA required at the directory level while the user is authenticating to a different directory.

Password replay and 'connect' rights require both the safe authorization and a valid platform connection component; missing either yields an authorization error, not a connection error.

Session and access reviews should reconcile group membership against the identity provider; orphaned accounts in the vault are a frequent audit finding.

Audit records are written for every action: authentication, safe/account changes, password retrievals, CPM operations, and PSM session start/stop; each record includes user, source IP, target, and timestamp.

Reports are available in PVWA (Reports) and via the REST API; common reports include privileged account inventory, safe membership, activity logs, and compliance/audit reports.

The Vault audit log is stored in the vault and can be exported; SIEM integration typically uses syslog or the REST API to forward records.

CPM operation status is visible per account (success, failure, reason); a failed change should be triaged with the CPM log, not just the PVWA status.

Session recordings and keystroke logs are evidence artifacts; retention period for recordings is configured at the PSM/recording level, not in the safe.

Health monitoring: the System Health page shows component status (Vault, CPM, PSM, PVWA); alerts can be configured for component failures and CPM errors.

Audit retention and archiving must satisfy the organization's compliance window; purging audit data before that window is a compliance violation.

Report scheduling allows periodic delivery; reports run against the vault and can be scoped by safe, user, or account to limit noise.

CPM password change failure triage order: check account status/reason, verify CPM user safe permissions, verify the platform's logon account and privileges, then check network/firewall to the target.

'Verify' failing while 'change' succeeds usually indicates the platform's verification method or the target account lockout policy differs from the change path.

PSM session failure triage: confirm the PSM server is reachable, the connection component matches the platform, the PSM user has 'connect' rights, and the target host is reachable from the PSM.

Common vault errors: 'user is not authorized' (safe membership/authorization), 'account is locked' (dual control or exclusive access held by another user), and 'authentication failed' (directory/MFA mismatch).

Service account lockouts and expired CPM credentials cause mass change failures; monitor the CPM service account and rotate it before expiry.

Backup/restore and DR: the vault must be backed up with the correct procedure; restoring a vault requires the same version and the recovery keys.

Routine operations: review failed CPM operations daily, reconcile orphaned accounts, audit safe membership quarterly, and test PSM connectivity after network changes.

Log collection: CPM logs, PSM logs, and Vault audit logs are the primary sources; correlate timestamps across components when diagnosing a single failed operation.