Windows policies

The Overview tab allows you to quickly access the following features of your policy:

• General

  Allows you to edit the description of your Workstyle and enable or disable it.

• Totals

  Allows you to configure the following types of rule:

  • Application Rules
  • On-Demand Application Rules
  • Content Rules

• Trusted Application Protection

  Allows you to configure the following type of rule:

  • Trusted Application DLL Protection

• General Rules

  Allows you to configure the following General Rules:

  • Collect User Information
  • Collect Host Information
  • Prohibit Privileged Account Management
  • Enable Windows Remote Management Connections

• Filters

  Allows you to configure the following Filters:

  • Account Filters
  • Computer Filters
  • Time Range Filters
  • Expiry Filter
  • WMI (Windows Management information) Filters

There are two components to rule scripts:

• Rule script
• (Optional) Settings file: Each rule script can have an optional Settings file which must be in a valid *.json format. They are useful for managing credentials required for integrations and other sensitive information.

BeyondTrust-supported integrations are available from BeyondTrust.

ℹ️

Note

Do not edit BeyondTrust-supported integrations, as this may affect the level of support we are able to provide.

While you can edit a rule script in the Script Manager, we recommend you import the completed script into the Script Manager.

To import a rule script:

1. Copy the PowerShell rule script (*.ps1) and associated settings (*.json) file somewhere locally so you can locate them from the Policy Editor.
2. Click the Run a Rule Script dropdown and select Manage Scripts.
3. Select the Rule Scripts node and click Import Script at the bottom of the dialog box.
4. Navigate to your PowerShell (*.ps1) file and click Open.
5. The script is loaded into the Script Manager.
6. Edit the rule script at this point, if required.
7. Optionally, change the Timeout settings. This is the time that Endpoint Privilege Management for Windows waits from the start of script execution for the script to complete before running the default rule.
8. Click Close to save your changes.

After you add a rule script (*.ps1), you can optionally add a Settings file (*.json) if one is required for the integration. The Settings file contains any information that is specific to your integration environment, such as URLs, usernames, and passwords. The Settings file is encrypted on the endpoint.

1. Go to Settings > Import Settings.
2. Navigate to and select your Settings file.
3. Click Open. Before you proceed, review and edit the Settings file in this window. Click Save to associate this Settings file with your rule script.
4. The name of the Settings file that is associated with your rule script is shown next to the Settings button. Click Settings to view the contents of your settings file at any time.

You can click Delete Settings at any time to clear the Settings window. Importing a new script overwrites the existing one.

After you associate a settings (*.json) file with a rule script (*.ps1), it is always associated with that rule script wherever you use it. For example, if you associate a settings file with a rule script for an Application Rule and select the same rule script in an On-Demand Application Rule, the same settings file is used. Changes to the settings or rule script file in either location are applied wherever it's used.

If you need to share the rule script you can export it. You cannot export the settings file because it is linked to the rule script.

To export an existing rule script:

1. From the Script Manager, click Export Script.
2. Navigate to where you want to save the script to and click Save.

ℹ️

Note

A rule script assigned to an Application Rule or an On-Demand Application Rule cannot be deleted.

To delete a rule script:

1. From the Script Manager, select the rule script and click Delete Script.
2. If the script is not used by an Application Rule or an On-Demand Application Rule, you are prompted to confirm the deletion.

A rule script is only assigned to an Application Group after you click Close on the Script Manager dialog box and click OK on the Edit Application Rule dialog box. Clicking Close on only the Script Manager does not associate a rule script with that Application Group.

You can create audit scripts using the Policy Editor.

To create an audit script:

1. Click New in the Audit Scripts node in the Script Manager.
2. You can choose the following options and enter your script directly into the Policy Editor.
   • Script Language: Choose from VB Script, Javascript, or PowerShell Script. Switching between languages clears all code in the script editor window.
   • Script Context: An audit script can run in the User or System context.
   • Timeout: The time that Endpoint Privilege Management for Windows waits from the start of script execution for the script to complete before activating the default rule options.
3. Click Close to save the changes.

Audit scripts can be imported in the Policy Editor.

To import an audit script:

1. Copy the audit script (*.vbs, *.js, or *.ps1) file somewhere locally so you can locate it from the Policy Editor.
2. Click either the Run a Rule Script or Run an Audit Script dropdown and click Manage Scripts.
3. Select the Audit Scripts node and click Import Script at the bottom of the dialog box.
4. Navigate to the audit script file and click Open.
5. The script is loaded into the Script Manager.
6. Edit the audit script here, if required.
7. Click Close to save your changes.

You can export an existing audit script if you need to share it.

To export an existing audit script:

1. From the Script Manager, click Export Script.
2. Navigate to where you want to save the script and click Save. The audit script is exported.

You can delete an audit script, even if it is assigned to an existing Application Rule.

To delete an audit script:

1. From the Script Manager, select the audit script and click Delete Script.

This rule, when enabled, raises an audit event each time a user logs onto the client machine. The audit event collects the following information, which is reported through the Reporting pack:

• Logon Time: The date and time the user logged on.
• Is Administrator: The client checks whether the user account has been granted local administrator rights either directly or through group membership.
• Session Type: The type of logon session, for example, console, RDP, or ICA.
• Session Locale: The regional settings of the user session/profile.
• Logon Client Session Hostname: The hostname of the client the user is logging on from. This is either the local computer (for Console sessions) or the remote device name (for remote sessions).
• Logon Client Session IP Address: The IP address of the client the user is logging on from. This is either the local computer (for console sessions) or the remote device name (for remote sessions).

This rule, when enabled, raises an audit event on computer start-up or when the Endpoint Privilege Management for Windows service is started. The audit event collects the following information, which is reported through the Reporting pack:

