Recently, I ran into an interesting issue with a custom IDIRA/CyberArk CPM TPC plugin that I use to manage passwords in One Identity.

The plugin had been working before, but suddenly password changes started failing.

At first, everything pointed toward the PowerShell script. After all, the TPC plugin launches PowerShell, the script makes the API calls to One Identity, and the failure appeared during that process.

But as is often the case with CPM troubleshooting, the first error was only part of the story.

In this post, I want to walk through what happened, the two separate problems I found, and why understanding the PluginManagerUser is important when troubleshooting custom CPM plugins.

How the Plugin Works

The plugin is a TPC-based CPM plugin.

At a high level, the workflow looks like this:

CPM
 |
 +-- Process.ini
 |
 +-- Prompts.ini
 |
 +-- PowerShell script
       |
       +-- Connect to One Identity
       +-- Build the API request
       +-- Change the password
       +-- Return the result to the TPC plugin

The Process.ini controls the execution flow, while Prompts.ini identifies the responses returned during the process.

The PowerShell script performs the actual interaction with the One Identity API.

When everything works, the process is straightforward:

CPM
  |
  v
TPC Plugin
  |
  v
PowerShell
  |
  v
One Identity API
  |
  v
Password changed

Then one day, it stopped working.

Problem 1: At line:1 char:143

The first error I saw in the TPC trace was:

At line:1 char:143

The plugin attempted to find a known prompt in Prompts.ini, but none of the expected responses matched.

Eventually, the generic standard prompt matched:

.*

At first, this made the problem look like an error inside the PowerShell script.

I tried adding things such as:

Write-Host

Write-Output

and even:

Start-Transcript

But nothing useful appeared in the logs.

That turned out to be an important clue.

The problem was happening before the PowerShell script was actually able to execute.

The Password Was Breaking the PowerShell Command

After looking more closely at the command generated by the TPC plugin, I found the first problem.

One of the passwords contained a special character:

*

The password was being inserted directly into the command used to launch PowerShell.

Conceptually, the TPC plugin was doing something similar to:

PowerShell.exe & ".\bin\MyPlugin.ps1" -uri <address> -serviceAccPass <password> -UpdateUserPass <newpassword>

Because the password became part of the PowerShell command line, the special character affected how PowerShell parsed the command.

The location reported by:

At line:1 char:143

was exactly where the problematic character appeared in the generated command.

This also explained why my Write-Host, Write-Output, and Start-Transcript debugging attempts didn’t help.

The execution was effectively:

TPC
 |
 v
Start PowerShell.exe
 |
 v
PowerShell parses command line
 |
 X  Parsing error
 |
 +--> At line:1 char:143

The script itself never got far enough to execute my debugging commands.

After correcting the password/argument handling problem, PowerShell could launch the script again.

But then I was back to the original problem.

Problem 2: A Strange File Called 1

Once the PowerShell parsing problem was solved, the plugin still wasn’t successfully managing the password.

This time I noticed something very unusual.

Every time the plugin failed, a file called simply:

1

with no extension was created under the CPM installation directory:

[Drive]:\Program Files (x86)\CyberArk\PasswordManager

That immediately changed the direction of my troubleshooting.

Why was the plugin creating a file in the root of the Password Manager installation instead of writing where it was supposed to?

This started looking less like an API problem and more like an execution-context or filesystem-permissions problem.

And then I performed a test that provided the most useful clue in the entire investigation.

The Test That Pointed Me Toward Permissions

As part of the troubleshooting, I temporarily added the following parameter to the CyberArk platform:

RunPluginWithHighPrivilege=Yes

Then I ran the password change again.

This time, the plugin worked successfully.

That was a major clue.

The PowerShell script was the same.

The One Identity API was the same.

The account being managed was the same.

The TPC logic was essentially the same.

But changing the privilege context under which the plugin executed changed the result from:

FAILURE

to:

SUCCESS

That immediately made me think:

If the plugin works with higher privileges but fails under its normal execution context, maybe the problem isn’t the plugin logic at all. Maybe the normal plugin user doesn’t have permission to access something it needs.

That shifted my investigation toward the Windows security context used to execute CPM plugins.

And that eventually led me to the PluginManagerUser.

