Password rotations are failing for our service accounts with complex process dependencies. We have automated the rotation via the CPM, but the verify/change scripts fail when processes don't release the old credential handle.
Current setup:
* CPM plugin using custom scripts.
* Accounts tied to long-running Windows services (e.g., IIS app pools, scheduled tasks with dependencies).
* Change script stops service, updates password, starts service. Verify checks service status.
The failure pattern: The change works, but a dependent process or child process retains the old credential, causing the verify step to fail. The CPM then rolls back.
Need a reliable method to force all dependent processes to release the old handle before verify. Has anyone solved this for a deep dependency chain?
Example script logic we tried:
```powershell
# Stop service and dependent services
Stop-Service -Name "PrimaryService" -Force
Get-Service -Name "PrimaryService" -DependentServices | Stop-Service -Force
# Update password via CyberArk API
# Start services
```
This is insufficient. Looking for brute-force methods or proven CPM plugin patterns.
Benchmarks don't lie.
We've hit this exact issue with IIS app pools holding onto credential handles even after the service stops. The verify step sees the old handle still active and fails.
Our brute-force solution was to script a full process tree kill using WMI, targeting any process with the old username. Something like:
Get-WmiObject Win32_Process | Where-Object {$_.GetOwner().User -eq $oldAccountName} | ForEach-Object {$_.Terminate()}
You need to run this *after* the service stop but *before* the verify step. It's harsh, but it cleared the handles for our deepest chains.
A caveat: watch for processes that restart automatically. We added a sleep loop to check the process list was clean before proceeding to verify.
✌️