CyberArk PTA 14.6.1 Installation and Configuration

Production SOP for RHEL/CentOS

This document provides a structured, production-ready procedure for installing and configuring CyberArk Privileged Threat Analytics (PTA) version 14.6.1. The focus is on correctness, repeatability, and eliminating common failure points.

---

1. Environment Overview

Operating System: RHEL / CentOS 7.9 (Minimal)
CPU / Memory: 8 vCPU / 16 GB RAM
Disk: 500 GB
Domain: corp.com

Components:

• Vault: 10.0.20.201
• PVWA: 10.0.20.203
• PTA: 10.0.20.206

---

2. Vault and PVWA Pre-Requisites

2.1 Vault Configuration

Create the following users using PrivateArk Client:

• PTAAppUser (Application type)
• PTAGWUser (Gateway type)

Grant permissions in the PasswordVault safe:

• List Accounts
• Retrieve Accounts
• View Safe Members

Update the Vault configuration file:

C:\Program Files (x86)\PrivateArk\Server\Conf\dbparm.ini

Add:

AllowNonStandardUserTypes=Yes

Restart the PrivateArk Server service.

Failure to apply this setting results in PTA authentication issues.

---

2.2 PVWA Configuration

Enable double escaping in IIS:

cd %windir%\system32\inetsrv

appcmd set config "Default Web Site/PasswordVault" ^
-section:system.webServer/security/requestFiltering ^
/allowDoubleEscaping:"True" /commit:apphost

iisreset

If this step is skipped, PTA API communication will fail (commonly observed as P023 errors).

---

3. PTA Server Base OS Configuration

3.1 Hostname and DNS

hostnamectl set-hostname pta.corp.com

Update /etc/hosts to ensure bidirectional resolution for Vault, PVWA, and PTA.

---

3.2 SELinux Configuration

sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
setenforce 0

PTA is not supported with SELinux in enforcing mode.

---

3.3 Time Synchronization

dnf install -y chrony
systemctl enable --now chronyd

Time skew greater than five minutes causes authentication failures.

---

3.4 Required Packages

dnf update -y

dnf install -y unzip tar net-tools bind-utils curl telnet rsyslog \
policycoreutils-python-utils iptables-nft-services tmpwatch sshpass libnsl

systemctl enable --now rsyslog

---

3.5 Firewall Configuration

systemctl disable --now firewalld

PTA manages iptables internally.

---

3.6 Reboot

reboot

---

4. PTA Installation

mkdir -p /opt/PTA
cd /opt/PTA

unzip PTA-Installer-Rls-v14.6.1.zip
chmod +x pta_installer.sh

./pta_installer.sh

Installation directories:

• /opt/pta
• /opt/tomcat

---

5. Certificate Trust Configuration

5.1 Import CA into OS Trust

cp domain.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract

---

5.2 Import CA into Java Truststore

/opt/pta/infra/jvm/jre17/bin/keytool -import \
-alias pvwa-rootca \
-keystore /opt/pta/infra/jvm/jre17/lib/security/cacerts \
-file domain.crt \
-storepass changeit \
-noprompt

OS-level trust is not sufficient. PTA relies on Java truststore for outbound communication.

---

6. PTA Pre-Configuration Wizard

Run:

/opt/tomcat/prepwiz/run.sh

Provide the following critical inputs:

• Vault IP: 10.0.20.201
• Vault Port: 1858
• securityModuleTrustedConnection: Yes
• PVWA Address: pvwa.corp.com
• PVWA Port: 443
• Authorized Sources: Vault and PVWA IP addresses

Incorrect values here result in authentication failures and diagnostic errors.

---

7. Tomcat Keystore Alias Fix

After running prepwiz, update the Tomcat configuration:

sed -i 's|keystorePass=".*"|& keyAlias="1"|' /etc/opt/pta/tomcat/server.xml

Without this fix, the PTA service will not bind to port 8443.

---

8. Start and Validate Services

systemctl start appmgr

