Role-Based Policy Roles

A list of available roles shows the existing entities. This list is searchable and can be filtered by Enabled, Disabled, or all options. Selecting the Add Role option creates a role.

To edit an existing role, select an entry from the Roles list and click Edit.
To delete an existing role, select an entry from the Roles list and click Delete.

Role Ordering

The order in which role-based policies are applied can be set by ordering the roles in the list of available roles. Click and drag a role entry up or down in the Roles list to establish the priority order. Changes to role order is saved automatically.

General Details

The following options are available:

Role name: This should be unique on the policy server.
Tag: Add a tag to the role. Once added, tags function as a filter and can be used to sort through policy roles.
Description: A brief description to identify the role.
Comment: The admin can add a comment here. These are only visible to the admin.
Role Risk Level: The perceived risk level of the policy.
Request Type: Allows the administrator to specify which request types this policy will apply to. For example, a policy might apply to commands issued only by pbrun invocations. Use the dropdown to select the appropriate request type, or select Any. The default value is to allow any request type.
Policy Enabled: Whether or not the role is active (default Enabled).
Action: Whether this should trigger an accept or reject action (default Accept).
Entitlement Reporting: Whether or not Entitlement Reporting is enabled (default Disabled).

If Change Management is enabled, an additional Change requested by [loggedInUserName] field is visible and requires you to enter a reason for the change. For more information, see Change Management.

Click Save.

Assignments

Assign allowed users, hosts, commands, and schedule to a role. Each role can have zero to many relationships with each entity type. This is managed using the lists matching the appropriate entity. The following configuration sections are available:

Who: Defines which users the policy applies to. This item is divided into two user types:
- Submit Users
- Run Users
These lists contain the user entities.
Select Use Default Group and Working Directory to automatically populate the run users in a script block on the Script Policy page. Changing the block properties is not recommended.
What: Defines which commands the policy applies to. This list contains the command entities.
Where: Defines which hosts the policy applies to. This item is divided into two host types:
- Submit Hosts
- Run Hosts
These lists contain the host entities.
When: Defines which schedule the policy applies to. This list contains the schedule entities.

Click Save.

Reauthentication

If configured, this feature requires users to reauthenticate themselves when this policy is invoked. Only one reauthentication method can be configured per policy. Most reauthentication options allow for customization of messages and prompts to be displayed to the user as well as logs. Reauthentication can be enabled in a number of configurations:

None: Reauthentication is not required.
Shared Secret: Create a shared secret value. The user must provide it to reauthenticate.
Privilege Access Management (PAM): A number of PAM modules can be selected, or a custom one can be provided. Additionally, most options allow the user to configure where the authentication will occur.

To configure the Shared Secret option:

From the Type dropdown, select Shared Secret.
Enter the Shared Secret and confirm it.
Enter a Reauthentication Prompt message, or use the default.
Enter the Number of attempts (retries) before reauthentication locks up.
Enter the Failure Message the user sees if reauthentication fails, or use the default.
Enter the Log Message that is recorded in the log when reauthentication fails, or use the default.

Click Save.

To configure the PAM option:

From the Type dropdown, select PAM.
Select the PAM Service to use for authentication.
Select the Location to use, where the authentication happens. If you select the Run Host option, you only need to complete steps 4 and 5, and then click Save.
Select the User Type, whether you are providing authentication for the user requesting the elevation, the user running the command, or some other user. If you select Custom, enter a custom user name.
Enter a Reauthentication Prompt message, or use the default.
Enter the Number of attempts (retries) before reauthentication locks up. That depends entirely on the policies imposed by the authentication services that EPM-UL accesses through PAM.
Enter the Valid time length, in seconds, or use the default. This is how long the reauthentication is cached for, before a login is required again.
Enter the Failure Message the user sees if reauthentication fails, or use the default.
Enter the Log Message that is recorded in the log when reauthentication fails, or use the default.
In the Change requested by [loggedInUserName] field, enter a reason for the assignment or change.

Click Save.

Messages

Enables the administrator to output a message to the user when this policy is processed. This field can interpolate variables to provide a custom, context specific message using the EPM-UL template syntax of %<variable>%. A few options are available using buttons to quickly insert the most popular options. Values can also be entered freely.

Click Save.

Session Replay

Generate a file location for session replay logs and configure Path Options.The Session Replay Location field allows for the use of variables in the file name. BIUL provides a template builder to assist with creating the path; select the build option, provide a path to save the file, and select the desired variable options. Values can also be entered freely.

Click Save.

Script Policy

A configuration area to include a custom script. Script policy can be entered into the code editor to set the script content.

Click Save.