Understanding the PluginManagerUser

The PluginManagerUser was introduced starting with CPM version 12.2.4.

It is a local Windows user involved in the CPM plugin execution architecture and is used by the CyberArk Password Manager service when executing plugins.

This separation is important from a security perspective.

We generally don’t want every plugin to execute with unnecessarily high privileges. The principle of least privilege applies here as well: a plugin should have only the permissions it requires to operate, rather than being granted elevated access to the server.

This also means that there can be an important difference between:

"I can run the PowerShell script successfully."

and:

"The CPM can run the PowerShell script successfully."

Those are not necessarily equivalent tests.

For example, I might log onto the CPM server and manually execute:

.\rb_OneIdentity-Change.ps1

under my administrative account.

The execution context is then something like:

Administrator
     |
     v
PowerShell
     |
     v
Script

But during normal CPM operation, the plugin is executed under the security controls and permissions associated with the CPM plugin infrastructure:

CPM
 |
 v
Plugin execution
 |
 v
PluginManagerUser context/permissions
 |
 v
PowerShell
 |
 v
Script

So a script working manually doesn’t necessarily prove that the CPM execution context has everything it needs.

Why RunPluginWithHighPrivilege=Yes Was Such an Important Test

This was probably the most useful diagnostic step in my troubleshooting.

The fact that:

RunPluginWithHighPrivilege=No

resulted in failure, while temporarily using:

RunPluginWithHighPrivilege=Yes

allowed the plugin to work, strongly pointed toward an execution-context or permissions difference.

It gave me a much narrower troubleshooting question:

What can the elevated execution context access that the normal PluginManagerUser context cannot?

Instead of continuing to modify the API calls or PowerShell logic, I started looking at:

• filesystem permissions;
• CPM folders;
• hardening;
• permissions assigned to PluginManagerUser;
• and directories the plugin might need during execution.

This is also why I would treat RunPluginWithHighPrivilege=Yes primarily as a troubleshooting clue in this scenario, rather than simply leaving it enabled as the fix.

If elevating the plugin resolves the problem, I want to understand why before deciding that elevation is necessary.

Finding the Actual Permissions Problem

Once I started looking at the problem from that perspective, things began to make sense.

I checked the permissions on the CPM directories and found that the PluginManagerUser did not have all the required permissions on the:

[Drive]:\Program Files (x86)\CyberArk\PasswordManager\Logs

directory.

I also found missing permissions associated with:

[Drive]:\Program Files (x86)\CyberArk\PasswordManager\Scanner

This was consistent with what I had observed.

The plugin worked when I forced it to execute with higher privileges, but failed under its normal security context.

After correcting the required permissions for PluginManagerUser, I removed the need to rely on the high-privilege test and executed the password management operation again.

This time:

CPM
 |
 v
TPC Plugin
 |
 v
PowerShell
 |
 v
One Identity API
 |
 v
Password successfully managed

The CPM was able to manage the One Identity password successfully again.

Hardened CPMs Make the Execution Context Even More Important

This becomes especially relevant on hardened CPM servers.

IDIRA/CyberArk has specific guidance around the PluginManagerUser profile and permissions when using the Web Application Framework on a hardened CPM.

That is an important reminder that hardening is not simply about restricting access.

The required execution accounts still need access to the specific resources that allow CPM components and plugins to function correctly.

A useful way of thinking about it is:

Too many permissions
        |
        v
Security problem
Correct permissions
        |
        v
Plugin works securely
Too few permissions
        |
        v
Plugin failure

The goal isn’t to give PluginManagerUser broad administrative permissions.

The goal is to make sure that the account has the specific permissions required by the CPM architecture and the plugin execution process.

That is why the high-privilege test was useful: it demonstrated that permissions were likely involved without making elevated execution the permanent solution.

Why This Incident Was Misleading

What made this troubleshooting particularly interesting was that I actually encountered two separate problems.

The first was:

At line:1 char:143

which led me to a special-character issue in the command used to launch PowerShell.

After resolving that, the original problem remained.

Then I noticed the unexpected:

1

file.

Finally, the high-privilege test gave me the key clue:

Normal plugin execution
        |
        X
      FAILURE
