4.1 CPM Service Architecture, Logs & Multi-CPM Load Distribution

4.1 CPM Service Architecture, Logs & Multi-CPM Load Distribution

Quick Answer: The Central Policy Manager (CPM) is the automated credential management engine of CyberArk Privileged Access Manager (PAM). It runs on Windows Server as two primary services: CyberArk Password Manager (credential lifecycle execution) and CyberArk Central Policy Manager Scanner (account discovery). The CPM polls the Digital Vault over TCP port 1858 using dedicated service accounts (PasswordManager and PasswordManager_Workspace). Workload distribution and network segmentation across multiple CPMs are governed strictly at the Safe level using the ManagingCPM attribute, ensuring that only a single active CPM manages accounts in any given Safe to eliminate race conditions.

---

CPM Architecture & Windows Service Framework

The Central Policy Manager (CPM) is the active operational component in the CyberArk Privileged Access Security suite tasked with enforcing password policies across enterprise endpoints. While the Digital Vault acts as a passive repository and Password Vault Web Access (PVWA) serves as the presentation interface, the CPM actively provisions, changes, verifies, and reconciles credentials directly on target systems.

The CPM operates as two distinct background Windows services on a hardened Windows Server instance:

1. CyberArk Password Manager (PasswordManager.exe): The primary service responsible for periodic credential management. It executes the core lifecycle tasks—verification, password rotation, and administrative reconciliation—by invoking protocol-specific plug-ins. It operates on an asynchronous polling cycle, pulling work orders from assigned Safes in the Vault over TCP port 1858.
2. CyberArk Central Policy Manager Scanner (CACCPMScanner.exe): The automated account discovery engine. It executes discovery tasks to locate unmanaged accounts, SSH keys, and Windows service dependencies across the network, uploading discovered assets to the Vault's PasswordManager_Pending Safe for administrative review and onboarding.

Both services are configured with automatic startup (Startup type: Automatic) and recover automatically from system restarts. They run under the local Windows system context (Local System or dedicated local service accounts configured during installation), while maintaining their own cryptographic identities for interacting with the Digital Vault.

---

CPM Service Identities & Vault Authentication

The CPM does not use generic administrative credentials to authenticate to the Digital Vault. During deployment, the installation utility creates two specialized Vault user identities tailored for least-privilege operations:

• PasswordManager: The primary operational identity assigned to the CPM instance. When the CPM polls the Vault for queued tasks, retrieves account passwords, or updates rotated secrets, it acts as this user. In multi-CPM architectures, subsequent CPM installations create uniquely named identities (such as PasswordManager_DMZ or PasswordManager2).
• PasswordManager_Workspace: An auxiliary internal identity used by the CPM engine to manage temporary objects, query account properties, and manipulate staging data during intensive safe search operations.

Vault Permissions & Credential Files

For the CPM to manage accounts within a Safe, the PasswordManager user must be granted specific Safe authorizations:

• Manage Safe (to update safe-level operational flags)
• Access Safe without confirmation (to bypass dual-control authorizations during automated tasks)
• View Audit and List Accounts
• Add/Update Accounts and Delete Accounts (for rotation and version creation)
• Unlock Accounts and Initiate CPM account management operations

Authentication to the Vault is achieved using encrypted credential files:

• user.ini: Houses the encrypted authentication token for PasswordManager.
• workspaceuser.ini: Houses the encrypted authentication token for PasswordManager_Workspace.

These files are protected by local host entropy using the CyberArk CreateCredFile utility. The credential files are bound to the CPM server's unique machine hardware keys and the PasswordManager.exe process path, ensuring that even if the files are copied to an unauthorized system, they cannot be decrypted.

---

Local Directory Structure & Operational Artifacts

The CPM installation resides by default in C:\Program Files (x86)\CyberArk\Password Manager. Candidates preparing for the CyberArk Defender (PAM-DEF) exam must be intimately familiar with the functional directory structure:

• Password Manager\bin: Houses all core binary executables, including PasswordManager.exe, CACCPMScanner.exe, PMConsole.exe, dynamic link libraries (.dll), and the modern plug-in execution wrapper CyberArk.TPC.exe. Protocol engines and standalone command-line utilities are executed from this directory.
• Password Manager\Vault: Stores critical Vault communication parameters and authentication artifacts. Contains Vault.ini (which specifies the Vault IP address, secondary/DR Vault addresses, TCP port 1858, and connection timeout thresholds) alongside the encrypted credential files (user.ini and workspaceuser.ini).
• Password Manager\Logs: The centralized destination for operational and diagnostic telemetry. Contains active runtime logs, error dumps, and thread console logs. Archived logs are moved to the Logs\Old subfolder based on retention policies.
• Password Manager\Tmp: A transient working directory utilized by CPM plug-ins during credential changes. Temporary scripts, intermediate execution outputs, and staging files are created here and purged immediately upon task completion.

