RDP is one of the most used protocols for managing servers and jumping around in the IT infrastructure environment. This is a 3-part series about how to protect it and use it with different delegation models.
This is part one where we look at how to configure SSO and use Restricted Admin mode and other technologies minimizing our credential exposure.

Network Level Authentication
Lets start with Network Level Authentication (NLA) which should be enabled on all servers.

As per MS documentation: Configure Network Level Authentication for Remote Desktop Services Connections

Network Level Authentication completes user authentication before you establish a remote desktop connection and the logon screen appears. This is a more secure authentication method that can help protect the remote computer from malicious users and malicious software. The advantages of Network Level Authentication are:

• It requires fewer remote computer resources initially. The remote computer uses a limited number of resources before authenticating the user, rather than starting a full remote desktop connection as in previous versions.
• It can help provide better security by reducing the risk of denial-of-service attacks.

Another thing that should be mentioned is that it also provides protection against Man In The Middle (MITM) attacks. With Kerberos or TLS it can perform a mutual authentication verifying the servers identity as well.

Note: you can read more about NLA and MITM protection at: Configuring Terminal Servers for Server Authentication to Prevent “Man in the Middle” Attacks

NLA was introduced in Windows Vista and Windows Server 2008 and is default enabled.
It can also be set via Group Policy:
Computer Configuration/Policies/Administrative Templates/ Windows Components/Remote Desktop Services/Remote Desktop Session Host/Security
Enable: Require user authentication for remote connections by using Network Level Authentication

This should be enabled to all servers with RDP enabled.

Computer Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Connection Client
Enable: Configure server authentication for client and in the drop-down menu choose “Do not connect if authentication fails” for the strongest option.

This should be enabled on all RDP clients.

In a RDP session, this can also be verified in the session menu if you click on the padlock icon, you should get a dialog box stating the server has been verified.

Restricted admin mode

One problem when you jump around on different servers with RDP is that you will expose your credentials on each server you land on. Since you are performing a remote interactive logon your credentials will end up in LSASS and you will have Kerberos TGT and other tickets as well.
If that machine the admins land on is owned by a malicious user, he can easily steal the credentials and maybe gain access to new systems he wasn’t in possession of.

To protect against lateral movement, pass the hash and pass the ticket Microsoft introduced Restricted Admin Mode (RDPRA) in Windows 8.1 and Windows Server 2012R2. This is also backported down to Windows 7 and Windows Server 2008R2 to being able to initiate and receive RDPRA.

See kb: 2984972, 2984976, 2984981, 2973501

When a user jumps to a server with RDPRA it performs a context switch and you land on the server with the servers identity.
If we use whoami /user /groups /priv it will look ordinary.

My demo user Fox is a Domain Admin and if he hasn’t logged on with RDPRA he will be able to browse the Domain Controller C: drive:

But when he has connected with RDPRA he won’t be able to do that anymore since it will be in the servers context:

We can check the Kerberos tickets with klist.exe and compare with two different servers where he is logged on with and without RDPRA:

Without RDPRA Client is fox @ DEMO.SECID.SE:

With RDPRA Client is SRV01$ @ DEMO.SECID.SE:

And just to make sure, we can use Mimikatz and dump the credentials and we will see that Fox has the server credentials:

To enable and use this the user needs to be a local administrator on the server he will RDP to. We also need to create a new DWORD value in the registry on the server. This can be done via Group Policy or just run:
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

If DisableRestrictedAdmin has the value 0, it will be enabled. If its 1 it will be disabled.

And if you want to disable the possibility for the user to connect to network resources you can create a DWORD value in the same location on the server:
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdminOutboundCreds /d 1 /t REG_DWORD

If DisableRestrictedAdminOutboundCreds is set to 0 it will allow outbound connections in the servers context. If it is set to 1 this will be denied.

Now the users only need to start the RDP client with the restricted admin switch:
mstsc /restrictedadmin and we will see that the username is greyed out and you will get a SSO experience.

In this case I want this to be mandatory for all my admins and to have this as default we can enable it via Group Policy on the client computers:

Computer Configuration/Policies/Administrative Templates/System/Credentials Delegation
Enable: Restrict delegation of credentials to remote servers
and choose: Use the following restricted mode: Require Restricted Admin

Now when a user start the RDP client it will always use RDPRA.

The Client computer

Now when we have protected the credentials on the remote server we will take a look at the client.
The first thing people starts with is using a regular user account for daily work, e-mailing, internet browsing and so on. Then they have a separate admin account they use when performing administrative tasks on the system. The starting point of where that account is used the credentials will be exposed in different ways.

The best start would be to introduce a PAW model with special workstations for administrators, separating the User and Admin accounts to different computers.

Note: you can read more about the PAW model at: Privileged Access Workstations

This way we have a good disconnect and only expose our admin credentials on that machine. It is recommended to use Windows 10 and take advantage of Credential Guard and other technologies. If we have older workstations what can we do to protect them? To make this as strong as possible we can take advantage of a group which was introduced in Active Directory on Windows Server 2012R2.

