u/AdElectrical9508

Hi everyone,

We have a setup where some departments access their accounts through RDM instead of PVWA because they are more familiar with RDM.

We created a script for this access flow, and it was working fine when the user had only one account and the account address was defined as an IP.

Later, after password rotation changes, we grouped multiple IPs under one account and changed the address definition to use the LDAP server DNS instead of individual IPs for rotation purposes.

Since this change, the script is no longer behaving as expected.

Here is the RDM script we are using (sensitive info masked):

Full address:s:X.X.X.X
alternate shell:s:psm /u <username> /a X.X.X.X /c PSM-RDP
username:s:<RDM_User>
desktopwidth:i:1024
desktopheight:i:768
screen mode id:i:2
redirectdrives:i:1
drivestoredirect:s:*
redirectsmartcards:i:0
use multimon:i:0
EnableCredSspSupport:i:0
redirectcomports:i:0
remoteapplicationmode:i:0

The script was working before when the account address was directly mapped to a single IP. After switching to DNS/LDAP-based addressing for rotation, the behavior changed.

Has anyone faced a similar issue when using RDM with CyberArk PSM after changing from direct IP-based accounts to DNS/LDAP-based rotation? Could this be related to PSM target resolution, alternate shell behavior, or account mapping?

Any troubleshooting suggestions would be appreciated.

Hi all,

We have PSM servers on Windows Server 2022, and recently our target servers were upgraded to Windows Server 2025.

Now when users connect via PSM (RDP), we get this error:

>

Looks like an RDP/TLS/CredSSP negotiation issue.

Has anyone seen compatibility issues between CyberArk PSM (Win 2022) and Windows Server 2025?
Did you fix it through TLS/cipher suites, Schannel, CredSSP, GPO, or CyberArk patching?

Any help is appreciated.

https://preview.redd.it/d7qotzdkb92h1.png?width=910&format=png&auto=webp&s=56f36efe76b337b898155bdf0d9dadd7d6ea52f3

We are currently investigating an issue in CyberArk PAM where approximately 60 accounts were deleted.

We need to identify who performed these deletions (targeting the accounts on the target servers, not the users themselves).

We have already extracted multiple reports from both PVWA and the Vault, but we were not able to find any relevant results or trace the deletion activity.

Has anyone faced a similar issue or can advise where else we should look to identify the source of these deletions?

We are currently facing a challenge regarding Linux local account password rotation using CyberArk CPM.

For Linux local users, CyberArk recommended configuring sudo permissions to allow the CPM user to execute the /usr/bin/passwd binary as root through /etc/sudoers or /etc/sudoers.d/.

However, this solution is not acceptable in our environment for the following reasons:

• Granting sudo permissions to normal users introduces significant security concerns and potential privilege escalation risks.
• Implementing and maintaining this configuration across a large number of Linux servers and local users would require considerable operational effort and time.

We are looking for alternative and secure approaches for Linux local account password rotation without granting broad sudo privileges.

Has anyone implemented a different method or best practice for handling Linux password rotation in a secure and scalable way?

Any recommendations or real-world experience would be appreciated.

Hello everyone, I’m trying to understand the real operational impact of the recent CyberArk / Idira rebranding for self-hosted PAM deployments.

I’m reviewing the recent CyberArk / Idira rebranding announcement for self-hosted PAM customers and trying to understand the practical operational impact in on-prem environments.

The announcement indicates that Self-Hosted PAM customers will receive rebrand-related updates in upcoming releases, including:

• PAM Self-Hosted v15.2
• Credential Provider v15.2
• Secrets Manager Self-Hosted v13.9

The stated changes appear to be primarily:

• UI branding updates
• Documentation updates
• Product-generated email changes
• Potential changes to display names and email subject lines
• A gradual rollout intended to minimize disruption

For organizations running fully on-prem or self-hosted CyberArk PAM deployments, I’m interested in understanding whether there are any real technical or operational impacts beyond cosmetic branding.

Specifically:

• SIEM integrations (QRadar, Splunk, Microsoft Sentinel, etc.)
• Email alert parsing and downstream automation
• API compatibility and backward compatibility considerations
• Any hardcoded references to “CyberArk” in scripts, tooling, or automation workflows
• Monitoring and observability tools relying on naming conventions
• Certificates, service URLs, endpoints, or internal service identifiers
• Upgrade and rollback behavior in mixed-version environments
• Any unexpected issues observed after applying the rebranded versions in production

If anyone has already evaluated or deployed these updates in a production self-hosted environment, insights on actual operational impact versus purely cosmetic changes would be appreciated.

Or If anyone has gone through a similar upgrade or rebranding cycle in a production PAM environment, it would be helpful to share any real risks or issues encountered, especially anything beyond cosmetic or UI changes.

Hi Community,

We are planning to temporarily disable hardening on CyberArk PAM components during Nessus vulnerability scans and would like to understand the possible operational and security impact before proceeding.

Environment:

• CyberArk PAM On-Premises Deployment
• Components included:
• Vault / DR Vault
• PVWA / DR PVWA
• CPM / DR CPM
• PSM / DR PSM
• PSMP / DR PSMP
• Vulnerability scanning performed using Nessus

We would appreciate feedback from anyone who has experience with this scenario.

Questions:

1. Has anyone disabled CyberArk hardening temporarily for vulnerability assessments or Nessus scans?
2. Did it impact:

• PAM services availability
• Session management or recordings
• CPM password management activities
• Vault communication
• PSM/PSMP connectivity
• Security baselines or compliance requirements

1. Were there any issues after re-enabling hardening?
2. Is there an officially recommended approach to perform authenticated Nessus scans without disabling hardening completely?
3. Are there recommended Nessus exclusions, safe checks, or scan tuning settings for CyberArk servers?

We are trying to identify:

• Potential risks and operational impact
• Best practices for vulnerability assessments in hardened CyberArk environments
• Whether temporary hardening disablement is considered safe or supported

Any recommendations, lessons learned, or official guidance would be highly appreciated.

Can we open these ports without disable Hardening?
If Yes / How?

https://preview.redd.it/ccv9p62ssn1h1.png?width=717&format=png&auto=webp&s=1537ac452504946752ae7b43ed8ddb5cb457a23d

Thanks.