Tchater maintenant avec le support
Tchattez avec un ingénieur du support

One Identity Safeguard for Privileged Sessions 6.14 - 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 and operating systems 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 and cleanup Using plugins Forwarding data to third-party systems Starling integration
User management and access control 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

Inband destination selection

Inband destination selection allows you to create a single connection policy and allow users to access any server by including the name of the target server in their username (for example, ssh username@targetserver:port@scb_address). One Identity Safeguard for Privileged Sessions (SPS) can extract the address from the username and direct the connection to the target server.

Figure 11: Inband destination selection

Since some client applications do not permit the @ and : characters in the username, alternative characters can be used as well:

  • To separate the username and the target server, use the @ or % characters, for example: username%targetserver@scb_address

  • To separate the target server and the port number, use the :, +, or / characters, for example: username%targetserver+port@scb_address

  • If you do not specify the username or the address in nontransparent SSH and Telnet connections, One Identity Safeguard for Privileged Sessions (SPS) displays an interactive prompt where you can enter the username and the server address.

In RDP, do not use the @ character as an inband data separator but use alternative characters, for example, the % character.

You can use both IPv4 and IPv6 addresses with inband destination selection. For IPv6 addresses, add square brackets to separate the address and the port number:

username@[targetserver_ipv6]:port@[scb_address_ipv6]:port

When Network Level Authentication (NLA) is disabled, you can omit the username when starting an RDP connection (for example, use only %targetserver). The user can type the username later in the graphical login screen. However, the username must be specified if Network Level Authentication (NLA) is used in the connection.

For other details on inband destination selection in RDP connections, see Inband destination selection in RDP connections.

You can find examples of using inband destination selection in Using inband destination selection in SSH connections.

Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS)

When a client initiates a connection to a server, One Identity Safeguard for Privileged Sessions (SPS) performs a procedure similar to the ones detailed below. The exact procedure depends on the protocol used in the connection.

Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) using SSH

