立即与支持人员聊天
与支持团队交流

One Identity Safeguard for Privileged Sessions 7.4 - Administration Guide

Preface Introduction The concepts of One Identity Safeguard for Privileged Sessions (SPS)
The philosophy of One Identity Safeguard for Privileged Sessions (SPS) Policies Credential Stores Plugin framework Indexing Supported protocols and client applications Modes of operation Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) Archive and backup concepts Maximizing the scope of auditing IPv6 in One Identity Safeguard for Privileged Sessions (SPS) SSH host keys Authenticating clients using public-key authentication in SSH The gateway authentication process Four-eyes authorization Network interfaces High Availability support in One Identity Safeguard for Privileged Sessions (SPS) Versions and releases of One Identity Safeguard for Privileged Sessions (SPS) Accessing and configuring One Identity Safeguard for Privileged Sessions (SPS)
Cloud deployment considerations The Welcome Wizard and the first login Basic settings
Supported web browsers The structure of the web interface Network settings Configuring date and time System logging, SNMP and e-mail alerts Configuring system monitoring on SPS Data and configuration backups Archiving Cleaning up audit data Using plugins Forwarding data to third-party systems Starling integration
User management and access control
Login settings Managing One Identity Safeguard for Privileged Sessions (SPS) users locally Setting password policies for local users Managing local user groups Managing One Identity Safeguard for Privileged Sessions (SPS) users from an LDAP database Authenticating users to a RADIUS server Authenticating users with X.509 certificates Authenticating users with SAML2 Managing user rights and usergroups Creating rules for restricting access to search audit data Displaying the privileges of users and user groups Listing and searching configuration changes
Managing One Identity Safeguard for Privileged Sessions (SPS)
Controlling One Identity Safeguard for Privileged Sessions (SPS): reboot, shutdown Managing One Identity Safeguard for Privileged Sessions (SPS) clusters Managing a High Availability One Identity Safeguard for Privileged Sessions (SPS) cluster Upgrading One Identity Safeguard for Privileged Sessions (SPS) Managing the One Identity Safeguard for Privileged Sessions (SPS) license Accessing the One Identity Safeguard for Privileged Sessions (SPS) console Sealed mode Out-of-band management of One Identity Safeguard for Privileged Sessions (SPS) Managing the certificates used on One Identity Safeguard for Privileged Sessions (SPS)
General connection settings HTTP-specific settings ICA-specific settings MSSQL-specific settings RDP-specific settings SSH-specific settings Using Sudo with SPS Telnet-specific settings VMware Horizon View connections VNC-specific settings Indexing audit trails Using the Search interface Advanced authentication and authorization techniques Reports The One Identity Safeguard for Privileged Sessions (SPS) REST API One Identity Safeguard for Privileged Sessions (SPS) scenarios Troubleshooting One Identity Safeguard for Privileged Sessions (SPS)
Network troubleshooting Gathering data about system problems Viewing logs on One Identity Safeguard for Privileged Sessions (SPS) Changing log verbosity level of One Identity Safeguard for Privileged Sessions (SPS) Collecting logs and system information for error reporting Collecting logs and system information of the boot process for error reporting Support hotfixes Status history and statistics Troubleshooting a One Identity Safeguard for Privileged Sessions (SPS) cluster Understanding One Identity Safeguard for Privileged Sessions (SPS) RAID status Restoring One Identity Safeguard for Privileged Sessions (SPS) configuration and data VNC is not working with TLS Configuring the IPMI from the BIOS after losing IPMI password Incomplete TSA response received Using UPN usernames in audited SSH connections
Using SPS with SPP Configuring external devices Using SCP with agent-forwarding Security checklist for configuring One Identity Safeguard for Privileged Sessions (SPS) Jumplists for in-product help Configuring SPS to use an LDAP backend Glossary

Configuring four-eyes authorization

The following describes how to configure four-eyes authorization.