Verify Listening Ports

ss -tlnp | grep -E '8080|8443|11514'

---

Test PTA UI

curl -kI https://localhost:8443

---

Test PVWA API Connectivity

curl -sk -X POST https://pvwa.corp.com/PasswordVault/api/auth/CyberArk/Logon \
-H "Content-Type: application/json" \
-d '{"username":"Administrator","password":"<password>"}'

If this API call fails, PTA integration is not functioning.

---

9. Post-Installation Configuration

Access PTA UI:

https://<PTA-IP>:8443

Complete the following:

• Change administrator password
• Upload license
• Configure AD connectivity (GC port 3269)
• Validate PVWA connectivity
• Configure SMTP and SIEM

---

10. Vault Syslog Integration

On Vault server, update:

dbparm.ini

Add:

SyslogServerIP=10.0.20.206
SyslogServerPort=11514
SyslogServerProtocol=UDP

Restart Vault service.

Without syslog integration, PTA will not receive audit data.

---

11. Hardening

sed -i 's/#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart sshd

---

12. Common Failure Scenarios

12.1 PTA UI Not Accessible on Port 8443

• Cause: Keystore alias mismatch
• Fix: Set keyAlias="1" in server.xml

---

12.2 P023 Diagnostic Failure

• Cause: Double escaping disabled in PVWA
• Fix: Enable via IIS appcmd

---

12.3 Authentication Failures (401 Errors)

• Cause: Trusted connection disabled
• Fix: Set securityModuleTrustedConnection to Yes

---

12.4 SSL Works via Curl but PTA Fails

• Cause: Missing CA in Java truststore
• Fix: Import certificate using keytool

---

13. Engineering Takeaways

Two practices determine whether this deployment succeeds or fails:

Configuration Discipline

• Applying Vault and PVWA prerequisites correctly versus assuming defaults
• Importing certificates into Java truststore rather than relying only on OS-level trust

Validation Approach

• Verifying API connectivity manually instead of assuming success
• Checking service ports explicitly instead of relying on service status

 

CyberArk PSM for SSH (PSMP) 15.x

Installation and Configuration Guide (Rocky Linux / RHEL 8.x)

---

1. Introduction

This document provides detailed step-by-step instructions for installing and configuring CyberArk Privileged Session Manager for SSH (PSMP) version 15.x on a Rocky Linux / RHEL 8.x server.

PSMP enables secure proxy-based SSH access to target systems via CyberArk Vault without exposing credentials to end users.

---

2. Prerequisites

2.1 Supported Operating System

Verify that the operating system is supported.

Command:

cat /etc/os-release

Ensure the OS is Rocky Linux 8.x or RHEL 8.x.

---

2.2 CyberArk License Requirements

Ensure that the CyberArk license includes:

• PSMPServer
• PSMPApp access

Installation will not proceed without a valid license.

---

2.3 Vault Connectivity

Verify connectivity between PSMP server and Vault.

Commands:

ping <Vault-IP>
telnet <Vault-IP> 1858

Ensure required ports are open:

• 1858 / 1859 (Vault)
• 443 (PVWA if TLS used)

---

2.4 Required Vault Permissions

The Vault user used during installation must have:

• Add Safes
• Audit Users
• Add/Update Users
• Manage Server File Categories
• Ownership of PVWAConfig Safe with:
  • List Accounts
  • Retrieve Accounts
  • Manage Safe Owners

---

2.5 SELinux Configuration

Check SELinux status:

getenforce

Install required package:

yum install -y policycoreutils-python-utils

SELinux should be in enforcing mode before installation.

---

2.6 Disable NSCD (If Installed)

Check:

rpm -qa | grep nscd

If installed:

systemctl stop nscd.service nscd.socket
systemctl disable nscd.service nscd.socket

---

2.7 Create Local Administrative User

useradd psmpadmin
passwd psmpadmin

This user is used for server administration.

---

3. Prepare Installation Files

Create installation directory:

