Workstyles

Policy Editor Workstyles are used to assign Application Groups for a specific user, or group of users.

Create a Workstyle

A Workstyle can include the following components: Application Rules, On-Demand Application Rules, Trusted Application Protection, content rules, general rules, and filters.

Content rules are not currently available. You can use the MMC Policy Editor to manage these components.

Workstyle Summary

The Workstyle Summary pane provides a high-level overview of the Workstyle properties.

Create the Workstyle

  1. Select Policies on the sidebar menu.
  2. Find the row of the policy you would like to create a Workstyle for, and then click the vertical ellipsis.
  3. From the dropdown menu, select Edit & Lock Policy, or Edit (if the policy is already locked by you).
  4. On the Policy Editor page, expand Windows > Workstyles.
  5. Click Create New Workstyle.
  6. Enter a name and a description. By default, the Workstyle is disabled.
  7. Click Create Workstyle.
  8. Select the Workstyle in the navigation pane to expand the properties.
  9. Configure the Workstyle properties: Application Rules, On-Demand Application Rules, Trusted Application Protection, Content Rules, General Rules, and Filters.

For quick access to the Workstyles Summary Page, hover over and click the hyperlink for the appropriate Workstyle name.

Enable a Workstyle

By default, a Workstyle is disabled when initially created.

  1. Go to the Policy Editor, and then navigate to the Windows Workstyles.
  2. Select the vertical ellipsis menu for the Workstyle, and then select Enable.

The Workstyle can be disabled later, if required. You can disable a Workstyle when you want that Workstyle to stop processing.

Workstyle Precedence

Workstyles are evaluated in the order they are listed. When an application matches on a Workstyle, no further Workstyles are processed for that application. Ensure the order of the Workstyles is correct because it is possible for an application to match more than one Workstyle.

Select a Workstyle in the list to change the order. Changes are automatically saved.

Workstyle precedence in the web Policy Editor

Application Rules

Application Rules are applied to Application Groups. Application Rules can be used to enforce allow listing, monitoring, and assigning privileges to groups of applications. They are a set of rules that apply to the applications listed in the Application Group.

Create an Application Rule

  1. On the Policy Editor page, expand Windows.
  2. Expand the Workstyles node, and then expand a Workstyle.
  3. Click Application Rules, and then click Create New.
  4. Set the following:
    • Target Application Group: Select an Application Group.
    • Action: Select Allow, Allow as Password Safe User, Block, or Request. The action that occurs if the application in the targeted Application Group is launched by the end user.
    • Password Safe Account Name: Enter the Managed Account name configured in Password Safe for the computer.
    • Run Rule Script: Assign a rule script that is run before the Application Rule triggers. Select a rule script from the list.
    • End User Message: Select a message from the list.
    • Access Token: Select the type of token to pass to the target Application Group. You can select from:
      • Passive (no change): Doesn't make any change to the user's token. This is essentially an audit feature.
      • Enforce User's Default Rights: Removes all rights and uses the user's default token. Windows UAC always tries to add administration rights to the token being used so if the user clicked on an application that triggers UAC, the user cannot progress past the UAC prompt.
      • Drop Admin Rights: Removes administration rights from the user's token.
      • Add Full Admin (Required for installers) : Standard Windows Admin token containing all Admin privileges.
      • Add Basic Admin Rights: Gives greater control over the privileges granted when targeting rules at actions. This excludes the following privileges: SeDebugPrivilege, SeLoadDriverPrivilege.
      • Privilege Management Support Token: Applies Add Full Admin privileges with tamper protection removed.
    • Raise An Event: Off, On, Anonymous. Select if an event is raised if this Application Rule is triggered. When on, an event is sent to the local event log file. Anonymous removes user and host name from events so the user / host are not identifiable.
    • Run an Audit Script: Select an audit script from the list.
    • Privilege Monitoring: Off, On, Anonymous. Select On to raise a privileged monitoring event.
    • Reporting Events: On by default, click to turn off. When the setting is on, events are raised for viewing in PMC Reporting.
  1. Click Create Application Rule.

Application Rule Precedence

If you add more than one Application Rule to a Workstyle, entries higher in the list have precedence. When an application matches an Application Rule, no further rules or Workstyles are processed. If an application could match more than one Workstyle or rule, then it is important that you order both your Workstyles and rules correctly.

Select an Application Rule in the list to change the order. Changes are automatically saved.

On Demand Application Rules

The On-Demand Application Rules node of the Workstyle allows you to create rules to launch applications with specific privileges (usually admin rights), on-demand from a right-click Windows context menu.

Windows Modern UI

If Apply the On-Demand Application Rule to the "Run as administrator" option is enabled and an On-Demand Application Rule is triggered, Privilege Management for Windows intercepts the Run as administrator option in the right-click context menu and overrides it. The labeling of the option does not change in this instance. If the option is not selected, Privilege Management for Windows does not intercept the option to Run as Administrator.

If Hide "Run as" and "Run as administrator" commands in the Classic Shell context menu is selected, these options, where present, are hidden from the right-click context menu. Privilege Management for Windows does not continue process additional Application Rules.

Windows Classic Shell

If Apply custom on-demand option to the Classic Shell context menu (this will not affect the "Run as administrator" option) is selected, and an On-Demand Application Rule is triggered, Privilege Management for Windows adds a new option to the right-click context menu that you configured in the Classic Shell Context Menu Option section, for example, Run with Privilege Management for Windows.

If Hide "Run as" and "Run as administrator" commands in the Classic Shell context menu is selected, these options, where present, are hidden from the right-click context menu. Privilege Management for Windows does not continue process additional Application Rules.

Unlike Application Rules, the on-demand rules list only receives the assigned privileges if the user launches a relevant application using the context menu.

To create an On-Demand Application Rule:

  1. Expand Workstyles, and then expand a Workstyle.
  2. Select On Demand Application Rules.
  3. Select Create New.
  4. Set the following:
    • Target Application Group: Select an Application Group.
    • Action: Select Allow, Allow as Password Safe User, Block, or Request. The action that occurs if the application in the targeted Application Group is launched by the end user.
    • Password Safe Account Name: Enter the Managed Account name configured in Password Safe for the computer.
    • Run Rule Script: Assign a rule script that is run before the Application Rule triggers. Select a rule script from the list.
    • End User Message: Select a message from the list.
    • Access Token: Select the type of token to pass to the target Application Group. You can select from:
      • Passive (no change): Doesn't make any change to the user's token. This is essentially an audit feature.
      • Enforce User's default rights: Removes all rights and uses the user's default token. Windows UAC always tries to add administration rights to the token being used so if the user clicked on an application that triggers UAC, the user cannot progress past the UAC prompt.
      • Drop Admin Rights: Removes administration rights from the user's token.
      • Add Full Admin (Required for installers) : Standard Windows Admin token containing all Admin privileges.
      • Add Basic Admin Rights: Gives greater control over the privileges granted when targeting rules at actions. This excludes the following privileges: SeDebugPrivilege, SeLoadDriverPrivilege.
      • Privilege Management Support Token: Applies Add Full Admin privileges with tamper protection removed.
    • Raise An Event: Off, On, Anonymous. Select if an event is raised if this Application Rule is triggered. When on, an event is sent to the local event log file. Anonymous removes user and host name from events so the user / host are not identifiable.
    • Run an Audit Script: Select an audit script from the list.
    • Privilege Monitoring: Off, On, Anonymous. Select On to raise a privileged monitoring event.
    • Reporting Events: On by default, click to turn off. When the setting is on, events are raised for viewing in PMC Reporting.
  1. Click Create On-Demand Rule.

Integrate BeyondTrust Password Safe

Password Safe users can be included in an Application Rule or On-Demand Application Rule to help manage access to applications.

Password Safe must already be installed and configured.

For more information, please see the Password Safe Integration Guide.

Use the following procedure to set up the integration to Password Safe. After this initial setup is complete, you can edit the Application Rule or On-Demand Application Rule to allow Password Safe users.

  1. On the Policy Editor page, expand Windows.
  2. Expand the Workstyles node, and then expand a Workstyle.
  3. Click Application Rules or On Demand Application Rules, and then click Integration Settings.
  4. From the Activation list, select one of the following: Not Configured, Enabled, or Disabled.
  5. Set a heartbeat interval. This is the time span the computer polls Password Safe unless the time is determined by Password Safe. For most subsequent messages, the poll time is driven by Password Safe in the messages it sends to Privilege Management for Windows. This is because Password Safe knows when the next scheduled action must be performed.
  6. Click Update Settings.

Trusted Application Protection Rules

Privilege Management for Windows can dynamically evaluate DLLs for trusted applications for each Workstyle.

Unless a DLL has a trusted publisher and a trusted owner, it is not allowed to run within the Trusted Application Protection (TAP) application.

  • Trusted Publisher: A trusted publisher must be signed. In addition, the publisher certificate must be valid, in date, and not revoked.
  • Trusted Owner: A trusted owner is any owner that is in the default Windows groups Administrators, SystemUser or TrustedInstaller.

TAP rules affect the following applications:

  • Microsoft Word, Microsoft Excel, Microsoft PowerPoint, Microsoft Publisher, Adobe Reader 11 and earlier, Adobe Reader DC, Microsoft Outlook, Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, Microsoft Edge

You can turn on monitoring for TAP applications in any Workstyle.

To create a TAP rule:

  1. Expand Workstyles, and then expand a Workstyle.
  2. Select Trusted Application Protection.
  3. In the Rule section, set the following:
    • Trusted Application Protection: From the list select Enabled, Disabled, or Not Configured. The first Workstyle evaluated that has TAP set to Enabled or Disabled is matched by Privilege Management for Windows, meaning subsequent Workstyles are not evaluated by Privilege Management for Windows.
    • Action: Select from Passive (No Change) or Block. The selected action is applied when the DLL in the TAP application tries to run.
    • End User Message: Select if a message is displayed to the user when the DLL tries to run (regardless of if it is allowed to run). We recommend using messages if you are blocking a DLL from running, so the end user has some feedback.
  4. In the Auditing section, select On or Anonymous. This setting determines if an event is raised when the TAP application tries to run a DLL. When auditing is on, the event is sent to the local event log file. Anonymous removes user and host name from events so the user and host details are not identifiable.
  5. In the Reporting Options sections, select Reporting Events to capture events.
  6. Click the Configure Exclusions link to add DLLs to exclude from the TAP applications rule. These are DLLs that have either an untrusted owner or an untrusted publisher, but you still want to be allowed to run with TAP enabled in the Workstyle. This list of DLLs is not validated. If the DLL name listed is not matched by the client, then nothing is excluded.

