PSM load balancer
Session access no longer depends on any single PSM server.
A live CyberArk platform, made resilient and complete
A privileged access platform can be live and still fragile: one session server away from an outage, activity nobody looks at until the audit, and privileged accounts that never made it into the vault. A US specialty retailer asked our engineers to close those gaps on its CyberArk estate. Five pieces of work took the platform from working to defensible.
Session servers load balancedBrowser-based sessionsActivity monitoredNew accounts vaulted by rulePasswords out of code
Delivery summary: CyberArk PAMApplied IAM
- PSM load balancerResilience
- HTML5 GatewayResilience
- PTA upgrade and monitoringVisibility
- Discovery and onboarding rulesCoverage
- Central Credential ProviderCoverage
From working to defensible.
The gaps
Five initiatives, grouped by what they fix
Each piece of work closed a gap in one of three things: whether the platform stays up, whether anyone sees misuse, and whether it covers the whole estate.
HTML5 Gateway
Users connect through a browser, with no RDP client and no direct route to the PSM.
PTA upgrade and monitoring
Vault activity and PSM sessions are analysed continuously, so credential theft and policy bypass surface as alerts rather than turning up later in logs.
Discovery and onboarding rules
The estate is mapped, and rules bring new privileged accounts into the vault automatically.
Central Credential Provider
Applications retrieve credentials at runtime instead of holding them in code.
PSM load balancer
Session access no longer depends on one server
The PSM servers now sit in a pool behind one virtual address.
- One address, a pool behind it. A load-balanced PSM pool sits behind a single virtual address, with health checks draining a failed node automatically.
- Sessions stay put. Source-IP persistence keeps each session on one node for its whole duration.
- Tested with sessions running. Cutover was proven by taking nodes out of service while sessions were live.
- Patching without a window. Session access survives the loss of a node, so patching no longer needs a maintenance window.
- Room to grow. Capacity grows by adding a node, and users keep the same connection address.
01Privileged usersOne connection address for everyone
one address
02Load balancerA single virtual address, with health checks
healthy node
03PSM poolThree PSM nodes, any one can drop out
brokered session
04Target systemsReached through whichever node is healthy
A failed or patched node is drained without an outage.
HTML5 Gateway
Privileged sessions run in the browser, and RDP is off the user's path
- Gateway deployed. The HTML5 Gateway runs with a public certificate and an external DNS name.
- HTTPS from the user. Session traffic from users now runs over port 443. RDP stays between the gateway and the PSM.
- Piloted first. The browser experience was validated with a pilot group before the wider rollout.
- Nothing to install. Vendors and remote staff connect from any browser, with no client software to deploy.
- Same audit trail. Port 3389 no longer needs to be open from user networks, and session recording and audit are unchanged.
BeforeRDP client
- An RDP client on every endpoint
- Port 3389 open from user networks to the PSM
NowHTML5 Gateway
- A browser, and nothing to install
- HTTPS 443 to the gateway; RDP stays inside the data center
Same PSM recording, policy and audit trail either way.
PTA upgrade and monitoring
Misuse now surfaces as an alert, not an audit finding
- Upgraded. PTA runs on a current, vendor-supported release.
- Fed continuously. Vault activity and PSM session data feed the analytics engine as they happen.
- Tuned, and sent to the SIEM. The detection set is enabled and tuned, with alerts forwarded to the SIEM.
- Minutes, not audits. Credential theft, vault bypass and irregular access are detected in minutes rather than found at audit.
- Automatic response. High-confidence detections rotate the credential or suspend the session automatically.
What PTA watchesApplied IAM
- Credential theftDetection
- Vault bypass or direct loginDetection
- Irregular access hoursDetection
- Suspicious session commandsDetection
High-confidence detections rotate the credential or suspend the session.
Discovery and onboarding rules
The privileged estate is mapped, and new accounts are vaulted by rule
A discovery scan was completed across Windows, Unix and service accounts, and the results now feed onboarding rules on a schedule.
1ScanDiscovery sweeps Windows, Unix and service accounts across the estate.
accounts found
2ClassifyAccounts sorted by risk: stale passwords, shared use, SSH key exposure.
risk sorted
3Onboard by ruleRules match platform, OU and naming pattern, then place the account in the right safe.
vaulted
4Stay currentScheduled scans catch new accounts, so coverage does not decay between projects.
New privileged accounts are vaulted automatically instead of waiting on a request, and coverage becomes a number that can be reported on and held steady between projects.
Central Credential Provider
Applications fetch passwords at runtime, so they are out of code
The Central Credential Provider is deployed and integrated with the first wave of applications. Before any credential is released, the application is authenticated by its path, hash, operating system user and certificate. Hardcoded passwords were removed from those scripts, configuration files and source control.
Because nothing breaks when a password changes, service account passwords now rotate on schedule, and every non-human retrieval is logged against the application that asked for it. The wider approach is on service account management.
01Application or scriptScheduled tasks and bots too
authenticates
02Central Credential ProviderChecks path, hash, OS user and certificate
releases
03VaultLogs every retrieval and rotates on schedule
Summary
What changed across the platform
| Initiative | Before | Now |
|---|---|---|
| PSM load balancer | Session access depended on one PSM server | Pooled PSM behind one address; nodes drain without an outage |
| PTA upgrade and monitoring | Misuse was found later, in logs | Vault and session activity scored continuously; alerts to the SIEM |
| HTML5 Gateway | RDP client on every endpoint; 3389 open to the PSM | Browser sessions over HTTPS; RDP stays in the data center |
| Discovery and onboarding rules | Unmanaged accounts found by hand, project by project | Estate mapped; new accounts vaulted by rule on a schedule |
| Central Credential Provider | Passwords held in scripts, config and source control | Applications authenticate and fetch credentials at runtime |
Repeatable?
Where this applies
Any CyberArk estate that is live but not finished: a single session server, monitoring that stopped at the last upgrade, discovery that never became routine, passwords still sitting in scripts. The same engineers delivered the endpoint privilege work for this retailer. For the delivery side, see CyberArk implementation; for what each module does, the CyberArk modules; and if you would rather not run it yourself, managed IAM services.
Find the gaps in your own CyberArk platform
A free audit is 30 minutes with a certified engineer on your own environment, with the findings in writing. No cost, no obligation.