One Identity Safeguard for Privileged Sessions 6.0 LTS - Administration Guide

Configuring inband destination selection

With inband destination selection, you can 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@scb_address, or username%@targetserver%scb_address).

To configure a Connection Policy to extract the address of the server from the username

1. Navigate to the Connection policy you want to modify, for example, to SSH Control > Connections.

2. Select Inband destination selection.

   Figure 140: <Protocol name> Control > Connections — Configuring inband destination selection

   

3. Optional Step: Enter the IP address or the hostname of the domain name server used to resolve the address of the target server into the DNS Server field.

   If you do not set the DNS Server field, SPS will use the global DNS server (set on the Basic Settings > Networking page) to resolve the hostnames in this connection.

4. Optional Step: Configure domain names and CNAME records.

   If the clients do not include the domain name when addressing the server (for example they use username@server instead of username@server.example.com, or username%server for RDP connections), SPS can automatically add domain information (for example example.com). Enter the domain name to add into the Append domain field.

   SPS can also resolve CNAME records.

   To enter more domain names (for example because connections extend through subnets), click . In case of more domain names in the Append domain field, SPS appends the first domain name in the list that the target can be resolved with.

5. Enter the addresses of the servers that the users are permitted to access into the Targets field. Note the following points:

   • Use the IP address/prefix (for example 192.168.2.16/32, or 10.10.0.0/16) format. Alternatively, you can use the FQDN of the server. To permit access to any server, enter *.

   • For FQDN, you can use the * and ? wildcard characters.

     Caution: If only the hostname of the server is listed and the client targets the server using its IP address, SPS refuses the connection.

   • If the clients target the server using its IP address, include the IP address of the server in the Targets > Domain list. This is required because SPS resolves the hostnames to IP addresses, but does not reverse-resolve IP addresses to hostnames.

   • If the clients target the server using its hostname, then the hostname-from-the-client-request + the-value-of-the-Append-domain-option must appear in the Targets > Domain list. Alternatively, you must include the IP address of the hostname-from-the-client-request + the-value-of-the-Append-domain-option host.

   Example: Hostnames and inband destination selection

   For example, you have set Append domain to example.com, and your clients use the username%servername request, then you must include either the servername.example.com host or its IP address in the Targets > Domain list.

6. If the clients can access only a specified port on the server, enter it into the Port field. If the Port is not set, the clients may access any port on the server.

7. If there are any servers that the users cannot target using inband destination selection, add them to the Exceptions field.

8. To use inband destination selection with RDP connections without using One Identity Safeguard for Privileged Sessions (SPS) as a Remote Desktop Gateway (or RD Gateway), you must use SSL-encrypted RDP connections (see Enabling TLS-encryption for RDP connections).

9. Click .

   Expected result

   The connection policy will extract the address of the destination server from the protocol information.

   NOTE: For examples on using inband destination selection to establish an SSH connection, including scenarios where non-standard ports or gateway authentication is used, see Using inband destination selection in SSH connections.

Modifying the source address

The source address is the address that One Identity Safeguard for Privileged Sessions (SPS) uses to connect the server. The server sees this address as the source of the connection.

To modify the source address of a connection

1. Navigate to the Connections tab storing the connection and click to display the details of the connection.

   Figure 141: <Protocol name> Control > Connections — Configuring connections

   

2. The SNAT section allows you to configure Source Network Address Translation (SNAT) on the server side of SPS. SNAT determines the IP address SPS uses in the server-side connection. The target server will see the connection coming from this address. The following options are available:

   • Use the IP address of a SPS logical interface: Server-side connections will originate from SPS's logical network interface. This is the default behavior of the connection.

   • Use the original IP address of the client: Server-side connections will originate from the client's IP address, as seen by SPS.

   • Use fixed address: Enter the IP address that will be used as the source address in server-side connections.

     You can also enter a hostname instead of the IP address, and One Identity Safeguard for Privileged Sessions (SPS) automatically resolves the hostname to IP address. Note the following limitations:

     • SPS uses the Domain Name Servers set Basic Settings > Network > Naming > Primary DNS server and Secondary DNS server fields to resolve the hostnames.

     • If the Domain Name Server returns multiple IP addresses, SPS selects randomly from the list.

     Caution: Do not forget to properly configure routers and other network devices when using the Use fixed address option: messages sent by the server to this address must reach SPS.

3. Click .

Creating and editing channel policies

The Channel policy lists the channels (for example, terminal session and SCP in SSH, or Drawing and Clipboard in RDP) that can be used in the connection, and also determines if the channel is audited or not. The Channel policy can also restrict access to each channel based on the IP address of the client or the server, a user list, user group, or a time policy. For example, all clients may access the servers defined in a connection via SSH terminal, but the channel policy may restrict SCP access only to a single client. The policies set in the channel policy are checked when the user attempts to open a particular channel type in the connection.

Figure 142: <Protocol name> Control > Channel Policies — Configuring channel policies

To create a new channel policy or edit an existing one

1. Channel policies are configured individually for every protocol. Navigate to the Channel Policies tab of the respective protocol (for example, SSH Control > Channel Policies) and click to create a new channel policy. Enter a name for the policy (for example, shell_and_backup).

