Remote desktop encryption. RDP - Remote Desktop Protocol

Twitter

RDP with network layer security (SSL), unfortunately, is not widely used among system administrators who prefer to secure terminal connections in another way. This may be due to the apparent complexity of the method, but this is not the case; in this material we will look at how to organize such protection simply and without difficulty.

What benefits does securing RDP with SSL give us? Firstly, strong channel encryption, server authentication based on a certificate, and user authentication at the network level. The latter feature is available starting in Windows Server 2008. Network level authentication helps improve the security of a terminal server by authenticating the user before the session begins.

Network-level authentication is performed before connecting to the remote desktop and displaying the login screen, this reduces the load on the server and significantly increases its protection from intruders and malware, and also reduces the likelihood of denial of service attacks.

To take full advantage of RDP over SSL, client PCs must be running Windows XP SP3, Windows Vista or Windows 7 and use RDP client version 6.0 or later.

When using Windows Server 2003 SP1 and later, channel encryption using SSL (TLS 1.0) and server authentication will be available; client PCs must have RDP client version 5.2 or later.

In our article we will look at setting up a terminal server based on Windows Server 2008 R2, however, everything said will also be true for Windows Server 2003 (with the exception of missing features).

To successfully implement this solution, your network must have a working certification authority, the configuration of which we discussed in the previous article. To trust the certificates issued by this CA on the terminal server, you must install the CA certificate (or chain of certificates) in the storage Trusted Root Certification Authorities.

You should then request a server certificate of authenticity with the following parameters:

Send a request to the certificate authority and install the issued certificate. This certificate must be installed in the computer's local storage, otherwise it cannot be used by Terminal Services. To check this, let's launch the console MMC (Start - Run - mmc) and add the equipment Certificates(File - Add or remove snap-in) for a computer account.

At the console root, select click View - Options and set the viewing mode Organize certificates by purpose. The issued certificate must be in a group Server authentication.

If you received a certificate using an isolated (stand-alone) CA (the network does not have a domain structure), then it will be installed in the user account store by default and you will have to perform a number of additional steps.

Open Internet Explorer - Internet Options - Content - Certificates, the issued certificate must be installed in the store Personal.

Export it. When exporting, specify the following options:

Yes, export private key
Remove private key after successful export

Then delete the certificate from this store. In the snap Certificates (local computer) select

chapter Server authentication, right click on it All tasks - Import and import the certificate.

Now in Administration - Remote Desktop Services open Remote Desktop Session Host Configuration(in Windows Server 2003 Administrative Tools - Configuring Terminal Services).

And finally, a drop of ointment in the ointment. Windows Terminal Services cannot verify the authenticity of connecting clients, so if necessary, you should use additional security methods, such as an SSH tunnel or IPSec VPN.

The Windows system has been providing the ability to implement remote access via the RDP protocol for a long time. This standard tool appeared in the version of Windows NT 4.0, released in 1996. It was more or less functionally modified in the Windows XP version, and found its completeness already as part of Windows 7. Versions of Windows 8/8.1 and 10 inherited remote access via the RDP protocol from Windows 7 without functional changes.

Below we will take a closer look at how remote access works via the RDP protocol in versions of Windows 7, 8.1 and 10.

1. Remote access via RDP protocol

Connection using the RDP protocol is carried out between computers located on the same local network. This type of connection is intended primarily for IT specialists who maintain company computers integrated into their production network. Without leaving their workplace, connecting remotely to the computers of enterprise employees, system specialists can solve problems that do not require intervention in the hardware of the machines and carry out preventive measures.

Connecting to a remote computer using the RDP protocol is also possible outside the local network, over the Internet. But this will require additional steps - either forwarding port 3389 on the router, or combining it with a remote computer into a single VPN network. In view of this, connecting to a remote computer over the Internet is much easier using other software tools that do not require unnecessary actions. This is, for example, the standard Windows “Remote Assistance” utility for providing computer assistance over the Internet. It works on the principle of sending an invitation file to the user who will provide computer assistance. Its more functional analogues on the Windows software market are programs like .

The RDP protocol is also used to connect to virtual machines. A remote connection via RDP can offer more opportunities than the standard connection window of a standard hypervisor. The Hyper-V connection window does not provide sound playback in the guest OS, does not see connected USB storage media, and cannot offer more connection with a physical computer than pasting text copied into it. Whereas an RDP connection can provide the virtual machine with visibility of various devices connected to the physical computer, a better image of the guest OS desktop, work with sound, etc.

