Application Groups

Application Groups are used to define logical groupings of applications.

Application Groups are assigned to Workstyles, so you must define Application Groups for all of the applications you want to assign to a Workstyle.

Show Hidden Application Groups

  1. On the Policy Editor page, expand Windows.
  2. Select Application Groups, and then select Show Hidden.

Create an Application Group

  1. On the Policy Editor page, expand Windows.
  2. Select Application Groups.
  3. Select Create New Application Group.
  4. Add a name and description. Click Create Application Group.
  5. The Application Group is now displayed in the navigation pane and the grid. You are now ready to add applications to the group.

View or Edit the Properties of an Application Group

  1. On the Policy Editor page, expand Windows.
  2. Select Application Groups.
  3. Select an Application Group in the list, and select Edit from the menu.
  4. Change the properties.
  5. Click Save Changes.

Delete

  1. On the Policy Editor page, expand Windows.
  2. Select Application Groups.
  3. Select an Application Group in the list, and select Delete from the menu.

Duplicate

  1. On the Policy Editor page, expand Windows.
  2. Select Application Groups.
  3. Select an Application Group in the list, and select Duplicate from the menu.
  4. Select the duplicated group and change the settings, as required.

Add an Application to an Application Group

When adding an application, you can configure the following components:

  • Application Definitions: The application definitions are the properties of an application that are used to detect the application in your environment. When the application matches on the configured criteria the rule triggers.
  • Advanced Options: When adding the application, advanced settings on child processes and standard user rights enforcement can be configured.
For more information, please see the following:

 When adding file or folder paths, you can use environment variables as part of the entry. Using environment variables is optional.

For more information, please see Environment Variables

You can add applications using a template. Application templates provide a way to pick from a list of known applications.

For more information, please see Add an Application From a Template.

The procedure for adding an application is generally the same for every application. The matching criteria varies depending on the application.

To add an application:

  1. In the navigation pane, select the Application Group.
  2. Click Create New Application, and then select the application type you want to add.
  1. Enter a description, if required. By default, this is the name of the application you're inserting.
  2. Configure the matching criteria for the application.
  1. 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
  1. Click OK. The application is added to the Application Group.
For more information about advanced options, please see Advanced Options

Add an Application From Reports

You can add an application to a policy based on events generated from a particular application type.

  1. In the console, select the Reports tile.
  2. Expand Events and select All or Process Detail.

Web Policy Editor add event to policy from the Events page

  1. Select events in the list and select Add to Policy. The Policy Editor opens.

 

  1. On the Add Application to Policy page, select a policy and an Application Group.
  2. Select Add and Edit. Alternatively, select Add and Close here which adds the application to the Application Group and redirects you back to the report.
  3. The policy opens to the Application Groups > Applications page where you can edit the application settings.

Add an Application From a Template

Application templates provide a way to pick from a list of known applications. A standard set of templates is provided that covers basic administrative tasks for all supported operating systems, common ActiveX controls, and software updaters.

  1. On the Policy Editor page, navigate to the policy to update.
  2. Go to Application Groups > Applications, and then select Add From Templates.
  3. Select an application template from the list, and then click Add. You can select more than one template at a time.

Application Definitions

The Policy Editor must match every enabled criteria in an application definition before it will trigger a match (the rules are combined with a logical AND).

Application definitions that require a match can also be negated. To target applications that do not match the definition, select does NOT match.

NameDescription
ActiveX Codebase matches

When inserting ActiveX controls, this is enabled by default and we recommend you use this option in most circumstances. You must enter the URL to the codebase for the ActiveX control. You can choose to match based on the following options (wildcard characters ? and * may be used):

  • Exact Match
  • Starts With
  • Ends With
  • Contains
  • Regular Expressions

Although you can enter a relative codebase name, we strongly recommend you enter the full URL to the codebase, as it is more secure.

ActiveX Version matchesIf the ActiveX control you entered has a version property, then you can choose Check Min Version and/or Check Max Version and edit the respective version number fields.
App ID matches

Matches on the App ID of the COM class, which is a GUID used by Windows to set properties for a CLSID. AppIds can be used by 1 or more CLSIDs.

The available operators are identical to the File or Folder Name definition.

Application Requires Elevation (UAC)This option can be used to check if an executable requires elevated rights to run and would cause UAC (User Account Control) to trigger. This is a useful way to replace inappropriate UAC prompts with PMC end user messages to either block or prompt the user for elevation.
Application Requires Elevation (UAC)

This option can be used to check if an MSI requires elevated rights to run and would cause User Account Control (UAC) to trigger.

This is supported on install only.

BeyondTrust Zone Identifier exists