• Instance ID: A unique reference identifying a specific service start event.
• OS Version: The name and version of the operating system, including service pack.
• Chassis Type: The type of chassis of the client, for example, workstation, mobile, server, or VM.
• Language: The default system language.
• Location: The current region and time zone of the device.
• Client Version: The version of the Endpoint Privilege Management for Windows.
• Client Settings: The type of installation and current settings of the Endpoint Privilege Management for Windows.
• System Uptime: Time since the computer booted.
• Unexpected Service Start: Only added if the service has unexpectedly started (that is, a previous start was not proceeded by a service stop).

An additional event is raised if the computer shuts down, or if the Endpoint Privilege Management for Windows service is stopped:

• Instance ID: A unique reference identifying the last service start event.
• Computer Shutdown: Value identifying whether the service stopped as part of a computer shutdown event.

This option is only available in policies set under the Computer Configuration Group policy.

This rule, when enabled, blocks users from modifying local privileged group memberships. This prevents real administrators, or applications which have been granted administrative rights through Endpoint Privilege Management for Windows, from adding and/or removing and/or modifying a privileged account.

The list of local privileged groups that are prohibited from modification when this rule is enabled is:

• Built-in administrators
• Power users
• Account operators
• Server operators
• Printer operators
• Backup operators
• RAS servers group
• Network configuration operators

This rule provides three options:

• Not Configured: This Workstyle is ignored.
• Enabled: The user cannot add, remove, or modify user accounts in local privileged groups.
• Disabled: Default behavior based on the users rights or those of the application.

This rule, when enabled, authorizes standard users who match the Workstyle to connect to a computer remotely using WinRM, which would normally require local administrator rights. This general rule supports remote PowerShell command management, and must be enabled in order to allow a standard user to execute PowerShell scripts and/or commands.

To allow remote network connections, you may be required to enable the Windows Group Policy setting access this computer from the network.

Account filters specify the users and groups the Workstyle are applied to.

When a new Workstyle is created, a default account filter is added to target either Standard users only, or Everyone (including administrators), depending on your selection in the Workstyle wizard.

Configure account filters

1. On the Filter tab, click Add a filter.
2. Click Add an Account Filter > Add a new account.
3. Select the following to add groups:
   • From Local or Domain AD: Add an account or group name on the AD object dialog box. Enter the name and click Check Names to validate.
   • From Microsoft Entra ID: Add a group name on the Select Groups from Microsoft Entra ID dialog box. Enter the name and click Check Names to validate.
4. The group name is underlined when the name matches on an Active Directory or Microsoft Entra ID group name. Otherwise, an error message is displayed.

ℹ️

Note

When no filters exist on a Workstyle, it applies to all. Microsoft Entra ID group filters depend on Endpoint Privilege Management for Windows agent version 21.1 or later. Earlier Endpoint Privilege Management for Windows agent versions ignore Microsoft Entra ID filters.

Domain and well known accounts display a Security Identifier (SID). The SID is used by Endpoint Privilege Management for Windows, which avoids account lookup operations. For local accounts, the name is used by Endpoint Privilege Management for Windows, and the SID is looked up when the Workstyle is loaded by the client. Local Account appears in the SID column of the accounts list for local accounts.

By default, an account filter applies if any of the user or group accounts in the list match the user. If you have specified multiple user and group accounts within one account filter, and want to apply the Workstyle only if all entries in the account filter match, then check the option All items below should match.

You can add more than one account filter if you want the user to be a member of more than one group of accounts for the Workstyle to be applied.

If an account filter is added, but no user or group accounts are specified, a warning is displayed advising No accounts added, and the account filter is ignored.

ℹ️

Note

If All items below should match is enabled, and you have more than one user account listed, the Workstyle never applies, as the user cannot match two different user accounts.

A computer filter can be used to target specific computers and remote desktop clients. You can specify a computer using either its host/DNS name, or by an IP address.

• If the computer filter is intended to match the IP address of remote computers using remote desktop sessions, check the option Match the remote desktop (instead of the local computer).
• Use the asterisk wildcard (*) in any octet to include all addresses in that octet range, for example, 192.168.*.*. Alternatively, you can specify a particular range for any octet, for example, 192.168.0.0-254. Wildcards and ranges can be used in the same IP address, but not in the same octet.

To restrict the Workstyle to specific computers by IP address:

1. Select the Filters tab, and then click Add a new filter.
2. Click Add a Computer Filter > Add a new IP rule. The Add IP rule dialog box appears.
3. Enter the IP address manually, in the format 123.123.123.123.
4. Click Add.

To restrict the Workstyle to specific computers by hostname:

1. Select the Filters tab, and then click Add a Filter.
2. Click Add a Computer Filter > Add a new hostname rule. The Add hostname rule dialog box appears.
3. Enter one or more hostnames, separated by semicolons, or alternatively browse for one or more computers. You can use the * and ? wildcard characters in hostnames.
4. Click Add.
5. If the computer filter is intended to match the hostname of remote computers using remote desktop sessions, check the option Match the remote desktop (instead of the local computer).

ℹ️

Note

By default, a computer filter is applied if any of the computers or IP Addresses in the list match the computer or client. If you specified multiple entries, and want to apply the Workstyle only if all entries in the computer filter match, then check the option All items below should match.

If a computer filter is added, but no host names or IP addresses are specified, a warning is displayed advising No rules added, and the computer filter is ignored.

A time range filter can specify the hours of a day and days of week for a Workstyle to be applied.

To restrict a Workstyle to a specific date/time period of activity:

1. Select the Filters tab, and click Add a new filter.
2. Click on Add a Time Filter > Edit time restrictions. The Time Restrictions dialog box appears.
3. Select Active and Inactive times in the time grid by either selecting individual elements or dragging over areas with the left mouse button held down.
4. Click OK.

