EPM-W - Default Tokens for Default Catch-Alls
Recently a question came up if the (Default) catch-all rules in the EPM-W Quick Start policy should be modified to use a custom token rather than a default Full Admin or Basic Admin token. Posting this here in case others had the same question.
The use case is that the support desk will elevate with custom permissions traditionally, and need different privileges than the basic or full admin tokens.
The short answer is “no.”
Why Not?
The support desk permissions required is likely a very small subset of the total cases in which require elevation. When building out a policy with Quick Start, the goal is to identify the common, and the exceptions of the exceptions, in the catch-all rules to help build out a policy that best reflects the privileges required. This ensures that we have a cleaner baseline of “default” when assessing anything new that hits the exception policies, and allows for easier processes changes later on.
So What Now?
The recommendation would be to have two application groups - one that requires the custom token, and one that doesn’t. For anything found that requires the custom token, add it to the application group that requires the custom token, and have that above the default catch-all rule that it would otherwise hit.
What about child-processes from the on-demand rule?
If the on-demand is the only method in which the approval for the custom token should be run, you will need to add an application group in the workstyle rules (not on-demand). You can set up either the application group with custom tokens required, or create a rule that’s explicitly for the children of certain processes in the custom token group to inherit the custom token - this would then be given the token of passive. This should be above where the default catch-all rule would otherwise hit as well.
