Best Practice: Policies

If you configure Privilege Manager policies incorrectly they could prevent services or programs from starting or running with the proper rights.

Policies are evaluated in order based on the Policy Priority value on the Policy. If a blocking policy that denies applications is too broad and is set with too high a priority, it can unintentionally prevent other applications from running or letting the user request approval to run.

You can avoid conflicts resulting from incorrectly configured Privilege Manager policies by using the following best practices:

Always test policies on machines which mirror the production environment before rolling out to production.

• Assign policies that allow processes a lower policy priority number than policies that deny processes.

• Make sure your other policy enforcement settings check boxes are selected or cleared, depending on the aims of your policy.

• Policies that deny processes always exclude the following application filters:

  • LocalSystem and Service

  • Signed Security Catalog

• You should (almost) never use wildcards in deny policies. Wildcards should be considered only after performing extensive testing.

Do not add User Context filters as the only application target to a policy. Starting with Privilege Manager version 11, the UI does alert to this as being an invalid policy. Refer to Warning Banner indicating Filter Error Conditions in Policies.