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.
Prerequisites:
-
The remote server must support NLA.
-
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.
-
To implement a Signing CA that is trusted by the clients, every CA certificate of the chain must be placed in the Trusted Root Certificate Authorities of the Local Computer, otherwise RDP the client will generate two warnings for each connection.
-
Configure your RDP clients so SPS can record the username of client uses in the connection. If you do not configure these settings on the clients, SPS will automatically display a login screen for the users to enter their usernames and passwords. Note that although SPS automatically displays a login screen if it cannot determine the username used in the connection, currently you cannot specify the destination address in this login screen, only in your RDP client application.
-
On Windows Vista SP1 and newer platforms (Remote Desktop Protocol 6.1 or newer):
Navigate to Local Group Policy Editor > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client and enable the Prompt for credentials on the client computer option in the clients. For details, see the Microsoft Documentation.
-
On Windows Vista and older platforms (Remote Desktop Protocol 6.0 or older):
Configure your RDP clients to save the credentials, or make sure that the Allow me to save credentials option is selected in the RDP client.
-
To configure NLA without domain membership and inband destination selection
-
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
-
Apply this RDP setting to the desired RDP connection policy.
-
For Target, select Inband destination selection. For details, see Configuring inband destination selection.
Figure 6: RDP Control > Connections — RDP Target Inband destination selection
-
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
-
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
-
Create a local credential store and inclide all credentials that you want to protect.
Figure 9: Policies > Credential Stores — Local Credential Store
-
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
-
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.
-
Assign the policies configured above to the previosuly created RDP connection policy in RDP Control > Connections.
Figure 11: RDP Control > Connections — RDP assigning policies
-
Configure the RDP client (mstsc). For details, see Inband destination selection in RDP connections.
-
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
-
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
-
-
Enter the Remote Desktop Gateway credentials.
Figure 14: TSGW credentials
-
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