2. Click to add a new channel.

3. Select the channel to be enabled in the connection from the Type field. All restrictions set in the following steps will be effective on this channel type. The available channels are different for every protocol. For their descriptions, see the following sections:

   • The HTTP protocol has only one channel type with no special configuration options.

   • Supported ICA channel types for the Independent Computing Architecture protocol.

   • Supported RDP channel types for the Remote Desktop Protocol.

   • Supported SSH channel types for the Secure Shell protocol

   • The Telnet protocol has only one channel type with no special configuration options.

   • The VNC protocol has only one channel type with no special configuration options.

4. To restrict the availability of the channel only to certain clients, click in the From field and enter the IP address of the client allowed to use this type of the channel. Repeat this step until all required client IPs are listed.

   You can also enter a hostname instead of the IP address, and One Identity Safeguard for Privileged Sessions (SPS) automatically resolves the hostname to IP address. Note the following limitations:

   • SPS uses the Domain Name Servers set Basic Settings > Network > Naming > Primary DNS server and Secondary DNS server fields to resolve the hostnames.

   • If the Domain Name Server returns multiple IP addresses, SPS selects randomly from the list.

5. To restrict the availability of the channel only to certain servers, click in the Target field and enter the IP address of the server allowed to use this type of the channel. Repeat this step until all required server IPs are listed.

   NOTE: Use the real IP address of the server, which may be different from the one addressed by the clients, specified in the Target field of the connection policy.

   You can also enter a hostname instead of the IP address, and One Identity Safeguard for Privileged Sessions (SPS) automatically resolves the hostname to IP address. Note the following limitations:

   • SPS uses the Domain Name Servers set Basic Settings > Network > Naming > Primary DNS server and Secondary DNS server fields to resolve the hostnames.

   • If the Domain Name Server returns multiple IP addresses, SPS selects randomly from the list.

6. To restrict the availability of the channel only to certain users, click in the Remote Group field and enter the name of the user group allowed to use this type of the channel. Repeat this step until all permitted groups are listed.

   To restrict the availability of the channel when using gateway authentication, click in the Gateway Group field and enter the name of the user group allowed to use this type of the channel. Repeat this step until all permitted groups are listed.

   You may list local user lists as defined in Creating and editing user lists, or LDAP groups (for details on accessing LDAP servers from SPS, see Authenticating users to an LDAP server). Note the following behavior of SPS:

   • If you list multiple groups, members of any of the groups can access the channel.

     NOTE: When listing both a whitelist and blacklist in the Remote Group section and a username appears on both lists, the user will be able to access the channel.

   • If you do not list any groups, anyone can access the channel.

     NOTE: When the channel opens, there are certain cases when the remote group is not known yet. For example, in case of an RDP or ICA login screen, the drawing channel has to be opened first to properly display the logon screen. Only those channel rules will apply, where the Remote group field is empty. In case of network level authentication, all required information is present already so this limitation does not apply.

   • If a local user list and an LDAP group has the same name and the LDAP server is configured in the connection that uses this channel policy, both the members of the LDAP group and the members of the local user list can access the channel.

   NOTE: User lists and LDAP support is currently available only for the SSH and RDP protocols. For other protocols, see Configuring gateway authentication.

7. Select a time policy to narrow the availability of the channel. If the time policy of the channel policy is set to 7x24, the channel is always available. For details, see Configuring time policies.

8. Some channel types require additional parameters, for example port forwarding in SSH needs the IP addresses and ports of the source and destination machines. Click in the Details field and enter the required parameters. For a list of parameters used by the different channels, see Supported SSH channel types and Supported RDP channel types.

9. Select the Record audit trail option to record the activities of the channel into audit trails. Typically large file-transfers (for example system backups, SFTP channels) are not audited because they result in very large audit trails. Check regularly the free hard disk space available on SPS if you do audit such channels. You can also receive alerts about disk space fill-up if you set these. For details, see Preventing disk space fill-up and System related traps.

10. Select the 4 eyes option to require four-eyes authorization to access the channel. For details, see Configuring four-eyes authorization.

11. Repeat Steps 2-10 to add other channels to the policy.

    NOTE: The order of the rules matters. The first matching rule will be applied to the connection. Also, note that you can add the same channel type more than once, to fine-tune the policy.

12. Click to save the list.

Real-time content monitoring with Content Policies

You can monitor the traffic of certain connections in real time, and execute various actions if a certain pattern (for example, a particular command or text) appears in the command line or on the screen, or if a window with a particular title appears in a graphical protocol. Since content-monitoring is performed real-time, One Identity Safeguard for Privileged Sessions (SPS) can prevent harmful commands from being executed on your servers. SPS can also detect numbers that might be credit card numbers. The patterns to find can be defined as regular expressions. In case of ICA, RDP, and VNC connections, SPS can detect window title content.

The following actions can be performed:

• Log the event in the system logs.

• Immediately terminate the connection.

• Send an e-mail or SNMP alerts about the event.

• Store the event in the connection database of SPS.

SPS currently supports content monitoring in SSH session-shell connections, Telnet connections, RDP and Citrix ICA Drawing channels, and in VNC connections.