Redirect Capability

Audience: IT admins. This page describes the redirect capability: when a user is allowed to elevate, the product can substitute a different executable instead of launching the one they requested. The main example is ncpa.cpl (Windows Network Connections) redirected to Keeper.NetworkConnections.

---

What Redirect Does

When a privilege elevation request is allowed by policy, the LaunchPrivilegeElevation job normally launches the requested executable with elevation. In some cases the original executable does not behave correctly when launched via the product’s elevation flow (e.g. ephemeral account). Redirect lets you send the user to a substitute executable instead, so they get the intended functionality in a controlled way.

• User experience: The user still triggers the same action (e.g. “Open Network Connections”). Policy allows it; the product then denies launching the original process and launches the substitute elevated instead. The user sees the substitute app (e.g. Keeper.NetworkConnections) and can do what they need without standing admin rights.

• Control: Redirect rules are configured by you. You choose which executable + command-line combinations are redirected and to which substitute.

Redirect is enabled or disabled globally. When disabled, no redirect rules are evaluated and the normal launch-elevated flow is used.

---

Example: ncpa.cpl → Keeper.NetworkConnections

Scenario: On Windows, users often open Network Connections via rundll32.exe with ncpa.cpl on the command line. You want to allow that elevation for standard users, but launching the real rundll32 + ncpa.cpl through the product’s elevation path does not work correctly. Redirect sends these requests to Keeper.NetworkConnections instead—a dedicated UI that lets users manage network adapter properties (IP, DNS, etc.) without needing local admin.

Result: Standard users open “Network Connections” as usual; they get the Keeper.NetworkConnections UI instead of the OS dialog, with a seamless experience and least privilege preserved.

Rule Configuration

Redirect rules are defined in the RedirectEvaluator plugin configuration under metadata.redirect. Example for ncpa.cpl → Keeper.NetworkConnections:

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

What each field does:

Field	Meaning
sourceExePattern	Regex matched against the executable name of the request (e.g. rundll32.exe). Use \\. for a literal dot. Matching is case-insensitive.
commandLinePattern	Regex matched against the full command line (e.g. ncpa\\.cpl matches any command line containing ncpa.cpl). Case-insensitive.
elevationOnly	If true, this rule applies only to Privilege Elevation requests. Set to true for typical redirect behavior.
nonAdminOnly	If true, this rule applies only when the requesting user is not an administrator. Standard users get the substitute; admins can run the original if no other policy blocks it.
targetExe	Name of the substitute executable (e.g. Keeper.NetworkConnections). The product resolves this to a full path under Jobs/bin (or Plugins/bin). The substitute must be deployed on the endpoint.
targetArguments	Optional arguments for the substitute. Often empty ("").

Order: The first rule that matches the request is used. Put more specific rules before broader ones.

---

Flow When a Redirect Rule Matches

1. User triggers elevation for rundll32.exe with ncpa.cpl in the command line; user is a standard user (non-admin).

2. Policy allows the request; MFA, justification, or approval run if required.

3. LaunchPrivilegeElevation job runs. The check-redirect task runs only when redirect is enabled.

4. RedirectEvaluator is invoked with the request context (executable, command line, user, event type). It evaluates the rules and returns whether to redirect and which substitute to use.

5. If a rule matches:

   • The job sends DENY to the caller so the original exe is not launched.

   • The job launches the substitute (e.g. Keeper.NetworkConnections) elevated.

   • On success, the client is told the elevation succeeded; the user sees the substitute app (e.g. Network Connections UI).

If redirect is disabled or no rule matches, the job follows the normal path: launch the requested executable elevated and report success or failure.

---

Enabling and Disabling Redirect

• Configuration file: Plugins/RedirectEvaluator.json (under the Keeper Privilege Manager install directory).

  • metadata.redirect.enabled = true → redirect is on; check-redirect runs and rules are evaluated.

  • metadata.redirect.enabled = false → redirect is off; the check-redirect task does not run the RedirectEvaluator, and the job always uses the normal launch-elevated path.

• Pushing config: You can update RedirectEvaluator (including redirect rules) via a SettingsUpdate configuration policy so the dashboard or policy store writes the full plugin JSON to Plugins/RedirectEvaluator.json. The Process Configuration Policies job runs the configuration processor to apply it. After the file is updated, the product uses the new settings (reload may require a plugin restart or next request, depending on your version).

---

Keeper.NetworkConnections (substitute app)

Keeper.NetworkConnections is the substitute UI for Windows Network Connections. It lets standard users change network adapter properties (e.g. IP, DNS) without being added to special groups. Elevation is handled through the product’s ephemeral account and redirect flow.

• Deployment: Keeper.NetworkConnections must be built and deployed with the product (e.g. under Jobs/bin/Keeper.NetworkConnections/). If it is not present, redirect to it cannot launch the substitute.

• User entry points: Users can open it via the same path they use for “Network Connections” when you have the ncpa.cpl redirect rule above; they can also have a shortcut or menu item to “Network Connections (Enhanced)” or similar.

---

Adding or Changing Redirect Rules

1. Edit the RedirectEvaluator plugin configuration (the metadata.redirect section in Plugins/RedirectEvaluator.json).

2. Set redirect.enabled to true if you want redirect on.

3. Add or change objects in redirect.rules. Each rule has sourceExePattern, commandLinePattern, elevationOnly, nonAdminOnly, targetExe, targetArguments.

4. Order: First matching rule wins; put specific rules first.

5. Ensure the targetExe (e.g. Keeper.NetworkConnections) is deployed so the product can resolve it to a path under Jobs/bin or Plugins/bin.

Regex tips: Patterns are case-insensitive. Escape a literal dot as \\. (e.g. ncpa\\.cpl, rundll32\\.exe). Keep patterns specific enough to avoid redirecting unintended applications.

---

Summary

Topic	Detail
What redirect is	Substitute a different executable for an allowed elevation request so the user gets the right experience without launching the original exe.
ncpa.cpl example	Redirect rundll32 + ncpa.cpl (Network Connections) to Keeper.NetworkConnections for non-admin users.
Where to configure	Plugins/RedirectEvaluator.json → metadata.redirect.enabled and metadata.redirect.rules.
How to push	Use a SettingsUpdate policy targeting the RedirectEvaluator plugin and run Process Configuration Policies.
Substitute app	Keeper.NetworkConnections must be built and deployed (e.g. under Jobs/bin) for the ncpa.cpl redirect to work.

Return to Reference Index