One Identity Safeguard for Privileged Sessions 6.9.3 - Quick Start Guide

Public key-based gateway + password-based server-side authentication from credential store

This scenario differs from the previous one only in the client-side authentication method. In this case, the end-user is authenticated with the public key method, and if all permissions are granted by SPS (for example usermapping is allowed), they get logged in automatically to the requested server with the requested server account without having to enter a password.

To configure this, upload a public key for the user in the applied local user database, and make sure that the private key is accessible for the client application (openSSH, PuTTY, and so on).

To configure public key-based gateway + password-based server-side authentication from credential store

1. Create a local user database:

   Navigate to Policies > Local User Databases and create a local user database.

   For details, see Creating a Local User Database.

2. Connect the local user database with a client-side gateway authentication policy:

   Navigate to SSH Control > Authentication Policies. Create an authentication policy. Select Authenticate the client to SPS using > Local. Select Public key. Configure the required settings.

   For details, see Local client-side authentication.

3. Create a user list:

   Navigate to Policies > User lists and create a user list.

   For details, see Creating and editing user lists.

4. Create a usermapping policy:

   Navigate to Policies > Usermapping policies and create a usermapping policy.

   For details, see Configuring usermapping policies.

5. Create a local or remote credential store with the server user and its password. SPS provides a plugin framework to integrate with other remote credential stores/password management systems.

   For details, see Using a custom Credential Store plugin to authenticate on the target hosts.

6. Expected outcome:

   If all prerequisites are met, SPS is ready to perform inband gateway authentication in an SSH session, which together with inband destination selection could be performed with the following connection string by an end-user:

   Example: Inband gateway authentication and destination selection

   $ ssh gu=balabit@root@192.168.56.10@192.168.56.200

   • gu=balabit = gateway user (balabit)

   • root = server user

   • 192.168.56.10 = target server

   • 192.168.56.200 = IP address of SPS

Configuring connections: RDP

The following procedures will provide a skeleton of configuring RDP connections in SPS. If you want to have a deeper understanding, see the in-depth detailed procedure in Configuring connections.

Configure an RDP connection with fixed destination IP

The following describes how to configure a basic Remote Desktop (RDP) connection in SPS. This Connection Policy uses a fixed destination IP, that is, it receives connections on an IP address of SPS (on the default RDP port 3389), and forwards them to a server explicitly set in the policy.

The destination address is the address of the server where the clients finally connect to. To modify the destination address of a connection, complete the following steps.

To configure a basic RDP connection in SPS

1. Navigate to RDP Control > Connections.

2. Click to define a new connection and enter a name that will identify the connection (for example admin_mainserver).

   TIP: It is recommended to use descriptive names that give information about the connection, for example refer to the name of the accessible server, the allowed clients, and so on.

3. Enter the IP address of the client that will be permitted to access the server into the From field. Click to list additional clients.

4. Enter the IP address that the clients will request into the To field. To test SPS the easiest is to use the IP address of SPS, meaning that the connection will be non-transparent. (To test transparent connections, you must place SPS into the network between the client and the server, or route the traffic that way.)

   Figure 9: Configuring fixed IP destination selection for RDP

   

5. The Target section allows you to configure Network Address Translation (NAT) on the server side of SPS. Destination NAT determines the target IP address of the server-side connection. You can set the destination address as required for your environment. For this example non-transparent connection, select Use fixed address.

6. Enter the IP address and port number of the server. SPS will connect all incoming client-side connections to this server.

   You can also enter a hostname instead of the IP address, and 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.

   • Only IPv4 addresses are supported.

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

7. Click to save the connection.

   This connection allows any user from the client machine to connect to the specified server, but permits only Desktop sessions — other RDP channels like disk redirection are disabled.

8. Test the new configuration: try to initiate an RDP connection from the client (your computer) to the server.

9. After successfully connecting to the server, do something in the connection, then disconnect from the server.

10. Navigate to Search on the SPS web interface. Your sessions are displayed in the list of connections. Note that for the transparent connection, the client addresses the target server, while the non-transparent connection addresses SPS.

11. Click the icon. A summary will be displayed about the connection.

Inband destination selection with Remote Desktop Gateway

Non-transparent operation with inband destination selection in RDP is supported with the implementation of the Remote Desktop Gateway protocol. When it is enabled, end-users configure their MSTSC client to use SPS as an RDP proxy/gateway and keep specifying target server addresses on the General tab the way they are used to.

Figure 10: Inband destination selection via RDP with RD Gateway