Privileged access management options
This chapter describes options that you can set globally for privileged access management. Product administrators with all administrative privileges enabled (superuser) can control:
Local service mode software installation
Push mode initial randomization
Password randomization intervals
Account access check-in/check-out behavior
Group set access check-in/check-out behavior
Triggers for external programs
Access disclosure plugins
Email notification intervals
Generic access check-in/check-out retries
Product administrators can also configure these options for each managed system policy to which they are assigned permission. Group-level settings override global settings. Some group-level settings are only available if they apply to the authentication type defined for the managed system policy.
See also
Bravura Security Fabric includes access disclosure plugins to permit secure access to a password for a privileged account. See Access Disclosure Plugins for information on configuring these plugins.
General policy management options
These options are available in the Manage the system > Privileged access > Options > Managed system policies menu:
Local service mode discovery queue space
When local service mode discoveries encounter failures, they can rapidly cause disks to fill up via archived discovery queues.
Enable LWS SAVE QUEUE SPACE to preserve disk space by allocating smaller queue files for local workstation service discoveries.
Local service mode workstation keys
Bravura Privilege uses a key to ensure secure communication between a local service mode managed system and the Bravura Security Fabric server. For security purposes, this key is changed periodically.
Set the RESOURCE KEY CHANGE INTERVAL to control the interval, in days, after which workstation keys are changed. The default is 30 days.
See Resource key for more information.
Local service mode create credentials retry
Bravura Privilege can be configured to create administrative accounts on Local Workstation Service mode target systems. If the initial create fails, additional retries are governed by RES ADMIN CREATE RETRY INTERVAL .
Configure the RES ADMIN CREATE RETRY INTERVAL to determine the interval at which to retry. The default is 1440 minutes.
See Creating administrator accounts on target systems for more information.
Local service mode software installation
After a Local Workstation Service registers with the Bravura Privilege server and is managed, it continues to contact the server at the interval set by RES POLL INTERVAL . The default is 60 minutes.
The default port number for the Local Workstation Service listener using the RES LISTENER PORT option.
The Local Workstation Service will periodically contact the Bravura Privilege server to obtain the options that are set. The default interval is 86400 seconds. You can use the RES CONFIG UPDATE INTERVAL option to change this interval; the change will take effect the next time the Local Workstation Service contacts the server.
Local service mode connection timeout
When the Bravura Privilege server is slow in responding to a Local Workstation Service the service will retry after an amount of time set by RES CONNECTION TIMEOUT . The default timeout is 600 seconds.
Local service mode resynchronization
After a Local Workstation Service registers with the Bravura Privilege server and is managed, it will automatically resynchronize itself with the Bravura Privilege server as configured by the system variables in the table below.
Option | Description |
|---|---|
RES RESYNC FAILURE RETRY INTERVAL | The interval (in minutes) a managed local service mode system will wait before attempting to resynchronize with the instance server after a failed attempt. The default is 120 minutes. |
RES RESYNC INTERVAL | The interval (in minutes) a managed local service mode system will wait before resynchronizing with the instance server. The default is 10080 minutes (approximately 1 week). |
RES TRANSACTION FAILURE RETRY INTERVAL | The interval (in minutes) a managed local service mode system will wait before sending a transaction to the instance server after a failed attempt. The default is 60 minutes. |
See Resynchronizing a local service mode system for more information about resynchronization.
User attribute updates on local service mode systems
Changes made to user attributes on a local service mode managed system are updated on the next poll of the Local Workstation Service. You can configure this so that some user attributes are updated less frequently than the default poll time of the Local Workstation Service.
Using a separate time interval RES ATTRIBUTE UPDATE DELAY, you can control the delay in which the user attributes will be updated. By default, the delay is set to 1440 minutes (once a day).
Only user attributes specified in RES DELAY UPDATE ATTRIBUTES are updated according to this time interval, otherwise they are updated after every poll. By default, the pwda (password age) and llogon user attributes are updated using the RES ATTRIBUTE UPDATE DELAY.
Display of policy member systems
Bravura Privilege displays member systems for each managed account on the Managed accounts page.
Set the RES NUM SYSTEMS DISPLAY option to control the maximum number of member systems to display per account the Managed accounts page of a managed system policy. The default value is 3.
Global managed system external program triggers
Managed system policy exit points do not override global settings and vice versa; however, in the case where an exit point is configured to run the same program from both locations, only one instance of the program is run.
The system always defaults to request access events before generic events are fired. For example, PAM CHECKOUT EXPIRY will not fire if RES CHECKOUT EXPIRY has been triggered. Events defined for "Account access request", "Account set access request" and "Group set access request" will always fire instead of generic events. The events listed in the table below can trigger email or other external program actions.
See Event actions (exit traps) for more information about configuring event actions.
Conflicting passwords
You can choose whether to automatically resolve conflicting passwords or set a limit on how many conflicting passwords can be processed at once.
Option | Description |
|---|---|
PASSWORD CONFLICT ATTEMPT VERIFICATION | Attempt to automatically resolve conflicted passwords by running agents and querying replicas. This is enabled by default. |
PASSWORD VERIFICATION BATCH LIMIT | The maximum size of a password verification batch. The default is 50. |
See Conflict resolution for more information.
Generic access check-in and check-out retries
If a generic access check-in or check-out fails, automatic retry attempts occur as configured by the system variables in the table below.
Option | Description |
|---|---|
PAM ACTION CI RETRY INTERVAL | The interval (in minutes) to wait before retrying a generic access check-in attempt. The default is 1 minute. This value must be less than PAM ACTION CI RETRY TIMEOUT . |
PAM ACTION CI RETRY TIMEOUT | The timeout (in minutes) at which retry attempts stop for generic access check-ins. The default is 10 minutes. |
PAM ACTION CO RETRY INTERVAL | The timeout (in minutes) at which retry attempts stop for generic access check-ins. The default is 10 minutes. |
Generic access check-in retry attempts cannot be disabled.
Privileged access check-in / check-out options
Bravura Privilege allows regular users to request temporary privileged access to managed systems, for themselves or other users, using authorization workflow.
Some examples of privileged access:
Access to a single administrative account
Access to keys
Access to documents
Temporary group membership using group sets
The ability to run commands on multiple systems and accounts
Requests can be auto-approved for certain users, or require approval by authorizers . If approval is required, Bravura Privilege notifies one or more authorizers, by email or other means, that they need to review the request. Bravura Security recommends that, as a best practice, Bravura Privilege auto-approves most requests (80%+); when an authorizer receives too many requests, they tend to approve requests without reading them. This is called approver fatigue .
Checking out account access does not allow a user to reset or change the account’s password.
If approved, a user can check out the requested privileged access. Broadly, the check-out workflow proceeds as follows:
A user logs in to the Front-end and clicks the Privileged access link.
From the available menu options, the user chooses:
Accounts to select one or more administrative accounts
Account sets to select an existing account set
Group sets to select from a list of group sets
The user selects an account, account set, or group set and begins the request for access.
The user enters required information, including the time needed for the check-out, and submits the request.
You can grant permission for users to bypass this step and proceed to Step 6.
Bravura Privilege notifies appropriate authorizers who must log in to approve, modify or deny the request.
If approved, the user logs in to check out the access privilege. The account access or group membership applies once they have it checked out.
In the case of account check-outs, access disclosure plugins provide the user with access to the password or automatic connection to the managed system.
In the case of account set check-outs, the user can access each individual account included in the set and may be able to run commands on multiple systems.
When finished, the user checks in the account(s) or group membership(s). Bravura Privilege forces the check-in after a certain time. The user can check out and check in once during an authorized interval. Messages can be configured to display remaining check-out time and check-out expiration to users. See Privileged access request messages .
When a one-time disclosure plug-in is downloaded and executed, the plug-in will check with Bravura Privilege to determine how much time is left in the checkout, or if the authorized interval has expired. This also applies to one-time plug-ins that have been saved for future use.
In the case of account check-outs, the password is randomized upon check-in.
Checking access privileges in and out allows Bravura Privilege to control and audit who has access to an account or group set and when, and provides “dual-key” limitations on account access.
In this section, unless specified, account access refers to both single account and account set access requests.
Controlling user access request capabilities
The following sections describe:
Who can check out privileged account access
Who can check out group sets
Who can see managed system and account information
Who can see check-out information
Who can request check-out extensions
Who can check out privileged account access
By default, any user can request permission to access managed accounts on any managed system. You can control this by:
Disabling the IDARCHIVE PASSWORD REQUESTED setting on the Modules > Privileged access menu.
This changes the default behavior so that users must be assigned to a user group with appropriate permission. See Privileged access app for more module options.
Specifying a user class in ACCESS ACCOUNTSETS USERCLASS setting on the Modules > Privileged access menu.
This changes the default behavior so that only users belonging to the specified user class can access managed account sets.
Enable the ACCESS PERSONALADMINACCOUNTS USERCLASS setting on the Modules > Privileged access menu.
This setting defines the user class that filters users who can view the personal admin accounts filter in the Privileged access . If the owner of the personal administrative account is part of the user class specified, the personal admin accounts filter will be displayed in the Privileged access . See Privileged access app for more module options.
Assigning users to groups.
Users can also be granted permission to check out account access privileges without authorization.
Configuring access controls from within a managed system policy .
Checking out account access does not allow a user to reset a password or to configure managed systems or managed system policies.
Who can check out group sets
By default, any user can request permission to groups for any managed system. You can control this by:
Disabling the IDARCHIVE GSET REQUESTED setting on the Modules > Privileged access menu. This changes the default behavior so that users must be assigned to a user group with appropriate permission. See Privileged access app for more module options.
Specifying a user class in ACCESS GROUPSETS USERCLASS setting on the Modules > Privileged access menu.
This changes the default behaviour so that only users belonging to the specified user class can access group sets.
Assigning users to groups. Users can also be granted permission to check out group set access privileges without authorization.
Who can see managed system and account information
By default, all requesters can view additional information about the managed system and account when requesting account access. This information can be accessed from a hyperlink that will be shown whenever the managed system or account name is displayed.
All default push and local service mode managed system policies will have the View information: Managed systems/Managed accounts/Group sets/Account sets access control enabled for the ALLREQUESTERS and ALLRECIPIENTS user groups.
You can choose not to disclose this information for any future push or local service mode managed system policies created. To do this, go to Modules > Privileged access menu and set IDARCHIVE VIEW MANAGED SYSTEM ACCOUNT INFO to Disabled . Modifying this option will not affect any managed system policies created prior to this change.
Who can see check-out information
Users may be able to view details about who has currently checked out the password or group set and the maximum number of check-outs allowed. This is controlled by the RES PWD CICO VIEW DETAILS and RES GSET CICO VIEW DETAILS settings on the Manage the system > Modules > Privileged access page.
Standard details include password or group set status, expiry time and last change, whether the password or group set can be requested, or whether a request has been approved and when it can be checked out.
Who can request check-out extensions
By default, any user can request a check-out extension to an active managed account or group set access. You can control this by:
Removing the "Request check-out extensions" privilege for ALLREQUESTERS in the Manage the system > Security> Access to user profiles> Global help desk rules.
This changes the default behavior so that check-out extensions are disabled for privileged access requests.
Specifying a user class in the ACCESS EXTENSIONS USERCLASS setting on the Manage the system > Modules > Privileged access menu.
This changes the default behavior so that only users belonging to the specified user class can request check-out extensions.
Account access check-out options
The managed system policy must have the password or SSH key authentication type in order to configure account access check-out options. Use options available in the Manage the system > Privileged access > Options > General > Account access request menu to control:
Options that can be configured on both Account access request and Group set access request tabs share the same value.
Options for external program triggers for generic access check-outs are available in Manage the system > Modules > Privileged access .
Account access request behavior
The following settings affect privileged account access request behavior:
Option | Description |
|---|---|
MAX CHECKOUT PASSWORD CHANGE INTERVAL | The maximum interval time, in days, that a checked-out account’s password stays unchanged. Passwords are randomized once this interval has passed. The default is 2 days. Setting this to 0 allows passwords to remain unchanged until a user checks it in. Once a password is checked out, it is not randomized according to the RESOURCE PASSWORD CHANGE INTERVAL. It is recommended that MAX CHECKOUT PASSWORD CHANGE INTERVAL be set to a value greater than RESOURCE PASSWORD CHANGE INTERVAL. This will prevent passwords from being randomized while they are checked out regardless of the RES CHECKOUT PASSWORD RANDOMIZE MODE setting. |
RES CHECKIN RANDOMIZE | The managed account’s password is randomized when the user checks in. |
RES CHECKOUTEXP RANDOMIZE | The managed account’s password is randomized when the check-out interval has expired. |
RES CHECKOUT LIMIT | The number of users allowed to check out account access simultaneously. The default is 1. |
RES CHECKOUT PASSWORD RANDOMIZE MODE | Choose the randomization mode for cases where passwords can be checked out by multiple users simultaneously (the RES CHECKOUT LIMIT is greater than 1). Choose EXTEND to have passwords randomized when the MAX CHECKOUT PASSWORD CHANGE INTERVAL is passed or when all users who have checked out the password check it in. Choose RESET to have a password randomized at expiry time or whenever any user checks in. Users who have checked out the password are notified that it has changed, and that they should log in again to re-access the password. |
RES DEFAULT CHECKOUT INTERVAL | The default interval, in minutes, at which managed account passwords can be checked out. The value must be smaller than RES MAXIMUM CHECKOUT INTERVAL and larger than RES MINIMUM CHECKOUT INTERVAL. This value is used to pre-load the Duration and Duration unit values on the check-out access request page and the check-out extension request page. The default is 240 minutes, or 4 hours. You can also set this value in the Group set access request tab. |
RES MAQ CHECKOUT ABORT | Enable this setting to disallow an account set check-out if one of the member accounts fails to be checked out; for example, if the check-out limit for the individual account has been reached. |
RES MAQCHECKOUT LIMIT | The number of users allowed to check out an account set simultaneously. The default is 1. |
RES MAQ CMDFILE CLEANUP INTERVAL | The interval (in days) that account set access command output files can exist on the Bravura Privilege server. The default is 365 days. This does not affect command output files generated with "Never delete command output file from server" option. |
RES MAXIMUM CHECKOUT INTERVAL | The maximum interval, in minutes, at which privileged access can be checked out. When RES VALIDATE EXTENSION is disabled, approved check-out extension requests may exceed this limit. The default is 1440 minutes, or 24 hours. You can also set this value in the Group set access request tab. This should be less than the RESOURCE PASSWORD CHANGE INTERVAL, in order to prevent scheduled password changes from being skipped. |
RES MINIMUM CHECKOUT INTERVAL | The minimum interval, in minutes, at which managed account passwords can be checked out. The default is 5 minutes. You can also set this value in the Group set access request tab. |
RES PORT TEST | The port to use when testing for connectivity on remote systems. The default is 445. Set this value to "0" to disable port checks on connection failures. |
RES PWD ACL PLUGIN | Plugin to determine user access controls when viewing passwords via the API. See Using a plugin to define access to passwords for more information. |
RES REVOKE RANDOMIZE | The managed account’s password is randomized when a user’s access to it is checked in by another user. |
RES VALIDATE EXTENSION | The setting to configure if check-out extension requests are restricted by RES MAXIMUM CHECKOUT INTERVAL. Enable to only allow extension requests when the current check-out interval does not exceed the maximum check-out interval. Disable to always allow privileged access check-out extension requests. The default is disabled. You can also set this value in the Group set access request tab. |
Account access check-out external program triggers
Managed system policy exit points do not override global settings and vice versa; however, in the case where an exit point is configured to run the same program from both locations, only one instance of the program is run.
The following settings relate to account access request events and can be set in the Account access request tab:
The following settings relate to account set requests and can be set in the Account access request tab:
Account set events that launch interface programs
Option | Description |
RES MAQ ACCESS REVOCATION CHECKIN | An account set access is checked in by another user. |
RES MAQ CHECKIN FAILURE | An account set access check-in has failed. |
RES MAQ CHECKIN SUCCESS | An account set access check-in is successful. |
RES MAQ CHECKOUT EXPIRY | A checked out account set access expires. |
RES MAQ CHECKOUT FAILURE | A checked out account set access has failed. |
RES MAQ CHECKOUT LIMIT REACHED | An account set access check-out limit has exceeded. |
RES MAQ CHECKOUT PARTIAL | An account set access check-out is partially successful. |
RES MAQ CHECKOUT SUCCESS | An account set access check-out is successful. |
See also
Privileged access app for configuring external program triggers for generic access check-outs.
Event configuration (exit traps) for more information about configuring event actions.
Generic access check-in and check-out failure retries
In the event that a generic access check-out fails for a managed account, the check-out is retried every 10 minutes (by default) until successful or the check-out expiry time has passed. In addition, recipients are able to manually retry the check-out in the Privileged access app.
In the event that a generic access check-in fails for a managed account, the check-in is retried once every minute (by default) until successful or the retry timeout (default 10 minutes) has been reached.
See also
Generic access check-in and check-out retries for modifying interval or timeout values for generic access check-in and check-out retries.
Group set check-out options
The managed system policy must have the group set authentication type in order to configure group set check-out options. Use options available in the Manage the system > Privileged access > Options > General > Group set access request menu to control:
Options that can be configured on both Group set access request and Account access request tabs share the same value.
Group set access request behavior
The following settings affect group set access request behavior:
Option | Description |
|---|---|
RES DEFAULT CHECKOUT INTERVAL | The default interval, in minutes, at which managed account passwords can be checked out. The value must be smaller than RES MAXIMUM CHECKOUT INTERVAL and larger than RES MINIMUM CHECKOUT INTERVAL. This value is used to pre-load the Duration and Duration unit values on the check-out access request page and the check-out extension request page. The default is 240 minutes, or 4 hours. You can also set this value in the Account access request tab. |
RES GSET ACCT SEL PLUGIN | Specify a program to automatically select an account that will receive temporary group membership. |
RES GSET CHECKOUT AGENT POLICY | Specify the connector behavior used when a group set check-out fails. The available options are "Ignore failure", "Roll back", and "Abort." |
RES GSET CHECKOUT LIMIT | The number of users allowed to check out group set access simultaneously. This limit is based on a single group set for a single managed system. The default is 1. |
RES MAXIMUM CHECKOUT INTERVAL | The maximum interval, in minutes, at which privileged access can be checked out. When RES VALIDATE EXTENSION is disabled, approved check-out extension requests may exceed this limit. The default is 1440 minutes, or 24 hours. You can also set this value in the Account access request tab. |
RES MINIMUM CHECKOUT INTERVAL | The minimum interval, in minutes, at which managed account passwords can be checked out. The default is 5 minutes. You can also set this value in the Account access request tab. |
RES PORT TEST | Port to use when testing for connectivity to remote systems. Default is 445. Set this value to "0" to disable port checks on connection failures. |
RES VALIDATE EXTENSION | The setting to configure if check-out extension requests are restricted by RES MAXIMUM CHECKOUT INTERVAL. Enable to only allow extension requests when the current check-out interval does not exceed the maximum check-out interval. Disable to always allow privileged access check-out extension requests. The default is disabled. You can also set this value in the Account access request tab. |
Group set access check-out external program triggers
Managed system policy exit points do not override global settings and vice versa; however, in the case where an exit point is configured to run the same program from both locations, only one instance of the program is run.
The system always defaults to request access events before generic events are fired. For example, PAM CHECKOUT EXPIRY will not fire if RES CHECKOUT EXPIRY has been triggered. Events defined for "Account access request", "Account set access request" and "Group set access request" will always fire instead of generic events. The following events can trigger email or other external program actions:
The following settings relate to group set requests and can be set in the Group set access request tab:
See Event configuration (exit traps) for more information about configuring event actions.
Automatically selecting user accounts to receive temporary group membership
Users can have many accounts from a single target or across multiple targets. You can filter the amount of accounts that are available to the user for temporary group membership. Use the RES GSET ACCT SEL PLUGIN setting to specify a plugin that will be used to automatically return a single user account or a subset of the user’s accounts.
See the sample script plugin-tmp_gset_acct_sel.psl in the sampes directory for more details.
Determining the connector behavior of group set check-out failures
Use the RES GSET CHECKOUT AGENT POLICY setting to specify the behavior of the connector when group membership fails to be added to at least one group during check-out of a group set from a push-mode managed system policy. A behavior policy is used to determine how group set check-out failures should be treated.
This policy can be one of three states:
Ignore failure: skips any failures encountered by the agent and continues to process subsequent groups. This is the default policy.Roll back: revert any successful group memberships made before the failure was encountered.Abort: halt processing subsequent groups after failure is encountered; existing group memberships are left as-is.
These policies do not apply when checking in a group set. Any failures encountered during check-in are skipped and reported back, to be retried at a later time.
Group set check-in failure retries
The following system variables can be configured in Manage the system > Modules > Privileged access .
In the event that an account fails to be removed from one or more groups in the group set during check-in, the check-in can be retried at a later time. Use RES GSET CHECKIN MAX RETRY to set the maximum number of group set check-in retries.
You can also configure event actions to trigger external programs when group membership has been successfully removed after subsequent retries or when group membership fails to be removed after exhausting all retries, using RES GSET CHECKIN RETRY SUCCESS and RES GSET CHECKIN RETRY FAILURE , respectively.
Configure event actions RES GSET CHECKIN GRP NO SUCH MEMBER if an account loses its group membership before the group set has been checked-in, or RES GSET CHECKIN GRP NOT FOUND if a group in the group set cannot be located on the managed system. In these situations, the check-in is considered successful and will not be retried.
See Privileged access app for more details.
Checking in access
Users who are granted the "Check in access" privilege can check in the access of other users by clicking Check in button in Privileged access app. This only applies to active check-outs.
Superuser accounts (the ones with "All" privileges granted in Manage the system > Security > Access to product features > Individual administrators or Administrator groups), are product administrators, so they cannot get the Privileged Access link on their login page to perform a check-in. The check-in operation is available to end users, usually a manager who is granted "revoker" privileges.
You can grant the check-in privilege to a set of users:
By granting "Check in access" privilege in Security > Access to user profiles > Global help desk rules > <user group>.
Adding users to the built-in Policies > User classes > _ACCESS_ALL_ACTIVE_CHECKOUTS if the user class exists.
On the user group page, you can check who gets the privilege by using the Test... button on Membership criteria tab.
The check-in operation carries out an emergency check-in. For privileged accounts, it immediately randomizes any password the user has checked out. For privileged accounts checked out using SSH keys, it removes the user’s SSH key from the target. For temporary group membership, it revokes group memberships from all group sets the user has checked out. By default, the recipient user can still request permission to check out privileged access. Other users who have permission to access the affected account are advised that the password has been changed.
Requests that are in the status of checking out cannot be checked in.
Example
Click below to view a demonstration:
Privileged access request messages
The following settings affect messages displayed to users when certain events occur when requesting access check-outs, and can be set in either the Account access request tab or Group set access request tab:
Option | Description |
|---|---|
RES CHECKOUT EXPIRED MSG | The message to display to users when their connection is terminated when their access session reaches the forced check-in time. The message is controlled by the !!!ERROR_EXPIRED_CHECKOUT M4 tag, which by default displays in English: “Your check-out time has expired. Please request the account access again. |
RES CHECKOUT EXPIRY WARNING MSG | The message to display to users when their connection will be terminated X minutes before their access session reaches the forced check-in time. The value of X is controlled by RES NOTIFY IMMINENT CHECKIN INTERVAL. The message is controlled by the !!!WARNING_CHECKOUT_EXPIRY_APPROACHING M4 tag, which displays in English: “This session will be terminated in X minutes when the check-out time expires.” |
RES CONNECTION TO SERVER FAILED MSG | The message to display to users when a remote desktop connection cannot be established. This is used by the remote desktop access disclosure module ( |
RES CONNECTION TO SERVER FAILED TEST FAILED MSG | The message to display to users when a remote desktop connection cannot be established, and connectivity to the remote system does not exist. This is used by the remote desktop access disclosure module ( |
RES CONNECTION TO SERVER FAILED TEST PASSED MSG | The message to display to users when a remote desktop connection cannot be established, but connectivity to the remote system exists. This is used by the remote desktop access disclosure module ( |
RES FAILED TO CREATE PROCESS MSG | The message to display to users when an access disclosure plugin fails to launch. The message is controlled by the !!!RES_FAILED_TO_CREATE_PROCESS_MSG_DEFAULT M4 tag, which displays in English: “Failed to launch access disclosure plugin.” |
RES LOGIN FAILED MSG | The message to display to users when the remote desktop connection encounters authentication problems. The message is controlled by the !!!RES_LOGIN_FAILED_MSG_DEFAULT M4 tag, which displays in English: “Unable to log into remote system using managed account and password.” |
RES PASSWORD EXPIRED MSG | The message to display to users when they try to access an account that has expired because it has been automatically randomized. The message is controlled by the !!!ERROR_EXPIRED_PASSWORD M4 tag, which displays in English: “The password has expired.” This value only applies to Account access request. |
RES PROGRAM PATH INVALID MSG | The message to display to users when a required program cannot be found on their system. This is used by the command prompt access control ( |
RES SESSION EXPIRED MSG | The message to display to users when they try view or use a password after their session has expired. The message is controlled by the !!!ERROR_EXPIRED_SESSION M4 tag, which displays in English: “The session has expired. Please re-log in.” |
RES SHOW PASSWORD ANYWAY MSG | The message to display to users who try to access an expired password. The message is controlled by the !!!WARNING_RES_PASSWORD_EXPIRED M4 tag, which displays in English: “You are attempting to use an expired password. Do you want to continue? Refresh the page to load the current password.” This value only applies to Account access request. |
Check-in / check-out notifications
The following settings affect notifications sent to users when a checked out account is about to expire, and can be set in the Account access request tab:
Option | Description |
|---|---|
RES NOTIFY IMMINENT CHECKIN | Program to notify users that their check-outs are about to expire. Configure this event to specify the details of the check-out expiry email notification. Use this in conjunction with RES NOTIFY IMMINENT CHECKIN INTERVAL. |
RES NOTIFY IMMINENT CHECKIN INTERVAL | The time interval (in minutes) before check-out expiry that notifications (configured in RES NOTIFY IMMINENT CHECKIN) will be sent and that warning messages (configured in RES CHECKOUT EXPIRY WARNING MSG) will start appearing. By default, this field is blank and no check-out expiry notifications are sent. If this field is blank, check-out expiry warning messages will start appearing 5 minutes before the check-out expires. If this field is set to 0, no check-out expiry notifications will be sent and no warning messages will appear. |
Users are notified in the following cases for:
Account access request notification events
When an account access request is approved, the recipient receives an email including a link to the account access page. The link requires the user to verify their identity as the recipient of the request.
When the check-out limit is reached, Bravura Privilege warns users who request a check-out, and notifies users who currently have checked out the account access.
When an account access is checked out, Bravura Privilege notifies other users who currently have checked out access for the same account, listing the status of all other requests on the account. You can control the details in the notification using the RES PWD CICO VIEW DETAILS setting in the Manage the system > Modules > Privileged access menu.
If a checked out account password is checked in and the password is randomized, depending on the RES CHECKIN RANDOMIZE , Bravura Privilege notifies other users who currently have checked out access to the same account and asks them to get the updated password.
If a checked out account’s password expires, Bravura Privilege notifies users who have checked it out. If the password was randomized, depending on the RES CHECKOUT PASSWORD RANDOMIZATION MODE , Bravura Privilege notifies other users who currently have checked out the password and asks them to get the updated password.
When a check-out request is denied or canceled, Bravura Privilege notifies the user that the request is denied or canceled respectively.
When a user’s permission to access an account is checked in by another user, Bravura Privilege notifies:
The recipient user
Other users who currently have checked out the access accounts
Other users waiting to check out the password
Authorizers, if the request was submitted through workflow.
If the password is randomized, depending on the RES REVOKE RANDOMIZE setting, Bravura Privilege notifies other users who currently have checked out the password and asks them to get the updated password.
When a managed account’s password is manually randomized, Bravura Privilege notifies all users who currently have checked out the access to that account and asks them to get the updated password.
When the MAX CHECKOUT PASSWORD CHANGE INTERVAL is reached and if a password is randomized, depending on the RES CHECKOUTEXP RANDOMIZE setting, Bravura Privilege notifies all users who currently have checked out access for that password and asks them to get the updated password.
Group set access request notification events
When a temporary group membership access request is approved, the recipient receives an email including a link to the temporary group membership access page. The link requires the user to verify their identity as the recipient of the request.
When the check-out limit is reached, Bravura Privilege warns users who request a check-out, and notifies users who currently have checked out the temporary group membership access.
When a temporary group membership access is checked out, Bravura Privilege notifies other users who currently have checked out access for the same temporary group membership.
If a checked out temporary group membership expires, Bravura Privilege notifies users who have checked it out.
When a check-out request is denied or canceled, Bravura Privilege notifies the user that the request is denied or canceled respectively.
When a user’s permission to access a temporary group membership is checked in by another user, Bravura Privilege notifies:
The recipient user
Other users waiting to check out the temporary group membership access.
Authorizer(s), if the request was submitted through workflow.
Email notification for privileged access
You can set the following email notification options in the Manage the system > Privileged access > Options > Email notification menu:
Option | Description |
|---|---|
EMAIL NOTIFICATION TIME | Set times of day to send out notification emails for administrative password resets. Write times in the format HH:MM in a comma-delimited list. If no time is specified, an email is sent immediately after a password reset event. |
RES RECIPIENT EMAIL | A comma-delimited list of email addresses to notify of password change issues. |
RES FAIL RECIPIENT EMAIL | A comma-delimited list of email addresses to notify of password change failures. |
RES SUCCESS RECIPIENT EMAIL | A comma-delimited list of email addresses to notify of successful password changes. |
If you alter the reminder times or interval, messages that have already been queued will be sent at the previously set time. The new time values apply to messages triggered after you make the changes.
See also
See Email notification for detailed information on general settings for email.
Using the API to retrieve administrative passwords
You can use API functions to access the API via:
Using a product administrator with OTP rights
You can access the API and retrieve, randomize, and override passwords, or download large credentials, via a product administrator with one time password (OTP) rights.
Configuration
To configure Bravura Privilege access to privileged access API functions:
Create an _OTP_USER product administrator account with the "OTP IDAPI caller" administrative privilege.
The IP address with CIDR bitmask field must specify the list of IP addresses from which the product administrator will access the API Service.
Create a user class with the following properties:
ID: _EXPLICIT_OTP_USERS_
Participants: USERID
Explicit user: _OTP_USER
Create a user group
ID: _OTP_USERGROUP
Access control: For the managed system from which you are requesting passwords, grant Pre-approved check-out of managed accounts managed accounts and Request check-out of managed accounts.
membership criteria: _EXPLICIT_OTP_USERS_
API functions
In order to retrieve an account password that Bravura Privilege is managing you must:
Use the LoginEx function to log in to the API Service.
After a successful login, LoginEx automatically resets the product administrator ’s password to a new 64 byte string. The new password is made available through the newapw argument. The new password has to be used for the next log in.
Use the KMKeyGetByAccount function to retrieve a password.
When using KMKeyGetByAccount, note that the accountID is case sensitive and that the resourceID must be uppercase.
Best practices
Note the following:
If the password is accessed by IDAPI SOAP, either ws binding or basic binding over HTTPS is used.
When saving the OTP password, ensure that it remains encrypted.
When using the OTP account, the calling program cannot access the IDAPI service concurrently. Use a MUTEX or serial access to the OTP account or one OTP account per program/caller.
Once the password is given, it is the caller’s responsibility to use the password correctly and dispose of the password. Storing the current password is not recommended. It should be encrypted if it is stored.
Using the API to check out passwords
You can use API functions Login, WFRequestCheckout, and WFRequestCheckin, to access the API and retrieve passwords being managed by Bravura Privilege , via a workflow-based approval to check out access privileges.
In order to checkout a privileged account password via the API you must use the Login function to log in to the API Service, via a user with the IDAPI Caller privilege. The user must effectively log in as the recipient, using the AuthConsoleUser option for Login.
The checkout availability windows must be valid at the time the WFRequestCheckout/WFRequestCheckin functions are executed.
You can use the API at each stage of the workflow, using the Login function with AuthConsoleUser option to impersonate the appropriate user; that is, you can:
Issue a request for checkout via Privileged access app, or the API (as the requester) using the WFRequestCreate, WFRequestSubmit, WFRequestAttrsSet (PPM_VIEW_TIME_BEGIN, PPM_VIEW_TIME_END), and WFRequestActionsGet (ARCHREQPWD).
Issue a request to approve the checkout request via Requests app, or the API (as the authorizer) using the WFApprove function. Ensure the primary field is set correctly in the WFApprove input.
Issue a request to fetch the password via Privileged access app, or the API (as the recipient) using the WFRequestCheckout function.
Issue a request to check in the password via Privileged access app, or the API (as the recipient) using the WFRequestCheckin function, or check in the password using Privileged access app.
For generic access check-outs, the following API functions must be used instead of the WFRequestCheckout and WFRequestCheckin functions:
WFRequestGenericCheckout
WFRequestGenericCheckin
GenericCheckoutStatusGet
GenericCheckoutDisclose