PAM-DEF Practice Questions

The user account configured for Windows Discovery in CyberArk performs a scan of the Active Directory environment to identify computer objects. This is a read-only operation that queries the directory service. To adhere to the principle of least privilege, the discovery user only requires permissions to read the directory. Standard "Domain User" accounts in Active Directory possess sufficient read permissions by default to enumerate objects within the domain, making them suitable for this task without granting excessive privileges.

A. Domain Admin membership grants excessive privileges, including write and delete capabilities, which are unnecessary and a security risk for a discovery-only account.

B. There is no standard, built-in "LDAP Admin Group" in Active Directory, and administrative-level permissions are not required for discovery.

C. Write permissions are not needed for the discovery process, which only reads information from Active Directory, not modifies it.

1. CyberArk Privileged Access Manager - Self-Hosted Documentation (Version 14.0). Section: Administration > Managing automatic onboarding and discovery > Discovery and onboarding processes > Windows discovery. Under the subsection "Permissions for the discovery user

" it states

"The discovery user requires read permissions for the domains that will be scanned. By default

a domain user has read permissions for the domain."

2. CyberArk Privileged Access Manager - Self-Hosted Documentation (Version 13.2). Section: Installation > Post-Installation > Accounts Discovery > Configure accounts discovery > Windows discovery. The "Permissions for the discovery user" section specifies

"The discovery user requires read permissions for the domains that will be scanned."

In CyberArk, platforms define the management policies and connection methods for accounts. To enable a specific connection method, the corresponding Connection Component must be associated with the platform. For SSH connections initiated from the PVWA (web interface), the PSM-SSH component is required. For direct SSH connections from a native client, the PSMP-SSH component is necessary. To allow a user to connect to the same Unix account using either method, the platform managing that account must have both the PSM-SSH and PSMP-SSH connection components configured and active.

B. SSH fingerprint storage is a host key verification security feature to prevent man-in-the-middle attacks, not the primary configuration step to enable the connection methods.

C. In modern CyberArk versions, enabling PSMP for a platform is achieved by adding the PSMP-SSH connection component, not by a simple 'Enable PSMP' toggle.

D. Creating a duplicate platform is incorrect and inefficient. Both connection components can and should be configured on the single, authoritative platform managing the account.

1. CyberArk Privileged Access Security Documentation v12.6

"Connect through PSM for SSH"

Section: "Configure the PSM for SSH connection component".

This section explicitly states: "To enable users to connect to target machines through PSM for SSH

you must add the PSM for SSH connection component to the relevant platforms." It then details the procedure for adding the PSMP-SSH component.

2. CyberArk Privileged Access Security Documentation v12.6

"Platform Management"

Section: "Connection Components".

This document explains the core concept: "Connection components are the part of the platform that enables users to connect to remote machines... To enable users to connect with a particular account

the relevant connection component must be configured in the platform that manages the account." This principle applies to both PSM-SSH and PSMP-SSH.

3. CyberArk Privileged Access Security Documentation v12.6

"Privileged Session Management"

Section: "Configure PSM".

This section describes the general configuration for PSM

including the requirement to associate connection components like PSM-SSH with platforms to enable connections through the PVWA interface.

The question asks how to configure the CPM to use a reconcile account for a password change when the target account itself lacks the permissions to change its own password. The parameter ChangePasswordInResetMode (option B contains a common typo, "Made" instead of "Mode") directly addresses this scenario. When ChangePasswordInResetMode is set to Yes, it instructs the CPM to perform the standard 'Change' operation by using the associated reconcile account to log in and reset the password, rather than logging in as the target account. This effectively replaces the 'change' action with a 'reset' action, fulfilling the requirement.

A. Set the parameter RCAllowManualReconciliation to Yes.

This parameter only enables users with appropriate permissions to manually trigger a reconciliation from the PVWA interface; it does not affect automatic password management processes.

C. Set the parameter IgnoreReconcileOnMissingAccount to No.

This parameter triggers a reconcile action only if a change or verification fails because the account is not found on the target system, which is a different scenario.

D. Set the UnlockUserOnReconcile to Yes.

This parameter instructs the CPM to attempt to unlock a locked account during a reconcile process; it does not trigger the reconcile or alter the change process.