mkdir -p /opt/CARKpsmp
cd /opt/CARKpsmp

Copy the following files:

• CARKpsmp-15.x.x.x.rpm
• psmpparms.sample
• RPM-GPG-KEY-CyberArk

---

3.1 Verify RPM Signature

rpm --import RPM-GPG-KEY-CyberArk
rpm -K -v CARKpsmp-15.x.x.x.rpm

Ensure output shows “OK”.

---

4. Create Parameter File (psmpparms)

Copy sample file:

cp psmpparms.sample psmpparms
vi psmpparms

---

4.1 Mandatory Parameters

AcceptCyberArkEULA=Yes
Hardening=Yes

---

4.2 Recommended Parameters

EnablePSMPRestService=Yes
PSMPCreateEnvRetryTimeout=1
PSMPCreateEnvClientsCount=10

---

4.3 Optional Parameter

EnableADBridge=Yes

---

4.4 Move Parameter File

mv psmpparms /var/tmp/

This location is mandatory.

---

5. Install PSMP Package

Run installation:

rpm -ivh CARKpsmp-15.x.x.x.rpm

Installation runs non-interactively.

Expected output:
“Installation process was completed successfully.”

---

6. Vault Registration (Finalize Step)

This is the most critical step.

---

6.1 Create vault.ini File

cp /opt/CARKpsmp/doc/examples/vault.ini /root/vault.ini
vi /root/vault.ini

---

Mandatory Parameter

Address=<Vault-IP-or-Hostname>

---

Optional TLS Configuration

VaultCommunicationProtocol=TLS
TLSVersions=TLS_1_2
TLSPort=443

---

6.2 Create Credential File

cd /opt/CARKpsmp/bin
./createcredfile user.cred

Provide:

• Vault username
• Password
• Enable entropy (recommended)

---

6.3 Execute Finalize Script

/opt/CARKpsmp/bin/psmp_setup.sh --finalize --vault-ini /root/vault.ini --credfile /opt/CARKpsmp/bin/user.cred

---

6.4 Expected Output

PSM for SSH service instance registered in Vault and enabled.
All configuration tasks were completed successfully.

---

7. Verification

---

7.1 Check Running Processes

ps -ef | grep psmp

Expected processes:

• psmpserver
• psmpadbserver
• psmprestservice

---

7.2 Check Service

systemctl status psmpsrv

Expected:

active (exited)

This is normal behavior.

---

7.3 Check Logs

tail -f /var/opt/CARKpsmp/logs/PSMPConsole.log

---

8. Functional Testing

---

8.1 Test SSH Access via PSMP

From client machine:

ssh <vault-user>@<psmp-server>

This validates:

• Vault integration
• PSMP proxy functionality

---

9. Post-Installation Tasks

---

9.1 Verify ADBridge Service

systemctl status psmpsrv-psmpadbserver

---

9.2 Enable SFTP (Optional)

Edit SSH configuration:

vi /etc/ssh/sshd_config

Uncomment:

Subsystem sftp /usr/libexec/openssh/sftp-server

Restart SSH:

systemctl restart sshd

---

9.3 Remove Sensitive Files

rm -f /opt/CARKpsmp/bin/user.cred
rm -f /root/vault.ini

---

9.4 Verify Time Synchronization

timedatectl

---

9.5 Firewall Configuration

Ensure the following ports are open:

• 22 (SSH to PSMP)
• 1858 (PSMP to Vault)
• 443 (PSMP to PVWA if TLS)

---

10. Optional Integrations

---

10.1 LDAP Integration (AD Bridge)

• Enable ADBridge
• Configure LDAP settings in Vault

---

10.2 RADIUS Integration

• Configure RADIUS in Vault
• PSMP authentication will follow Vault settings

---

11. Troubleshooting

---

Issue: Service shows “active (exited)”

Resolution: This is expected behavior.

---

Issue: Vault registration fails

Check:

• Network connectivity
• Vault user permissions
• TLS configuration

---

Issue: SSH connection fails

Check:

ss -tulnp | grep 22
firewall-cmd --list-all

---

Issue: SELinux blocking

Temporary test:

setenforce 0

---

Issue: Port conflicts

netstat -tulnp | grep 18923

---

12. Architecture Flow

User connects to PSMP via SSH
PSMP authenticates user via Vault
PSMP proxies session to target system
Session is controlled and audited

---

13. Conclusion

The PSM for SSH installation and configuration is complete once:

• Vault registration is successful
• PSMP services are running
• SSH access through PSMP is validated

---

SailPoint IIQ | Tomcat Server SSL port 443 configuration

 

Installing a Windows Domain Certificate in Apache Tomcat — Step-by-Step

Below is a cleaned, ordered article-style transcription of the screenshots you provided. Follow these steps to create a keystore, request a certificate from a Windows CA, import the CA response, export the certificate and key, and configure Tomcat to use the certificate.

---

Step1. Configure and install (prerequisites)

1. Install JavaSoft (Oracle) registry keys for AdoptOpenJDK JRE (if not already installed).

2. Download and install KeyStore Explorer from: https://keystore-explorer.org/.

3. In the Tomcat installation directory create a folder named certs and grant write permissions to the account that will run the key/certificate operations and Tomcat.

---

Step2. Create the keystore file (use KeyStore Explorer)

1. Open KeyStore Explorer.

2. File → New → PKCS #12 (create a new PKCS#12 keystore).

3. Tools → Generate Key Pair → choose RSA 2048.

4. Version → Version 3 (this should be the default).

5. Signature Algorithm → SHA-256 with RSA.

6. Validity Period — set e.g. 5 Years and apply (only applicable if you create a self-signed cert).

7. Click the Name (or Distinguished Name) button and set Common Name (CN) to the fully qualified domain name (FQDN) of the server; fill other DN fields as appropriate.

8. Click Add Extensions and add these extensions:

   • Extended Key Usage — TLS Web Server Authentication

   • Key Usage — Digital Signature and Key Encipherment

   • Subject Alternative Name — DNS Name: the server FQDN (and any additional SANs if required)

   • Subject Key Identifier — 160-bit Hash

9. Enter and confirm a key pair password (store securely).

10. Save the keystore in the Tomcat certs directory using a .pfx extension (use the same password you used for the key pair).

---

Step3. Create a Certificate Signing Request (CSR)

1. In KeyStore Explorer, right-click the key pair → Generate CSR.

2. Format: PKCS #10 (default).

3. Signature Algorithm: SHA-256 with RSA (default).

4. Select Add certificate extensions to request if it is not already selected (this will include the SANs and usages you set).

5. Specify an output filename with a .csr extension and save it to the certs folder.

---

Step4. Submit the CSR to your Windows Certificate Authority (CA)

Example CA web path shown in screenshots: https://dc01/certsrv (replace dc01 with your CA host).

1. Open the CA web enrollment page (e.g. https://dc01.corp.com/certsrv).

2. From the CA home page, click Request a certificate.

3. Click Advanced certificate request (link depends on CA configuration).

4. Paste the entire contents of your .csr file into the text box on the CA request page.

5. Choose Web Server as the certificate template (or the correct template for your environment), then Submit.

6. When the certificate is available choose Base 64 encoded and click Download certificate chain (or Download certificate).

7. Download the file, rename it to name-response.cer (or similar) and copy it into your Tomcat certs directory.

---

Step5. Import the CA response into the keystore (KeyStore Explorer)

1. In KeyStore Explorer, right-click the key pair → Import CA Reply → From File.

2. Select the downloaded response .cer file (the CA reply chain).

3. Import and save the keystore file (.pfx) again (this will attach the CA-signed certificate to your private key entry).

---

Step6. Export certificate chain and private key (to files Tomcat can use)

1) Export the certificate chain

1. Right-click the key pair → Export → Export Certificate Chain.

