The aim of the document is to present different working scenarios for One Identity Safeguard for Privileged Sessions (Safeguard for Privileged Sessions) when RDP monitoring is required and present some best practices for those scenarios. Also, it is intended to demonstrate possible issues with different scenarios. Please note it is only an extract of the official Administration Guide, emphasizing the most important RDP specific topics, so in any case please refer to the official documentation cover this and other topics as well.
This is only an extract of Administration Guide, emphasizing the most common RDP-specific topics.
The core network device alters the traffic and directs packets to be monitored through Safeguard for Privileged Sessions (seamless integration: no change required on the computers and servers in the network).
CRL includes a list of the serial numbers of revoked certificates and it must have made publicly available by the PKI service that generates the certificates. Microsoft RDP Client rigorously checks the availability of CRLs.
Gateway authentication requires a secondary logon before the authentication on the remote server, so rules defined on the gateway (in this case Safeguard for Privileged Sessions) can be evaluated and applied. With gateway authentication it is possible to limit access to specific resources (for example specific sub-channels) to specific local or central groups. It also allows to use usermapping.
Safeguard for Privileged Sessions placed directly between the source and destination. This means that the client’s and server’s gateway is changed to Safeguard for Privileged Sessions's address.
MitM is a required method to be able to decode encrypted traffic. Safeguard for Privileged Sessions must be placed between the source and the destination of the encrypted traffic, so the client connection attempt to the destination server will be terminated at Safeguard for Privileged Sessions, decoded, recorded and Safeguard for Privileged Sessions will establish a second, also encrypted channel to the original destination server. Because this breaks the original encryption chain, some additional measures (for example signing CA) must be applied to avoid warnings.
User will change the destination host to Safeguard for Privileged Sessions where some kind of gateway authentication performed (or in some cases not-performed), then Safeguard for Privileged Sessions will establish the connection to the original destination server.
A system placed between two different zones to allow monitoring the traffic between them. The monitored traffic must be passed through the proxy to allow it to be monitored. Safeguard for Privileged Sessions is a proxy-based solution.
A public key infrastructure (PKI) is a set of roles, policies, and procedures required to create, manage, distribute, use, store, and revoke digital certificates and manage public-key encryption.
A proprietary protocol developed by Microsoft, which provides a user with a graphical interface to connect to another computer over a network connection. The user employs RDP client software for this purpose, while the other computer must run RDP server software.
One Identity Safeguard for Privileged Sessions is a user monitoring appliance that controls privileged access to remote IT systems, records activities in searchable, movie-like audit trails, and prevents malicious actions.
CA certificate installed on Safeguard for Privileged Sessions to allow generating certificates for TLS layer of different protocols. RDP implementation of Safeguard for Privileged Sessions also requires TLS layer.
Service developed by Microsoft to provide authentication front-end for Remote Desktop Services. One Identity provides an own implementation of RD Gateway (Remote Desktop Gateway) in Safeguard for Privileged Sessions
In transparent mode the user will connect to the original destination server, however the traffic will be passed through the proxy for recording and analysis. From the user perspective there should be no difference between the monitored and not-monitored traffic.
With usermapping Safeguard for Privileged Sessions can allow / deny using generic accounts (for example Administrator) based on group membership and can map real users to generic accounts.
Certain components of the solution (for example TS-GW TLS layer, Signing-CA) require trusted certificates. It means if the common name parameter of the certificate is different from the DNS name user trying to connect, or the signing CA is not trusted by the client, the connection may fail or generate an error. This is especially true when TS-GW is in use, because the MS RDP client (mstsc) requires a fully trusted third party certificate for this function.
Safeguard for Privileged Sessions must be part of the target domain, and users can log on to only one domain unless there is a trust relationship between the different domains. For details on using Safeguard for Privileged Sessions with multiple domains, see Network Level Authentication (NLA) with domain membership.
To avoid certificate warnings, configure a signing CA that is trusted by the clients for the connection between the client and Safeguard for Privileged Sessions.
The One Identity Safeguard for Privileged Sessions connection policies can work in different network models to make it easy to integrate it into an existing network. These two modes are transparent, and non-transparent modes (for details on modes of operation, see "Modes of operation" in the Administration Guide). The aim is usually the transparent implementation. Although the non-transparent mode can provide some transparency, it is not the best to be used for that purpose.
For the easy-to-deploy and totally transparent solution the transparent mode would be the best. This mode requires integrating Safeguard for Privileged Sessions in the network level, so all the administrative traffic could pass the box to make it controllable and auditable (for details and illustrations on transparent mode, see "Transparent mode" in the Administration Guide).
Figure 1: Safeguard for Privileged Sessions in transparent mode
In most cases it is not possible, or not optimal to integrate Safeguard for Privileged Sessions into the network as in the abovementioned example, because it would require significant changes to the network topology, and Safeguard for Privileged Sessions could act as a single point of failure. However, it is possible to use Safeguard for Privileged Sessions in transparent mode transparently without changing the network layout, with a few additional configuration steps in some of the active network devices (firewalls or routers) and the Safeguard for Privileged Sessions itself.
Remote Desktop Gateway (RD Gateway) cannot be used, only out-of-band gateway authentication is possible
Because of this, user mapping is not possible unless out-of-band gateway authentication is implemented, where the gateway authentication is performed using the web interface of Safeguard for Privileged Sessions.
The following use-cases will cover most common scenarios for monitoring RDP connections with Safeguard for Privileged Sessions. Also the requirements and limitations has been indicated. As a general guideline, implement TLS (with signing CA) or NLA.
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 Safeguard for Privileged Sessions, authenticate, then Safeguard for Privileged Sessions 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.
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 Safeguard for Privileged Sessions as a Remote Desktop Gateway.
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 Safeguard for Privileged Sessions 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.
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
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.
The user initiates a connection to Safeguard for Privileged Sessions on port 443 and use it as a Remote Desktop Gateway (RD Gateway).
Figure 3: Initiating a connection in RD Gateway
If the user authentication is successful:
Safeguard for Privileged Sessions evaluates the policies and Safeguard for Privileged Sessions settings.
Safeguard for Privileged Sessions determines whether to allow the user to use the specified server / username combination.
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
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.