7.2 Platform Architecture, Settings Tree & Platform Duplication

7.2 Platform Architecture, Settings Tree & Platform Duplication

Quick Answer: In CyberArk PAM, every managed account is bound to exactly one platform. While Safes define who has access to an account, Platforms define how that account is technically managed—including Central Policy Manager (CPM) rotation plugins, Privileged Session Manager (PSM) connection components, and UI behavior. Platforms are organized in the PVWA under Administration -> Platform Management into a hierarchical settings tree consisting of four primary branches: UI & Workflows, Automatic Password Management, Privileged Session Management, and Credentials Management. Out-of-the-box (OOTB) platforms must never be edited directly; administrators must duplicate standard platforms and customize the cloned versions to preserve baseline templates and prevent upgrade conflicts.

---

The Core Relationship: Account-to-Platform Binding

A fundamental architectural distinction tested on the CyberArk Defender examination is the division of responsibility between Safes and Platforms:

• Safes dictate Access and Containment: Safes are logical storage repositories protected by Vault encryption keys. Safe permissions (Access Control Lists) determine which human users or service identities can view, retrieve, edit, or authorize access to stored accounts.
• Platforms dictate Behavior and Technology: Platforms are operational policy blueprints. A platform defines the technical protocols, password generation rules, CPM plugin scripts, session recording parameters, and connection components required to interact with the target asset.

Every credential onboarded into the Digital Vault must be assigned to exactly one target platform. An account cannot exist without a platform, nor can it be associated with multiple platforms simultaneously. If an organization manages ten thousand Windows local administrator accounts distributed across three hundred Safes, every single one of those accounts can be bound to the exact same Windows platform. Conversely, multiple accounts within the same Safe can be bound to completely different platforms (such as an Oracle DBA account, a Linux root account, and a Windows service account residing in a single project Safe).

---

Platform Categorization & Specialization

Platforms are engineered to support diverse infrastructure tiers through four primary architectural classifications:

1. Regular Target Platforms

These represent standard device and operating system platforms governing interactive administrative accounts on standalone endpoints, domain servers, databases, and network equipment. Examples include WinServerLocal, UnixSSH, and CiscoRouter. They execute direct, 1-to-1 password changes and verifications against the target asset's local authentication database.

2. Group Platforms

Group platforms manage Account Groups, where multiple accounts share a single synchronized password or rotate together on an identical schedule. For example, in an un-clustered application farm where fifty standalone web servers use a local administrator account with an identical password, a Group platform coordinates the CPM so that changing the credential updates all fifty nodes concurrently or updates a designated master account while synchronizing member accounts.

3. Service Account Platforms

Service account platforms are engineered for complex operational environments where a password change on a target system requires cascading updates across dependent applications. When managing Windows domain or local service accounts, changing the credential in Active Directory or the local SAM without updating dependent services causes immediate application failure. Service account platforms interface directly with:

• Windows Service Control Manager (SCM): Automatically updates the logon account password for Windows Services and restarts them if configured.
• Windows Task Scheduler: Updates credentials embedded in automated scheduled tasks.
• IIS Application Pools: Updates identities running web application worker pools in Microsoft Internet Information Services.

4. Rotated Secrets Platforms

Designed for modern cloud, DevOps, and SaaS environments, rotated secrets platforms manage non-traditional secrets such as API access keys, OAuth tokens, AWS IAM access keys, Azure Service Principals, and database connection strings. Rather than executing legacy SSH or RPC password change scripts, these platforms interact with cloud provider REST APIs over HTTPS (TCP port 443).

---

Out-of-the-Box (OOTB) Platforms

CyberArk provides an extensive library of pre-packaged, out-of-the-box platforms designed to support major enterprise technologies immediately upon Vault installation:

• Windows Server Local & Domain Accounts (WinServerLocal, WinDomain): Leverages Microsoft NetAPI32 and RPC/SMB (TCP port 445) or LDAP/LDAPS (TCP port 389/636) to manage local SAM accounts and Active Directory domain identities.
• Unix via SSH (UnixSSH): Interacts with Linux, AIX, Solaris, and BSD operating systems over SSH (TCP port 22) using Terminal Plugin Controller (TPC) or PMTerminal to spawn shells, parse prompts, and execute passwd commands.
• Database Platforms (Oracle, MS-SQL, MySQL, PostgreSQL): Uses native database communication clients, ODBC, or JDBC drivers to authenticate to database instances and execute ALTER USER DDL statements.
• Cloud Infrastructure Platforms (AWS IAM, Microsoft Azure, Google Cloud Platform): Interacts with hyperscaler APIs to rotate access keys, console login passwords, and service identities.

---

Deep Dive: The Platform Settings Tree in PVWA

When an administrator selects a platform in the PVWA (Administration -> Platform Management -> Edit Platform), configuration parameters are organized into a strict hierarchical tree structure comprising four primary functional branches:

1. UI & Workflows

This branch governs how accounts bound to this platform appear and behave within the PVWA user interface:

• User Workflows: Configures dual control approval requirements, ticketing system validation (e.g., forcing ServiceNow change request entry), and reason-for-access prompts specific to this platform.
• Privileged Access Workflows: Configures check-in/check-out exclusive access behavior and auto-release timers.
• Properties Display: Defines required and optional account properties displayed in the PVWA (such as Address, Username, DeviceType, Database, or custom attributes like CostCenter or Environment).

2. Automatic Password Management

This is the operational engine governing Central Policy Manager (CPM) automation. It contains key sub-sections:

• General: Controls operational parameters such as Interval (days between scheduled rotations), HeadStartInterval, ImmediateInterval, and operational boolean flags like ResetImmediately and AllowManualChange.
• Change, Verify, Reconcile: Individual sub-nodes defining whether automated periodic changes, verifications, and reconciliations are enabled, and specifying failure retry limits.
• GeneratePassword: Dictates password complexity rules, including PasswordLength, MinUpperCase, MinLowerCase, MinDigits, MinSpecial, and PasswordForbiddenChars.
• Notifications: Configures Event Notification Engine (ENE) email alerts prior to password expiration or upon CPM task failure.

3. Privileged Session Management

This branch controls how the Privileged Session Manager (PSM) isolates, connects to, and records sessions for accounts on this platform:

• Connection Components: Specifies which connection tools are available in the PVWA (e.g., PSM-RDP, PSM-SSH, PSM-SQLPlus, PSM-Toad). Administrators can enable or disable specific components or configure client-specific connection parameters.
• Session Isolation & Recording: Enforces full session recording, keystroke logging, and window title capture for administrative sessions launched from this platform.

4. Credentials Management

This branch dictates the underlying execution engine and plugin scripts executed by the CPM:

• Plugin Architecture: Specifies the execution executable, determining whether the platform uses the modern Terminal Plugin Controller (CyberArk.TPC.exe) or the legacy PMTerminal.exe.
• Process and Prompts Files: Defines the exact state-machine scripts (e.g., UnixProcess.ini and UnixPrompts.ini) that tell the CPM how to respond to terminal prompts, send usernames, detect password change challenges, and confirm success.
• DLL Library Paths: Specifies native compiled libraries (such as CAPWindows.dll) used for Windows NetAPI calls.

---

Platform Duplication: Rationale and Administrative Procedures

A central best practice emphasized on the Defender exam is: Never edit default out-of-the-box (OOTB) platforms directly.

Why Duplicate Platforms?

1. Preserving Baseline Templates: Default platforms serve as the golden reference baseline provided by CyberArk. Modifying an OOTB platform directly eliminates the clean reference architecture needed for troubleshooting.
2. Preventing Upgrade Overwrites: During CyberArk component upgrades or service pack installations, out-of-the-box platform definitions may be refreshed or overwritten by the installer, reverting custom enterprise settings back to factory defaults.
3. Environment Segregation: Different business tiers require distinct operational parameters. Rather than altering WinServerLocal, an enterprise should create CORP-Windows-Tier0-Daily (with 1-day rotation and dual control) and CORP-Windows-Workstations-90Day (with 90-day rotation and manual change enabled).

Administrative Duplication Procedure

1. Navigate to Administration -> Platform Management.
2. Select the target baseline platform (e.g., Unix via SSH).
3. Click Duplicate in the platform toolbar.
4. Enter a distinctive, standardized Platform Name (e.g., CORP-Linux-RHEL-Production) and Description.
5. Save the duplicated platform.
6. Edit the newly created platform's settings tree to configure enterprise-specific parameters (such as rotation intervals, TPC timeouts, and PSM connection components).
7. Test the cloned platform in a non-production Safe before onboarding production assets.

---

Platform Lifecycle: Active vs. Inactive Operational States

Platforms maintain an administrative operational state that determines their availability across the CyberArk infrastructure:

• Active State: The platform is fully operational. It appears in the PVWA Platform dropdown list when onboarding new accounts, and the CPM actively processes all scheduled verification, change, and reconciliation tasks for accounts bound to it.
• Inactive State: The platform is administratively disabled. It is hidden from the account onboarding interface, preventing administrators from binding new accounts to it. Existing accounts previously bound to an inactive platform remain safely stored in their Safes, but the CPM suspends all automated password management activities for those accounts. Inactivating a platform is an effective method for decommissioning legacy systems or temporarily freezing automated rotations during enterprise change freezes.

---

Platform Settings Tree Reference Table