Hi everyone, I've been looking into CyberArk for managing privileged accounts, and I'm really stuck on a specific issue. I'm trying to figure out how to handle automatic password rotation for our legacy, on-premise applications. A lot of them are old custom apps or databases that don't have a modern API or any way to integrate directly with a PAM solution like CyberArk.
We're currently doing this manually, and it's a huge pain point. I know CyberArk can rotate passwords automatically, but everything in the documentation seems to assume the target system can be integrated via an API or has a standard connector. What about the systems that just... don't?
I've seen mentions of "PSM Connect" and "SSH Proxy," but I'm not sure if those are the right tools for this job. My main questions are:
1. Is there a standard method within CyberArk to handle password rotation for these "non-standard" or "headless" applications? Maybe some kind of custom script or plugin system?
2. If we have to build something custom, what's the best practice? Do we create a small wrapper service that the legacy app can call, or does CyberArk provide a way to trigger a script on its own that would then update the password locally in the app's config file?
3. How do others handle the verification step? After rotating a password for, say, a legacy database, how do you confirm the new password actually works before committing the change in the vault?
I'm a bit cautious about proposing a solution that might be too complex or fragile. Any insights or real-world examples from your own environments would be incredibly helpful. 😅
You're asking the right question about PSM Connect and SSH Proxy, but those are primarily for secure access, not rotation. For headless systems, CyberArk's CPM (Central Policy Manager) uses "plugins" which are essentially scripts that handle the password change logic for a specific platform. The key is that many legacy systems are covered by generic plugins like "OS Generic" for Windows/Linux local accounts or "Database Generic" which uses ODBC/JDBC.
When a generic plugin doesn't fit, you build a custom CPM plugin. The pattern is straightforward: your script, invoked by the CPM, must log into the target system using the current credentials, execute the password change command (be it a SQL query, an LDAP modify, or even screen-scraping a telnet menu), and verify the new credential works. The CPM provides the old and new passwords as inputs. You'd typically develop this in PowerShell, VB, or a shell script.
The architectural decision is whether the plugin runs directly on the CPM server (needing network access to the legacy app) or if you deploy a lightweight agent on a server closer to the target. For truly archaic protocols, the latter is often cleaner, using the agent as a mediation point.
brianh
Custom CPM plugins are the answer. User978 is right about the pattern, but they undersold the complexity.
Those generic plugins often fail on truly legacy systems. The "OS Generic" one will break if the login prompt isn't standard. You'll end up writing a custom script anyway.
The best practice is to treat it like any other automation problem: your script needs to handle the specific login sequence, the exact password change command (like an ALTER USER statement sent over a CLI), and verification. Write it to log everything so you can debug why a rotation failed.
Don't build a wrapper service for the app. That just creates another system to manage. The CPM scheduler runs the script directly. It's ugly, but it works. Your script just needs to accept the current and new password as parameters.
I've had to script rotations for old AS/400 systems and proprietary databases. It's always brittle, but still better than manual.
Trust but verify, then don't trust.
You're correct about the brittleness, but I'd push back slightly on the advice to avoid a wrapper service entirely. For a cluster of similar legacy apps, a simple internal service that standardizes the connection and command layer can reduce the script sprawl. Instead of fifty unique CPM plugins, you manage one service endpoint and fifty configuration files. The complexity shifts from scripting edge cases in each plugin to maintaining a single, well-instrumented integration component. It's a trade-off, but in large environments, the centralization of logic wins out.
Single source of truth is a myth.
Custom CPM plugins are the only method. PSM and SSH Proxy are for access, not rotation.
The "wrapper service" argument has merit for scale, but it's often overkill. Start with a custom plugin script that directly handles the app's login and change command. You'll find many legacy systems just need a simple expect script or a SQL client call.
If you end up with dozens of these, then consider consolidating the logic. But prove the script works first.
Trust but verify, then don't trust.
Great question, and you've hit on the classic PAM dilemma. You're right that the documentation glosses over this, but the answer is absolutely custom CPM plugins. They're designed exactly for this headless, non-API scenario.
The trick is thinking of it as automating the manual process you do now. Your script, triggered by CyberArk, needs to simulate a user session: log in with the old password, send the system's specific change command (whether that's a SQL string, a shell command, or even navigating a telnet menu), and then test the new password. I've had to write plugins that use expect scripts for old Solaris boxes and PowerShell for ancient Windows apps.
I'd start simple - build one custom plugin for your most critical legacy database to prove the workflow. You'll quickly see if the generic connectors will work or if you need to go fully custom. It's not pretty, but it gets the job done and beats manual rotation forever.
Pipeline is king.
You've captured the exact mindset shift needed: treat it as automating the manual session. That "simulate a user session" approach is crucial.
One important caveat with custom scripts is error handling for connection timeouts or unexpected prompts. A script that works in a quiet lab can fail when the target system is under load. I always build in retry logic and explicit wait states, rather than relying on a single expect command.
Your suggestion to start with the most critical system is the right path. It forces you to confront the real complexity early, whether that's a quirky SQL*Plus version or a mainframe TN3270 screen. Once that first plugin is stable, the pattern repeats for others, albeit still requiring deep understanding of each legacy protocol.
You're getting excellent, practical advice here about custom CPM plugins. That's definitely the standard method for the scenario you're describing.
One thing I'd add from a process perspective: when you start building those custom scripts, treat them like any other piece of critical infrastructure code. Put them in source control and establish a lightweight review process, especially since they'll be handling your most sensitive credentials. It's easy for a one-off script to become a "write-only" piece of legacy itself.
Also, consider the verification step as part of your design. A script that changes a password but can't reliably verify the new one works will create a different kind of manual headache.
—HR
I agree that starting with a direct custom plugin is the pragmatic first step. The point about using `expect` for non-standard prompts is key, but it's worth calling out that you can hit a wall with truly opaque systems, like those that use a custom binary client with no scripting interface.
In those cases, you sometimes have to get creative. I've had to write a plugin that essentially automated a PuTTY session via AutoHotkey because the only interface was a GUI tool. It was fragile, but it worked. The verification step there was the hardest part - you have to script the entire login sequence again with the new password.
So while I agree you should start simple, I'd add that your "simple expect script" assessment needs to include a check for whether the system even *has* a command line you can script against. If not, you're in for a much uglier ride, and that's when the wrapper service idea starts to look more appealing, even for a handful of systems.
Extract, transform, trust