To connect via RDP, the remote computer must meet the following requirements:

It must have a password-protected account;
The system must allow remote connections;
If you do not want to change your access data every time you connect with a constantly changing dynamic IP address, you must assign a static IP address in the network settings.

Remote access is only possible on computers with Windows Pro, Enterprise or Ultimate editions installed. Home versions of Windows (Home) do not provide remote access via RDP.

2. Password on the remote computer

If you are working on a remote computer using a Microsoft account, and using a short PIN code instead of a long password, when connecting via RDP, you must enter that same long password, and not a four-digit PIN code.

If an unpassword-free local account is used on the remote computer, and there is no special need for a password, such as when connecting to Hyper-V virtual machines, you will have to create at least a simple password like “777” or “qwerty”.

3. IP address of the remote computer

When connecting via RDP, you will need to enter the IP address of the remote computer. The internal IP address is visible in the system network settings. But in versions of Windows 7, 8.1 and 10 these are three different paths. In Windows 7, this is a section of the Control Panel, and in Windows 8.1 and 10 it is the Settings application, with its own organization inherent in each version. Therefore, we will find out the internal IP address in a universal way suitable for each of these systems - through the command line. The shortcut to launch Command Prompt in Windows 7 is available in the Start menu. In Windows 8.1 and 10, Command Prompt is launched from the context menu on the Start button.

In the command line window, enter:

After pressing Enter, we will get a summary of the data, where the internal IP address will be visible.

4. Allowing remote connections

Permission to connect remotely on Windows systems is usually initially disabled. In any case, this definitely applies to licensed assemblies. The ability to connect via RDP on a remote computer is activated in the system settings. We need the "System" section. In the Windows 7 version, it can be accessed by searching the Start menu. And in Windows 8.1 and 10, you can get to the “System” section from the context menu on the “Start” button.

Click “Remote Access Settings”.

In the system properties window, you must set the option to allow remote connections to active. There is no need to remove the authentication option. To apply the changes, click “Apply” below.

Such settings will open the path to a remote connection, but only for the administrator account. Regular account users are not allowed to provide their own computer for remote control. The administrator can give them this right.

Below the option to allow remote connections there is a “Select users” button. Let's press it.

In the field below, enter the name of the user who is allowed to connect to him via the RDP protocol. For local accounts, this is their name, and for Microsoft accounts, this is the email address used for authorization. Click "Ok".

That’s it – now this user’s account will be accessible from any computer within the local network.

5. Connect to a remote computer

All necessary actions on the remote computer have been completed, let’s move on to the main computer from which connection and control will be carried out. You can launch the standard RDP connection utility by finding its shortcut using a search within the system. In Windows 7, this is a search in the Start menu.

In versions of Windows 8.1 and 10, press the Win+Q keys.

A small connection window will appear. In the future, it will be possible to connect to remote computers using exactly this abbreviated form. But for now, click “Show options”.

In the “Computer” field, enter the IP address of the remote computer. In the field below - “User” - accordingly, enter the user name. If a Microsoft account is connected to the remote computer, enter the email address.

If you work on your computer using a regular local account, the username must be entered in the format:

Computer\User

For example, DESKTOP-R71R8AM\Vasya, Where DESKTOP-R71R8AM is the name of the computer, and Vasya– username of the local account.

Below the username there is an option to save authorization data on a remote computer. Connection parameters - IP address, username and password - can be saved as a separate RDP file and used to open it on another computer. Click “Connect”, and then “Connect” again in a new window.

Enter the password for the remote computer account.

Click “Yes” in the certificate error window.

We will get more settings for connecting via the RDP protocol in the utility window initially, before establishing the connection.

6. Connect to another account on a remote computer

Below the column for filling in the user name of the remote computer, if the “Always request credentials” checkbox is not checked, options for deleting and changing access data are displayed. By clicking the “Change” option, in addition to the authorization form in an existing account on a remote computer, we will see the ability to connect to another account that is present on the same computer.

After entering a new username and password, the authorization data for a specific IP address will be overwritten.

7. Connection settings

In the opened window for connecting to a remote computer, we will find tabs with customizable parameters. The first two concern the convenience and functionality of remote access.

“Screen” – in this tab you can set the screen resolution of the remote computer; the utility window will open with this resolution after connection. If accessing from a weak computer, you can set the resolution to low and sacrifice color depth.