1. CyberArk Privileged Access Manager Documentation - v12.6

"Platforms - Password Change":

Section: Platform Properties > Automatic Password Management > Password Change

Parameter: ChangePasswordInResetMode

Content: "Whether the CPM changes the password in reset mode or by logging on to the remote machine with the password's user.

Yes – The CPM uses the reconcile account to log on to the remote machine and change the password of the required account.

No – The CPM logs on to the remote machine with the password's user and then changes the password.

This parameter is used for accounts that do not have permission to change their own passwords."

This directly confirms that setting this parameter to 'Yes' achieves the exact outcome described in the question.

2. CyberArk Privileged Access Manager Documentation - v12.6

"Platforms - Password Reconciliation":

Section: Platform Properties > Automatic Password Management > Password Reconciliation

Parameter: RCAllowManualReconciliation

Content: "Whether or not users who have the appropriate permissions on an account can initiate a reconcile action manually."

This confirms that option A is for manual actions only.

The component log file locations are based on their default installation directories and operational frameworks.

• The PTA (Privileged Threat Analytics) System runs as a web application on an Apache Tomcat server, which stores its primary log files in the /opt/tomcat/logs directory.
• PSM for SSH (PSMP) is a dedicated Linux component, and its log files are stored in a specific directory created during installation, /var/opt/CARKpsmp/logs/.
• The Disaster Recovery component on the Vault server uses the PrivateArk Disaster Recovery (PADR) utility. The logs for this service, such as padr.log, are located by default in its installation folder, C:\Program Files (x86)\PrivateArk\Server\PADR.

CyberArk Privileged Threat Analytics Documentation, "PTA Logs," Section: Troubleshooting PTA.

Quote/Paraphrase: The main PTA log files are located in /opt/tomcat/logs/. This directory contains logs such as diamond.log, pta.log, and catalina.out.

CyberArk Privileged Session Manager for SSH Documentation, "PSMP Log Files," Section: Troubleshooting PSMP.

Quote/Paraphrase: "PSMP log files are created in /var/opt/CARKpsmp/logs." This section details the various logs found in this directory, including console logs and trace files for troubleshooting PSMP sessions.

CyberArk Privileged Access Security Documentation, "Troubleshoot the PADR service," Section: Vault Disaster Recovery.

Quote/Paraphrase: The PADR.log file, which contains information about the Disaster Recovery service activities, is located by default in C:\Program Files (x86)\PrivateArk\Server\PADR.

The question requires matching predefined CyberArk Vault users to their specific roles and permissions.

• The Master user is the ultimate superuser with all possible permissions, including the management of all other users, aligning with the first description.
• The Auditor user has system-wide, non-intrusive monitoring and reporting capabilities, matching the description of a user who views all activities to produce reports.
• The Batch user is a non-interactive internal account used for automated, background system tasks like clearing history, as described.
• The Administrator user holds high-level system control and recovery responsibilities and cannot be removed from Safes, fitting the final description. This user has extensive permissions but not the absolute power of the Master user.

CyberArk Privileged Access Security System, Version 12.6, "Privileged Access Security Implementation Guide":

Master User: Section: "The Master User", Page 18 states, "The Master user has the highest level of authority in the system and can perform any task." It also notes the Master user can "add, delete, and manage all users in the Vault."

Administrator User: Section: "The Administrator User", Page 19 describes, "The Administrator user has complete system control... This user is responsible for the overall function of the system and manages a full system recovery when necessary."

Auditor Users: Section: "Auditor Users", Page 20 explains, "Auditor users can see all activity in the entire system... They generate reports about user and Safe activities..."

Batch User: Section: "The Batch User", Page 20 clarifies, "The Batch user is an internal user that carries out internal tasks, such as automatically clearing expired user and Safe history."

For a user or group to act as an approver in a Dual Control workflow, they require two specific permissions. First, they need the "List accounts" permission to see the accounts within the Safe and view pending requests associated with them. Second, they must have the "Authorize account request" permission, which explicitly grants them the ability to approve or deny those requests. The approver's role is strictly to authorize access for another user; they do not need the ability to retrieve the credentials themselves.

