Plugin: Redirect Evaluator

Field

Description

sourceExePattern	The executable to intercept, matched by name (e.g. rundll32\.exe).
commandLinePattern	A pattern matched against the full command line (e.g. ncpa\.cpl). Use this to narrow a rule to a specific invocation of an executable.
elevationOnly	When true, the rule only applies to privilege elevation requests. Recommended for most redirect scenarios.
nonAdminOnly	When true, the rule only applies to standard (non-admin) users. Admins are unaffected and run the original process as normal.
targetExe	The substitute application to launch (e.g. Keeper.NetworkConnections). Must be a deployed EPM plugin or executable.
targetArguments	Optional arguments to pass to the substitute. Leave empty if none are needed.

Audience: IT admins. This page describes RedirectEvaluator, the EPM plugin that intercepts allowed privilege elevation requests and routes them to a substitute application instead of launching the original elevated process.

What RedirectEvaluator Does

When EPM allows a privilege elevation request, it normally launches the requested executable with elevation. RedirectEvaluator sits inside that flow and gives you the ability to substitute a different application instead — so the user gets the functionality they need through a controlled path, without the original process ever running elevated.

A common example: a standard user opens Windows Network Connections (rundll32.exe + ncpa.cpl). Rather than elevating that system process, RedirectEvaluator intercepts the request and launches Keeper.NetworkConnections instead. The user gets the same result through a purpose-built UI; the original privileged process never runs.

Redirect is additive — it only activates after policy has already allowed the request. All standard controls (MFA, justification, approval) run first, unchanged.

How It Works

RedirectEvaluator runs as the first task in the LaunchPrivilegeElevation job whenever redirect is enabled:

1. A privilege elevation request comes in and is allowed by policy.

2. The LaunchPrivilegeElevation job starts. The check-redirect task invokes RedirectEvaluator with the request context: executable path, command line, user admin status, and event type.

3. RedirectEvaluator fetches its active rules via GET /api/PluginSettings/RedirectEvaluator and evaluates them in order. The first matching rule wins.

4. If a rule matches: RedirectEvaluator returns the substitute target. The job sends DENY to the caller (so the original executable is not launched) and launches the substitute elevated instead. The user sees the substitute app.

5. If no rule matches or redirect is disabled: The job proceeds normally — the originally requested executable is launched elevated.

RedirectEvaluator runs as a Service-execution-type process task. Its output is a single JSON object (denyOriginalRequest, redirectTargetExe, redirectTargetArgs) that is merged into the job context and acted on by subsequent tasks.

Deployment

RedirectEvaluator is deployed as part of the standard EPM component set:

• Location: Jobs/bin/RedirectEvaluator/

• Configuration file: KeeperPrivilegeManager/Plugins/RedirectEvaluator.json

• Required companion job: LaunchPrivilegeElevation — redirect runs inside this job and has no effect without it.

• Substitute apps (e.g. Keeper.NetworkConnections) must also be deployed under Jobs/bin/ for RedirectEvaluator to resolve and launch them.

Redirect Rules

Rules are defined under metadata.redirect.rules in Plugins/RedirectEvaluator.json. Each rule specifies what to intercept and what to launch instead.

Field	Description
sourceExePattern	Regex matched against the executable name of the elevation request (e.g. rundll32\.exe). Case-insensitive. Use \. for a literal dot.
commandLinePattern	Regex matched against the full command line. Acts as a "contains" match. Cannot be empty — use .* to match any command line.
elevationOnly	When true, the rule applies only to Privilege Elevation requests. Recommended for most redirect scenarios.
nonAdminOnly	When true, the rule applies only to standard (non-admin) users. Admins are unaffected and run the original process.
targetExe	Short name of the substitute to launch (e.g. Keeper.NetworkConnections). Resolved to a full path from Jobs/bin/ or Plugins/bin/.
targetArguments	Optional arguments passed to the substitute. Leave empty if none are needed.

Rules are evaluated in order. The first matching rule wins — put more specific rules before broader ones.

Built-in Example: ncpa.cpl → Keeper.NetworkConnections

The default configuration ships with a rule for Windows Network Connections:

"redirect": {
  "enabled": true,
  "rules": [
    {
      "sourceExePattern": "rundll32\\.exe",
      "commandLinePattern": "ncpa\\.cpl",
      "elevationOnly": true,
      "nonAdminOnly": true,
      "targetExe": "Keeper.NetworkConnections",
      "targetArguments": ""
    }
  ]
}

This intercepts any elevation request where rundll32.exe is called with ncpa.cpl on the command line, for non-admin users only. Matching requests are redirected to the Keeper Network Connections UI with no extra arguments. Admins are unaffected.

Enabling and Disabling Redirect

Redirect is controlled by a single flag in Plugins/RedirectEvaluator.json:

• metadata.redirect.enabled: true — redirect is on; rules are evaluated for every allowed elevation request.

• metadata.redirect.enabled: false — redirect is off; the check-redirect task is skipped entirely and the normal launch-elevated path runs.

When disabled, RedirectEvaluator is not invoked at all — there is no performance impact on the elevation flow.

Deploying Configuration Centrally

Rather than editing Plugins/RedirectEvaluator.json on each endpoint manually, redirect rules can be pushed centrally using a SettingsUpdate policy:

{
  "PolicyId": "redirect-evaluator-ncpa-redirect",
  "PolicyName": "Redirect ncpa.cpl to Keeper.NetworkConnections",
  "PolicyType": "SettingsUpdate",
  "Status": "enabled",
  "Extension": {
    "PluginName": "RedirectEvaluator",
    "Action": "Update",
    "SettingsJson": "{ ...full RedirectEvaluator plugin JSON including metadata.redirect... }"
  }
}

SettingsJson must contain the complete plugin JSON — the existing file on the endpoint is replaced entirely when the policy is applied, not merged. Build the inner JSON separately and serialize it into the SettingsJson string to avoid escaping errors.

Once the policy is deployed and the Process Configuration Policies job runs, the updated configuration is written to Plugins/RedirectEvaluator.json. A service restart may be required depending on your deployment version.

Note on tamper protection: If EPM detects that Plugins/RedirectEvaluator.json was modified outside of the normal policy flow, it may skip reloading the file on hot reload. In that case, a full service restart is required for changes to take effect. Pushing settings via the management console into Unified Storage avoids this constraint.

Summary

Topic	Detail
What it does	Substitutes a different executable for an allowed elevation request
When it runs	Inside LaunchPrivilegeElevation, after policy allows the request and before the elevated launch
Where to configure	Plugins/RedirectEvaluator.json → metadata.redirect.enabled and metadata.redirect.rules
Rule matching	First matching rule wins; ordered by specificity
Enabling/disabling	metadata.redirect.enabled — no service restart required to toggle
Deploying rules	SettingsUpdate policy + Process Configuration Policies job
Substitute app requirement	Target must be deployed under Jobs/bin/ or Plugins/bin/
Built-in example	rundll32.exe + ncpa.cpl → Keeper.NetworkConnections for non-admin users