An entitlement defines which users are authorized to check out passwords for accounts in the scope of the account's policies. A policy defines scope (that is, which accounts) and the rules for checking out passwords, such as the duration, how many approvals are required, and so on.
It is possible for an account to be governed by more than one entitlement, or is in the scope of more than one policy within an entitlement. When evaluating which policy governs a request to grant access, Safeguard for Privileged Passwords first determines if the request has Emergency Access and evaluates against only those policies which permit Emergency Access. It then considers the time for which the request is being made and further evaluates against only those policies which have Time Restrictions that permit the request. Finally, if there is a conflict between the remaining policies, it uses Priority to determine which policy should govern the request.
Example scenario:
- Entitlement A (priority 1)
- Policy: Week Day Policy.
- Policy time restrictions: Monday through Friday 08:00 to 17:00.
- Scope: AccountX
- Entitlement B (priority 2)
- Policy 1: Sunday AM (priority 1)
- Policy time restrictions: Sunday 08:00 to 12:00.
- Scope: AccountX
- Policy 2: Sunday PM (priority 2)
- Policy time restrictions: Sunday 13:00 to 17:00.
- Scope: AccountX
Notice that AccountX is in the scope of all three of these policies.
If a user requests the password for AccountX for Sunday at 16:00, Safeguard for Privileged Passwords first considers Entitlement A because it is priority 1. When it determines that the policy time restrictions prevent the password release, it then considers Entitlement B.
Safeguard for Privileged Passwords first considers Entitlement B's priority 1 policy. When it determines that the time restrictions prevent the password release, it then considers Policy 2. Once the request is satisfied, Safeguard for Privileged Passwords grants the request.
However, if the hours in Entitlement B's Policy 1 were instead 08:00 to 17:00 then Policy 1 would be preferred because it has a higher priority. And if Entitlement B's Policy 2 was instead configured to allow Emergency Access, and the request being made had Emergency Access, then Policy 1 (though it has a higher priority of 1) would be eliminated from the selection and Policy 2 would again be preferred.
It is the responsibility of the Security Policy Administrator to define access request policies in Safeguard for Privileged Passwords.
A policy defines:
- The scope, which may be assets, asset groups, accounts, or account groups.
- The access type, which may be a:
-
Credential access type:
- Password Release
- SSH Key
- API Key
-
Session access type:
- RDP (Remote Desktop Protocol)
- RDP Application
- SSH (Secure SHell)
- Telnet
- The rules for checking out passwords, such as the duration, how many approvals are required, and so on.
Considerations
- An access request policy is only assigned to one cluster.
- An access request policy is only used in the entitlement in which it is created. If you delete an entitlement, all access request policies associated with that entitlement are deleted.
To add an access request policy to an entitlement
- Navigate to Entitlements.
- In Entitlements, select to edit an entitlement from the list and open the Access Request Policies tab.
- Click
New Access Policy from the details toolbar.
- In the Create Access Request Policy dialog, provide information in each of the tabs:
On the General tab, enter the following information for the access request policy.
Navigate to:
web client: Security Policy Management > Entitlements > Access Request Policies > (create or edit a policy)
Table 196: Access Request Policy: General tab properties
| Name |
Enter a unique name for the access request policy.
Limit: 50 characters |
| Description |
Enter descriptive text that explains the access request policy.
Limit: 255 characters |
| Priority |
The priority of this policy compared to other policies in this entitlement.
If a user desires to access an account in the scope of two different request polices within an entitlement, then the policy with the highest priority (that is, the lowest number) takes precedence. For more information, see How Safeguard for Privileged Passwords evaluates policy when a user submits an access request. |
|
Choose Request Policy Type |
Specify the type of request policy:
-
Credential
-
Session
- RDP (Remote Desktop Protocol)
- RDP Application
- SSH (Secure SHell)
- Telnet
|
|
Choose Credential Type |
Specify the type of credential:
NOTE: You can configure an access request policy for a password, SSH key, or API key request; however, if the Privileged Passwords module license is not installed, you will not be able to submit a password, SSH key, or API key release request.
Similarly, you can configure an access request policy for a session request; however, if the Safeguard for Privileged Sessions server is not joined to Safeguard for Privileged Passwords, you will be unable to submit a session request.
NOTE: When checking out API keys, since multiple API keys may be associated with an account it will check out all the API Keys. |
| Have the Access Policy Expire on Date and Time |
Select this to enforce an expiration date for the policy. Enter the expiration date and time. |
|
Use Time Windows |
Select this option to enforce time windows.
Select and drag to highlight the hours you want to allow. Colored tiles are blocked times . Clear are available times. |
Use the Access Config tab to configure the access settings for the type of access being requested, based on the access type specified on the General tab.
Navigate to:
- web client: Security Policy Management > Entitlements > Access Request Policies > (create or edit a policy)
Table 197: Access Request Policy: Access Config tab properties
|
Include password release with sessions requests |
If Access Type is RDP, SSH, or Telnet, select this check box to include a password release with session access requests. |
|
Include SSH Key release with sessions requests |
If Access Type is RDP, SSH, or Telnet, select this check box to include an SSH Key release with session access requests. |
| Close expired sessions |
If Access Type is RDP, SSH, or Telnet, select this check box to close sessions that have expired. |
|
Change password after check-in |
Select this check box if the password is to be changed after the user checks it back in. This check box is selected by default. |
|
Change SSH key after check-in |
Select this check box if the SSH key is to be changed after the user checks it back in. This check box is selected by default. |
|
Passphrase Protect SSH Key |
If Access Type is SSH Key, select this check box to require a passphrase for the SSH key. |
|
Allow simultaneous access |
Select this check box to allow multiple users access to the accounts and assets governed by this policy. Use the next check box to identify how many users can have access at once. |
|
Maximum users at one time |
When the Allow simultaneous access option is selected, enter the maximum number of users that can request access at one time. |
|
Asset-Based Session Access |
If Access Type is RDP, SSH, or Telnet, select one of the following options to define the type of account credentials to be used to access any of the assets defined in the policy scope, in addition to the accounts defined in the policy scope when a session is requested:
- None (default): The credentials are retrieved from the vault when the session is requested.
- User Supplied: The requester user must provide the credentials when the session is requested.
- Linked Account: The requester user's account is linked to a directory account that will be used when the session is requested.
-
Directory Account: Use the Browse button to select one or more directory accounts to be used when the session is requested.
If the Directory Account was migrated from an SPP version prior to 2.7, the directory account identifier may be blank, because earlier SPP versions understood only one assignment and version 2.7 results in multiple assignments. |
|
Allow password access to linked accounts |
If Access Type is Password Release, select this check box to allow users to request passwords for their respective linked account. Access to each user’s linked account is governed by the other configurations defined in this policy.
Additionally, Enable scope filtering for linked accounts can be selected in order to limit the number of requestable accounts to linked accounts that are also defined in the scope. |
|
SPS Connection Policy |
Use this drop-down to select an SPS connection policy to use with the access request policy. |
|
RDP Host Asset |
If Access Type is RDP Application, use the Browse button associated with this field to select the asset configured to connect with the Windows Application Server. |
|
Require Host Account |
If Access Type is RDP Application, select this checkbox and then click Browse to locate the host account to use. When deselected, you will be prompted for the information when the session is initialized. |
|
Application Display Name |
If Access Type is RDP Application, this is the display name for the application that was provided when the remote application was published on the Windows application server. |
|
Use Application Alias |
If Access Type is RDP Application, this is the alias name defined when the remote application was published on the Windows application server. Ensure the full alias path is used, including the two vertical bars before the alias name (for example, ||OISGRemoteAppLauncher).
If this option is used, the Use Application Path and Command Line option will not be available. |
|
Use Application Path and Command Line |
If Access Type is RDP Application, this option contains the following 2 fields:
-
Application Path (path to the remove application): Enter the full path of an application program relative to the Windows host it will be running on.
-
Application Command Line (parameters for the remote application): The Application Command Line contains the command line parameters to the application specified in the Application Path. The command line depends on the application. For example, some applications may require a set command line that will include the full path of the remote application along with its command line parameters while other applications may not require a set command line at all.
If this option is used, the Use Application Alias field will not be available. |
|
Use Alternate Login Name |
If this option is selected, the alternate login name for the account will be used. |
