One Identity Safeguard for Privileged Sessions 6.0.1 - Remote Desktop Protocol Scenarios

Typical use-cases

The following use-cases will cover most common scenarios for monitoring RDP connections with SPS. Also the requirements and limitations has been indicated. As a general guideline, implement TLS (with signing CA) or NLA.

Non-transparent RDP + Domain + RD Gateway (Remote Desktop Gateway)

This is one of the most common non-transparent scenarios and the original out-of-the box solution when inline gateway authentication is supported (thanks to the RD Gateway). This is a non-transparent scenario, so users will first connect to SPS, authenticate, then SPS will establish a connection to the original destination server. In case of RDP6 the complete server side authentication also done prior opening Remote Desktop on the server.

Using SPS as a Remote Desktop Gateway (RD Gateway)

With usermapping, you can monitor the real user behind a generic login event (for example Sam Smith logged on as Administrator on Server1.

With usermapping, you can limit which users are allowed to use specific usernames on specific servers.

For details, see Using SPS as a Remote Desktop Gateway.

Prerequisites:

Provide a trusted certificate for Remote Desktop Gateway.

Configure a signing CA trusted by the clients for TLS part of the RDP protocol to avoid receiving a warning about untrusted (self-signed) certificate generated by SPS when the RDP connection is built. In this case, a trusted certificate will be generated for the RDP connection, however, a warning regarding the CRL accessibility will still be displayed.

NOTE: It is not required to use a signing CA for the Remote Desktop Gateway TLS connection. You can use the Use the same certificate for every connection option.

Figure 2: RDP Control > Connections — RDP Connections Signing CA

NOTE: In case of non-NLA, certain Windows settings may interfere with username extraction from the connection. If the DontDisplayLastUserName option is enabled on the server, the target username is not visible on the Search, Four Eyes and Active Connections pages. User mapping is also not available.

To use SPS as an RD Gateway

1. The user initiates a connection to SPS on port 443 and use it as a Remote Desktop Gateway (RD Gateway).

   Figure 3: Initiating a connection in RD Gateway

   

2. If the user authentication is successful:

   1. SPS evaluates the policies and SPS settings.

   2. SPS determines whether to allow the user to use the specified server / username combination.

   NOTE: In case of non-NLA configuration, the target username cannot be used to evaluate channel policies, because it is available too late.

   Figure 4: RDP non-NLA

   

3. In case of positive results, the connection is granted and established.

   • non-NLA: the drawing channel is opened and the server-side authentication is performed on the server.

   • NLA: the server-side authentication has to be successful first, and the drawing channel is opened only after the successful authentication.

Connecting to a server through SPS using a RD Gateway

For a detailed description of what happens when a client connects a server through SPS using a Remote Desktop Gateway (RD Gateway), and how the different configuration options and policies of SPS affect this process, see Connecting to a server through SPS using a RD Gateway.