Manage Privilege Management for Unix and Linux Role Based Policies
Role Based Policy management will be disabled on hosts configured to use Script Based Policy. For more information, please see Role Based vs. Script Based Policies.
A Privilege Management for Unix and Linux role based policy defines which users can use commands and when they can perform these actions on hosts. These role entities are then associated to a role. A User, Host, Command, and Schedule entity can be used in multiple roles, allowing the user to create a single definition and share it. The role based policy editor is divided into sections allowing for the management of roles and each of the role entities.
Choose the Privilege Management for Unix and Linux role based policy option and an appropriate Policy Server from the selection lists to load the Role Based Policy menu.
Fields may be disabled during policy configuration when the options are not available for the installed version of Privilege Management for Unix and Linux.
PMUL hosts running 10.1 and later in Role Based Policy Mode can take advantage of Entitlement reporting to discover who is able to do what, where, and when.
Entitlement reporting can be enabled per policy or to all role-based policies.
A default value for reporting can be configured in Settings; if enabled, all new role based policies defaults to entitlement reporting enabled, or vice versa if set to false. Additionally, this setting can be locked so the default value is both set and unchangeable per policy. This is for new policies only; disabling entitlement reporting does not change the values for existing policies.
For more information, please see the following:
Manage Role Based Policy Roles
A list of available roles will show the existing entities. This list is searchable and can be filtered by Enabled, Disabled, or all options. Selecting the Add Role option will create 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.
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 will be saved automatically.
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).
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 will 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 will contain the command entities.
- Where: Defines which hosts the policy applies to. This item is divided into two user types:
- Submit Hosts
- Run Hosts
These lists will contain the host entities.
- When: Defines which schedule the policy applies to. This list will contain the schedule entities.
- None: Reauthentication is not required.
- Shared Secret: Create a shared secret value. The user must provide it to reauthenticate.
- 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 enable reauthentication, choose the Type from the dropdown menu; this opens an appropriate editor for the selected type.
To configure this option:
- Use the Type dropdown to select the desired type of reauthentication. Depending on the selected type, fill in the requested information.
- Type in a message to prompt the user on how to proceed.
- Enter the number of retries before reauthentication locks up.
- Enter the message the user sees if reauthentication fails.
- Enter the message that is recorded in the log when reauthentication fails.
- Click Save.
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 PMUL template syntax of %<variable>%. A few options are available using buttons to quickly insert the most popular options. Values can also be entered freely.
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.
A configuration area to include a custom script. Script policy can be entered into the code editor to set the script content.