B: "Retrieve accounts" is for the requester, not the approver. "Access Safe without confirmation" is a separate workflow for Safe-level access, not account-level requests.

C: The "Retrieve accounts" permission is incorrect for an approver. This permission allows a user to access the credential, which is the requester's role after approval.

D: The "Unlock accounts" permission is for manually releasing an account locked by the CPM, which is a separate administrative task unrelated to the Dual Control approval workflow.

1. CyberArk Privileged Access Manager - Self-Hosted Documentation v12.6

"Add a Safe member". This section details the specific Safe member authorizations.

List accounts: "View accounts and files in the Safe." This is required for the approver to see the request.

Authorize account request: "Authorize requests for account access made by other users." This is the explicit permission for the approver role.

Retrieve accounts: "Retrieve and view accounts and files in the Safe." This permission is designated for the user who will ultimately use the account after approval.

2. CyberArk Privileged Access Manager - Self-Hosted Documentation v12.6

"Enforce dual control for password access". This document describes the workflow

clarifying that the user who confirms the request (the approver) is distinct from the user who retrieves the password (the requester). The approver's permissions are limited to authorization

not retrieval.

Generating the "Entitlement Report" in PVWA requires two distinct Vault-level authorizations. First, to access the main "Reports" page, a user needs the View Audit authorization. Second, to specifically generate the "Entitlement Report" from that page, the user requires the Audit Users authorization.

Option (B) Audit Users is explicitly required per official documentation.

Option (D) View Entitlements, while not an official authorization name, serves as the most logical proxy for the required View Audit permission, which is not listed as an option. The report's purpose is to view entitlements, making this the best-fitting choice for the prerequisite viewing permission.

A. Manage Users: This is an excessive administrative authorization and is not the minimum permission required to generate audit reports.

C. Read Activity: This is not a standard, documented Vault-level authorization within the CyberArk PAM solution.

E. List Accounts: This is a Safe-level permission that allows viewing accounts within a specific Safe, not a Vault-level authorization for generating cross-Safe entitlement reports.

1. CyberArk Privileged Access Manager - Self-Hosted Documentation (v13.2)

"Generate reports in the PVWA".

Section: Reports page: "To view the Reports page

users require the View Audit user authorization in the Vault."

Section: Entitlements report: "Required authorizations: Audit users"

This documentation confirms the two required permissions are 'View Audit' and 'Audit Users'

supporting the selection of (B) and the interpretation of (D) as a proxy for 'View Audit'.

2. CyberArk Privileged Access Manager - Self-Hosted Documentation (v13.2)

"User and Group Authorizations".

Section: Vault authorizations: This section provides a comprehensive list of all standard Vault-level authorizations. The list includes 'Audit Users' and 'View Audit' but does not include 'View Entitlements' or 'Read Activity'

confirming they are not official authorization names. This supports the reasoning for excluding option (C).

The configuration for LDAP integration, including the directory hosts and the specific port used for communication, is managed within the PVWA interface. An administrator can verify that the binding is configured to use TCP/636 (LDAPS) by navigating to the LDAP Integration settings, selecting the relevant directory, and inspecting the "Host" details. This section explicitly contains the IP/hostname and the port number for the connection to the domain controller.

A. This configuration path does not exist in Active Directory. CyberArk's LDAP binding configuration is stored within the CyberArk Vault, not in AD object properties.

C. LDAP Directory Mapping is configured through the PVWA web interface, not the PrivateArk Client, which is used for core Vault administration tasks.

D. Test-NetConnection is a PowerShell command used to test network connectivity from the PVWA server. It can confirm if a port is open but does not show how CyberArk is configured to use that port.

1. CyberArk Privileged Access Manager - Self-Hosted Documentation v14.0. "Configure LDAP integration". In the "Define directory hosts" step

the documentation states: "In the Host details area

in Port

specify the port number that is used to connect to the directory host. The default port is 389 for LDAP and 636 for LDAPS." This confirms the setting is located under the Host configuration in the PVWA's LDAP Integration section.

2. CyberArk Privileged Access Manager - Self-Hosted Documentation v13.2. "LDAP Integration". The procedure outlines the navigation path: "In the PVWA