To require four-eyes authorization for a connection

  1. Navigate to the Connections page of the traffic (for example to SSH Control > Connections), and select the connection policy to modify.

  2. Figure 331: <Protocol name> Control > Connections > Access Control — Configuring four-eyes authorization

    Navigate to Access Control and click .

  3. Enter the name of the usergroup whose members are permitted to authorize the sessions of the connection policy into the Authorizer Group field. This group must exist on the Users & Access Control > Local User Groups page. For details on creating and managing usergroups, see Managing user rights and usergroups.

    Caution:

    Usernames, the names of user lists, and the names of usergroups are case sensitive.

  4. By default, the authorizer can authorize any session of the connection policy.

    If the authorizer is permitted to authorize only the sessions of a certain usergroup, select Client user is > Member of, and enter the name of the userlist whose sessions the authorizer can authorize. If you use four-eyes authorization without gateway authentication, you can specify an LDAP group instead of a userlist.

    Caution:

    Usernames, the names of user lists, and the names of usergroups are case sensitive.

    Caution:

    When using both gateway authentication and four-eyes authorization in a Connection Policy, specify the usergroup of the gateway username. The specified group must be a local or LDAP group.

  5. Set the permissions of the usergroup set in the Authorizer Group field.

    • If the Authorizer group can authorize (that is, enable) and audit (that is, monitor in real-time and download the audit trails) the sessions, select Permission > Follow&Authorize.

    • If the Authorizer group can only authorize (that is, enable) the sessions, select Permission > Authorize.

      NOTE: This option is not valid for HTTP connections.

    • If the Authorizer group can only audit (that is, monitor in real-time and download the audit trails) the sessions, select Permission > Follow.

    NOTE: If the Client user is > Member of field is set, the auditor can only monitor the sessions of the specified usergroup. However, if Client user is > Member of field is set, the Auditor cannot access the Search page. To avoid this problem, add another Access Control rule for the Authorizer Group without setting the Client user isfield.

    The admin user of One Identity Safeguard for Privileged Sessions (SPS) can audit and authorize every connection.

  6. To ensure that the client and the authorizer use different IP addresses and thus prevent self-authorization, enable Require different IP. If this is enabled, and the client and the authorizer do not have different IP addresses, it disables all actions for the connection and the four-eyes authorization, until they have different IP addresses.

  7. To ensure that the client and the authorizer use different usernames and thus prevent self-authorization, enable Require different Username. If this is enabled, and the client and the authorizer do not have different usernames, it disables all actions for the connection and the four-eyes authorization, until they have different usernames.

  8. Repeat steps 2-6 to add other authorizers or usergroups if needed.

  9. Click .

  10. Navigate to the Channel Policies page of the traffic (for example, to SSH Control > Channel Policies), and select the channel policy used in the connection.

    Figure 332: <Protocol name> Control > Channel Policies — Configuring four-eyes authorization in the channel policy

  11. Enable the Four-eyes option for the channels which should be accessed only using four-eyes authorization.

    NOTE: If a connection uses secondary channels that require four-eyes authorization — for example, a Remote Desktop connection allows a Drawing channel but requires four-eyes authorization for a Disk redirection channel — the connection is locked until the authorizer accepts the channel on the Four-Eyes page of SPS, or the four-eyes request times out. During this time, the client application can become nonresponsive, for example, display the graphical desktop but not react to mouse clicks.

    NOTE: In Citrix ICA connections, four-eyes authorization is required before the user logs in to the destination server. To request four-eyes authorization only after the log in, when the server-side username is already known, select the Perform 4 eyes after user login option.

  12. Click . After that, users accessing connections using the modified channel policy must be authorized as described in Performing four-eyes authorization on One Identity Safeguard for Privileged Sessions (SPS).

  1. (Optional) If you want to provide a limited SPS web interface to your users that can be used only for gateway authentication and 4-eyes authorization, set up a dedicated user-only web login address. For details, see Configuring user and administrator login addresses.

Performing four-eyes authorization on One Identity Safeguard for Privileged Sessions (SPS)

The following describes how to perform four-eyes authorization on One Identity Safeguard for Privileged Sessions (SPS).

To perform four-eyes authorization on SPS

  1. When a user initiates a connection from a client and four-eyes authorization is required for the connection, SPS will pause the connection.

    NOTE: Four-eyes authorization can be set separately for every channel. However, if a client of an existing connection opens a new channel that requires four-eyes authorization, every channel is paused until the authorization is completed.

  2. Login to SPS, and select Four-Eyes from the main menu. The list of connections waiting for authorization will be displayed.

    Figure 333: Four-Eyes — Performing four-eyes authorization

    NOTE: Only those connections will be listed, where your usergroup has the Authorize or the Follow&Authorize permissions. No other SPS privilege is required to access this page.

  3. Select the connection and click Accept to enable the connection, Reject to deny the connection, or Accept&Follow to enable it and monitor in real-time.

    NOTE: Following a session requires the following:

    • The Record audit trail option must be enabled for the specific channel in the Channel policy of the connection.

    • The Audit Player application must be installed on the computer of the auditor.

    • If the Audit policy of the connection uses encryption, the appropriate decryption keys must be available on the computer of the auditor.

    The Safeguard Desktop Player application replays the live streams in live mode. For details on how to monitor a connection in real-time using the Safeguard Desktop Player, see .

  4. Enter a note why the connection was accepted/rejected into the appearing dialog box. This description will be stored in the connection database together with other metadata about the connection.

    Figure 334: Describing why a connection was accepted/rejected

  5. If you have to terminate an ongoing connection for some reason, select Active Connections from the main menu. The list of ongoing connections will be displayed.

    Figure 335: Active Connections — Displaying active connections

  6. Select the connection to stop, and click Terminate.

    NOTE: When following a connection in the Safeguard Desktop Player application, the auditor can also terminate the connection from the Audit Player by clicking Terminate.

    Figure 336: Terminating a connection in Safeguard Desktop Player

