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!!

   
   

CyberArk: CyberArk PVWA Integration with ServiceNow Ticketing System

Service Now Ticketing system integrating with CyberArk PAM (Coming soon ...) 

The purpose of integrating CyberArk PVWA (Privileged Vault Web Access) with the ServiceNow Ticketing System is to enforce secure and auditable access to privileged accounts by validating that a legitimate and approved change or incident ticket exists before granting access.

• All privileged access is tied to authorized business activity (via a ServiceNow ticket).

• Access is granted only when a valid, open, and approved ServiceNow ticket exists.

• Organizations meet compliance, audit, and regulatory requirements.

• Unauthorized or ad-hoc access to sensitive accounts is prevented.

• Integration supports Just-In-Time (JIT) access models and enhances accountability.

Phase 1:  ServiceNow Configuration 

1. Dev Tenant Registration. 
2. Service Account Creation 
3. Users & Groups Creation and Management 
4. Create INC, CHG and Management

Fig1 : 

Fig2: 

Fig3: 

Fig4: 

Phase 2:  CyberArk Configuration 

1. Onboard the Service Now Accounts (Local Under application | Domain User Under Domain Platform) 
2. Enable ServiceNow and configure on PVWA. 
3. 
   
   

Fig1:

Fig2:

Fig3:

Fig4:

Fig5:

Fig6: 

Fig7:

Fig8:

Fig9:

Phase 3:  Testing & Validation

Fig1:

Fig2:

Fig3:

Fig4:

Fig5: 

How To BYPASS the Ticket

Fig1: ( Phase2 : Fig4 is the configuration) 

Fig2:  

References: 

1. CyberArk: Integrate with Enterprise Ticketing Systems | CyberArk Docs

2. CyberArk: ServiceNow Ticketing System | CyberArk Docs

3. Community: CyberArk Integration with ServiceNow Ticketing System Walkthrough

Note: CyberArk should support only INC and CHG items only. 

Useful Information: 

Types tickets with tables Names

• INC – Incident Ticket

• INTSK – Incident Task

• RITM – Service Catalog Request

• TASK – Catalog Task

• CHG – Change Request

• CTASK – Change Task

• PRB – Problem Ticket

• PTASK – Problem Task
  

  
  

Happy Learning!!

CyberArk: CyberArk PVWA integrating with OKTA SAML

 Integrating CyberArk PVWA 14.4 with Okta SAML for Secure Single Sign-On and MFA

Integrating CyberArk Password Vault Web Access (PVWA) 14.4 with Okta SAML 2.0 enables secure and seamless Single Sign-On (SSO) for privileged users. This guide provides a step-by-step walkthrough to configure CyberArk as a SAML Service Provider and Okta as the Identity Provider (IdP), ensuring efficient and secure authentication.

Overview

Using SAML integration with Okta allows organizations to centralize identity management, enhance authentication security, and streamline user access to CyberArk. The integration also supports federated user provisioning and group-based access control.

Phase 1: Prerequisites

Ensure the following requirements are met before beginning the integration:

• CyberArk PVWA version 14.4 or later is installed and operational.
• Okta administrator access is available.
• A test user exists in both CyberArk and Okta.
• HTTPS is enabled for PVWA, as SAML requires secure communication.

Phase 2: Configure CyberArk PVWA for SAML

Step A: Enable SAML in PVWA Configuration

• Log in to CyberArk PVWA as an administrator.
• Navigate to Administration > Configuration Options > Options.
• Under Authentication Methods, expand saml:
• Set Enabled to Yes.
• Optionally, configure the LogoffUrl with your Okta logout URL if Single Logout (SLO) is required.
• Add your Okta domain (e.g., *.okta.com) to the AllowedReferrer list under Access Restriction.
• Click Apply to save the changes.

Step B: Configure the saml.config File

The saml.config file is located at:

<installation path>\inetpub\wwwroot\PasswordVault\WebUI\Configs\saml.config

Update the following parameters:

• ServiceProvider: Define the Name with the CyberArk PVWA URL.
• PartnerIdentityProvider: Set the Okta SAML metadata URL, SingleSignOnService endpoint, and EntityID.
• Configure certificates if required for signed requests or encrypted assertions.
• Ensure consistency between the ServiceProvider name and the values configured in Okta.

