Chat now with support
Chat mit Support

One Identity Safeguard for Privileged Passwords 7.2 - Administration Guide

Introduction System requirements and versions Using API and PowerShell tools Using the virtual appliance and web management console Cloud deployment considerations Setting up Safeguard for Privileged Passwords for the first time Using the web client Home Privileged access requests Appliance Management
Appliance Backup and Retention Certificates Cluster Enable or Disable Services External Integration Real-Time Reports Safeguard Access Appliance Management Settings
Asset Management
Account Automation Accounts Assets Partitions Discovery Profiles Tags Registered Connectors Custom platforms
Security Policy Management
Access Request Activity Account Groups Application to Application Cloud Assistant Asset Groups Entitlements Linked Accounts User Groups Security Policy Settings
User Management Reports Disaster recovery and clusters Administrator permissions Preparing systems for management Troubleshooting Frequently asked questions Appendix A: Safeguard ports Appendix B: SPP and SPS join guidance Appendix C: Regular Expressions About us

How Safeguard for Privileged Passwords evaluates policy when a user submits an access request

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.

Creating an access request policy

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

  1. Navigate to Entitlements.
  2. In Entitlements, select to edit an entitlement from the list and open the Access Request Policies tab.
  3. Click New Access Policy from the details toolbar.
  4. In the Create Access Request Policy dialog, provide information in each of the tabs:

    General tab (create access request policy)

    Where you add general information about the access request policy as well as specify the type of access being requested.

    Security tab (create access request policy)

    Where you define the access settings for the selected type of request including allowing users to request passwords from their respective linked accounts.

    Scope tab (create access request policy)

    Where you assign assets, asset groups, accounts, or account groups to an access request policy.

    Workflow tab (create access request policy)

    Where you configure the access request policy requester, approver, reviewer settings.

General tab (create access request policy)

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
Property Description
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

    • Password

    • SSH Key

    • API Key

  • Session

    • RDP (Remote Desktop Protocol)
    • RDP Application
    • SSH (Secure SHell)
    • Telnet

Choose Credential Type

Specify the type of credential:

  • Password

  • SSH Key

  • API Key

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.

Security tab (create access request policy)

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

Property

Description

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.
    • Enable scope filtering for linked accounts: When selected, this setting allows you to limit the number of requestable accounts to linked accounts that are also defined in the policy scope.

      NOTE: If the policy scope includes only assets/asset groups and no accounts, then the scope filtering setting has no effect, and the policy is available to all of the linked directory accounts on each scoped policy asset.

  • 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.

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen