When defining and testing PowerBroker for Windows rules for production or pilots, customers sometimes tell us, “I don’t think this policy / program is working.” This is usually a case of the policy not properly triggering because of the way the rule was created.
A unique feature of PowerBroker for Windows compared to other solutions is a client-side utility called Policy Monitor (Polmon). This utility is designed to determine exactly what is happening when an application executes and why a policy is not correctly interacting with the system. To get started, the utility can be launched from the command line by executing polmon.exe. Using the information below, technicians can dive deeper into the runtime of application launches and troubleshoot permissions at the most granular levels.
This level of detail exceeds that found in any competitive product, while most have no real-time diagnostics at all. When you become comfortable utilizing Policy Monitor, your use, troubleshooting, and overall experience of implementing PBW will greatly benefit. Below is a detailed description of all the results for the tool:
When using Polmon to inspect which rules match based on an application’s execution, the solution will decode several important runtime values:
GPO: This is a numerical representation of the order for the GPO rule. If you want to review the name of the GPO, executive the local Registry Editor (regedit.exe), and navigate to this section of the hive: HKLMSoftwareBeyondTrustSDApplicationsRules[Machine/Users]. All PowerBroker for Windows rules are located here when loaded.
Order ID: This is a numerical representation of the order for the loaded rule.
Note: If you have disabled rules in your GPO, this order number will not take those into consideration. They are properly ignored. For example, if your GPO has 10 rules in it, and the first rule is disabled, Rule 2 in the GPO will display as Order ID 1 in Polmon.
ProcessSecurity: This is a Hex Code representing which options are toggled ON under Process Security in the rule. The default is 0x80120000
BlockInheritance: [Set/Not Set]. If “Set,” then child applications will not be granted the elevation of the targeted app. If “Not Set,” then you are allowing the elevation of the parent process to propagate to the children of this application.
Note: Even with this set, you may encounter an application called as a separate (not a child) process. In these scenarios, you will need to create a rule that targets that secondary process if elevation is required.
Admin flag: (Set/Not Set]. If “Set,” the rule will only trigger if the caller process is owned by the Administrators Security Group. For MSI rules, this flag is enabled and cannot be changed. This is by design such that a “spoofed” MSIEXEC cannot be elevated.
Regular Expression flag: [Set/Not Set]. This value is used to enumerate regular expressions contained in the rules and is not configurable by the end user.
Authentication/Justification flag: [Set/Not Set]. This value is obsolete and only present for legacy rules in older versions of PowerBroker for Windows prior to the creation of User Messages.
DropDialogRights flag: [Set/Not Set]. In Options tab of a rule, there is a selection for “Apply rule to file system browsing within targeted application.” This feature allows or suppresses an elevated an application from browsing the file system when Windows API’s are used for the “File -> Open, Save, Save As” dialogs.
Note: Applications that use their own controls for these, or similar functions; cannot be limited by this option.
ArgumentsExactMatch flag: [Set/Not Set]. This value determines if the rule should match only when the specified arguments in the rule exactly match. If no argument is specified (blank or empty field), and the option is checked in the rule, “Blank” becomes an argument. Therefore if the application was called with an argument, the rule would not match since the expected field is just “Blank” or white space.
Note: Never use this option with Wildcards.
Disable UNC Translation flag: [Set/Not Set]. If a rule contains a Mapped Drive letter (such as F:, S:, or X:), by default it will not match because the PowerBroker for Windows Client always resolves the UNC path, even if the user clicks on a Mapped Drive Letter to execute the application. If the rule should translate to a Mapped Drive instead of UNC or DFS location, you must enable the “Allow use of mapped drive letter in path” option in the rule.
Note: This option is designed for legacy applications that do not recognize UNC paths. In addition, standard users can change mapped drive locations so the rule(s) should be very specific for publisher, hash, or executable in order to avoid a security issue.
Integrity Level: This is a Hex Code Representing the Integrity Level set in the rule. Options include:
- Untrusted: S-1-16-0
- Low: S-1-16-4096
- Medium: S-1-16-8192
- High: S-1-16-12288
- System: S-1-16-16384
Execution Options: This represents the setting under a rule’s Execution Options.Apply rule when:
- Connected
- Connected Locally
- Connected via VPN/Dialup
- Disconnected
Note: The client, unless using Item Level Targeting, cannot determine if the machine is connected to a particular domain, just that it is connected to “A” domain. To obtain this granularity, Item Level Targeting must be used and only evaluates at login, not at the change of state for Execution Options.
Clear Privileges flag: [Set/Not Set]. Within a rule, under “Token -> Privileges” there is a checkbox called “Remove all privileges before applying.” If enabled, all privileges will be cleared from the process, whether they were set there by default or not.
Enable Privileges flag: [Set/Not Set]. When an application has “Grant” a privilege under “Token -> Privileges,” the rule allows a Particular Privilege to be granted to a process only if the process's code specifically asks for it to be granted. In rare cases, the application will expect this privilege as part of it User Token and will not request. This results in an application error. If this happens, the rule will need the missing privileges manually enabled or the rule to have “Enable all granted Privileges” to overcome the application’s shortcomings.
Type: This value indicates you what type of rule it was that matched: PUBLISHER, PATH, HASH, MSI, etc.
Program: This displays the Path (Package for MSI Rules) specified in the rule. It does not necessarily indicate the path that was called when the application was launched.
Program Arguments: This displays the arguments as seen in the rule properties, not necessarily the arguments that were called when the application was launched.
Rule Action: This displays the action set in the rule properties: LOCAL ADMIN, CUSTOM, DROPADMIN, DENY, ALLOW, etc.
MessageGuid: This entry indicates the GUID of the specified User Message that should be applying to the rule. If no message is specified, the entry should read, {00000000-0000-0000-0000-000000000000}. If the MessageGuid is specified, but the MessageBox states “the configured user message cannot be found,” verify that the User Messages have been properly loaded into the local Registry. They can be found at this hive location: HKEY_LOCAL_MACHINESOFTWAREBeyondTrustPBDesktopsMessages Registry.
Publisher [Product Name, File Name, File Version, File Version Option]: This enumerates what settings are matching against a Publisher rule. Outside of seeing an asterisk (*), these values should match an application launch and not undesirable applications from the same publisher.
SID to [ADD/DEL]: This displays the SID of the Group/User you want to add or delete to/from the application.
Once an application has been launched with a matching rule, Polmon will display a series of privileges being added or removed, depending on the options within a rule. The most important entry to recognize is RULE APPLIED. This indicates a rule match and the options have been applied to that applications execution. If no entry is present, please refer to the Troubleshooting section of the “PowerBroker for Windows Best Practices Guide” available from your sales or support representative.
Jason Silva, Sr. Solutions Architect
Jason Silva is a Senior Solutions Architect focused in Privilege Access Management (PAM), Identity and Access Management (IAM), and Least Privilege. Jason brings over 25 years of experience in solutions management to BeyondTrust's Privileged Access Management Solutions enforcing Privileged Password Management and Privileged Session Management, Privileged Endpoint Management, and Secure Remote Access which utilizes a single pane of glass for all management aspects including Automated Account Discovery, Privileged Management and Elevation, Audit and Compliance, and Reporting.