click the Administration button

and then click LDAP Integration... In the Directories tab

select the directory to configure... In the Hosts tab

click Add host... In the Host details area

in Port

specify the port number...". This directly corresponds to the path described in option B.

A CyberArk platform dictates how the Privileged Session Manager (PSM) connects to a target system. For a Linux endpoint, the standard connection protocol is SSH. The PSM-SSH Connection Component is the specific module that the PSM uses to initiate and manage this type of session. If this component is not associated with the platform, the PSM does not know how to handle the connection request from the PVWA. As a result, when a user clicks the "Connect" button, the action fails without initiating a session, which manifests as "nothing happens."

B. UnixPrompts.ini: This is a Central Policy Manager (CPM) configuration file that defines expected command prompts for password management operations on Unix/Linux systems, not for user session connections.

C. UnixProcess.ini: This is a Central Policy Manager (CPM) file that defines the sequence of commands for password management processes (e.g., verify, change, reconcile) on Unix/Linux systems.

D. PSM-RDP Connection Component: This component is used for establishing connections to Windows systems via the Remote Desktop Protocol (RDP), not for connecting to Linux endpoints which typically use SSH.

1. CyberArk Privileged Access Manager Documentation - Self-Hosted v12.6: "Platforms and service account platforms" > "Target Account Platforms" > "Connection Components".

Section: Connection Components

Content: This section explicitly states

"Connection Components are the PSM connectors that can be used to connect to remote machines." It lists PSM-SSH as the out-of-the-box component for connecting to Unix systems. This confirms that a connection component is required for the "Connect" button to function.

2. CyberArk Privileged Access Manager Documentation - Self-Hosted v12.6: "Privileged Session Manager" > "Configure PSM" > "Connection Components" > "PSM-SSH".

Section: Configure the PSM-SSH connection component

Content: The documentation details that "The PSM-SSH connection component enables PSM to securely connect to SSH-based systems...". This directly links the PSM-SSH component to connecting to Linux/Unix endpoints.

3. CyberArk Privileged Access Manager Documentation - Self-Hosted v12.6: "Central Policy Manager" > "CPM plugins" > "Developing CPM plugins".

Section: Process and Prompts files

Content: This section describes the function of the Process.ini and Prompts.ini files

clarifying their role in CPM's password management workflows

which is distinct from PSM's session initiation. This supports why options B and C are incorrect.

The Master Policy in CyberArk Privileged Access Manager (PAM) is designed to enforce high-level, global security and compliance rules across the entire environment. It governs principles such as session recording, dual control, and exclusive access. It does not manage operational or platform-specific configurations.

A Logon Account is an operational component used by the Central Policy Manager (CPM) to connect to a target machine to perform password management tasks (e.g., change, verify). The specification of which Logon Account to use is a configuration detail defined at the Platform level, not within the Master Policy. Each platform is configured with the specific technical details required to manage accounts on that type of target system, including the assignment of Logon and Reconcile accounts.

The statement "True" is incorrect because it confuses the distinct roles of the Master Policy and the Platform. The Master Policy sets the strategic security requirements (the "what"), while the Platform defines the tactical implementation for a specific target type (the "how"), which includes assigning a Logon Account.

1. CyberArk Privileged Access Manager - Self-Hosted Documentation - "Master Policy": This section details the settings available in the Master Policy. The configurable rules include Enforce check-in/check-out exclusive access

Require dual control password access approval

and Enforce session recording and monitoring. The documentation makes no mention of specifying operational accounts like Logon Accounts

as this is outside its scope.

Reference: CyberArk Privileged Access Manager - Self-Hosted Documentation

Version 14.0

"Master Policy

" section "Default Policy Rules."

2. CyberArk Privileged Access Manager - Self-Hosted Documentation - "Platform Management": This documentation explicitly describes how Logon and Reconcile accounts are configured within a specific platform's settings. It shows that these accounts are properties of a platform

which is then applied to managed accounts.

Reference: CyberArk Privileged Access Manager - Self-Hosted Documentation

Version 14.0

"Platforms

" section "Edit a platform

" subsection "Automatic Password Management > Logon Account." This page details the procedure for associating a Logon Account with a platform.