- How to change the PowerShell prompt - Wed, Mar 22 2023
- Trim characters from strings in PowerShell - Tue, Mar 14 2023
- Set Chrome, Firefox and Edge as default mail client (mailto handlers) - Mon, Mar 6 2023
Windows 10 and Server 2016 and later offer a feature called Credential Guard, which protects credentials from theft. This is a feature of Microsoft's virtualization-based security and has only its name in common with the RDP protection discussed here.
Complement to Restricted Admin mode
Remote Credential Guard is another technique, in addition to Restricted Admin mode, that allows logging in to an RDP host without transmitting login credentials over the network. To do this, it redirects the Kerberos requests back to the client that wants to establish the connection.
In contrast, Restricted Admin mode uses the login credentials of a local administrator on the remote host. Accordingly, the protection of these accounts by means of LAPS is important there.
Restricted Admin mode does not send credentials to the host the user must have administrative rights there
As expected, while Remote Credential Guard only allows authentication using Kerberos, Restricted Admin mode also supports NTLM. Other differences between the two methods are as follows:
- As the name suggests, Restricted Admin mode requires that the user be a member of the Local Administrators group on the RDP server. Remote Credential Guard is suitable for all users as long as they are members of the Remote Desktop Users group on the host.
- Remote Credential Guard provides SSO for the locally logged-in user; authentication under other accounts is not possible. Restricted Admin mode does not have this limitation.
- If you want to access other network resources from the remote host, this is done in Restricted Admin mode under the remote computer's account. This results in a multihop problem if the computer account lacks the necessary permissions. Remote Credential Guard, on the other hand, always connects the users under their own identity.
- Restricted Admin mode is the older technology and was already available for Windows 7 or Server 2008 R2 (with a corresponding patch level). Remote Credential Guard, on the other hand, requires at least Windows 10 1607 or Server 2016 for both the client and the server. Furthermore, it only supports the traditional client mstsc.exe but not the UWP app.
Comparison of Remote Credential Guard and Restricted Admin mode
Since both technologies serve more or less the same purpose, the question arises as to whether Remote Credential Guard can replace Restricted Admin mode. However, as can be seen from the above comparison, the two technologies are suitable for different scenarios.
Therefore, depending on the requirements, you will choose one of the two options. For example, Microsoft does not recommend using Remote Credential Guard for remote support, where the helpdesk needs administrative privileges. In this case, if the user's PC is compromised, an attacker could abuse the RDP channel to connect on the user's behalf.
Enable Remote Credential Guard on the server
The feature must be configured separately for client and server. On the server, which can also be Windows 10 or 11, you need to create a key in the registry that also enables Restricted Admin mode. To do this, you can save the following code in a .reg file and execute it:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa] "DisableRestrictedAdmin"=dword:00000000
In managed environments, you will probably distribute the key centrally via Group Policy Preferences.
Activate Remote Credential Guard on the client using a GPO
There is a group policy for the client that not only activates Remote Credential Guard but also controls the interaction with Restricted Admin mode. It is called Restrict delegation of credentials to remote servers and can be found under Computer Configuration > Policies > Administrative Templates > System > Delegation of Credentials.
Group Policy setting for Remote Credential Guard management
The Restrict delegation of credentials option means that Remote Credential Guard is the preferred option, but if that is not available, then the connection is established using Restricted Admin mode.
The other two choices each specify one of the techniques and deny a connection if it cannot be used.
Starting Restricted Admin mode interactively
Using the above setting, admins can ensure that users can no longer establish RDP connections with insecure authentication. However, in environments where you want to use Remote Credential Guard on an ad hoc basis, you can enable it via a switch on the RDP client:
mstsc.exe /remoteGuard
For Restricted Admin mode, the switch /restrictedAdmin is provided.
If you start the session using Remote Credential Guard, you will see that you cannot change the user account in the RDP client. Instead, there is a single sign-on for the logged-in user; hence, you do not need to enter a password.
Remote Credential Guard allows connection to the host only through the locally logged on user
Conclusion
With Remote Credential Guard, Microsoft adds another method to secure RDP connections. It only uses Kerberos and requires newer versions of the operating system.
It is not always obvious for users to recognize which scenarios each of the two functions fits. Remote Credential Guard is primarily a big improvement for standard users, while Restricted Admin mode is only for system administration.
Subscribe to 4sysops newsletter!
However, if the prerequisites for either of the two techniques are not met, for example, because of the multihop problem with Restricted Admin mode, then resorting to the alternative method may help.
Hi Wolfgang.
I am using remote credential guard, but there’s a technical detail I don’t understand at all: imagine you have a domain user that may not logon anywhere, say, he may only logon to PC1 and PC2. But using mstsc /remoteguard, he may successfully connect from PC1 to PC3 (given that the registry key DisableRestrictedAdmin is set to 0 at PC3, else it does not work).
Why is that? Where’s the logic?
Hi Welf,
As far as I understand the logon happens at PC1, PC3 is merely allowed to use the Kerberos TGT which resides at PC1.
Hi Fabian.
Sure, that is how it works, but still, the PC you connect to should be able to ask the DC if that user is allowed to logon. In the meantime, I have contacted Microsoft, since it does not happen on Win11 insider builds, only on older stable builds. So far, Microsoft support is confused, talking of “Our engineering group is reviewing this…” but stopped reacting.
To me, this looks dangerous as it is not documented.
I have to correct myself: It does not occur if you use mstsc /remoteguard, but only when you set the policy to require remote credential guard at the client.