2. Export Length: Entire Chain.

3. Export Format: X.509.

4. Save the exported certificate as name.cer in the Tomcat certs directory.

2) Export the private key

1. Right-click the key pair → Export → Export Private Key → OpenSSL.

2. Uncheck the Encrypt checkbox (if you need an unencrypted PEM private key).

3. Select PEM checkbox if it is not already selected.

4. Save the private key as name.key in the Tomcat certs directory.

5. Restrict file permissions on the private key so only the Tomcat service account (or admin) can read it.

Security note: keep private keys secure. If you must keep them encrypted on disk, adjust Tomcat configuration accordingly.

---

Step7. Update Tomcat server.xml to use the certificate

1. Open PowerShell (or an elevated command prompt) as Administrator.

2. Set-Location (cd) to the Tomcat conf directory (e.g. C:\path\to\tomcat\conf).

3. Make a backup copy of server.xml (e.g. copy server.xml server.xml.bak).

4. Find the commented connector for SSL — e.g. the <Connector port="8443" ...> line for APR/native — copy and paste or uncomment the appropriate Connector block for APR/native or JSSE depending on your Tomcat build.

5. Modify the Connector attributes to point to the exported key and certificate files. For APR/native you typically set:

   • certificateKeyFile="certs/sailpoint.key"

   • certificateFile="certs/sailpoint.cer"

6. If there is a certificateChainFile attribute present, remove it (you exported the full chain into name.cer; configs vary—confirm your Tomcat connector type expects the fields you set).

7. Save server.xml.

8. Restart the Tomcat service to apply the changes.
   

   ---------------------------------------------------------------
   
   Troubleshoot Steps:
   
   

   Issue :
   SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException 
   Failed to initialize component [Connector["https-openssl-apr-443"]]
   org.apache.catalina.LifecycleException: The configured protocol [org.apache.coyote.http11.Http11AprProtocol] requires the APR/native library which is not available
   
   Resolution: 
   
   
   

   Enabling Tomcat Native with OpenSSL on Windows

   When running Apache Tomcat on Windows, enabling the Tomcat Native library improves performance and allows the use of OpenSSL for HTTPS connections. Below are the steps to install and configure it for Tomcat 9.0.109 (64-bit, Windows).

   ---

   Step 1: Download Tomcat Native (tcnative)

   Visit the official Apache Tomcat Native downloads page and download the pre-built 64-bit Windows binaries (ZIP).
   The package contains the required tcnative-1.dll.

   ---

   Step 2: Extract the DLL

   Unzip the downloaded archive.
   Inside the bin folder, locate tcnative-1.dll.
   Make sure you are using the 64-bit version since your OS is 64-bit.

   ---

   Step 3: Copy the DLL

   Copy tcnative-1.dll into one of the following directories:

   • C:\Apache\Tomcat\bin (recommended and safe)

   • C:\Windows\System32 (for system-wide access)

   ---

   Step 4: Install OpenSSL Runtime

   Tomcat Native requires OpenSSL.

   1. Download the latest Win64 OpenSSL Light installer from:
      https://slproweb.com/products/Win32OpenSSL.html

   2. Install it (default installation path is usually C:\Program Files\OpenSSL-Win64).

   3. During installation, if prompted, allow it to copy DLLs into the Windows system directory.

   ---

   Step 5: Add OpenSSL to PATH

   1. Open System Properties → Environment Variables.

   2. In the PATH variable, add:

      C:\Program Files\OpenSSL-Win64\bin
      

   3. Save and apply changes.

   ---

   Step 6: Restart Tomcat

   1. Stop the Tomcat service (if running).

   2. Start Tomcat again.

   If everything is configured correctly, the startup log will display messages similar to:

   org.apache.coyote.http11.Http11AprProtocol initialized with OpenSSL
   OpenSSL successfully initialized
   

   At this point, your HTTPS connector (for example, https-openssl-apr-443) should bind successfully.
   
   
   Happy Learning!!