ℹ️

Note

Only one time filter can be added to a Workstyle.

The time filter is applied based on the user’s timezone by default. Uncheck the Use timezone of user for time restrictions (otherwise use UTC) box to use UTC for the timezone.

An expiry filter specifies an expiry date and time for a Workstyle.

To restrict a Workstyle to an expiry date and time:

1. Select the Filters tab, and click Add a new filter.
2. Click Add an Expiry Filter.
3. Set the date and time that you want the Workstyle to expire.

ℹ️

Note

Only one expiry filter can be added to a Workstyle.

The expiry time is applied based on the user’s timezone by default. Uncheck the Use timezone of user for Workstyle expiry (otherwise use UTC) box to use UTC for the timezone.

A WMI filter specifies if a Workstyle should be applied, based on the outcome of a WMI query.

The filter allows you to specify the following:

• Description: Free text to describe the WMI query.
• Namespace: Set the namespace that the query executes against. By default, this is root\CIMV2.
• Query: The WMI Query Language (WQL) statement to execute.
• Timeout: The time (in seconds) the client waits for a response before terminating the query. By default, no timeout is specified.

ℹ️

Note

Long running WMI queries result in delayed application launches. Therefore, we recommend a timeout be specified to ensure that queries are terminated in a timely manner.

When you execute a WMI query, the client checks if any rows of data are returned. If any data is returned, then the WMI query is successful. If no data is returned or an error is detected in the execution, the WMI query is unsuccessful.

It is possible for a WMI query to return many rows of data, in which case you can create more complex WQL statements using WHERE clauses. The more clauses you add to your statement, the fewer rows are likely to return, and the more specific your WMI query will be.

The WMI filter includes several default templates for common WMI queries. To add a new WMI query from a template, click Add a WMI template and use the instant search box to quickly find a template.

WQL statements can include parameterized values, which allow you to execute queries including select user, computer, and Endpoint Privilege Management for Windows properties.

ℹ️

Note

WMI queries are always run as SYSTEM, and cannot be executed against remote computers or network resources. WMI filters do not support impersonation levels, and can only be used with SELECT queries.

By default, a WMI filter applies if any of the WMI queries in the list return true. If you specified multiple WMI queries, and want to apply the Workstyle only if ALL queries return true, then check the option All items below should match.

If a WMI filter is added, but no WMI queries are specified, a warning is displayed advising No queries added and the WMI filter is ignored.

ℹ️

Note

For more information on how to use parameters, see Windows QuickStart policy summary.

The Groups section of the Custom Token specifies the groups that will be added or removed from the token.

To insert a group:

1. Select Groups from the top tab. The token groups appear in the right pane.
2. Right-click and select Add a new account.
3. Enter the object names and click Check Names to validate it.
4. By default, when you insert a group, the Add Account box is checked, and the group is added to the Custom Token. If you want to remove the group from the Custom Token, check the Remove box instead.

Domain and well-known groups display a Security Identifier (SID). The SID is used by Endpoint Privilege Management for Windows, which avoids account lookup operations. For local groups, the name is used by Endpoint Privilege Management for Windows, and the SID is looked up when the Custom Token is created by the client. Local Account appears in the SID column of the groups list for local groups.

By default, the owner of a Custom Token that includes the administrators group has the owner set to the administrators group. If the administrators group is not present in the Custom Token, then the user is set as the owner.

If you want the user to be the owner, regardless of the presence of the administrators group, check the Ensure the User is always the Token Owner box.

Anti-tamper protection

By default, Endpoint Privilege Management for Windows prevents elevated processes from tampering with the files, registry, and service that make up the client installation. It also prevents any elevated process from reading or writing to the local Endpoint Privilege Management for Windows policy cache.

⚠️

Important

Domain Controllers don't have the Local Users and Groups databases once they're promoted to a Domain Controller. Therefore, Endpoint Privilege Management for Windows cannot offer the Anti-Tamper feature for Domain Controllers.

To disable anti-tamper protection, uncheck the Enable anti-tamper protection box.

ℹ️

Note

Under normal circumstances, this option should remain enabled, except in scenarios where elevated tasks require access to protected areas. For instance, if you are using an elevated logon script to update the local Endpoint Privilege Management for Windows policy.

The Privileges section of the Custom Token specifies the privileges that are added to or removed from the Custom Token.

If you want to add a privilege to the Custom Token, then check the Add box for the relevant privilege. If you want to remove a privilege from the Custom Token, check the Remove box for the relevant privilege.

You can also select multiple privileges and use the following options on the right-click menu:

• Reset Privilege
• Add Privilege
• Remove Privilege
• Add Admin Privileges
• Remove Admin Privileges

To clear all of the privileges in the Custom Token before applying privileges, check the Remove all existing privileges in access token before applying privileges box. If this box is left unchecked, the privileges are added or removed from the user’s default Custom Token.

The Integrity Level section of the Custom Token specifies the integrity level for the Custom Token.

To set the integrity level:

1. Select the Integrity Level node in the left pane. The integrity levels appear in the right pane as radio buttons. 
2. Set the appropriate integrity level.

The integrity level should be set as follows:

The Process Access Rights section of a Custom Token allows you to specify which rights other processes has over a process launched with that Custom Token.

Tokens that include the administrators group have a secure set of access rights applied by default, which prevents code injection attacks on elevated processes initiated by processes running with standard user rights in the same session.

Check or uncheck the Access Right Name box to enable or disable a specific access right.

You can also select multiple privileges and use the following options on the right-click menu:

• Reset all to default
• Add Right
• Remove Right

The access rights should be set as follows:

Unlike other application types, Endpoint Privilege Management for Windows only manages the privileges for the installation of ActiveX controls. ActiveX controls usually require administrative rights to install, but once installed, they run with the standard privileges of the web browser.

1. Select the Application Group you want to add the ActiveX control to.
2. Right-click and select Insert Application > ActiveX Control.
3. Enter the Codebase (URL) if required. This is a full or partial URL that specifies the location of the ActiveX control.
4. Enter a description if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the executable and then click Next. You can configure:
   • ActiveX Codebase matches
   • CLSID matches
   • ActiveX Version matches
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open/Save common dialogs
7. Click OK. The ActiveX Control is added to the Application Group.

ℹ️

Note

For more information, see Advanced options.

1. Select the Application Group you want to add the application to.
2. Right-click and select Insert Application > Batch File .
3. You can leave the File or Folder Name blank to match on all applications of this type, type in a specific name or path manually, or click Browse File , Browse Folder, or Template.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the executable. You can configure:
   • File or Folder Name matches
   • Command Line matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Trusted Ownership matches
   • Application Requires Elevation (UAC)
   • Parent Process matches
   • Source URL matches
   • BeyondTrust Zone Identifier exists
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open and Save common dialogs
7. Click OK. The Active X Control is added to the Application Group.

COM elevations are a form of elevation which are typically initiated from Explorer, when an integrated task requires administrator rights. Explorer uses COM to launch the task with admin rights, without having to elevate Explorer. Every COM class has a unique identifier, called a CLSID, that is used to launch the task.

COM tasks usually trigger a Windows UAC prompt because they need administrative privileges to proceed. Endpoint Privilege Management for Windows allows you to target specific COM CLSIDs and assign privileges to the task without granting full administration rights to the user. COM based UAC prompts can also be targeted and replaced with custom messaging, where COM classes can be allowed and/or audited.

1. Select the Application Group you want to add the COM Class to.
2. Right-click and select Insert Application > COM Class .
3. Enter a Class ID (CLSID) if required. Endpoint Privilege Management for Windows extracts information from this for the criteria if required. Or click Browse Class or Template.
4. Enter a description if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the executable. COM classes are hosted by a COM server DLL or EXE, so COM classes can be validated from properties of the hosting COM server. You can configure:
   • File or Folder Name matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Product Name matches
   • Publisher matches
   • CLSID matches
   • App ID matches
   • COM Display Name matches
   • Product Description matches
   • Product Version matches
   • File Version matches
   • Trusted Ownership matches
   • Application Requires Elevation (UAC): Match if Application Requires Elevation (User Account Control) is always enabled, as COM classes require UAC to elevate
   • Source URL matches
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open/Save common dialogs
7. Click OK . The application is added to the Application Group.

1. Select the Application Group you want to add the application to.
2. Right-click and select Insert Application > Control Panel Applet.
3. You can leave the File or Folder Name blank to match on all applications of this type, type in a specific name or path manually, or click Browse File, Browse Folder, or Template.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the control panel applet. You can configure:
   • File or Folder Name matches
   • Command Line matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Product Name matches
   • Publisher matches
   • Product Description matches
   • Product Version matches
   • File Version matches
   • Trusted Ownership matches
   • Application Requires Elevation (UAC)
   • Parent Process matches
   • Source URL matches
   • BeyondTrust Zone Identifier exists
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open/Save common dialogs
7. Click OK. The Application is added to the Application Group.

1. Select the Application Group you want to add the application to.
2. Right-click and select Insert Application > Executable.
3. You can leave the File or Folder Name field blank to match on all applications of this type, type in a specific name or path manually, or click Browse File, Browse Folder, or Template.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the executable. You can configure:
   • File or Folder Name matches
   • Command Line matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Product Name matches
   • Publisher matches
   • Product Description matches
   • Product Version matches
   • File Version matches
   • Trusted Ownership matches
   • Application Requires Elevation (UAC)
   • Parent Process matches
   • Source URL matches
   • BeyondTrust Zone Identifier exists
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open/Save common dialogs
7. ClickOK. The application is added to the Application Group.

Endpoint Privilege Management for Windows allows standard users to install and uninstall Windows Installer packages that normally require local admin rights. Endpoint Privilege Management for Windows supports the following package types:

• Microsoft Software Installers (MSI)
• Microsoft Software Updates (MSU)
• Microsoft Software Patches (MSP)

When a Windows Installer package is added to an Application Group, and assigned to an Application Rule or On-Demand Application Rule, the action is applied to both the installation of the file, and also uninstallation when using Add/Remove Programs or Programs and Features.

Installer packages typically create child processes as part of the overall installation process. Therefore, we recommend when elevating MSI, MSU, or MSP packages, that the advanced option Allow child processes will match this application definition be enabled.

ℹ️

Note

If you want to apply more granular control over installer packages and their child processes, use the Child Process validation rule to allowlist or blocklist those processes that you want or do not want to inherit privileges from the parent software installation.

1. Select the Application Group you want to add the installer package to.
2. Right-click and select Insert Application > Installer Package.
3. You can leave the File or Folder Name blank to match on all applications of this type, type in a specific name or path manually, or click Browse File, Browse Folder or Template.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the installer package. You can configure:
   • File or Folder Name matches
   • Command Line matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Product Name matches
   • Publisher matches
   • Product Version matches
   • Product Code matches
   • Upgrade Code matches
   • Trusted Ownership matches
   • Application Requires Elevation (UAC)
   • Parent Process matches
   • Source URL matches
   • BeyondTrust Zone Identifier exists
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open/Save common dialogs
7. Click OK. The application is added to the Application Group.