RunPluginWithHighPrivilege=Yes
        |
        v
      SUCCESS

That led me to investigate PluginManagerUser, where I eventually found the missing permissions.

My complete troubleshooting path therefore looked something like this:

Password change fails
        |
        v
"At line:1 char:143"
        |
        v
Inspect generated PowerShell command
        |
        v
Find special-character problem
        |
        v
Fix PowerShell invocation
        |
        v
Original failure remains
        |
        v
Notice unexpected file "1"
        |
        v
Test RunPluginWithHighPrivilege=Yes
        |
        v
Plugin works!
        |
        v
Suspect execution context/permissions
        |
        v
Investigate PluginManagerUser
        |
        v
Find missing permissions on Logs / Scanner
        |
        v
Correct permissions
        |
        v
Run plugin normally
        |
        v
SUCCESS

This is a good reminder that fixing one error doesn’t necessarily mean you have found the original root cause.

Sometimes you remove one layer of the problem only to expose the next one.

What I Would Check Next Time

If I encountered a similar TPC plugin problem again, I would keep a few things in mind.

1. Look at the exact PowerShell command

If the trace reports:

At line:1 char:143

don’t immediately assume it means line 143 of the .ps1 file.

Look at the command being passed to PowerShell.exe.

The error may be occurring while PowerShell is parsing the command that is supposed to launch your script.

2. Be Careful With Passwords as Command-Line Arguments

Passwords are unpredictable input.

A plugin may work perfectly with:

Password123

and fail when the next generated password contains a character that interacts badly with the way the command line is constructed.

A custom CPM plugin should be designed with the complete password policy in mind.

3. Compare Normal and Elevated Execution

If appropriate in your troubleshooting environment, comparing normal plugin execution with an elevated execution can provide a valuable diagnostic clue.

In my case:

RunPluginWithHighPrivilege=Yes

wasn’t the final solution.

It was the test that pointed me toward the solution.

4. Understand the PluginManagerUser

When troubleshooting modern CPM plugins, don’t forget about the Windows account under which plugin operations are being performed.

Check:

• folder permissions;
• user profile requirements;
• hardening;
• GPOs;
• local security policies;
• access to CPM directories;
• and anything else the plugin needs to read, write, or execute.

5. Pay Attention After CPM Hardening or Upgrades

If a plugin worked previously and starts failing after:

• a CPM upgrade;
• hardening changes;
• security baseline changes;
• GPO deployment;
• filesystem ACL modifications;

then permissions should be high on the troubleshooting list.

This is particularly important with PluginManagerUser, because a script may continue to work perfectly when tested manually by an administrator while failing when executed through the CPM.

Final Thoughts

The most useful lesson from this incident wasn’t specifically about One Identity, PowerShell, or even TPC plugins.

It was about execution context.

When developing or troubleshooting a CPM plugin, we naturally focus on:

Process.ini
     +
Prompts.ini
     +
PowerShell
     +
API

But underneath all of them there is another layer:

Windows security context
        +
Filesystem permissions
        +
CPM hardening

If that layer isn’t correct, a perfectly valid plugin can still fail.

In my case, the troubleshooting became much clearer when I temporarily tested:

RunPluginWithHighPrivilege=Yes

and the plugin suddenly worked.

That told me to stop asking:

“What’s wrong with my PowerShell?”

and start asking:

“What can this execution context access that the normal plugin execution context cannot?”

That question eventually led me to the missing PluginManagerUser permissions on the Logs and Scanner directories.

After correcting those permissions, the CPM was able to manage the One Identity passwords normally again without relying on the high-privilege workaround.

So if you ever find yourself thinking:

“The PowerShell works manually. Why doesn’t it work when CPM runs it?”

don’t just look at the script.

Look at who is running it — and what that user is allowed to access.

References

IDIRA/CyberArk Community — What are the differences between the PasswordManagerUser and PluginManagerUser?

Useful background for understanding the different Windows accounts associated with CPM operations and the role of PluginManagerUser.

IDIRA/CyberArk Community — CPM WebApplication Framework requires PluginManagerUser profile created for hardened CPM

Useful reference when investigating PluginManagerUser, CPM hardening, user-profile requirements, and the permissions required for plugin execution on a hardened CPM.