Phase 3: Configure Okta as the Identity Provider

Step A: Create a New SAML 2.0 Application

• Log in to the Okta Admin Console.
• Navigate to Applications > Applications, then click Create App Integration.
• Choose SAML 2.0 and click Next.
• Provide the following details:
• App name: CyberArk PVWA
• Optionally, upload the CyberArk logo.

Step B: Configure SAML Settings

Fill in the required fields:

• Single Sign-On URL: Use the Assertion Consumer Service (ACS) URL from the CyberArk saml.config.
• Audience URI (SP Entity ID): This should match the ServiceProvider Name in the CyberArk configuration.

Step C: Define Attribute Statements

Map Okta user attributes to CyberArk:

  

 

        Step D: Configure Group Attribute Statement (Optional)

        You may define a group filter to manage access control based on Okta groups. For example:

• Name: memberOf
• Filter: Starts with "CyberArk-"

Step E: Assign the Application

Assign the newly created SAML application to the users or groups who require access to CyberArk.

Phase 4: Allow Okta API Calls in PVWA

• In PVWA, navigate to Administration > Configuration Options > Security Settings.
• Under API Security > Allowed Domain, add your Okta domain (e.g., https://yourtenant.okta.com).
• Click Add, then Save.

Phase 5: Test the Integration

Method A: IdP-Initiated SSO

• From the Okta dashboard, click on the CyberArk PVWA application tile.
• You should be redirected and logged into CyberArk PVWA without entering credentials.

Method B: SP-Initiated SSO

• Open the CyberArk PVWA URL directly (e.g., https://pvwa.company.com).
• Choose the Okta authentication method from the login options.
• Authenticate using Okta credentials.

Upon successful authentication, the user should be redirected to the PVWA interface. If user attributes are mapped correctly, federated users may be automatically provisioned in CyberArk.

Important Considerations

• Versions of PVWA earlier than 11.3 use the web.config file for SAML configuration. From version 11.3 onward, saml.config is used.
• In PVWA 14.4 and later, users must have allowed authentication methods explicitly defined.
• During initial configuration, enable SAML debug logging to assist in troubleshooting authentication errors.
• Validate that the system clock is synchronized between PVWA and Okta, as time mismatches can lead to SAML assertion errors.

Reference Screenshots step by Step 

 Onboard the CyberArk Application into OKTA 

 

Enter the SAML SSO URL 
https://cyberarkpam.corp.com/PasswordVault/api/auth/saml/logon
Audience url : PasswordVault

 

1.2. Map the Respective PAM User Group to CyberArk Applications


SAML Configurations on PVWA Server  (saml.config file)
--
<?xml version="1.0"?>
<SAMLConfiguration xmlns="urn:componentspace:SAML:2.0:configuration">
  <ServiceProvider Name="[Enter Provider Name i.e. PasswordVault]" Description="PasswordVault Service Provider" AssertionConsumerServiceUrl="~/api/auth/saml/logon"/>
  <LocalCertificates>
      <Certificate FileName="C:\Stage\certs\pvwa.pfx" Password="Password@1234"/>
    </LocalCertificates> 
  <PartnerIdentityProviders>
    <PartnerIdentityProvider Name="[Enter Entity ID]" SingleSignOnServiceUrl="[Enter SSO Login URL]" SignAuthnRequest="false">
      <PartnerCertificates>
        <Certificate String="[Copy & paste the OKTA Cert code]" />
      </PartnerCertificates>
    </PartnerIdentityProvider>
  </PartnerIdentityProviders>
</SAMLConfiguration>

--

 

 

SAML Authentication Enable on the PVWA Portal. 

 

 

Access Retractions allow (Whitelist) [ Load Balancers, pvwa component url's and SSO OKTA URL]

Testing 
https://cyberarkpam.corp.com/PasswordVault/v10/logon/saml

 

 

References

• CyberArk SAML AuthN Doc: SAML authentication | CyberArk Docs
• Community Ref Doc: PVWA - SAML OKTA integration
• OKTA Ref Doc: Setup SSO

 

Happy Learning!!

---------------------------------------------------------------------------------------------------------------