The following describes what happens when a client connects to a server through One Identity Safeguard for Privileged Sessions (SPS) and how the different configuration options and policies of SPS affect this process. Note that this procedure does not cover the scenarios when inband destination selection is used.

  1. Client-side connection

    The client tries to connect to the server. SPS receives the connection request and establishes the TCP connection with the client.

  2. SPS examines the connection request: it checks the IP address of the client and the IP address and port number of the intended destination server. If these parameters of the request match a connection policy configured on SPS, SPS inspects the connection in detail. Other connections are ignored by SPS, and simply forwarded on the packet level.

    The selected connection policy determines all settings and parameters of the connection.

    NOTE:

    One Identity Safeguard for Privileged Sessions (SPS) compares the connection policies to the parameters of the connection request one-by-one, starting with the first policy in the policy list. SPS applies to the connection the first connection policy that completely matches the connection request.

    For details, see Configuring connections.

  3. SPS selects the destination server based on the Target parameter of the connection policy. Network address translation of the target address can be performed at this step. For details, see Modifying the destination address.

  4. SPS selects the source address used in the server-side connection based on the SNAT parameter of the connection policy. For details, see Modifying the source address.

  1. The client authenticates itself using an authentication method permitted by the Authentication policy set in the Connection policy. Different connections can use different authentication policies, thus allow different authentication methods. The Authentication policy also restricts which users can connect to the server if public-key authentication is used. SPS can authenticate the user to a Local User Database, or to a remote LDAP (for example, Microsoft Active Directory) or RADIUS server. This is inband authentication, since it is performed in the same connection that the client originally established to communicate with the server.

    The username used in this authentication step is referred to as the Gateway username and is used to determine the Gateway group memberships of the user. For details, see Authentication Policies.

    If an AA plugin is configured in SPS, the client may be prompted to provide additional information when authenticating to the server. For details on the AA plugin, see Integrating external authentication and authorization systems. Note that if the plugin sets or overrides the username of the connection, a Usermapping policy needs to be configured and set in the Connection policy. For further information, see Configuring usermapping policies.

  2. If the Gateway authentication option is set in the Connection policy, SPS pauses the connection until the user completes a gateway authentication on the SPS web interface. This is out-of-band authentication, since it is performed in an independent connection. For details, see The gateway authentication process.

  3. If the Usermapping policy option is set in the Connection policy, SPS checks if the Usermapping policy permits the users of the gateway group to access the username used in the server-side connection (the remote username, for example, root). For details, see Configuring usermapping policies.

  4. Before establishing the server-side connection, SPS can evaluate the channel policy to determine if the connection might be permitted at all, for example, it is not denied by a Time policy. SPS performs this check if the SSH Control > Settings > Enable pre channel check option is enabled. For details, see Creating and editing protocol-level SSH settings.

    For the SSH protocol, SPS checks the From (client address), Gateway group, and Time policy restrictions set in the Channel policy of the Connection policy. For details, see Creating and editing channel policies.

  1. Server-side connection

    SPS sets up the server-side connection and does the following:

    1. SPS establishes the TCP connection to the server.

    2. SPS negotiates the protocol parameters of the connection (for example, SSH encryption parameters) according to the SSH Control > Settings of the connection policy.

    3. SPS displays an SSH host key to the client. This host key is either generated on SPS, or it is the host key of the server (if it is available on SPS). The connection policy determines the host key shown to the client.

      		 IMPORTANT:

      If the SSH Settings of the Connection Policy enable only RSA keys, set the RSA key shown to the client in the Connection Policy.

    4. SPS verifies the host key of the server according to the Server side host key setting option of the Connection policy (in general, you can manage the server host keys on the SSH Control > Server Host Keys page). If the server has not been contacted before, SPS can accept and store the host key of the server. Alternatively, the host key of the server can be manually uploaded to SPS. For details, see Server host keys.

  1. SPS performs the authentication on the server, using the data received from:

  1. SPS authorizes the connection based on the Channel policy. It checks:

    • If the Channel policy includes a User List restriction for the Gateway group or Remote group, SPS checks if the user can access the server. If needed, SPS connects to the LDAP servers set in the LDAP Servers policy to resolve the group memberships of the user. For details, see Creating and editing user lists.

    • SPS consults the Time policy assigned to the channel policy. Channels may be opened only within the allowed period.

      TIP: Time policies are a good way to ensure that the server can be accessed only within the specified timeframe.

  1. Both the server- and the client-side connections have been established. From this step, the client can try to open any type and any number of channels in the connection.

  1. If 4-eyes authorization is set in the Channel policy, the SSH session of the client is paused until the authorizer permits the client to connect to the server. Who can authorize the session depends on the Access Control settings of the Connection policy. For details, see Four-eyes authorization.

  1. The client starts to work on the server. Information about the connection is now available on the Search page.

    • SPS records the entire communication into digitally encrypted audit trails if auditing is enabled in the Channel policy, and encryption is configured in the Audit policy used in the Connection policy. For details, see Creating and editing channel policies and Audit policies.

    • If a Content policy is configured in the Channel policy, SPS monitors the connection in real time, and raises an alert or terminates the connection if the user performs an undesired action. For details, see Real-time content monitoring with Content Policies.

    If the user opens another channel within the same connection, SPS consults the Channel policy of the connection to see if the channel is permitted, and processes it accordingly.

  1. Post-processing the connection

    Once the connection has been closed, the following post-processing steps take place:

    1. After the client closes the connection, or it is terminated for some reason (for example, it times out, or a Content policy or a 4-eyes auditor terminates it), SPS indexes the contents of the audit trail (if the Record audit trail option of the Channel policy, and the Enable indexing option of the Connection policy are enabled).

    2. SPS creates a backup of the data and the audit trail of the connection, and archives it to a remote server, if a Backup policy and an Archive policy is set in the Connection policy. For more information, see Data and configuration backups and Archiving and cleanup.

    3. When the Delete search metadata from SPS after period expires, SPS deletes all data about the connection from its database.

Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) using RDP

