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

Configuring Network Level Authentication without domain membership and inband destination selection

You can authenticate to multiple domains without having trust relationship between them.

Inband destination is available when the target server is not part of the domain or when a local account must be used for logon.

You can use inband destination selection with every RDP version (NLA and non-NLA) without using Remote Desktop Gateway and domain membership.

For details, see Network Level Authentication without domain membership.

To configure NLA without domain membership and inband destination selection

1. Navigate to RDP Control > Settings and configure an RDP setting as the following:

   Select Enable Network Level Authentication. Deselect Require domain membership.

   Figure 5: RDP Control > Settings — RDP settings domainless NLA

   

2. Apply this RDP setting to the desired RDP connection policy.

3. For Target, select Inband destination selection. For details, see Configuring inband destination selection.

   Figure 6: RDP Control > Connections — RDP Target Inband destination selection

   

4. Configure the RDP client:

   Figure 7: RDP client domainless NLA

   

Configuring RDP with credential store and autologin

To implement this scenario, you can use either internal or external credential store to provide login information for RDP sessions. You will have to configure some kind of gateway authentication to control who can checkout the credentials from the credential store. It is also advised to use usermapping, because most of the time the gateway username and the target username will be different.

In the following example, you will use the internal credential store.

To configure RDP with credential store and autologin

1. Configure the RDP connection policy similarly to the simple Remote Desktop Gateway (RD gateway) scenario. You can use either a fixed certificate, or a certificate that is generated on-the-fly. This example demonstrates the on-the-fly option, where you can specify an alternate common name to avoid DNS modification. In case of fixed certificate, make sure the common name is the same as the user enters in mstc > Advanced > Settings > Use these RD Gateway server settings > Server name field.

   Figure 8: RDP Control > Connections — Remote Desktop Gateway Signing CA

   

2. Create a local credential store and inclide all credentials that you want to protect.

   Figure 9: Policies > Credential Stores — Local Credential Store

   

3. Create a usermapping policy for the desired username to LDAP Group Mapping.

   NOTE: Usernames in usermapping are case-sensitive, therefore make sure to use the same format in the RDP client, as in SPS.

   Figure 10: Policies > Usermapping Policies — Usermapping Policy

   

4. LDAP groups are the same as AD groups most of the time. However, for this feature, navigate to Policies > LDAP Servers and configure and LDAP server.

5. Assign the policies configured above to the previosuly created RDP connection policy in RDP Control > Connections.

   Figure 11: RDP Control > Connections — RDP assigning policies

   

6. Configure the RDP client (mstsc). For details, see Inband destination selection in RDP connections.

   1. In the RD Gateway, navigate to the Advanced > Settings tab, select Use these RD Gateway server settings and configure it accordingly.

      Figure 12: RDP RD Gateway settings

      

   2. On the General tab, configure the remote server address and username. Make sure to use the -AUTO suffix, this is mandatory for autologin.

      Figure 13: RDP RD Gateway settings General tab

      

7. Enter the Remote Desktop Gateway credentials.

   Figure 14: TSGW credentials

   

8. Make sure to enter the same username into the password field too.

   Figure 15: TSGW credentials

   

Prerequisites for RDP with Smartcard authentication

In case of Smartcard-based authentication on the server side (SPS to RDP server connection), the follow limitation exists:

This authentication method is only available when RDP5 / TLS is available on the server. For example on Windows Server 2012 and above, the default setting is more restrictive and does not allow the use of Smartcards. Make sure to deselect this option: Allow connections only from computers running Remote Desktop with Network Level Authentication.

Figure 16: Configuring Smartcard authentication

Prerequisities:

• Smartcard-based authentication is usually used in a domain environment, so this is not common to be used for standalone Windows servers

• Microsoft Certificate Services or other third party PKI must be available and users must be allowed to use Smartcard for login

• Smartcard supported by Windows operating system and the related tools / libraries

Components that were used in the test system:

• Domain Controller: Windows Server 2008r2

• Certificate Server: Windows Server 2012r2

  NOTE: These two roles (Domain Controller and Certificate Server) cannot reside on the same server

• Client: Windows 10

• Session monitoringSPS 4F4

• Smartcard: YubiKey 4 Nano

• Guidelines for Windows CA set-up: YubiKey PIV Deployment Guide

• Yubikey PIV manager for the certificate request: YubiKey PIV Manager

Troubleshooting