General Rules

To view or edit the general rules of a Workstyle, select Windows > Workstyles > 'Workstyle Name' > General Rules.

The general rules include the following:

  • Collect User Information: When enabled, raises an audit event each time a user logs on to the client machine.
  • Collect Host Information: When enabled, raises an audit event on computer start-up or when the Privilege Management for Windows service is started.
  • Prohibit Privileged Account Management: When enabled, blocks users from modifying local privileged group memberships. This prevents real administrators, or applications which have been granted administrative rights through Privilege Management for Windows, from adding, removing, or modifying a privileged account.

    The local privileged groups that cannot be changed when this rule is enabled:

    • Built-in administrators
    • Power users
    • Account operators
    • Server operators
    • Printer operators
    • Backup operators
    • RAS servers group
    • Network configuration operators
  • Enable Windows Remote Management Connections: 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 to allow a standard user to execute PowerShell scripts or commands.

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

For more information, please see the following:

Filters

A Workstyle filter refines when a Workstyle is applied. Workstyle filters apply to Windows and macOS systems.

By default, a Workstyle applies to all users and computers who receive it. However, you can add one or more filters that restrict the application of the Workstyle:

  • Account Filter: Restrict the Workstyle to specific users or groups of users.
  • Computer Filter: Restrict the Workstyle to specific computers (names or IP addresses), or Remote Desktop clients.
  • WMI (Windows Management information) Filter: Restrict the Workstyle based on the success or failure of a WMI query.

The following conditions can be applied to a filter:

  • ALL filters must match: The Workstyle is applied only if all filters match.
  • ANY filter can match: The Workstyle is applied when any filter matches.

Account Filters

An account filter restricts a Workstyle to specific users or groups of users. Account filters can be created for Windows and macOS Workstyles.

You can add local or domain users and groups and Azure Active Directory groups (Windows only).

To create an account filter:

  1. Expand a Workstyle, and then select Filters.
  2. Select Create New Filter, and then select Account Filter.
  3. Select the new filter in the list, and then select Go To from the menu.
  4. Select the following to add users or groups:
    • Add From Local/Domain AD (Windows): Add an account name and SID details. If you are adding a group, you can select from a list of known Active Directory Built-in groups. Click Add Account.
    • Add From Azure AD (Windows): The Azure AD group list is populated with cached Azure AD group data. Select a group from the list, and then click Add. You can select more than one group at a time.
    • Add Account: (macOS). Add the account or group details. User IDs on macOS must be values greater than 500. A value less than that might be used by a system process.

To filter account names, click inside the Filter by list at the top of the Accounts grid and select Account Name, Type, or Value. You can use multiple filters to help narrow down an especially lengthy list of names.

Computer Filters

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

Computer filters can be configured on Windows and macOS computers.

To restrict the Workstyle to specific computers by IP address:

  1. Expand a Workstyle, and then select Filters.
  2. Select Create New Filter, and then select Computer Filter.
  3. Enter the IP address manually, in the format 123.123.123.123. Optionally, use asterisk wildcard (*) and - for range, as shown: 127.*.0.0-99.
  4. (Windows only) Select Match the remote desktop (instead of the local computer) if the computer filter is intended to match the IP address of remote computers using remote desktop sessions.
  5. Click Add.

To restrict the Workstyle to specific computers by host name:

  1. Expand a Workstyle, and then select Filters.
  2. Select Create New Filter, and then select Computer Filter.
  3. Enter one or more host names, separated by semicolons. You can use the * and ? wildcard characters in host names.
  4. (Windows only) Select Match the remote desktop (instead of the local computer) if the computer filter is intended to match the IP address of remote computers using remote desktop sessions.
  5. Click Add.

WMI filters

A WMI filter is applied to a Workstyle based on the outcome of a WMI query.

When a WMI query runs, the client checks whether 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, the WMI query is unsuccessful.

WMI queries are always run as the Windows SYSTEM account, 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.

To create a WMI filter:

  1. Expand a Workstyle, and then select Filters.
  2. Select Create New Filter, and then select WMI Filter.
  3. Click the WMI Filter link in the list. Alternatively, select Go To from the menu for that filter.
  4. Click Create New Query.
  5. Enter the following details:
    • Description: Free text to describe the WMI query.
    • Namespace: Set the namespace that the query runs 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 set. Long running WMI queries result in delayed application launches. Therefore, we recommend setting a timeout to ensure that queries are terminated in a timely manner.
  6. Click Add Query.

For more information, please see WMI (Windows Management information) Filters.