This options allows you to match on the BeyondTrust Zone Identifier tag, where present. If an Alternate Data Stream (ADS) tag is applied by the browser, we also apply a BeyondTrust Zone Identifier tag to the file. The BeyondTrust Zone Identifier tag can be used as matching criteria if required.

CLSID matches

This option allows you to match the class ID of the ActiveX control or COM class, which is a unique GUID stored in the registry.

COM Display Name matches

If the class you entered has a Display Name, then it will automatically be extracted and you can choose to match on this property. By default, a substring match is attempted (Contains). Alternatively, you may choose to pattern match based on either a wildcard match (? and *) or a regular expression. The available operators are identical to File or Folder Name definition.

Command Line matches

If the filename is not specific enough, you can match the command line, by checking this option and entering the command line to match. By default, a substring match is attempted (Contains). Alternatively, you may choose to pattern match based on either a wildcard match (? and *) or a regular expression. The available operators are identical to File or Folder Name definition.

PowerShell removes double quotes from command strings prior to transmitting to the target. Therefore, we do not recommend that Command Line definitions include double quotes, as they will fail to match the command.

Controlling Process matches

This option allows you to target content based on the process (application) that will be used to open the content file. The application must be added to an Application Group. You can also define whether any parent of the application will match the definition.

Drive matches

This option can be used to check the type of disk drive where the file is located. Choose from one of the following options:

  • Fixed disk: Any drive that is identified as being an internal hard disk.
  • Network: Any drive that is identified as a network share.
  • RAM disk: Any drive that is identified as a RAM drive.
  • Any Removable Drive or Media: If you want to target any removable drive or media, but are unsure of the specific drive type, choose this option which will match any of the removable media types below. Alternatively, if you want to target a specific type, choose from one of the following removable media types:
    • Removable Media: Any drive that is identified as removable media.
    • USB: Any drive that is identified as a disk connected by USB.
    • CD/DVD: Any drive that is identified as a CD or DVD drive.
    • eSATA Drive: Any drive that is identified as a disk connected by eSATA.
File or Folder Name matches

Applications are validated by matching the file or folder name. You can choose to match based on the following options (wildcard characters ? and * may be used):

  • Exact Match
  • Starts With
  • Ends With
  • Contains
  • Regular Expressions

For more information, please see Regular Expression Syntax.

Although you can enter relative file names, we strongly recommend you enter the full path to a file or the COM server. Environment variables are also supported.

We do not recommend you use the definition File or Folder Name does NOT Match in isolation for executable types, as it will result in matching every application, including hosted types, such as installer packages, scripts, batch files, registry files, management consoles, and Control Panel applets.

When creating blocking rules for applications or content, and the File or Folder Name is used as matching criteria against paths which exist on network shares, this should be done using the UNC network path and not by the mapped drive letter.

File Hash (SHA-1 Fingerprint) matchesIf a reference file was entered, then a SHA-1 hash of the PowerShell script will be generated. This definition ensures the contents or the script file (which can normally be edited by any user) remain unchanged, as changing a single character in the script will cause the SHA-1 Hash to change.
File Version matchesIf the file, service executable, or COM server you entered has a File Version property, then it will automatically be extracted and you can choose Check Min Version and/or Check Max Version, and edit the respective version number fields.
Parent Process matchesThis option can be used to check if an application’s parent process matches a specific Application Group. You must create an Application Group for this purpose or specify an existing Application Group in the Parent Process group. Setting match all parents in tree to True will traverse the complete parent/child hierarchy for the application, looking for any matching parent process, whereas setting this option to False will only check the application’s direct parent process.
Product Code matchesIf the file you entered has a Product Code, then it will automatically be extracted and you can choose to check this code.
Product Description matchesIf the file you entered has a Product Description property, then it will automatically be extracted, and you can choose to match on this property. By default, a substring match is attempted (Contains). Alternatively, you may choose to pattern match based on either a wildcard match (? and *) or a Regular Expression. The available operators are identical to the File or Folder Name definition.
Product Name matchesIf the file, COM server, or service executable you entered has a Product Name property, then it will automatically be extracted and you can choose to match on this property. By default, a substring match is attempted (Contains). Alternatively, you may choose to pattern match based on either a wildcard match (? and *) or a Regular Expression. The available operators are identical to the File or Folder Name definition.
Product Version matchesIf the file, COM server, or service executable you entered has a Product Version property, then it will automatically be extracted and you can choose Check Min Version and/or Check Max Version and edit the respective version number fields.
Publisher matches

Check for the existence of a valid publisher. If you browsed for an application, then the certificate subject name will automatically be retrieved, if the application is signed. For Windows system files, the Windows security catalog is searched, and if a match is found, the certificate for the security catalog is retrieved. Publisher checks are supported on Executables, Control Panel Applets, Installer Packages, Windows Scripts, and PowerShell Scripts. By default, a substring match is attempted (Contains).

