Reference Targeting

This section explains how you target policies and configuration at applications, machines, operating systems, and users, and how variables and wildcards make targeting simpler and scalable.

Targeting Applications, Machines, Operating Systems & Users

Policies and deployment apply to who (users), what (applications, commands, files), and where (machines, operating systems). You control this through filters when you create a policy or deployment group.

Applications

• What it is: The executable or app that the user is running (or trying to run) when the policy is evaluated. For example, notepad.exe, cmd.exe, or a path like C:\Program Files\MyApp\app.exe.

• How you target: In the policy’s application filter, you specify which applications the policy applies to. You can use exact names, paths, or patterns with variables and wildcards (see below). This lets you allow or restrict elevation, file access, or command execution per app.

Machines

• What it is: The endpoint (computer or device) where the agent runs. Machines can be identified by hostname, deployment group, or other identifiers your console uses.

• How you target: In the policy’s machine filter (or in deployment group assignment), you choose which machines the policy applies to. You can use collections or groups so one policy covers many machines without listing each one.

Operating Systems

• What it is: The OS of the endpoint—Windows, Linux, or macOS. Keeper EPM supports all three; policies and jobs can be written to work across platforms or to be OS-specific.

• How you target: When you define policies or jobs, you can scope them by platform where needed. Path variables (see below) help keep paths correct on each OS.

Users

• What it is: The user account (or group) on the endpoint or in your directory (e.g., AD/Azure AD) that is performing the action.

• How you target: In the policy’s user filter, you specify which users (or groups) the policy applies to. Again, collections and wildcards can apply one policy to many users.

When all of the filters in a policy match (user, machine, application, and any time/date rules), the policy is considered for that request. The product then applies precedence rules (e.g., more specific policies override broader ones) and enforces the matching policy’s controls. For more on policy behavior, see Policies in Detail.

Variable Support

Variables are placeholders that resolve to real paths or values on each endpoint. They let you write one policy that works on many machines and operating systems without hard-coding paths.

Format

Variables use curly braces: {variableName}. For example, {userprofile} might resolve to C:\Users\jane on Windows or /Users/jane on macOS.

Common Variables (examples)

You can use variables such as these in policy filters and configuration (exact names depend on the product version; these are typical):

• All platforms: {rootdir}, {documents}, {userdesktop}, {home}, {tmp}.

• Windows: {systemroot}, {system32}, {programfiles}, {userprofile}, {appdata}, {programdata}, {temp}.

• Linux / macOS: {bin}, {etc}, {usr}, {var}, {applications} (macOS), {library} (macOS).

So instead of writing C:\Users\* or /Users/*, you can use {userprofile} or {home} and the same policy works on Windows and macOS. The product resolves these at evaluation time on each endpoint.

Why Use Variables

• Cross-platform: One policy works on Windows, Linux, and macOS.

• Maintainable: No need to update paths when drive letters or install locations change.

• Consistent: Same logical meaning everywhere (e.g., “user’s documents” is always {documents}).

Use variables wherever the console or policy editor supports them (e.g., in application paths, file paths, or folder filters).

Form more information on Variable support, visit the Reference: Variables page.

Wildcard Support

Wildcards let one rule match many names or paths so you don’t have to list every application or file.

Typical Behavior

• * usually means “match any characters” in that part of the name or path. For example, *.exe matches any executable ending in .exe; {programfiles}\*\*.exe might match any .exe under any subfolder of Program Files.

• Path variables can be combined with wildcards, e.g. {userprofile}\Documents\*.pdf to match all PDFs in the user’s Documents folder.

• Prefix matching is often used for folders: e.g., a folder filter of {downloads} might match all files in the user’s Downloads folder and its subfolders.

Exact wildcard and prefix rules can vary by policy type (e.g., application vs. file access). The dashboard or policy UI will show which patterns are supported where.

Why Use Wildcards

• Scale: One policy can cover many apps or files (e.g., “all scripts in this folder” or “all executables in Program Files”).

• Flexibility: New apps or files that match the pattern are automatically included.

• Simplicity: Fewer rules to maintain.

Use wildcards in application filters, file/folder filters, or command-line rules where the product supports them. Together with variables, they keep your policies powerful and easy to manage.

Form more information on Wildcard support, visit the Reference: Wildcard page.