“Local resources” – here, in order to save system resources, you can disable sound playback on the remote computer. Or, on the contrary, you can also install audio recording from a remote computer. In the column of local devices and resources, after clicking the “Details” button, we can, in addition to the active printer, select devices of the main computer that will work on the remote computer. These are smart cards, separate hard drive partitions, flash drives, memory cards, external hard drives.

An obstacle to using the RDP protocol may be its blocking by antiviruses. In this case, the RDP protocol must be enabled in the settings of antivirus programs.

Have a great day!

RDP - Remote Desktop Protocol

First of all, we will talk about StandAlone Server here. That is, about a separate server. And not about domain controllers and corporate networks. (highly qualified specialists are required there)

A situation when an idea came to your mind and you decided to bring it to life. And to implement it, you need to have a Server, which you rent in a certain data center.

You chose the appropriate tariff, paid the money, and now you already have a Server on which the software you need is installed. In most cases, Windows 2003 Server is sufficient for such pilot projects. Quite inexpensive and effective.

Technical support will give you an IP address, Login and Password for RDP access, and you begin your journey, full of... well, in general - it doesn’t seem like much.

By default, we can say that this service in Windows is configured to cause the user a lot of trouble and problems.

Although, of course, it works on its own and performs its function perfectly. But over time, (sometimes it may be too late) the careless owner of a remote server will be horrified to realize what is really going on with his system and what a crowd of bloodthirsty people is standing around the walls of his fortress.
It's like turning off the infrared filter on the DVR and suddenly starting to see video sources - traffic police cameras with photo recording, and signals from TV remote controls.

You begin to see and then, perhaps, understand.

On the one hand, software developers pretend that they are making their systems for the average person, and you begin to believe it.

But on the other hand, these same developers assume that only a certified specialist can pick up the keyboard. And so that the certificate is from this year.

Such is the paradox.

Let me tell you what it really looks like.

But in fact, hordes of hackers, after reading a dozen lines on forums, download ready-made lists of servers with an open RDP port. And they start breaking into your car. Some do it manually (but this is rare), but mostly with different programs, running brute-force dictionaries: login - password. And no one limits them in anything. They are even cramped there at times.

Moreover, I look at the logs and see that for the most part, these are the same dictionaries.

And your server is forced to fight back. And you don’t know. And you don’t understand why your performance is low, why requests take so long to complete.

You're thinking about great things. Strategically, about functionality. And here - some kind of brakes are incomprehensible.

Therefore, you will start optimizing memory, deleting temporary variables, defragmenting disks, etc.

And maybe even take a closer look at the Events tab in the management snap-in.

But I assure you that you will not see the reason there! Because attempts to enter incorrect login and password are not displayed there. Perhaps you will even argue with other people that they don’t break you because they are afraid or respected.
No. I assure you, the developers are just such funny guys. And initially they tip the scales slightly towards darkness. They say that if these events were displayed, the load on the server would be higher.
But, just note that the first thing everyone should do is turn on this display. Although, of course, there are certain technological systems completely closed from the outside world, where no one ever hacks anything. But there it is just such systems that serve entire teams of professionals.

So, let’s start by correcting this situation and bringing the system into normal working order.

What we will do:

We will limit the number of simultaneously open sessions allowed.
(If you administer your remote server yourself, why do you need someone other than you to manage the server at the same time as you?
Although, one more may be needed - for example, for technical support. And why more?)
And turn on the light. That is, we will allow the system to display unsuccessful login attempts in the “Events” snap-in.
And here you will be surprised.
We will prohibit access to the server from more than 3000 IP addresses, which, strictly speaking, do nothing else but cause problems for people. Importing the Black List.

If you, out of nothing to do, make requests on the network about setting up RDP, you will come across a lot of advice (and for a long time I myself was sure that they were very effective, until I decided to conduct an experiment)

Limit the number of failed login attempts allowed.
(If you are not drunk, then 3 times is enough for you to understand that the keyboard is in the wrong language and in the wrong register.)
Limit the time for these 3 attempts.
(You can do it 3 times a week, or you can do it 3 times a second, and multi-threaded too. And therefore, since none of the cool hackers poke at the keyboard with one finger for a long time selecting a letter, there is decent traffic there, which in 10 minutes, that the developers have determined will have time to sort out several hundred, a couple of thousand combinations.)
Set a blocking time for entry if you are drunk, or if you are not you.
(The default is 3 minutes, which won’t upset anyone. Let’s set it to half an hour. Let them get tired of waiting.)

I admit, I was very happy when I found such articles, and immediately did everything right. I was sure that now I could focus on the project itself and not worry too much about safety.