1. Select the Application Group you want to add the application to.
2. Right-click and select Insert Application > Management Console....
3. You can leave the File or Folder Name blank to match on all applications of this type, type in a specific name or path manually, or click Browse File, Browse Folder, or Template.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the management console snap-ins. You can configure:
   • File or Folder Name matches
   • Command Line matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Publisher matches
   • Trusted Ownership matches
   • Application Requires Elevation (UAC)
   • Parent Process matches
   • Source URL matches
   • BeyondTrust Zone Identifier exists
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open/Save common dialogs
7. Click OK. The application is added to the Application Group.

Endpoint Privilege Management for Windows allows you to target specific PowerShell scripts and assign privileges to the script without granting local administration rights to the user. Scripts can also be blocked if they are not authorized or allowed.

1. Select the Application Group you want to add the PowerShell script to.
2. Right-click and select Insert Application > PowerShell Script .
3. You can leave the File or Folder Name blank to match on all applications of this type, type in a specific name or path manually, or click Browse File, Browse Folder or Template.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the PowerShell script. You can configure:
   • File or Folder Name matches
   • Command Line matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Publisher matches
   • Trusted Ownership matches
   • Parent Process matches
   • Source URL matches
   • BeyondTrust Zone Identifier exists
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open/Save common dialogs
7. Click OK. The application is added to the Application Group.

ℹ️

Note

A PowerShell script that contains only a single line is interpreted and matched as a PowerShell command, and does not match a PowerShell script definition. We recommend PowerShell that your scripts contain at least two lines of commands to ensure they are correctly matched as PowerShell scripts. This cannot be achieved by adding a comment to a script.

Example PowerShell configurations

Example

Create New Configuration, Save to Local File

# Import both Defendpoint cmdlet module
Import-Module 'C:\Program Files\Avecto\Privilege Guard Client\PowerShell\Avecto.Defendpoint.Cmdlets\Avecto.Defendpoint.Cmdlets.dll'
# Create a new variable containing a new Defendpoint Configuration Object
$PGConfig = New-Object Avecto.Defendpoint.Settings.Configuration


## Add License ##
# Create a new license object
$PGLicence = New-Object Avecto.Defendpoint.Settings.License
# Define license value
$PGLicence.Code = "5461E0D0-DE30-F282-7D67-A7C6-B011-2200"
# Add the License object to the local PG Config file
$PGConfig.Licenses.Add($PGLicence)

## Add Application Group ##
# Create an Application Group object
$AppGroup = new-object Avecto.Defendpoint.Settings.ApplicationGroup
# Define the value of the Application Group name
$AppGroup.name = "New App Group"
# Add the Application Group object to the local PG Config file
$PGConfig.ApplicationGroups.Add($AppGroup)

## Add Application ##
# Create an application object
$PGApplication = new-object Avecto.Defendpoint.Settings.Application $PGConfig
# Use the Get-DefendpointFileInformation to target Windows Calculator
$PGApplication = Get-DefendpointFileInformation -Path C:\windows\system32\calc.exe
# Add the application to the Application group
$PGConfig.ApplicationGroups[0].Applications.AddRange($PGApplication)

## Add Message ##
# Create a new message object
$PGMessage = New-Object Avecto.Defendpoint.Settings.message $PGConfig
#Define the message Name, Description and OK action and the type of message
$PGMessage.Name = "Elevation Prompt"
$PGMessage.Description = "An elevation message"
$PGMessage.OKAction = [Avecto.Defendpoint.Settings.Message+ActionType]::Proceed
$PGMessage.Notification = 0
# Define whether the message is displayed on a secure desktop
$PGMessage.ShowOnIsolatedDesktop = 1
# Define How the message contains
$PGMessage.HeaderType = [Avecto.Defendpoint.Settings.message+MsgHeaderType]::Default
$PGMessage.HideHeaderMessage = 0
$PGMessage.ShowLineOne = 1
$PGMessage.ShowLineTwo = 1
$PGMessage.ShowLineThree = 1
$PGMessage.ShowReferLink = 0
$PGMessage.ShowCancel = 1
$PGMessage.ShowCRInfoTip = 0
# Define whether a reason settings
$PGMessage.Reason = [Avecto.Defendpoint.Settings.message+ReasonType]::None
$PGMessage.CacheUserReasons = 0
# Define authorization settings
$PGMessage.PasswordCheck = 
Avecto.Defendpoint.Settings.message+AuthenticationPolicy]::None
$PGMessage.AuthenticationType = [Avecto.Defendpoint.Settings.message+MsgAuthenticationType]::Any
$PGMessage.RunAsAuthUser = 0
# Define Message strings
$PGMessage.MessageStrings.Caption = "This is an elevation message"
$PGMessage.MessageStrings.Header = "This is an elevation message header"
$PGMessage.MessageStrings.Body = "This is an elevation message body"
$PGMessage.MessageStrings.ReferURL = "http:\\www.bbc.co.uk"
$PGMessage.MessageStrings.ReferText = "This is an elevation message refer"
$PGMessage.MessageStrings.ProgramName = "This is a test Program Name"
$PGMessage.MessageStrings.ProgramPublisher = "This is a test Program Publisher"
$PGMessage.MessageStrings.PublisherUnknown = "This is a test Publisher Unknown"
$PGMessage.MessageStrings.ProgramPath = "This is a test Path"
$PGMessage.MessageStrings.ProgramPublisherNotVerifiedAppend = "This is a test verification failure"
$PGMessage.MessageStrings.RequestReason = "This is a test Request Reason"
$PGMessage.MessageStrings.ReasonError = "This is a test Reason Error"
$PGMessage.MessageStrings.Username = "This is a test Username"
$PGMessage.MessageStrings.Password = "This is a test Password"
$PGMessage.MessageStrings.Domain = "This is a test Domain"
$PGMessage.MessageStrings.InvalidCredentials = "This is a test Invalid Creds"
$PGMessage.MessageStrings.OKButton = "OK"
$PGMessage.MessageStrings.CancelButton = "Cancel"
# Add the PG Message to the PG Configuration
$PGConfig.Messages.Add($PGMessage)

## Add custom Token ##
# Create a new custom Token object
$PGToken = New-Object Avecto.Defendpoint.Settings.Token
# Define the Custom Token settings
$PGToken.Name = "Custom Token 1"
$PGToken.Description = "Custom Token 1"
$PGToken.ClearInheritedPrivileges = 0
$PGToken.SetAdminOwner = 1
$PGToken.EnableAntiTamper = 0
$PGToken.IntegrityLevel = Avecto.Defendpoint.Settings.Token+IntegrityLevelType]::High
# Add the Custom Token to the PG Configuration
$PGConfig.Tokens.Add($PGToken)

## Add Policy ##
# Create new policy object
$PGPolicy = new-object Avecto.Defendpoint.Settings.Policy $PGConfig
# Define policy details
$PGPolicy.Disabled = 0
$PGPolicy.Name = "Policy 1"
$PGPolicy.Description = "Policy 1"
# Add the policy to the PG Configurations
$PGConfig.Policies.Add($PGPolicy)

## Add Policy Rule ##
# Create a new policy rule
$PGPolicyRule = New-Object Avecto.Defendpoint.Settings.ApplicationAssignment PGConfig
# Define the Application rule settings
$PGPolicyRule.ApplicationGroup = $PGConfig.ApplicationGroups[0]
$PGPolicyRule.BlockExecution = 0
$PGPolicyRule.ShowMessage = 1
$PGPolicyRule.Message = $PGConfig.Messages[0]
$PGPolicyRule.TokenType = [Avecto.Defendpoint.Settings.Assignment+TokenTypeType]::AddAdmin
$PGPolicyRule.Audit = [Avecto.Defendpoint.Settings.Assignment+AuditType]::On
$PGPolicyRule.PrivilegeMonitoring = [Avecto.Defendpoint.Settings.Assignment+AuditType]::Off
$PGPolicyRule.ForwardEPO = 0
$PGConfig.Policies[0].ApplicationAssignments.Add($PGPolicyRule)

## Set the Defendpoint configuration to a local file and prompt for user confirmation ##
Set-DefendpointSettings -SettingsObject $PGConfig -Localfile –Confirm

Example

Open Local User Policy, Modify then Save

# Import the Defendpoint cmdlet module
Import-Module 'C:\Program Files\Avecto\Privilege Guard Client\PowerShell\Avecto.Defendpoint.Cmdlets\Avecto.Defendpoint.Cmdlets.dll'
# Get the local file policy Defendpoint Settings
$PGConfig = Get-DefendpointSettings -LocalFile
# Disable a policy
$PGPolicy = $PGConfig.Policies[0]
$PGPolicy.Disabled = 1
$PGConfig.Policies[0] = $PGPolicy
# Remove the PG License
$TargetLicense = $PGConfig.Licenses[0]
$PGConfig.Licenses.Remove($TargetLicense)
# Update an existing application definition to match on Filehash
$UpdateApp = $PGConfig.ApplicationGroups[0].Applications[0]
$UpdateApp.CheckFileHash = 1
$PGConfig.ApplicationGroups[0].Applications[0] = $UpdateApp
# Set the Defendpoint configuration to the local file policy and prompt for user confirmation
Set-DefendpointSettings -SettingsObject $PGConfig -LocalFile -Confirm

Example

Open Local Configuration and Save to Domain GPO

# Import the Defendpoint cmdlet module
Import-Module 'C:\Program Files\Avecto\Privilege Guard Client\PowerShell\Avecto.Defendpoint.Cmdlets\Avecto.Defendpoint.Cmdlets.dll'
# get the local Defendpoint configuration and set this to the domain computer policy, ensuring the user is prompted to confirm the change
Get-DefendpointSettings -LocalFile | Set-DefendpointSettings -Domain -LDAP "LDAP://My.Domain/CN={GUID},CN=Policies,CN=System,DC=My,DC=domain" –Confirm

1. Select the Application Group you want to add the application to.
2. Right-click and select Insert Application > Registry Settings .
3. You can leave the File or Folder Name blank to match on all applications of this type, type in a specific name or path manually, or click Browse File, Browse Folder, or Template.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the application. You can configure:
   • File or Folder Name matches
   • Command Line matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Trusted Ownership matches
   • Application Requires Elevation (UAC)
   • Parent Process matches
   • Source URL matches
   • BeyondTrust Zone Identifier exists
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open/Save common dialogs
7. Click OK. The application is added to the Application Group.

Endpoint Privilege Management for Windows provides an additional level of granularity for management of remote PowerShell cmdlets to ensure you can execute these commands without local administrator privileges on the target computer.

Get-service -Name *time* | restart-Service –PassThru

Endpoint Privilege Management for Windows allows you to target specific command strings and assign privileges to the command without granting local admin rights to the user. Commands can also be blocked if they are not authorized or allowed. All remote PowerShell commands are fully audited for visibility.

ℹ️

Note

We recommend allowlisting remote PowerShell commands with a general block rule to ensure unauthorized command variations are blocked.

To allow standard users to connect to a remote computer with Windows Remote Management, or WinRM (a privilege normally reserved for local administrator accounts), it is necessary to enable the General Rule Enable Windows Remote Management Connections. This rule grants standard users, who match the Endpoint Privilege Management for Windows Workstyle, the ability to connect using WinRM, and can be targeted to specific users, groups of users, or computers using Workstyle filters.