---

Core Log Files & Diagnostic Troubleshooting

Troubleshooting CPM operations requires understanding the specific role and verbosity of each log file maintained within Password Manager\Logs:

1. pm.log: The primary operational log. It tracks high-level execution cycles, scheduled Safe scans, polling heartbeats, and high-level outcomes of verification, change, and reconcile jobs. This log provides the first indicator of whether the CPM is actively communicating with the Vault.
2. pm_error.log: Captures all operational exceptions, task failures, and communication breakages. Any failure to reach a target host, credential mismatch, account lockout, or policy violation writes a timestamped record to this file. It is the primary reference for day-to-day administrative diagnostics.
3. PMConsole.log: Captures raw standard output from the PasswordManager.exe service console. It records engine initialization parameters, active worker thread pools, licensing limits, and internal exceptions encountered during service startup.
4. PMTrace.log: The granular diagnostic trace log. Enabled by configuring DebugLevel=3 and EnableTrace=yes within platform parameters or the CPM basic_ini file. It records every byte exchanged across terminal sessions, regex evaluation matching, API calls, and internal state machine transitions.

Log retention is governed by the LogFileKeepDays parameter (defaulting to 30 days). When log files reach their configured maximum size, the service rotates them into the Logs\Old directory with sequential numeric suffixes.

---

Multi-CPM Enterprise Topologies & Load Distribution

In enterprise environments, a single CPM cannot service thousands of accounts across dispersed network zones due to latency, firewall boundaries, and throughput constraints. CyberArk supports deploying multiple CPM instances.

Safe-Level Workload Allocation: The ManagingCPM Property

The core architectural rule governing multi-CPM deployments is that workload allocation is defined at the Safe level, never at the individual account level:

• Each Safe has a designated ManagingCPM property (configured via PVWA Safe Details or PrivateArk Client).
• This property contains the exact Vault username of the CPM assigned to that Safe (e.g., PasswordManager, CPM_DMZ, CPM_Azure).
• When a CPM executes its periodic scan, it queries the Vault only for Safes where ManagingCPM matches its own configured identity.
• This design prevents race conditions, eliminating double-rotation attempts or conflicting file locks on account objects.

Network Zone Separation & Enclave Architectures

Multi-CPM topologies enable zero-trust network segregation:

• DMZ & Perimeter CPM: Deployed in network DMZs to manage external-facing systems, firewalls, and reverse proxies. The CPM initiates outbound connections to the Vault on TCP 1858; the internal network never allows inbound traffic from the DMZ.
• Cloud Enclave CPM: Installed within AWS VPCs, Azure VNets, or Google Cloud projects to manage cloud-native infrastructure locally, reducing cross-cloud latency and eliminating expensive direct connect overhead.
• Operational Technology (OT) / SCADA CPM: Placed inside industrial control networks to rotate sensitive PLC and industrial workstation accounts without opening inbound routes into critical infrastructure.

---

Disaster Recovery (DR) Strategies for CPM

Because CPM actively modifies passwords on target systems, running multiple active CPMs against the same Safe simultaneously is strictly unsupported. For high availability and disaster recovery, CyberArk employs an Active-Passive (Cold/Warm Standby) architecture:

• Primary CPM: Actively manages designated Safes, pointing to the primary Vault in Vault.ini.
• DR / Standby CPM: Installed on a dedicated DR server with services set to Manual or Disabled. Its Vault.ini contains primary and DR Vault IP addresses.
• Failover Workflow: In a site disaster where the primary CPM or primary datacenter fails, administrators initiate failover by:
  1. Activating the DR Vault (if Vault failover occurs).
  2. Starting the CyberArk Password Manager service on the DR CPM host.
  3. Reassigning the ManagingCPM property on critical Safes to the DR CPM identity using automated REST API scripts or the PVWA interface.

---

CPM Architectural Components & Artifacts Summary

---

CPM Diagnostic Log Files & Analysis Matrix