How there were tens of thousands of attempts during the day. (and I don’t sit with my head glued to the monitor all day, but I go in once a day to check the functionality of my applications) That’s how it remains.

And I still couldn’t understand how this could happen, so I see that I have 3 attempts configured and then blocked for 30 minutes. And this bot has been busy for six hours now, tirelessly sorting through logins from “Administrator” to “ferapont”.
But everything was not leisure. And then - I set everything up, so it should work!

Once, I had to transfer one of my projects from one server to another due to the failure of the RAID array. And the old server was available to me for some time, but on it I could without fear try to conduct dangerous and not so dangerous experiments. Therefore, I decided to check it out.

To do this, for several minutes I tried to log in with the wrong password, expecting that the authentication system would now block me. Figurines. Nothing happened.

I spent a couple of days studying this problem in more detail. I immersed myself in manuals and scant comments. Everyone assures us on the forums that this method is super effective.

And this is what I will tell you now:

firstly, this method only works under a domain controller (you don’t know what it is? Spit, you don’t need it) and for a standalone server you need to immerse yourself in special knowledge and learn spells.
secondly, it turns out, and apparently many mistakenly and naively assume otherwise (like myself), that when such a mechanism is implemented, the one who tries to enter will be blocked.
No - just not him. And you will be blocked!
Yes - it is your account that will be blocked for the time that you registered there. And you yourself will never be able to log into your own server!

When I leave the house and lock the door, I break the lock. I’ll frostbite my ears to spite Grandma.

But I think that parting with such illusions was worth a couple of days of torment.

We're done with the preamble. Let's get down to business.

1. We will limit the number of simultaneously open sessions allowed.

Find and open the “Terminal Services Configuration” snap-in:

In this snap-in, select and open the RDP-Tcp “properties” tab, where we limit “Msximum Connections” to 2x, for all network adapters.

Click OK. Now, only one more person can enter with you at the same time. And without you, everyone who wants to will have to stand in lines of two.
Get in line - sons of bitches!

2. Enable the display of unsuccessful login attempts in the “Events” snap-in.

Find and open the “Local Security Settings” snap-in and in it – the section: “Audit Policy”:

And change the property values of all “Audit” entries - as shown in the screenshot. You will then need to reboot for the changes to take effect.

You can wait and after a few hours look at the now real picture in order to understand what kind of world we live in and who really surrounds us.

3. We deny access to the server from 100% malicious IP addresses. Importing the Black List.

Here you have 2 options:

Fast and everything at once.
Manual, with an understanding of what exactly you are doing.

Fast way.

After which, you should get something like this:

Manual method, with understanding.

First, you need to create an additional policy. Open the “Local Security Settings” snap-in.
Select the “IP Security Policies on Local Computer” section and right-click: “Create IP Security Policy...” and launch the Configuration Wizard.
You come up with a name for the new Rule. For example: "Block IP".
Next, click on all the questions and in the end you will have a form for editing the properties of the Policy.
Add a new Rule. Click. and if the Wizard checkbox is checked, then another Wizard will launch, whose questions need to be answered.
Tunnel Endpoint. press
Network Type. “All network connections” is already there. press
IP Filter List.
Add a new Filter. Click and come up with a meaningful Name.

For example: Block brute forcing IP.
His list is still empty. We save it as is.

Quite often, many users who use remote access sessions have a question about how to change the RDP port. Now let's look at the simplest solutions, and also indicate several main stages in the setup process.

What is the RDP protocol for?

First, a few words about RDP. If you look at the decoding of the abbreviation, you can understand that remote access

In simple terms, this is a tool for a terminal server or workstation. Windows settings (and any version of the system) use default settings that suit most users. However, sometimes there is a need to change them.

Standard RDP port: should it be changed?

So, regardless of the modification of Windows, all protocols have a preset meaning. This is RDP port 3389, which is used to carry out a communication session (connecting one terminal to remote ones).

What is the reason for the situation when the standard value needs to be changed? First of all, only with ensuring the security of the local computer. After all, if you look at it, with a standard port installed, in principle, any attacker can easily penetrate the system. So now let's see how to change the default RDP port.

Changing settings in the system registry

Let us immediately note that the change procedure is carried out exclusively in manual mode, and the remote access client itself does not provide for any reset or installation of new parameters.

First, call the standard registry editor with the regedit command in the “Run” menu (Win + R). Here we are interested in the HKLM branch, in which we need to go down the partition tree through the terminal server directory to the RDP-Tcp directory. In the window on the right we find the PortNumber key. It is its meaning that we need to change.

We go into editing and see 00000D3D there. Many people are immediately perplexed about what it is. And this is simply a hexadecimal representation of the decimal number 3389. To indicate the port in decimal form, we use the corresponding line to display the value representation, and then specify the parameter we need.

After this, we reboot the system, and when trying to connect, specify a new RDP port. Another way to connect is to use the special command mstsc /v:ip_address:XXXXX, where XXXXX is the new port number. But that's not all.

Windows Firewall Rules

Unfortunately, the built-in Windows firewall may block the new port. This means that you need to make changes to the settings of the firewall itself.

Call up the firewall settings with advanced security settings. Here you should first select incoming connections and click on the line to create a new rule. Now we select the item to create a rule for the port, then enter its value for TCP, then allow the connection, leave the profiles section unchanged and finally assign a name to the new rule, after which we click the complete configuration button. All that remains is to reboot the server and, when connecting, specify the new RDP port through a colon in the appropriate line. In theory, there should be no problems.

Forwarding the RDP port on the router

In some cases, when you are using a wireless connection rather than a cable connection, you may need to forward the port on your router. There is nothing complicated about this.

First, in the system properties, we allow and indicate the users who have the right to do so. Then go to the router settings menu through the browser (192.168.1.1 or at the end 0.1 - it all depends on the router model). In the field (if our main address is 1.1), it is advisable to indicate the address, starting with the third (1.3), and write the rule for issuing the address for the second (1.2).

Then in network connections we use the details view, where you should view the details, copy the physical MAC address from there and paste it into the router parameters.

Now, in the NAT settings section on the modem, enable the connection to the server, add a rule and specify port XXXXX, which needs to be forwarded to the standard RDP port 3389. Save the changes and reboot the router (the new port will not be accepted without a reboot). You can check the connection on some specialized website like ping.eu in the port testing section. As you can see, everything is simple.

Finally, note that the port values are distributed as follows:

0 - 1023 - ports for low-level system programs;
1024 - 49151 - ports allocated for private purposes;
49152 - 65535 - dynamic private ports.

In general, many users usually select RDP ports from the third range of the list to avoid problems. However, both specialists and experts recommend using these values in the settings, since they are suitable for most of the tasks.

As for this particular procedure, it is used mainly only in cases of Wi-Fi connection. As you can already see, with a normal wired connection it is not required: just change the values of the registry keys and add rules for the port in the firewall.

Remote Desktop Services (RDS) in Windows Server 2008 R2 is not just a rebranding of its predecessor, Terminal Services. New features, some of which appeared in Windows Server 2008, such as RemoteApp, RD Gateway and RD Virtualization Host, make it possible to simply and conveniently deploy and operate both individual user applications and entire desktops in RDS and VDI solutions, and the functionality and the convenience is no worse than that of Citrix solutions or complexes from other vendors.

What about the security of Remote Desktop Services? Microsoft has significantly updated and strengthened the security of this service. In this article we will talk about RDS security mechanisms, ensuring the security of terminal services using group policies, and the practical aspects of ensuring the security of RDS solutions.

What's new in R2

If you have worked with versions of Terminal Services in Windows Server 2003 and Windows Server 2008, then you probably remember that Windows 2008 introduced a number of new features such as (connection via browser), (access Terminal Services over the Internet), (publishing individual applications via RDP) and service (providing load balancing).

Windows Server 2008 R2 introduced the following features:

Remote Desktop Virtualization for VDI solutions
RDS Provider for PowerShell (Admin can now manage RDS configuration and management from the command line or using scripts)
Remote Desktop IP Virtualization, which allows you to assign IP addresses to connections based on the parameters of the session or application being launched
New version of the RDP protocol and Remote Desktop Connection (RDC) client - v. 7.0
CPU resource management to dynamically allocate CPU resources based on the number of active sessions
Compatibility with Windows Installer, allowing you to install programs with the ability to further configure application settings on the user side.
Client-side support for up to 16 monitors.

In addition, the functions for working with video and audio, and full support for Windows Aero technology have been improved (note that Aero is not supported in multi-monitor mode).

Naturally, RDS security issues vary by solution. For example, if you publish a desktop to users connecting via the Internet or using a browser, then the security issue arises much more acutely than with the standard solution, where clients connect using an RDC client over a local LAN.

Network Level Authentication