1. Select the Application Group you want to add the application to.
2. Right-click and select Insert Application > Remote PowerShell Command.
3. You can leave the Select reference script file blank to match on all applications of this files, type in a specific name or path manually, or click Browse Cmdlets. This lists the PowerShell cmdlets for the version of PowerShell that you installed. If the cmdlet you want to use is not listed because the target version of PowerShell is different, you can manually enter it.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the PowerShell command. You can configure:
   • Command Line matches: PowerShell removes double quotes from the Command Line before it is sent to the target. Command Line definitions that include double quotes are not matched by Endpoint Privilege Management for Windows for remote PowerShell commands.
6. Click OK. The application is added to the Application Group.

Messaging

Endpoint Privilege Management for Windows end user messaging includes limited support for remote PowerShell sessions; block messages can be assigned to Workstyle rules, which block remote PowerShell scripts and commands. If a block message is assigned to a Workstyle, which blocks a script or command, then the body message text of an assigned message is displayed in the remote console session as an error.

From within a remote PowerShell session, a script (.PS1) can be executed from a remote computer against a target computer. Normally this requires local administrator privileges on the target computer, with little control over the scripts that are executed, or the actions that the script performs.

Example

Invoke-Command -ComputerName RemoteServer -FilePath c:\script.ps1 –Credential xxx

Endpoint Privilege Management for Windows allows you to target specific PowerShell scripts remotely and assign privileges to the script without granting local administration rights to the user. Scripts can also be blocked if they are not authorized or allowed. All remote PowerShell scripts executed are fully audited for visibility.

ℹ️

Note

You must use the Invoke-Command cmdlet to run remote PowerShell scripts. Endpoint Privilege Management for Windows cannot target PowerShell scripts that are executed from a remote PowerShell session. Remote PowerShell scripts must be matched by either a SHA-1 File Hash or a Publisher (if the script has been digitally signed).

Endpoint Privilege Management for Windows allows you to elevate individual PowerShell scripts and commands which are executed from a remote machine. This eliminates the need for users to be logged on with an account which has local admin rights on the target computer. Instead, elevated privileges are assigned to specific commands and scripts which are defined in Application Groups, and applied by a Workstyle.

PowerShell scripts and commands can be allowed to block the use of unauthorized scripts, commands, and cmdlets. Granular auditing of all remote PowerShell activity provides an accurate audit trail of remote activity.

PowerShell definitions for scripts and commands are treated as separate application types, which allows you to differentiate between predefined scripts authorized by IT, and session-based ad hoc commands.

To allow standard users to connect to a remote computer with Windows Remote Management, or WinRM (a privilege normally reserved for local administrator accounts), it is necessary to enable the General Rule Enable Windows Remote Management Connections. This rule grants standard users who match the Endpoint Privilege Management for Windows Workstyle the ability to connect using WinRM, and can be targeted to specific users, groups of users, or computers using Workstyle filters.

1. Select the Application Group you want to add the Remote PowerShell script to.
2. Right-click and select Insert Application > Remote PowerShell Script.
3. You can leave the Select reference script file blank to match on all applications of this files, type in a specific name or path manually, or click Browse File.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the PowerShell script. You can configure:
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Publisher matches
6. Click OK. The application is added to the Application Group.

ℹ️

Note

Remote PowerShell scripts that contain only a single line are interpreted and matched as a Remote PowerShell Command, and fail to match a PowerShell script definition. We therefore recommend PowerShell scripts contain at least two lines of commands to ensure they are correctly matched as a script. This cannot be achieved by adding a comment to the script.

Messaging

Endpoint Privilege Management for Windows end user messaging includes limited support for remote PowerShell sessions; block messages can be assigned to Workstyle rules which block remote PowerShell scripts and commands. If a block message is assigned to a Workstyle which blocks a script or command, then the body message text of an assigned message is displayed in the remote console session as an error.

Endpoint Privilege Management for Windows allows standard users to uninstall Microsoft Software Installers (MSIs) and executables (EXEs) that would normally require local admin rights.

When the Uninstaller application type is added to an Application Group and assigned to an Application Rule in the Endpoint Privilege Management for Windows policy, the end user can uninstall applications using Programs and Features or, in Windows 10, Apps and Features.

The Uninstaller application type allows you to uninstall any EXE or MSI when it is associated with an Application Rule. As the process of uninstalling a file requires admin rights, you need to ensure when you target the Application Group in the Application Rules you set the access token to Add Full Admin.

ℹ️

Note

The Uninstaller type must be associated with an Application Rule. It does not apply to On-Demand Application Rules.

You cannot use the Uninstaller application type to uninstall the BeyondTrust Endpoint Privilege Management for Windows or the BeyondTrust EPM Adapter using Endpoint Privilege Management for Windows, irrespective of your user rights. The anti-tamper mechanism built into Endpoint Privilege Management for Windows prevents users from uninstalling Endpoint Privilege Management for Windows, and an uninstall attempt fails with an error message.

ℹ️

Note

If a user attempts to use Endpoint Privilege Management for Windows to modify the installation of Endpoint Privilege Management for Windows, for example, uninstall it, and they do not have an anti-tamper token applied, the default behavior for the user is used. For example, if Windows UAC is configured, the associated Windows prompt is displayed.

If you want to allow users to uninstall either BeyondTrust's Endpoint Privilege Management for Windows or the BeyondTrust EPM Adapter, you can do this by either:

• Logging in as a full administrator
• Elevating the Programs and Features control panel (or other controlling application) using a Custom access token that has anti-tamper disabled.

Upgrade considerations