The following describes what happens when a client connects to a server through One Identity Safeguard for Privileged Sessions (SPS) and how the different configuration options and policies of SPS affect this process.

  1. Client-side connection

    The client tries to connect to the server. SPS receives the connection request and establishes the TCP connection with the client.

  2. SPS examines the connection request: it checks the IP address of the client and the IP address and port number of the intended destination server. If these parameters of the request match a connection policy configured on SPS, SPS inspects the connection in detail. Other connections are ignored by SPS, and simply forwarded on the packet level.

    The selected connection policy determines all settings and parameters of the connection.

    NOTE:

    One Identity Safeguard for Privileged Sessions (SPS) compares the connection policies to the parameters of the connection request one-by-one, starting with the first policy in the policy list. SPS applies to the connection the first connection policy that completely matches the connection request.

    For details, see Configuring connections.

  3. SPS selects the destination server based on the Target parameter of the connection policy. Network address translation of the target address can be performed at this step. For details, see Modifying the destination address.

  4. SPS selects the source address used in the server-side connection based on the SNAT parameter of the connection policy. For details, see Modifying the source address.

  1. If an AA plugin is configured in SPS, the client may be prompted to provide additional information when authenticating to the server. For details on the AA plugin, see Integrating external authentication and authorization systems. Note that if the plugin sets or overrides the username of the connection, a Usermapping policy needs to be configured and set in the Connection policy. For further information, see Configuring usermapping policies.

  1. SPS checks if the client uses a version of the RDP protocol that is enabled in the Protocol settings of the Connection policy. Depending on the protocol version, different encryption is used in the connection, and different parameters are required in the Connection policy.

  2. Before establishing the server-side connection, SPS can evaluate the channel policy to determine if the connection might be permitted at all, for example, it is not denied by a Time policy. SPS performs this check if the RDP Control > Settings > Enable pre channel check option is enabled. For details, see Creating and editing protocol-level RDP settings.

  3. Server-side connection

    1. SPS establishes the TCP connection to the server.

    2. SPS checks the protocol parameters of the connection (for example, the version of the RDP protocol used ) according to the Protocol settings of the Connection policy. The RDP handshake is performed simultaneously on the server- and the client-side.

  4. The server opens a Drawing channel for the user to perform authentication.

  1. SPS authorizes the connection based on the Channel policy. It checks:

    • If the Channel policy includes a User List restriction for the Gateway group or Remote group, SPS checks if the user can access the server. If needed, SPS connects to the LDAP servers set in the LDAP Servers policy to resolve the group memberships of the user. For details, see Creating and editing user lists.

    • SPS consults the Time policy assigned to the channel policy. Channels may be opened only within the allowed period.

      TIP: Time policies are a good way to ensure that the server can be accessed only within the specified timeframe.

  1. If the Gateway authentication option is set in the Connection policy, SPS pauses the connection until the user completes a gateway authentication on the SPS web interface. This is out-of-band authentication, since it is performed in an independent connection. For details, see The gateway authentication process.

    It is also possible to perform gateway authentication inband, without having to access SPS's web interface. For details, see Connecting to a server through One Identity Safeguard for Privileged Sessions (SPS) using an RD Gateway.

  1. SPS performs the authentication on the server, using the data received from:

  1. If the authentication fails for any reason, SPS terminates the client-side connection as well. This is required to verify the username of the client when it attempts to access the server again.

  2. If 4-eyes authorization is set in the Channel policy, the RDP session of the client is paused until the authorizer permits the client to connect to the server. Who can authorize the session depends on the Access Control settings of the Connection policy. For details, see Four-eyes authorization.

  1. The client starts to work on the server. Information about the connection is now available on the Search page.

    • SPS records the entire communication into digitally encrypted audit trails if auditing is enabled in the Channel policy, and encryption is configured in the Audit policy used in the Connection policy. For details, see Creating and editing channel policies and Audit policies.

    • If a Content policy is configured in the Channel policy, SPS monitors the connection in real time, and raises an alert or terminates the connection if the user performs an undesired action. For details, see Real-time content monitoring with Content Policies.

    If the user opens another channel within the same connection, SPS consults the Channel policy of the connection to see if the channel is permitted, and processes it accordingly.

  1. Post-processing the connection

    Once the connection has been closed, the following post-processing steps take place:

    1. After the client closes the connection, or it is terminated for some reason (for example, it times out, or a Content policy or a 4-eyes auditor terminates it), SPS indexes the contents of the audit trail (if the Record audit trail option of the Channel policy, and the Enable indexing option of the Connection policy are enabled).

    2. SPS creates a backup of the data and the audit trail of the connection, and archives it to a remote server, if a Backup policy and an Archive policy is set in the Connection policy. For more information, see Data and configuration backups and Archiving and cleanup.

    3. When the Delete search metadata from SPS after period expires, SPS deletes all data about the connection from its database.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation