Policy: Launch File Redirect

Context: LaunchPrivilegeElevation job (no separate example project)


Overview

When a privilege-elevation request is allowed by policy, the LaunchPrivilegeElevation job can redirect to a substitute executable instead of launching the one requested. This is used when the original request is allowed but the OS or environment makes the original executable unsuitable (e.g. rundll32 with ncpa.cpl does not behave correctly when launched via the ephemeral account). Redirect is implemented inside the existing LaunchPrivilegeElevation job; policy evaluation and controls (MFA, justification, approval) are unchanged.

Key behavior:

  • Redirect is enabled or disabled via the RedirectEvaluator plugin setting metadata.redirect.enabled.

  • When a rule matches: the job sends DENY to the caller and launches the substitute executable elevated (e.g. Keeper.NetworkConnections).

  • When redirect is disabled or no rule matches: normal flow (launch requested exe elevated; on success send DidElevate).


Example: rundll32 + ncpa.cpl → Keeper.NetworkConnections

Scenario: User (non-admin) requests elevation for rundll32.exe with command line containing ncpa.cpl (Network Connections Control Panel). Policy allows it, but launching that combination via the ephemeral account does not work correctly. Redirect substitutes Keeper.NetworkConnections so the user gets the intended functionality.

Rule configuration

Rules are defined in RedirectEvaluator plugin configuration under metadata.redirect.rules. Example rule:

  • sourceExePattern: Regex; matched case-insensitively against the requested executable (e.g. rundll32.exe).

  • commandLinePattern: Regex; unanchored so it acts as “contains” (e.g. ncpa\.cpl matches any command line containing ncpa.cpl).

  • elevationOnly: true — only for privilege-elevation requests (already implied in LaunchPrivilegeElevation).

  • nonAdminOnly: true — redirect only when the requesting user is not an administrator.

  • targetExe: Resolved to a full path from Jobs/bin (e.g. Keeper.NetworkConnectionsJobs/bin/Keeper.NetworkConnections/...).

  • targetArguments: Command line for the substitute (empty string here).

Flow when the example rule matches

1

User Requests Elevation (Non-Admin)

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

2

Policy Evaluation & Access Controls

Policy allows the request; controls (MFA, justification, approval) run as usual.

3

Elevation Job Starts — Redirect Check

LaunchPrivilegeElevation job runs. First task: check-redirect (runs only when metadata.redirect.enabled is true).

4

RedirectEvaluator Invoked & Output Merged

RedirectEvaluator is invoked with context (FilePath, CommandLine, IsAdmin, OriginalEventType — the job passes the event type string, e.g. "PrivilegeElevation", so redirect rules work for both approval and justification paths). It returns JSON (camelCase) to stdout; the executor merges it and adds PascalCase aliases so conditions and launch-substitute see DenyOriginalRequest: true, RedirectTargetExe: "Keeper.NetworkConnections", RedirectTargetArgs: "".

5

Job Branches on Redirect Outcome

Job branches on redirect:

  • send-deny-redirect — publish DENY to the caller so the original exe is not launched.

  • launch-substitute — HTTP POST to launch-elevated with the resolved substitute path and args.

  • On success, send-did-elevate-response (DidElevate) so the client shows success; the user sees Network Connections as intended.

Enabling and Disabling Redirect

  • Plugin config: KeeperPrivilegeManager/Plugins/RedirectEvaluator.json

    • metadata.redirect.enabled: true = redirect on; false = redirect off (normal launch-elevated flow).

  • When disabled, the check-redirect task does not run the RedirectEvaluator executable; it sets DenyOriginalRequest: false in context and the job continues with the normal launch-elevated path.

Path resolution

RedirectTargetExe (e.g. Keeper.NetworkConnections) is resolved to a full path by the task executor before the launch-substitute HTTP call:

  • The executor resolves the name against Jobs/bin (and Plugins/bin as applicable), e.g. Jobs/bin/Keeper.NetworkConnections/.

  • Keeper.NetworkConnections is deployed under Jobs/bin/Keeper.NetworkConnections/ (e.g. via Setup-TestEnvironment.ps1 or your deployment process).

  • Only resolved paths under the manager’s control (Jobs/bin or approved plugin paths) are used for the substitute launch.


Last updated

Was this helpful?