Any pre 5.7 Uninstaller Application Groups which match all uninstallations are automatically upgraded when loaded by the Policy Editor to File or Folder Name matches *. These are honored by Endpoint Privilege Management for Windows.

Pre 5.7 versions of Endpoint Privilege Management for Windows no longer match the upgraded rules; the behavior is that of the native operating system in these cases.

If you do not want the native operating system behavior for uninstallers, please ensure that your clients are upgraded to the latest version before you deploy any policy which contains upgraded uninstaller rules.

1. Select the Application Group you want to add the uninstaller to.
2. Right-click and select Insert Application > Uninstaller.
3. Enter a description, if required. By default, this is the name of the application you're inserting.
4. Click Browse File to select an uninstaller file and populate the available matching criteria for the selected uninstaller file.
5. Configure the matching criteria for the executable. You can configure:
   • File or Folder Name matches
   • Product Name matches
   • Publisher matches
   • Upgrade Code matches

The Windows service type permits individual service operations to be allowed, so that standard users can start, stop, and configure services without the need to elevate tools such as the Service Control Manager.

1. Select the Application Group you want to add the application to.
2. Right-click and select Insert Application > Window Service.
3. You can leave the Service Name blank to match on all applications of this type, type in a specific name or path manually, or click Browse Services to browse the services on the local computer.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the windows services. You can configure:
   • File or Folder Name matches
   • Command Line matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Product Name matches
   • Publisher matches
   • Product Description matches
   • Product Version matches
   • File Version matches
   • Service Name matches
   • Service Display Name matches
   • Service Actions match
6. Click OK. The application is added to the Application Group.

The Windows Store application type can be used to elevate or block Windows Store applications.

Keep the following in mind when elevating Windows Store apps:

• Elevation of Store apps is only supported for Application Rules, not On-Demand Application Rules.
• Only Centennial Windows apps can be elevated. In the Microsoft Store, identity a Centennial app by checking for the following permission: Uses all system resources.

ℹ️

Note

When you use Endpoint Privilege Management for Windows to block a Windows Store application from launching and assign a block message to the Application Rule, the native Windows block message overrides the Endpoint Privilege Management for Windows block message, meaning it is not displayed. Event number 116 is still triggered if you have events set up in the Application Rule.

1. Select the Application Group you want to add the application to.
2. Right-click and select Insert Application > Windows Store Application.
3. Select the app to match on and click Next. You can specify an app by typing in a name or path manually, or by clicking Browse File, Browse Folder, or Template. Alternatively, you can leave the text box containing the File or Folder name blank to match on all applications of this type.
4. Enter a description, if required, and then click Next. By default, this is the name of the application you're inserting.
5. Select the Application Definition criteria you want to use for this app. The default is Package name, and you can also specify Publisher, Application Version, or Drive.
6. Select any Child Process options required for the app.
7. To add the application to the Application Group, click Finish.

ℹ️

Note

For more information, see Insert applications from templates.

1. Select the Application Group you want to add the application to.
2. Right-click and select Insert Application > Windows Script.
3. You can leave the File or Folder Name blank to match on all applications of this files, type in a specific name or path manually, or click Browse File, Browse Folder, or Template.
4. Enter a description, if required. By default, this is the name of the application you're inserting.
5. You need to configure the matching criteria for the executable. You can configure:
   • File or Folder Name matches
   • Command Line matches
   • Drive matches
   • File Hash (SHA-1 Fingerprint) matches
   • File Hash (SHA-256) matches
   • Publisher matches
   • Trusted Ownership matches
   • Application Requires Elevation (UAC)
   • Parent Process matches
   • Source URL matches
   • BeyondTrust Zone Identifier exists
6. You need to configure the Advanced Options for the application. You can configure:
   • Allow child processes will match this application definition
   • Force standard user rights on File Open/Save common dialogs
7. Click OK. The application is added to the Application Group.

1. Select the relevant Application Group.
2. Right-click the applications list in the details pane to access the context menu.
3. Select Insert Application and then select the Running Process from the sub-menu.
4. The Running Process dialog box appears.
5. Select Show processes from all users if you want to select a process from another user’s session.
6. Select the relevant process from the list. Click OK.

The Event Import wizard allows you to search from within any Endpoint Privilege Management for Windows event source, and create application definitions based on the properties collected by an audit event. The wizard provides a simple and convenient way to find specific applications based on any or all of the following search criteria:

• Event Source: Where the event is collected (Local or remote event log, Forwarded event log, or Enterprise reporting Pack database).
• Event Type: The type of event you are interested in. Choose Any application or choose from one of the following:
  • Applications that performed privileged operations
    • Event number 100
  • Applications that triggered UAC
    • If the UACTriggered flag on the event was set to 1
  • Applications that were blocked
    • Event number 116
  • Applications that were launched by the Shell Menu
    • Event numbers 101, 104, 107, 110, 114, and 119
• Timeframe: The period of time to search for applications. Choose from one of the following:
  • From: Pick a range starting from a predefined time period. From here you can also choose Anytime, to include all events.
  • Specific period: Pick an optional From and To date to include events collected during that period of time.

Once the search criteria is entered, the wizard returns a list of unique applications that were audited, matching the criteria you specified. From here you can browse the list (which is grouped by Publisher), or to find a particular application you can type into the Search publisher\Description field to instantly filter the list based on the text you enter.

Applications that are already members of the Application Group are highlighted and displayed with a check mark.

After you find an application or applications, select (or multi-select by holding down the Control or Shift key while selecting) and then click OK to create new application definitions from your selection.

Once the definitions are created, you can edit the definition and modify the matching criteria. All matching criteria are prepopulated with values collected from the application.

ℹ️

Note

A unique application is based on the product description of the application. So if two or more audited applications share the same product description, they are displayed as a single application.