Alternatively, you may choose to pattern match based on either a wildcard match (? and *) or a Regular Expression. The available operators are identical to the File or Folder Name definition.

Service Actions match

Define the actions which are allowed. Choose from:

  • Service Stop: Grants permission to stop the service.
  • Service Start: Grants permission to start the service.
  • Service Pause / Resume: Grants permission to pause and resume the service.
  • Service Configure: Grants permission to edit the properties of the service.
Service Display Name matches

Matches on the name of the Windows service, for example, W32Time. You may choose to match based on the following options (wildcard characters ? and * may be used):

  • Exact Match
  • Starts With
  • Ends With
  • Contains
  • Regular Expressions
Service Name matches

Matches on the name of the Windows service, for example, W32Time. You may choose to match based on the following options (wildcard characters ? and * may be used):

  • Exact Match
  • Starts With
  • Ends With
  • Contains
  • Regular Expressions
Source URL matches

If an application was downloaded using a web browser, this option can be used to check where the application or installer was originally downloaded from. The application is tracked by Privilege Management for Windows at the point it is downloaded, so that if a user decided to run the application or installer at a later date, the source URL can still be verified. By default, a substring match is attempted (Contains). Alternatively, you may choose to pattern match based on either a wildcard match (? and *) or a Regular Expression. The available operators are identical to the File or Folder Name definition.

Trusted Ownership matches

This option can be used to check if an application’s file is owned by a trusted owner (the trusted owner accounts are SYSTEM, Administrators, or Trusted Installer).

Upgrade Code matches

If the file you entered has an Upgrade Code, then it will automatically be extracted and you can choose to check this code.

Windows Store Application Version

Matches on the version of the Windows Store application, for example, 16.4.4204.712. You can choose Check Min Version and/or Check Max Version and edit the respective version number fields.

Windows Store Package Name

Matches on the name of the Windows Store Application, for example, microsoft.microsoftskydrive. You can choose to match based on the following options (wildcard characters ? and * may be used):

  • Exact Match
  • Starts With
  • Ends With
  • Contains
  • Regular Expressions
Windows Store Publisher

Matches on the publisher name of the Windows Store Application, for example, Microsoft Corporation. By default, a substring match is attempted (Contains). Alternatively, you may choose to pattern match based on either a wildcard match (? and *) or a Regular Expression. The other available operators are:

  • Exact Match
  • Starts With
  • Ends With
  • Contains
  • Regular Expressions

The Browse File and Browse Apps options can only be used if configuring PMC settings from a Windows 8 client.

You can use the following environment variables in file path and command line application definitions.

System Variables

  • %ALLUSERSPROFILE%
  • %COMMONPROGRAMFILES(x86)%
  • %COMMONPROGRAMFILES%
  • %PROGRAMDATA%
  • %PROGRAMFILES(x86)%
  • %PROGRAMFILES%
  • %SYSTEMROOT%
  • %SYSTEMDRIVE%

User Variables

  • %APPDATA%
  • %USERPROFILE%
  • %HOMEPATH%
  • %HOMESHARE%
  • %LOCALAPPDATA%
  • %LOGONSERVER%

To use any of the environment variables above, enter the variable, including the % characters, into a file path or command line. PMC will expand the environment variable prior to attempting a file path or command line match.

Allow child processes will match this application definition

If selected, then any child processes that are launched from this application (or its children) will also match this rule. The rules are still processed in order, so it’s still possible for a child process to match a higher precedence rule (or Workstyle) first. Therefore, this option will prevent a child process from matching a lower precedence rule. It should also be noted that if an application is launched by an on-demand rule and this option is selected, then its children will be processed against the on-demand rules, and not the Application Rules. If this option is not selected, then the children will be processed against the Application Rules in the normal way. You can further refine this option by restricting the child processes to a specific Application Group. The default is to match <Any Application>, which will match any child process.

If you want to exclude specific processes from matching this rule, then click …match… to toggle the rule to …does not match….

Child processes are evaluated in the context that the parent executed. For example, if the parent executed through on-demand shell elevation, then PMC will first attempt to match On-Demand Application Rules for any children of the executed application.

Force standard user rights on File Open/Save common dialogs

If the application allows a user to open or save files using the common Windows open or save dialog box, then selecting this option ensures the user does not have admin privileges within these dialog boxes. These dialog boxes have Explorer-like features, and allow a user to rename, delete, or overwrite files. If an application is running with elevated rights and this option is disabled, the open/save dialog boxes will allow a user to replace protected system files.

Where present, this option is selected by default to ensure PMC forces these dialog boxes to run with the user’s standard rights, to prevent the user from tampering with protected system files.