Protected Users group:
Protected users was introduced in Windows 8.1 and Windows Server 2012R2. When a 2012 R2 Domain Controller has the PDC Emulator role, the group will be created in the domain.
When a user is member of this group a few things happen on the DC side and the Client side.

DC side protection
If the Domain Functional Level is Windows Server 2012R2 this applies on the DCs when a user authenticates:

• Authenticate with NTLM authentication is denied
• Use DES or RC4 encryption types in Kerberos pre-authentication is denied
• Be delegated with unconstrained or constrained delegation is denied
• Renew the Kerberos TGTs beyond the initial four-hour lifetime is denied

Client side protection
When a user logon a client/server the following applies:

• Default credential delegation (CredSSP). Plain text credentials are not cached even when the Allow delegating default credentials Group Policy setting is enabled
• Windows Digest. Plain text credentials are not cached even when Windows Digest is enabled
• NTLM. The result of the NT one-way function, NTOWF, is not cached
• Kerberos long-term keys. The keys from Kerberos initial TGT requests are typically cached so the authentication requests are not interrupted. For accounts in this group, Kerberos protocol verifies authentication at each request
• Sign-in offline. A cached verifier is not created at sign-in

With users in this group we force them to use Kerberos with strong ciphers and the NTLM hash won’t be stored in LSASS mitigating pass the hash. This is a strong protection and needs to be evaluated if it’s possible to use. The client side protection was also backported to Windows 7 and Windows Server 2008R2 with the same patches as for RDPRA.

Note: you can read more about this patches at: An Overview of KB2871997

With my demo user Fox we can verify that the NTLM hash is missing when he is a member of the Protected Users group:

Authentication Id : 0 ; 3987041 (00000000:003cd661)
Session : RemoteInteractive from 7
User Name : fox
Domain : DEMO
Logon Server : DC01
Logon Time : 2017-06-10 21:55:30
SID : S-1-5-21-3853762650-1621689003-1095148016-1114
msv :
tspkg :
wdigest :
kerberos :
ssp :
credman :

And also, compare with another user danne which isn’t member of that group:

Authentication Id : 0 ; 4379518 (00000000:0042d37e)
Session : Interactive from 0
User Name : danne
Domain : DEMO
Logon Server : DC01
Logon Time : 2017-06-10 22:02:40
SID : S-1-5-21-3853762650-1621689003-1095148016-1105
msv :
[00000003] Primary
* Username : danne
* Domain : DEMO
* NTLM : 46ba1790939cb60f3eadf0cd5cd77015
* SHA1 : 3b4e6dc93402f0ff93b9ad135d698271c69d3d6c
* DPAPI : 16b2839b69078b4740ac1869c44b477e
tspkg :
wdigest :
* Username : danne
* Domain : DEMO
* Password : (null)
kerberos :
* Username : danne
* Domain : DEMO.SECID.SE
* Password : (null)
ssp :
credman :

With this in combination with RDPRA were starting to build a strong protection model with built-in tools. Since we’re using SSO when connecting RDP we get a protection against key loggers as well. Key loggers are a simple but powerful tool that often is used by malicious users and it works well. That is also a reason to have a separate admin workstation so you don’t need to expose admin credentials by using runas or jumping to a server with another account directly from the ordinary workstation.

Note: this is just some techniques to protect against credential theft and depending on OS versions other things should be implemented as well. E.g. RunAsPPL, Authentication Policy and Silos, AMA etc.

Speaking of SSO and RDP, what happens when we use Remote Desktop Gateway?

Remote Desktop Gateway

The last thing I would like to share in this post is about Remote Desktop Gateway (RDGW).
With RDGW we can better control the RDP traffic in the network. If we configure the servers to only allow RDP traffic from the RDGW we have only one way in to the servers with our RDP traffic. In the RDGW we can dictate who can connect to the gateway, from which machine and to which machines. We can also control if MFA is required. With this we can also easily monitor the connections from a central point.

I will cover more about how you can configure and use RDGW in part two of this series. Now we will just assume we have RDGW in our environment with the most basic configuration.

In the RDP client we can navigate to the Advanced tab and klick on the Settings button in the Connect from anywhere category.

Here we can mark the radio button Use these RD Gateway server settings and configure RDGW server to use and choose logon settings.

The problem with this is that when connecting to the RDGW you will get a logon prompt for you username and password, even if your using RDPRA.

The only option you had was the box “Use my RD Gateway credentials for the remote computer”. On my admin workstations, I want to use my current logged on user credentials and take advantage of SSO minimizing the exposure of my password.

Luckily this can be done with Group Policy:

User Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/RD Gateway
Enable: Set RD Gateway authentication method
Clear the checkbox: Allow users to change this setting
Set RD Gateway authentication method: Use locally logged-on credentials

And in the same category we can also enable the policy Set RD Gateway server address and configure the RDGW address for the users.

If we take a look at the client after the policy settings has been applied for the users it looks a little different:

And this is really nice. My admin users are now members of the Protected Users group, is forced to use RDPRA via RDGW and everything is Kerberos SSO.
I have the 4 hours tickets on my client:

In the next post, I will cover an interesting delegation model taking advantage of RDGW and RDPRA.