To ensure greater security, Network Level Authentication (NLA) must be enabled for all connections. NLA requires the user to log in to the RD Session Host server even before the session is created. This mechanism allows you to protect the server from processing unnecessary sessions that can be generated by attackers or bot programs. In order to take advantage of NLA, the client operating system must support the Credential Security Support Provider (CredSSP) protocol, which means Windows XP SP3 () and higher, as well as an RDP client 6.0 or higher.

You can configure NLA on the RD Session server by opening the Administrative Tools -> Remote Desktop Services -> Desktop Session Host Configuration console.

Right click on connection
Select Properties
Go to the General tab
Check the option “Allow connections only from computers running Remote Desktop with Network Level Authentication”
Click OK.

Transport Layer Security (TLS)

An RDS session can use one of three security mechanisms to protect the connection between clients and the RDS Session Host server:

RDP security layer– built-in encryption of the RDP protocol is used, which is less secure.
Negotiate– TLS 1.0 (SSL) encryption will be used if supported by the client, if the client does not support it, the normal RDP security level will be used.
SSL– TLS 1. encryption will be used to authenticate the server and encrypt the transmitted data between the client and the server. This is the most secure mode.

To ensure a high level of security, you must use SSL/TLS encryption. For these purposes, you must have a digital certificate; it can be self-signed or issued by a CA (which is preferable).

In addition to the security level, you can select the connection encryption level. The following types of encryption are available:

Low– 56-bit encryption is used for data sent from the client to the server. Data transferred from the server to the client is not encrypted.
Client Compatible– this type of encryption is used by default. In this case, all traffic between the client and server is encrypted with the maximum key length that the client supports.
High– all data transmitted between the client and server in both directions is encrypted with a 128-bit key
FIPS Compliant– all data transmitted between the client and server in both directions is encrypted using the FIPS 140-1 method.

It is worth noting that if High or FIPS Compliant encryption levels are used, then all clients that do not support this type of encryption will not be able to connect to the server.

You can configure the server authentication type and encryption level as follows:

On the RD Session Host server, open the Remote Desktop Session Host configuration window and go to the properties window.
On the General tab, select the required security level and encryption type from the drop-down menus.
Click OK.

Group policies

There are a number of Group Policy options for configuring RDS settings in Windows Server 2008 R2. All of them are located in the Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services section (a screenshot of the Group Policy Management Console is shown in the picture).

As you can see, there are licensing management policies, RDC client configuration policies, and the RD Session Host server itself. RD Session Host security policies include:

Set Client Connection Encryption Level: The policy is used to control the level of encryption. If enabled, all connections must use the specified encryption level (default is High).
AlwaysPromptforPassworduponConnection: This policy is used if it is necessary to always ask for the user's password when connecting to an RD session, even if the password was entered in the RDC client. By default, users can be automatically logged into a session if they have provided a password in the RDC client.
RequireSecureRPCCommunication: — when the policy is enabled, only authenticated and encrypted requests from clients are allowed.
RequireUseofSpecificSecurityLayerforRemote (RDP) Connections: When the policy is enabled, all connections between the client and the terminal server must use the security level specified here (RDP, Negotiate, or SSL/TLS)
DoNotAllowLocalAdministratorstoCustomizePermissions: The policy disables the ability for administrators to configure RD Session Host security settings.
Require User Authentication for Remote Connections by using Network Level Authentication: The policy includes an NLA requirement for all connections to the terminal server (clients without NLA support will not be able to connect).

RDC client settings are located in the subsection RemoteDesktopConnectionClient:

Donotallowpasswordstobesaved: the policy prohibits saving passwords in the RDC client, the “Save password” option becomes unavailable, all previously saved passwords will be deleted.
SpecifySHA1 thumbprintsofcertificatesrepresentingtrusted.rdppublishers: This policy allows you to create a list of SHA1 certificate thumbprints, and if a certificate matches a thumbprint in this list, it is considered trusted.
Promptforcredentialsontheclientcomputer: The policy enables prompting for user credentials on the client computer rather than the RD Session server.

RD Web Access

Users on computers that do not have the RDC client installed can access published applications using a web browser. To do this, the user must open the URL in the browser where the RDS resources are published. The RD Web Access server is a separate role of the RD server and is usually located on a dedicated server.

The web interface of the RD Web Access server is based on the use of SSL and users can log in to it using their credentials. Authenticated users only see a list of published programs (RemoteApp) to which they have access.

The Web Access server uses an X.509 certificate for encryption. The default is a self-signed certificate.