When enabled, this option also prevents processes launched from within these dialog boxes from inheriting the rights of an elevated application.

Application Details

This section provides details about the properties that can be configured on the application.

In some cases, additional information to configure the application is provided.

Unlike other application types, PMC 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.

Matching critieria:

  • ActiveX Codebase matches
  • CLSID matches
  • ActiveX Version matches

Matching criteria

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) matches
  • Trusted Ownership matches
  • Application Requires Elevation (UAC)
  • Parent Process matches
  • Source URL matches
  • BeyondTrust Zone Identifier exists

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. PMC 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 allowlisted and/or audited.

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:

Matching criteria:

  • File or Folder Name matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) 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

Matching criteria:

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) 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

Matching criteria:

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) 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

PMC allows standard users to install and uninstall Windows Installer packages that normally require local admin rights. The following package types are supported:

  • 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 will be applied to both the installation of the file, and also uninstallation when using Add/Remove Programs or Programs and Features.

The publisher property of an MSx file may sometimes differ to the publisher property once installed in Programs and Features. We therefore recommend applications targeted using the Match Publisher validation rule are tested for both installation and uninstallation, prior to deployment, using the PMC Activity Viewer.

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 is enabled.

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 will or will not inherit privileges from the parent software installation.

Matching criteria:

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) 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

Matching criteria:

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) matches
  • Publisher matches
  • Trusted Ownership matches
  • Application Requires Elevation (UAC)
  • Parent Process matches
  • Source URL matches
  • BeyondTrust Zone Identifier exists

Matching criteria:

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) matches
  • Publisher matches
  • Trusted Ownership matches
  • Application Requires Elevation (UAC)
  • Parent Process matches
  • Source URL matches
  • BeyondTrust Zone Identifier exists

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 allowlisted.

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

Matching criteria:

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) matches
  • Publisher matches
  • Trusted Ownership matches
  • Parent Process matches
  • Source URL matches
  • BeyondTrust Zone Identifier exists

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

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

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

Matching criteria:

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) matches
  • Trusted Ownership matches
  • Application Requires Elevation (UAC)
  • Parent Process matches
  • Source URL matches
  • BeyondTrust Zone Identifier exists

PMC 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

PMC 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 allowlisted. All remote PowerShell commands are fully audited for visibility.

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 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 PMC for remote PowerShell commands.

For more information, please see Application Definitions.

  1. Click OK. The application is added to the Application Group.

If you want to manage remote PowerShell scripts instead of a single cmdlet, please see Insert Remote PowerShell Scripts

Messaging

PMC 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 will be 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. For example:

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

You can 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 allowlisted. All remote PowerShell scripts executed are fully audited for visibility.

You must use the Invoke-Command cmdlet to run remote PowerShell scripts. PMC 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).

You can 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 allowlisted 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 PMCWorkstyle the ability to connect using WinRM, and can be targeted to specific users, groups of users, or computers using Workstyle filters.

Matching criteria:

  • File Hash (SHA-1 Fingerprint) matches
  • Publisher matches

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.

Remote PowerShell scripts that contain only a single line will be interpreted and matched as a Remote PowerShell Command, and will 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

PMC 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 will be displayed in the remote console session as an error.

PMC 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 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 an 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 Admin Rights.

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 or the BeyondTrustPMC Adapter using , irrespective of your user rights. The anti-tamper mechanism built into PMC prevents users from uninstalling PMC, and the uninstall will fail with an error message.

If a user attempts to use PMC to modify the installation of PMC, 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 will be displayed.

If you want to allow users to uninstall either BeyondTrust's or the BeyondTrust PMC 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 matched all uninstallations will be automatically upgraded when loaded by the Policy Editor to File or Folder Name matches *. These will be honored by Privilege Management for Windows.

Pre 5.7 versions of Privilege Management for Windows will no longer match the upgraded rules, the behavior will be 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
    • Upgrade Code matches
    • Product Name matches
    • Publisher matches

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

Matching criteria:

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) 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

The Windows Store application type allows the installation and execution of Windows Store applications on Windows 8 and later to be allowlisted, so that users are prevented from installing or using unknown or unauthorized applications within the Windows Store.

PMC can only be used to block Windows Store Applications. When you use PMC to block a Windows Store Application and assign a PMC block message to the Application Rule, the native Windows block message overrides the PMC block message, meaning it is not displayed. Event number 116 is still triggered if you have events set up in your Application Rule.

Matching criteria:

  • File or Folder Name matches
  • Command Line matches
  • Drive matches
  • File Hash (SHA-1 Fingerprint) matches
  • Publisher matches
  • Trusted Ownership matches
  • Application Requires Elevation (UAC)
  • Parent Process matches
  • Source URL matches
  • BeyondTrust Zone Identifier exists