Using credential stores for server-side authentication

Credential Stores offer a way to store user credentials (for example, passwords, private keys, certificates) and use them to log in to the target server, without the user having access to the credentials. That way, the users only have to perform gateway authentication on SPS with their usual password (or to an LDAP database), and if the user is allowed to access the target server, SPS automatically logs in using the Credential Store.

For more information on gateway authentication, see Configuring gateway authentication.

NOTE: Keyboard-interactive authentication is not supported when using credential stores.

Figure 337: Authenticating using Credential Stores

Credential Stores can be stored locally on SPS, or on a remote device. For remote Credential Stores, SPS integrates with external authentication and authorization systems using plugins.

NOTE: After performing a successful gateway authentication, if the credential store does not contain a password for the user, the user is prompted for the server-side password as a fallback.

In case of authenticating to RDP servers using Network Level Authentication (NLA), the server-side password is prompted at the start of the connection. If there is no password in the credential store for the user and the server-side password is incorrect, the connection is terminated.

Configuring local Credential Stores

The following describes how to configure a local Credential Store that stores the credentials used to login to the target host.

Prerequisites

NOTE: Users accessing connections that use Credential Stores to authenticate on the target server must authenticate on SPS using gateway authentication or an AA plugin. Therefore gateway authentication or an AA plugin must be configured for these connections.

For more information, see and .

To configure a local Credential Store that stores the credentials used to login to the target host

  1. Navigate to Policies > Credential Stores.

  2. Click and enter a name for the Credential Store.

  3. Select Local.

  4. Select Encryption key > Built-in. That way the credentials will be encrypted with a built-in password, and the Credential Store is automatically accessible when SPS boots up. To use custom passwords to encrypt the Credential Store, see Configuring password-protected Credential Stores.

    Figure 338: Policies > Credential Stores > Local — Configuring local Credential Stores

  1. Add credentials to the Credential Store.

    1. Click and enter the destination host and the username. For the destination host, you can use hostname, IP address, or subnet as well. To use the same credentials for every destination host, enter the 0.0.0.0/0 subnet. To use the credentials only on the hosts of a specific domain, enter *.domain. Note that:

      • Usernames are case sensitive.

      • To authenticate users of a Windows domain, enter the name of the domain into the Host field.

      Use an IPv4 address.

    2. Set the credentials. SPS will use these credentials to login to the destination host if the credential store is selected in a Connection policy. If more than one credential is specified to a host-username pair, SPS will attempt to use the credentials as the destination host requests it.

      • To add a password, click Passwords > , then enter the password corresponding to the username.

      • To upload a private key, click SSH Keys > >, then paste or upload a private key.

        NOTE: If the private key is protected by a passphrase, enter the passphrase. The passphrase is needed only once during the upload, it is not required for the later operation of the Credential Store.

      • To generate a keypair on SPS click SSH Keys > > , set the length and type of the key, then click Generate. After that, click the fingerprint of the key to download the public part of the keypair. There is no way to download the private key from the SPS web interface.

        NOTE:

        TIP: One Identity recommends using 2048-bit RSA keys (or stronger).

      • To upload a certificate and the corresponding private key, click X509 Keys > > , then paste or upload a certificate and the private key.

        NOTE: If the private key is protected by a passphrase, enter the passphrase. The passphrase is needed only once during the upload, it is not required for the later operation of the Credential Store.

      NOTE: SPS accepts passwords that are not longer than 150 characters and supports the following characters:

      • Letters A-Z, a-z

      • Numbers 0-9

      • The space character

      • Special characters: !"#$%&'()*+,-./:;<>=?@[]\^-`{}_|

    3. Repeat the previous step to add further credentials to the username as necessary.

  2. Repeat the previous step to add further hosts or usernames as necessary.

    NOTE: Credential Stores can be used together with usermapping policies to simplify the administration of users on the target hosts.

    For more information, see Configuring usermapping policies.

  1. Click .

  2. Navigate to the Connection policy where you want to use the Credential Store (for example, to SSH Control > Connections), select the Credential Store to use in the Credential Store field, then click .

    NOTE: The Connection Policy will ignore the settings for server-side authentication (set under Relayed authentication methods) if a Credential Store is used in the Connection Policy.

    Figure 339: <Protocol name> Control > Connections — Select a Credential Store to use

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级